相对设计和开发来说，测试工程师是产品经理接触较少的一类人群，因为测试人员往往也是躲在项目幕后，默默地奉献着自己，确保产品能够正常运行。产品测试是很重要的一个环节，目前所有的互联网公司都有测试工程师，他们是产品上线的最后一环，对公司和用户负责，他们的定位是产品把关者，颇有点像一座城市内的保卫人员，守护着一座城市的宁静和安全。

产品经理虽然与测试接触的少，但仍然需要了解测试工程师具体的一些工作内容，以及测试相关的一些知识，这样可以更好的处理好工作。比如在和测试沟通需求的时候，测试人员会说单元测试通过了吗，或者说黑盒测试、白盒测试，这些测试上的名词，如果你懂的话，那么沟通起来就会很顺畅，你就不会一脸懵逼的状态，而能够把产品需求和问题向测试人员传达的非常清楚。

测试定义及相关的方法、概念

目前普遍使用行业标准IEEE/ANSI的测试定义：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。目的是为了检验软件系统是否满足需求。

从测试方法来说，测试主要可以分为两类：黑盒测试和白盒测试。

1、黑盒测试

也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

优点 ：

1) 比较简单，不需要了解程序的内部的代码及实现

2) 与软件的内部实现无关

3) 从用户的角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题

4) 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能

5) 在做软件自动化测试时较为方便

缺点 ：

1) 不可能覆盖所有的代码， 覆盖率较低，大概只能达到总代码量的30%

2) 自动化测试的复用性较低。

2、白盒测试

又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据，贯穿程序的独立路径数是天文数字。白盒测试一般需要技术基础支持，同时需要相关工具配合，比如日志抓取工具。

优点 ：

1) 帮助软件测试人员增大代码的覆盖率，提供代码的质量评估，发现代码中隐藏的问题

缺点 ：

1) 程序运行会有很多不同的路径，不可能测试所有的运行路径

2)测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求

3) 系统庞大时，测试开销会非常大。

当然，无论是黑盒测试还是白盒测试，都必须要写测试用例，黑盒的测试用例技术设计有三种：边界值分析、等价类划分、错误推测法；白盒的测试用例技术包括逻辑覆盖和基本路径测试。

常见的一些测试概念：

单元测试：又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。

集成测试：也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。

系统测试：通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

兼容性测试：主要测试软件是否能在不同的操作系统平台上兼容，是否能在不同的设备上兼容；软件本身能否向前或向后兼容；软件能否与其他相关的软件兼容；数据是否兼容，主要是指数据能否共享等。

性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

回归测试：修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

测试人员的相关岗位职责

其实，在我看来，一个优秀的测试工程师  =  半个产品  +  半个开发 。既要求测试对产品有足够的了解，包括业务目标、内部逻辑和界面显示，这也是产品测试的基础；也要了解部分开发代码，能够对代码质量做出评估，并且给开发提供优化方案。

通常来说，测试工程师的主要职责分以下几部分：

1.编写测试计划、规划详细的测试方案、编写测试用例。

2. 根据测试计划搭建和维护测试环境;

3. 执行测试工作，提交测试报告。包括编写用于测试的自动测试脚本，完整地记录测试结果，编写完整的测试报告等相关的技术文档，;

4.对测试中发现的问题进行详细分析和准确定位，与开发人员讨论缺陷解决方案。

5.对测试结果进行总结与统计分析，对测试进行跟踪，并提出反馈意见。

产品经理在了解了测试人员的相关岗位职责后，才能更好地理解对方提出问题及建议的出发点。所以，很多测试工程师都有一句口头禅：你这样做是不对的......在大家讨论的热火朝天的时候，有一个理性又冷静的旁观者来控制事情的走势，也是整个项目得以健康发展关键因素。

产品经理如何与测试人员沟通

产品经理想要顺畅地和测试人员沟通，最重要的其实还是了解测试思维，了解测试的流程是怎样的。

其中，测试用例恐怕是产品经理与测试人员打交道最多的地方了，测试用例主要是测试人员根据PRD、UI设计稿来进行编写，通过需求文档了解需求背景，目标用户、使用场景、用户目标，通过流程图、原型图了解功能需求，站在用户角度和业务角度去思考，尽可能地覆盖全面使用路径。

测试用例编写之前，产品经理应该给测试工程师们好好宣讲宣讲产品，把产品建设的来龙去脉简单介绍一下，包含产品定位、目标用户、主要的使用场景、解决用户的什么痛点等等；然后还需要把每一个大的功能模块给讲清楚，比如核心操作流程、业务逻辑、用户的使用场景、目标之类的；最后，要告知产品主要是在什么系统、平台运行，有没有调用外部接口等等；

经过了这么一番详细的介绍，测试人员才能更好地理解产品目标、编写测试用例，产品经理也能借助测试人员的经验更好地进行测试验收产品。

编写完测试用例之后，我们就可以根据测试用例来逐项测试产品，并根据测试的结果填写测试用例表格，并根据预期结果和测试结果的差异，填写是否存在缺陷，并反馈给开发人员进行跟进和修改。