文章主要涉及产品经理工作上经常接触到的基础的测试知识，包括测试的定义、测试何时进行、产品经理应该懂的测试概念、产品经理如何测试验收产品。
作者：铅笔小葵
为什么产品需要懂测试
产品每个阶段都有验收标准，比如需求评审阶段验收、开发阶段验收，所以每个阶段都需要测试。产品经理尽管不是专业的测试人员，但
产品经理作为最熟悉产品的人，理应对产品每个阶段都进行相应的测试验收产品
，比如功能测试、可用性测试、用户体验测试，确保符合需求文档的要求，所以产品经理应该懂得相应的测试知识。
产品经理懂测试，在相应的测试方式中验收产品的时候，能更清楚的系统地记录产品的每个问题，然后用产品思维去思考如何解决这些问题。
可以用极简主义去思考如何把选择复杂的问题简单化减少用户的选择，比如刻意显示引导用户选择的功能按钮或隐藏用户很少用到的功能，比如微信用户很少用到的朋友圈停用的功能，使用路径刻意加深隐藏。
可以用可用性原则的思维去思考如何去引导用户更好的完成产品使用，比如页面说明该页面所处的位置状态，比如微信的朋友圈页面顶部显示朋友圈的位置说明。
可以用情感化设计的思维去思考如何超出用户的期望，比如微信聊天窗口发送我想你了会落下满天星星的效果超出用户的期望。
可以用可行性的思维去思考如何用现有的资源解决产品的问题，比如前端工程师人数少的情况下可以直接借助前端开源框架快速开发MVP，比如借助bootstrap。
还可以去和开发人员沟通如何解决app使用卡顿启动难加载缓慢等产品本身的性能问题，比如使用网易新闻app滑动时卡顿，开发人员会告诉你其中的一个原因是因为每个页面上承受的控件过多，app一个页面看起来的效果是一个平面，但app中一个页面的组成由webview或者文本框等多个控件布局叠加的，控件过多会占用内存，导致使用卡顿，这时你可以思考如何去平衡控件数量和卡顿体验问题。
所以
懂得测试，产品经理能更好地沟通，能更好地测试验收产品确保符合产品需求文档，能更好地解决和优化产品。
产品经理不应该只为一个产品设计而不为一个产品测试。
补充说明：
网易新闻app使用卡顿的原因之控件
以android为例，首先打开显示布局边界，在开发者选项里可以找到显示布局边界，打开。然后再打开网易新闻，你会看到界面布满各种边界；每个边界都是一个控件，控件可以包括控件，所以你会看到大边界包括小边界。如下图所示：
当然有些为了使用流畅度，会采用webview控件，就相当于调用一个网页显示内容的控件；但是也影响使用用户体验，内容加载慢，目前利用cache缓存技术提供离线功能，预加载。新闻详情的大边界就是一个webview，如下图所示：
一些建议：
原生UI应用场景：
webview的HTML5页面应用场景：
测试的定义
测试，顾名思义就是
测试程序保证其可正确运行
。而早期的测试定义就是如此，即对程序能够按预期运行建立起一种信心。
随着技术的发展，目前测试的经典定义是：
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
即运行程序发现错误。
目前普遍使用行业标准IEEE/ANSI的测试定义：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。目的是为了检验软件系统是否满足需求。
从以上我们可以看出，不管怎么定义，测试既需要程序能符合需求文档的要求运行，也不能产生错误，测试可以归为两点：
-
程序做了它应该做的事情；
-
程序没有做它不该做的事情。
注意：
软件测试不等于程序测试，测试的对象包括文档、数据、程序。
测试何时进行
我们看看一张发现缺陷的时间和缺陷修复成本的关系图，下图中，横轴表示项目开发周期时间阶段，纵轴表示缺陷占比。如下图所示：
从图中，我们可以看出越后期修复缺陷的成本就越高，且指数增长，而缺陷主要是开发前期引入的，且前期缺陷修复成本很低，所以我们应该知道，测试越早越好。
前面说过，测试的对象包括文档、数据、程序，即测试贯穿软件开发开发周期，从需求开始到编码到验收测试结束，包括但不限于对需求、概要设计、详细设计、源码、可运行程序、运行环境的测试。所以，
产品经理应该从需求开始阶段就进行测试产品。
当然，专门的测试人员也应该从需求开始阶段就参与测试，
产品的相关人员越早参与进来，对产品的需求理解就越透彻，还可以对需求二次分析补充。
当然这里我们主要讲产品程序可运行后的相关测试，毕竟编码前的需求评审、原型、UE、UI的测试，这是每个产品经理必须具备的技能，编码期间的单元测试集成测试主要是开发人员实施，所以我们主要是讨论产品程序可运行后的相关测试。
产品程序可运行后开发人员交付build给产品经理和测试人员的测试流程一般为用例测试
（是否符合需求文档）
、探索测试
（是否存在隐患bug）
、其他测试
（兼容性、安全性……）
。
补充说明：编码前的需求评审、原型、UE、UI的测试重点：
-
需求评审：
定位、用户画像、说明规则是否明确；
-
原型：
页面是否完整，信息架构是否清晰；
-
UE：
业务流程是否舒适；
-
UI：
视觉设计是否干净，风格是否一致；
这些编码前的测试一定要验收，因为会直接影响到产品开发的后续，比如UI测试的视觉设计，直接影响到目标产品的整个生命周期的视觉效果。
应该懂的测试概念
产品经理和测试人员沟通需求或者反馈产品的bug时，经常听到测试人员说的脚本录制及自动化测试的一些
（测试概念上）
名词，经常会说什么这个功能模块采用黑盒测试的流程分析法就知道bug的位置了，这个时候产品经理就懵逼，感觉沟通不下去了，产品做不下去了。
产品经理懂得岗位的相关上下游知识，可以更好的处理好工作，比如和测试人员沟通需求时，测试人员会说文档测试通过了吗，或者说这个等到集成测试后再系统测试验证这个问题吧，这些测试上的名词，如果你懂的话，那么沟通起来就会很顺利，你就不会去问什么是文档测试，什么是集成测试，既节约时间，更主要可以让产品的相关人员都能清楚地理解需求。
所以，这里我们讲讲产品经理一般接触到的测试概念。
测试一般是随着项目开发周期进行，根据开发模型对应相应的测试模式，比如瀑布开发模型的测试模式。测试分类有多个维度分类，比如根据测试阶段、测试手段、测试模块的维度分类，每个测试分类都有相应的测试办法，比如系统测试、白盒测试、黑盒测试、自动化测试。
目前，我们最常用的开发模型是V模型，如下图所示：
所以我们主要是根据V模型讲讲解测试知识。
▍测试分类
V模型是按测试阶段来分类测试，分为单元测试、集成测试、系统测试、验收测试，这也是根据开发进度进行的测试分类。
单元测试
又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。由开发人员实施，用以检验所开发的代码功能符合设计要求。单元测试是其他测试的基础，单元测试用例代码和函数一对一，便于维护和实现条件覆盖与路径覆盖，可以尽早发现缺陷和利于重构，但一行代码需要3-5行测试代码才能完成单元测试，支出较大，典型的空间换取利益，所以需要权衡。
单元测试有相应的测试框架，比如Xunit、Junit、PHPunit。我们平时接触的敏捷开发比较强调TDD
（测试驱动开发）
，即在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。这样能保证功能代码的正确性，也能保证对需求的二次确认和理解，对需求设计有个清晰的认识。
集成测试
也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。
集成测试的主要实施方案：一次性集成方法
（big bang）
，即一次性把所有模块组装起来测试；增殖式集成方式，即一个个模块持续集成测试，最后把所有模块组装起来。
系统测试
通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
系统测试的目的在于通过与系统
（软件）
的需求定义作比较， 发现软件与系统
（软件）
的定义不符合或与之矛盾的地方。即把可运行的软件安装在真实环境下操作使用，测试软件的功能和性能，比如某功能能否正常运行，软件在该平台下能否正常运行。
系统测试主要是从业务角度验证产品是否符合需求文档，所以，产品经理测试产品是否符合需求文档和设计的要求，一般都是在系统测试阶段。当然，测试人员主要针对的也是系统测试阶段。
验收测试
也称交付测试，以用户为主的测试，由用户参加设计测试用例，使用生产中的实际数据进行测试，确定软件是否满足验收标准，是否接受系统软件。
验收测试驱动开发，是TDD的延伸，也就是定义好用户故事，验收标准，再去开发功能，功能通过验收标准，功能满足用户故事。
▍有关功能测试
从上面的定义，我们知道产品经理测试验收产品一般是在系统测试阶段，系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、兼容性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度
（功能流程&业务流程、数据处理&业务数据处理）
