产品经理必备干货：周全具体的产品测试常识

1、写在前面

文章紧张涉及产品经理事情上常常打仗到的根本的测试知识，包括测试的定义、测试何时进行、产品经理该当懂的测试观点、产品经理如何测试验收产品。

2、为什么产品经理须要懂测试

产品每个阶段都有验收标准，比如需求评审阶段验收、开拓阶段验收，以是每个阶段都须要测试。

产品经理只管不是专业的测试职员，但产品经理作为最熟习产品的人，理应对产品每个阶段都进行相应的测试验收产品，比如功能测试、可用性测试、用户体验测试，确保符合需求文档的哀求，以是产品经理该当懂得相应的测试知识。

产品经理懂测试，在相应的测试办法中验收产品的时候，能更清楚的系统地记录产品的每个问题，然后用产品思维去思考如何办理这些问题。

可以用极简主义去思考如何把选择繁芜的问题大略化减少用户的选择，比如刻意显示勾引用户选择的功能按钮或隐蔽用户很少用到的功能，比如微信用户很少用到的朋友圈停用的功能，利用路径刻意加深隐蔽。

可以用可用性原则的思维去思考如何去勾引用户更好的完成产品利用，比如页面解释该页面所处的位置状态，比如微信的朋友圈页面顶部显示朋友圈的位置解释。

可以用情绪化设计的思维去思考如何超出用户的期望，比如微信谈天窗口发送我想你了会落下满天星星的效果超出用户的期望。

可以用可行性的思维去思考如何用现有的资源办理产品的问题，比如前端工程师人数少的情形下可以直接借助前端开源框架快速开拓MVP，比如借助bootstrap。

还可以去和开拓职员沟通如何办理app利用卡顿启动难加载缓慢等产品本身的性能问题，比如利用网易新闻app滑动时卡顿，开拓职员会见告你个中的一个缘故原由是由于每个页面上承受的控件过多，app一个页面看起来的效果是一个平面，但app中一个页面的组成由webview或者文本框等多个控件布局叠加的，控件过多会占用内存，导致利用卡顿，这时你可以思考如何去平衡控件数量和卡顿体验问题。

以是懂得测试，产品经理能更好地沟通，能更好地测试验收产品确保符合产品需求文档，能更好地办理和优化产品。

产品经理不应该只为一个产品设计而不为一个产品测试。

补充解释：网易新闻app利用卡顿的缘故原由之控件

以android为例，首先打开显示布局边界，在开拓者选项里可以找到显示布局边界，打开。
然后再打开网易新闻，如下图，你会看到界面布满各种边界，每个边界都是一个控件，控件可以包括控件，以是你会看到大边界包括小边界。
如下图所示：

当然有些为了利用流畅度，会采取webview控件，就相称于调用一个网页显示内容的控件，但是也影相应用用户体验，内容加载慢，目前利用cache缓存技能供应离线功能，预加载。
新闻详情的大边界便是一个webview，如下图所示：

一些建议：

原生UI运用处景：

流畅度体验哀求高的UI样式相对固定交互繁芜

webview的HTML5页面运用处景：

活动运营的页面需求，可重复调用交互大略

3、测试的定义

测试，顾名思义便是测试程序担保其可精确运行。
而早期的测试定义便是如此，即对程序能够按预期运行建立起一种信心。
随着技能的发展，目前测试的经典定义是，在规定的条件下对程序进行操作，以创造程序缺点，衡量软件质量，并对其是否能知足设计哀求进行评估的过程。
即运行程序创造缺点。

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

从以上我们可以看出，不管怎么定义，测试既须要程序能符合需求文档的哀求运行，也不能产生缺点，测试可以归为两点：程序做了它该当做的事情；程序没有做它不该做的事情。

把稳，软件测试不即是程序测试，测试的工具包括文档、数据、程序。

4、测试何时进行

我们看看一张创造毛病的韶光和毛病修复本钱的关系图，下图，个中，横轴表示项目开拓周期韶光阶段，纵轴表示毛病占比。
如下图所示：

从图中，我们可以看出越后期修复毛病的本钱就越高，且指数增长，而毛病紧张是开拓前期引入的，且前期毛病修复本钱很低，以是我们该当知道，测试越早越好。

前面说过，测试的工具包括文档、数据、程序，即测试贯穿软件开拓开拓周期，从需求开始到编码到验收测试结束，包括但不限于对需求、概要设计、详细设计、源码、可运行程序、运行环境的测试。
以是，产品经理该当从需求开始阶段就进行测试产品，当然，专门的测试职员也该当从需求开始阶段就参与测试，产品的干系职员越早参与进来，对产品的需求理解就越透彻，还可以对需求二次剖析补充。

当然这里我们紧张讲产品程序可运行后的干系测试，毕竟编码前的需求评审、原型、UE、UI的测试，这是每个产品经理必须具备的技能，编码期间的单元测试集成测试紧张是开拓职员履行，以是我们紧张是谈论产品程序可运行后的干系测试。

产品程序可运行后开拓职员交付build给产品经理和测试职员的测试流程一样平常为用例测试（是否符合需求文档）、探索测试（是否存在隐患bug）、其他测试（兼容性、安全性……）。

补充解释：编码前的需求评审、原型、UE、UI的测试重点：

需求评审：定位、用户画像、解释规则是否明确；原型：页面是否完全，信息架构是否清晰；UE：业务流程是否舒适；UI：视觉设计是否干净，风格是否同等；

这些编码前的测试一定要验收，由于会直接影响到产品开拓的后续，比如UI测试的视觉设计，直接影响到目标产品的全体生命周期的视觉效果。

5、产品经理该当懂的测试观点

产品经理和测试职员沟通需求或者反馈产品的bug时，常常听到测试职员说的脚本录制及自动化测试的一些测试观点上名词，常常会说什么这个功能模块采取黑盒测试的流程剖析法就知道bug的位置了，这个时候产品经理就懵逼，觉得沟通不下去了，产品做不下去了。

产品经理懂得岗位的干系高下游知识，可以更好的处理好事情，比如和测试职员沟通需求时，测试职员会说文档测试通过了吗，或者说这个等到集成测试后再系统测试验证这个问题吧，这些测试上的名词，如果你懂的话，那么沟通起来就会很顺利，你就不会去问什么是文档测试，什么是集成测试，既节约韶光，更紧张可以让产品的干系职员都能清楚地理解需求。

以是，这里我们讲讲产品经理一样平常打仗到的测试观点。

测试一样平常是随着项目开拓周期进行，根据开拓模型对应相应的测试模式，比如瀑布开拓模型的测试模式。
测试分类有多个维度分类，比如根据测试阶段、测试手段、测试模块的维度分类，每个测试分类都有相应的测试办法，比如系统测试、白盒测试、黑盒测试、自动化测试。

目前，我们最常用的开拓模型是V模型，如下图所示：

以是我们紧张是根据V模型讲讲解测试知识。

V模型是按测试阶段来分类测试，分为单元测试、集成测试、系统测试、验收测试，这也是根据开拓进度进行的测试分类。

单元测试：又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行精确性考验的测试事情。
其目的在于创造各模块内部可能存在的各种差错。
由开拓职员履行，用以考验所开拓的代码功能符合设计哀求。
单元测试是其他测试的根本，单元测试用例代码和函数一对一，便于掩护和实现条件覆盖与路径覆盖，可以尽早创造毛病和利于重构，但一行代码须要3-5行测试代码才能完成单元测试，支出较大，范例的空间换取利益，以是须要权衡。

单元测试有相应的测试框架，比如Xunit、Junit、PHPunit。
我们平时打仗的敏捷开拓比较强调TDD（测试驱动开拓），即在开拓功能代码之前，先编写单元测试用例代码，测试代码确定须要编写什么产品代码。
这样能担保功能代码的精确性，也能担保对需求的二次确认和理解，对需求设计有个清晰的认识。

集成测试：也称联合测试，将程序模块采取适当的集成策略组装起来，对系统的接口及集成后的功能进行精确性检测的测试事情。
其紧张目的是检讨软件单位之间的接口是否精确，集成测试的工具是已经经由单元测试的模块。

集成测试的紧张履行方案：一次性集成方法（big bang），即一次性把所有模块组装起来测试；增殖式集成办法，即一个个模块持续集成测试，末了把所有模块组装起来。

系统测试：通过确认测试的软件，作为全体基于打算机系统的一个元素，与打算机硬件、外设、某些支持软件、数据和职员等其它系统元素结合在一起，在实际运行环境下，对打算机系统进行一系列的组装测试和确认测试。
系统测试的目的在于通过与系统（软件）的需求定义作比较， 创造软件与系统（软件）的定义不符合或与之抵牾的地方。
即把可运行的软件安装在真实环境下操作利用，测试软件的功能和性能，比如某功能能否正常运行，软件在该平台下能否正常运行。

系统测试紧张是从业务角度验证产品是否符合需求文档，以是，产品经理测试产品是否符合需求文档和设计的哀求，一样平常都是在系统测试阶段。
当然，测试职员紧张针对的也是系统测试阶段。

验收测试：也称交付测试，以用户为主的测试，由用户参加设计测试用例，利用生产中的实际数据进行测试，确定软件是否知足验收标准，是否接管系统软件。

验收测试驱动开拓，是TDD的延伸，也便是定义好用户故事，验收标准，再去开拓功能，功能通过验收标准，功能知足用户故事。

从上面的定义，我们知道产品经理测试验收产品一样平常是在系统测试阶段，系统测试紧张包括功能测试、界面测试、可靠性测试、易用性测试、兼容性测试、性能测试。
功能测试紧张针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。
个中功能测试是最紧张的一种测试类型，一样平常说测试便是功能测试。

功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检讨产品是否达到用户哀求的功能。
测试职员会借助一些功能测试工具，比如QTP winrunner，紧张是测试业务流程。

界面测试：也称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否同等、各个控件的放置位置是否符合客户利用习气，此外还要测试界面操作便捷性、导航大略易懂性，页面元素的可用性，界面中笔墨是否精确，命名是否统一，页面是否都雅，笔墨、图片组合是否完美等。

可靠性测试：对软件或者硬件的一种质量测试，用来检测产品是否存在不可靠成分，比如硬件老化。

易用性测试：指用户利用软件时是否觉得方便，紧张特点为易理解性、易学性、易操作性、吸引性、易用的允从性，比如是否最多点击鼠标三次就可以达到用户的目的。
易用性和可用性存在一定的差异，可用性是指是否可以利用，强调软件可运行性，而易用性是指是否方便利用，强调用户体验，是交互的适应性、功能性和有效性的集中表示。

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

推举个网页跨平台浏览器兼容性测试网址http://browsershots.org/有兴趣的产品经理可以理解。

性能测试：通过自动化的测试工具仿照多种正常、峰值以及非常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。
通过负载测试，确定在各种事情负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变革情形。
压力测试是通过确定一个别系的瓶颈或者不能接管的性能点，来得到系统能供应的最大做事级别的测试。

性能测试紧张分为：

运用在客户端性能的测试：紧张并发性能测试，利用自动化工具通过仿照成百上千用户重复实行和运行运用进行黑盒测试，比如loadrunner。
一样平常测试职员进行性能测试便是运用在客户端性能的测试。
运用在网络上性能的测试：紧张网络运用性能监控、网络运用性能剖析和网络预测的测试，目的是准确展示网络带宽、延迟、负载和TCP端口的变革是如何影响用户的相应韶光的，性能的问题根源位置，会借助一些工具，比如Application Expert。
运用在做事器性能的测试：目的是实现做事器设备、做事器操作系统、数据库系统、运用在做事器上性能的全面监控。

性能测试目的是验证软件系统是否能够达到用户提出的性能指标，同时创造软件系统中存在的性能瓶颈，优化软件，末了起到优化系统的目的。

补充解释：两个插件YSlow、page speed，静态评估网页性能的插件，可以评估网页性能并得到有关如何改进性能的建议，有兴趣的产品经理可以理解，后期优化产品时可以有底气地和开拓职员沟通。
当然也有APM（运用性能管理）对企业系统即时监控以实现对运用程序性能管理和故障管理的系统化的办理方案，比如听云官网。

软件经由上述紧张的测试后提交bug修正bug后，须要再次测试考验软件是否能正常运行，也便是所谓的回归测试。

回归测试：修正了旧代码后，重新进行测试以确认修正没有引入新的缺点或导致其他代码产生缺点。
在全体软件测试过程中霸占很大的事情量比重，软件开拓的各个阶段都会进行多次回归测试，且只管即便实现自动化，作为自动化测试的优先级。
测试重心在关键模块和重点功能模块上。

产品经理测试验收产品时，紧张是采取手工测试以用户视角来测试产品，根据用户需求，采取事宜驱动，输入和输出，测试软件系统的界面和功能，紧张测试方向为功能、可用性、用户体验，以是紧张是进行系统测试的功能测试、界面测试、可靠性测试、易用性测试、兼容性测试。
而性能测试、安全测试等自动化测试由专门的测试职员履行。

其余，该当知道测试原则的几个紧张特点：软件测试不能担保百分百没有缺陷，毛病具有群集特性（即毛病紧张涌如今有缺陷的模块，重点关注），测试的二八原则（80%韶光用在20%的重点模块上，提升效率和资源利用率），测试活动依赖测试背景（依赖软件的运用背景，比如银行金融软件，侧重安全，以是更倾向于安全性测试）。

补充解释：目前互联网公司大多强调敏捷开拓，以是我们讲讲敏捷开拓及敏捷测试的知识。

敏捷开拓：以用户的需求进化为核心，采取迭代、循规蹈矩的方法进行软件开拓。
也便是需求一贯在变更，我们须要拥抱变更。
主见的代价不雅观：沟通、大略、反馈、勇气、谦善。

敏捷宣言：个体和交互 赛过 过程和工具；可以事情的软件 赛过 面面俱到的文档；客户互助 赛过 条约会谈；相应变革 赛过 遵照操持。
每项比拟中，虽然后者也有代价，但我们认为前者更有代价。

敏捷测试是遵照敏捷宣言的一种测试实践：

强调从客户的角度，即从利用系统的用户角度，来测试系统。
重点关注持续迭代地测试新开拓的功能，而不再强调传统测试过程中严格的测试阶段。
建议尽早开始测试，一旦系统某个层面可测，比如供应了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试担保之前测试过内容的精确性。
强调持续反馈，预防毛病赛过创造毛病。

敏捷开拓的好处：开拓和测试职员是紧密互助，大家都有任务对软件卖力，以是产品更能符合需求文档的哀求。
核心系统集成和高频集成是敏捷开拓的比较常用的测试方法。

6、产品经理如何测试验收产品

讲完测试观点，就该当到实践了，即如何测试验收产品。

产品经理测试一个产品，不能用产品思维去测试一个产品，由于产品经理是最熟习产品的人，产品每一功能每一个步都知道操作流程，以是每每只能创造一些不符合产品需求功能上的bug，而会忽略真实用户去利用的问题，比如某个功能点的利用路径过深，导致用户找不到，用户产生挫败感。

以是产品经理测试验收产品，除了验收是否符合产品需求外，还须要创造产品的可用性、可行性、情绪化设计的用户体验问题。
因此，测试产品过程中，产品经理须要跳出产品思维，转为用户思维，乃至转为测试职员的思维，更广度和深度的测试验收。

那么如何转为测试职员的思维呢？首先须要理解测试职员的职责及事情，这样才能更好地理解到测试职员利用到的测试思维，才能更好地转为测试职员的思维。

下面来看看拉勾的腾讯的测试工程师的招聘的职位哀求，如下图所示：

抛开技能层面，只从测试思维考虑，从职位哀求可以看出，以是测试工程师的核心能力在于有耐心地提出寻衅性的干系问题，从不同的角度，验证产品的可行性，长于找出错误让程序不能正常运行的问题。
由于带着问题，才能创造问题，比如他们会问，产品的目的，产品紧张在什么平台上利用，如果不符合的数据输入会不会发生程序崩溃，会从各种实用场景中创造问题。

从各种场景创造问题，也便是哀求我们要多利用，多问“如果…会怎么样“”为什么”的问题，毕竟找到关键问题的最好办法便是提问。
由于多问为什么，发散思维，也使得测试职员会从不同的用户角度（交叉测试）去思考问题，包括毫无履历的用户、很有履历的用户、爱好者、黑客、竞争对手等等，产品的受众越多，不同类型的用户就越多，就须要从更多的用户去思考问题，当然，用户越多，其操作行为和事情流程就越多，比如随意输入、随意点击。

随意输入、随意点击，不断和系统交互，带着问题测试，也便是所谓的探索性测试，探索产品未被创造的bug的存在隐患。
探索性测试，完备抛开测试脚本的测试，是一种测试风格、思维而不是一种测试技能，分为局部性测试和全局性测试，局部性测试紧张是对某个模块进行输入输出的测试，全局性测试紧张是像游客一样利用软件系统。

探索性测试，自由灵巧会增加创造新的bug的可能性，实行与设计（思考）并行，减少在大略、繁复上用例的无谓编写韶光，不断和系统交互，带着问题测试，但更依赖系统完成可用的情形下才能交互利用探索，且难折衷和掌握，以是一样平常都是测试工程师采取monkey自动化测试进行探索性测试。

从上面的职责和测试职员的测试事情，我们不丢脸出，测试的紧张思维便是带着问题以不同用户的不同操作流程去利用产品达到创造bug。

理解了测试思维，那么还须要理解测试的流程是若何的，毕竟流程是规范性的哀求，担保测试能有序有目的的进行。
测试的流程紧张为测试操持-测试用例-测试实行-测试报告。

测试用例紧张是测试职员根据PRD、流程图、原型图、UI、网络的资料来编写，通过需求文档理解需求背景，用户画像、利用场景、用户故事，通过流程图、原型图理解功能需求，站在用户角度和项目实情去思考，尽可能地覆盖全面利用路径。
测试用例编写之前，产品经理都是最熟习产品，知道产品的目的，即用户故事同理心，知道产品紧张是在什么系统、平台运行，知道数据是什么类型，知道调用哪些外部的接口，知道哪些是关键模块，知道产品的方案，可以更快速地测试是否符合产品需求文档的哀求，以是产品经理该当和测试职员详细地宣讲产品，也便是所谓的必须进行的产品宣讲，这样测试职员能好地理解编写测试用例，产品经理也能借助测试职员的履历更好地进行测试验收产品。

编写好测试用例时，根据需求文档的需求优先级和风险级别定义测试优先级别，重点测试核心模块，比如电商网站的搜索浏览商品和下单的完全流程是优先级别的测试模块。
开始测试产品过程中，详细写好步骤和详细问题，问题很多类型，以是记好问题类型，当然很多问题是可以被预先确定和测试的，以是把稳操作步骤及操作环境，比如是否按照正常流程操作，用户是否打开数据网络。

产品经理一样平常是根据测试用例来测试验收产品，符合验收标准即可。
测试用例可以从测试职员那里要，或者自己根据谁、怎么做、结果的用户操作流程编写一个符合规则的测试用例去测试，末了去思考问题的缘故原由和解决方案，以及把测试的问题反馈给测试职员跟进和开拓职员办理。
测试模块只管即便独立，覆盖全面，减少耦合。

这里我们以微信手机号登录功能模块的功能测试为测试案例，讲讲测试步骤和测试用例。
当然，不同公司的测试步骤和测试用例会有些不一样，不过相差不大。

测试前须要准备一些测试的硬性需求，比如测试的干系数据（比如是否后台创建测试账号）、测试设备（比如iphone5、6、7）、测试须要的软件（比如操作系统，浏览器）。

这里微信登录功能测试的需求：数据（一个已注册的用户账号密码，一个未注册的手机号码），设备（一部手机），须要的软件（android/ios）。

根据带着问题以不同用户的不同操作流程去利用产品达到创造bug的测试思维，编写测试用例。

首先用脑图列出模块的不同用户的不同操作流程，这样可以覆盖功能全面路径。
这里只列举紧张利用场景，如下图所示：

根据PRD的用户故事或者原型图的规则解释列出每个功能点的验收标准，列出每个操作流程的验收标准，即预期结果（预期结果以微信实操的结果仿照，吐槽一下微信手机号码输入框没限定号码长度的等一系列的低级体验问题）。
在操作流程的脑图根本上补上每个故事点的验收标准，如下图所示：

末了根据上述的脑图，我们可以写出大概的测试用例列表，当然，测试列表须要补充解释一些干系信息。
如下图所示：

编写完测试用例后，我们就可以根据测试用例逐项测试产品，并根据测试结果填写测试用例列表中的测试结果，并根据预期结果和测试结果的差异，填写是否存在毛病，并反馈给测试职员和开拓职员进行跟进和修正毛病。
至此，一个模块功能测试就完全了，当然，修正毛病后跟进还须要回归测试。

补充解释：上述的根本测试知识只是产品经理常常涉及到的测试知识，测试还有很多观点，比如冒烟测试、AB测试、自动化测试，测试的未来会自动化，对技能哀求越来越高，以是测试是一门大学问，如果有兴趣学习的产品经理，可以找套教程学学。

作者：铅笔小葵（微旗子暗记：gaokaikui 知乎专栏：铅笔小葵），待业中，2年多事情履历，现产品经理，全权卖力从0到1的产品开拓，曾任Java工程师，参与后台开拓。
欢迎大家互相交流关注。

本文由 @铅笔小葵 原创发布于大家都是产品经理。
未经容许，禁止转载。