什么是产品测试？测试可归为两点：程序做了它应该做的事情；程序没有做它不该做的事情。
1、写在前面
文章主要涉及产品经理工作上经常接触到的基础的测试知识，包括测试的定义、测试何时进行、产品经理应该懂的测试概念、产品经理如何测试验收产品。
产品每个阶段都有验收标准，比如需求评审阶段验收、开发阶段验收，所以每个阶段都需要测试。产品经理尽管不是专业的测试人员，但产品经理作为最熟悉产品的人，理应对产品每个阶段都进行相应的测试验收产品，比如功能测试、可用性测试、用户体验测试，确保符合需求文档的要求，所以产品经理应该懂得相应的测试知识。
产品经理懂测试，在相应的测试方式中验收产品的时候，能更清楚的系统地记录产品的每个问题，然后用产品思维去思考如何解决这些问题。
可以用极简主义去思考如何把选择复杂的问题简单化减少用户的选择，比如刻意显示引导用户选择的功能按钮或隐藏用户很少用到的功能，比如微信用户很少用到的朋友圈停用的功能，使用路径刻意加深隐藏。
可以用可用性原则的思维去思考如何去引导用户更好的完成产品使用，比如页面说明该页面所处的位置状态，比如微信的朋友圈页面顶部显示朋友圈的位置说明。
可以用情感化设计的思维去思考如何超出用户的期望，比如微信聊天窗口发送我想你了会落下满天星星的效果超出用户的期望。
可以用可行性的思维去思考如何用现有的资源解决产品的问题，比如前端工程师人数少的情况下可以直接借助前端开源框架快速开发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测试的视觉设计，直接影响到目标产品的整个生命周期的视觉效果。
产品经理和测试人员沟通需求或者反馈产品的bug时，经常听到测试人员说的脚本录制及自动化测试的一些测试概念上名词，经常会说什么这个功能模块采用黑盒测试的流程分析法就知道bug的位置了，这个时候产品经理就懵逼，感觉沟通不下去了，产品做不下去了。
产品经理懂得岗位的相关上下游知识，可以更好的处理好工作，比如和测试人员沟通需求时，测试人员会说文档测试通过了吗，或者说这个等到集成测试后再系统测试验证这个问题吧，这些测试上的名词，如果你懂的话，那么沟通起来就会很顺利，你就不会去问什么是文档测试，什么是集成测试，既节约时间，更主要可以让产品的相关人员都能清楚地理解需求。
测试一般是随着项目开发周期进行，根据开发模型对应相应的测试模式，比如瀑布开发模型的测试模式。测试分类有多个维度分类，比如根据测试阶段、测试手段、测试模块的维度分类，每个测试分类都有相应的测试办法，比如系统测试、白盒测试、黑盒测试、自动化测试。
目前，我们最常用的开发模型是V模型，如下图所示：
所以我们主要是根据V模型讲讲解测试知识。
V模型是按测试阶段来分类测试，分为单元测试、集成测试、系统测试、验收测试，这也是根据开发进度进行的测试分类。
单元测试：又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。由开发人员实施，用以检验所开发的代码功能符合设计要求。单元测试是其他测试的基础，单元测试用例代码和函数一对一，便于维护和实现条件覆盖与路径覆盖，可以尽早发现缺陷和利于重构，但一行代码需要3-5行测试代码才能完成单元测试，支出较大，典型的空间换取利益，所以需要权衡。
单元测试有相应的测试框架，比如Xunit、Junit、PHPunit。我们平时接触的敏捷开发比较强调TDD（测试驱动开发），即在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。这样能保证功能代码的正确性，也能保证对需求的二次确认和理解，对需求设计有个清晰的认识。
集成测试：也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。
集成测试的主要实施方案：一次性集成方法（big bang），即一次性把所有模块组装起来测试；增殖式集成方式，即一个个模块持续集成测试，最后把所有模块组装起来。
系统测试：通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统（软件）的需求定义作比较， 发现软件与系统（软件）的定义不符合或与之矛盾的地方。即把可运行的软件安装在真实环境下操作使用，测试软件的功能和性能，比如某功能能否正常运行，软件在该平台下能否正常运行。
系统测试主要是从业务角度验证产品是否符合需求文档，所以，产品经理测试产品是否符合需求文档和设计的要求，一般都是在系统测试阶段。当然，测试人员主要针对的也是系统测试阶段。
验收测试：也称交付测试，以用户为主的测试，由用户参加设计测试用例，使用生产中的实际数据进行测试，确定软件是否满足验收标准，是否接受系统软件。
验收测试驱动开发，是TDD的延伸，也就是定义好用户故事，验收标准，再去开发功能，功能通过验收标准，功能满足用户故事。
从上面的定义，我们知道产品经理测试验收产品一般是在系统测试阶段，系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、兼容性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。其中功能测试是最主要的一种测试类型，一般说测试就是功能测试。
功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。测试人员会借助一些功能测试工具，比如QTP winrunner，主要是测试业务流程。
界面测试：也称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
可靠性测试：对软件或者硬件的一种质量测试，用来检测产品是否存在不可靠因素，比如硬件老化。
易用性测试：指用户使用软件时是否感觉方便，主要特点为易理解性、易学性、易操作性、吸引性、易用的依从性，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，强调软件可运行性，而易用性是指是否方便使用，强调用户体验，是交互的适应性、功能性和有效性的集中体现。
兼容性测试：主要测试软件是否能在不同的操作系统平台上兼容，是否能在不同的设备上兼容；软件本身能否向前或向后兼容；软件能否与其他相关的软件兼容；数据是否兼容，主要是指数据能否共享等。
性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
性能测试主要分为：
应用在客户端性能的测试：主要并发性能测试，利用自动化工具通过模拟成百上千用户重复执行和运行应用进行黑盒测试，比如loadrunner。一般测试人员进行性能测试就是应用在客户端性能的测试。
应用在网络上性能的测试：主要网络应用性能监控、网络应用性能分析和网络预测的测试，目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的，性能的问题根源位置，会借助一些工具，比如Application Expert。
应用在服务器性能的测试：目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控。
性能测试目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。
补充说明：两个插件YSlow、page speed，静态评估网页性能的插件，可以评估网页性能并获得有关如何改进性能的建议，有兴趣的产品经理可以了解，后期优化产品时可以有底气地和开发人员沟通。当然也有APM（应用性能管理）对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案，比如听云官网。
软件经过上述主要的测试后提交bug修改bug后，需要再次测试检验软件是否能正常运行，也就是所谓的回归测试。
回归测试：修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试，且尽量实现自动化，作为自动化测试的优先级。测试重心在关键模块和重点功能模块上。
产品经理测试验收产品时，主要是采用手工测试以用户视角来测试产品，根据用户需求，采用事件驱动，输入和输出，测试软件系统的界面和功能，主要测试方向为功能、可用性、用户体验，所以主要是进行系统测试的功能测试、界面测试、可靠性测试、易用性测试、兼容性测试。而性能测试、安全测试等自动化测试由专门的测试人员实施。
另外，应该知道测试原则的几个主要特点：软件测试不能保证百分百没有缺陷，缺陷具有群集特性（即缺陷主要出现在有缺陷的模块，重点关注），测试的二八原则（80%时间用在20%的重点模块上，提升效率和资源使用率），测试活动依赖测试背景（依赖软件的应用背景，比如银行金融软件，侧重安全，所以更偏向于安全性测试）。
补充说明：目前互联网公司大多强调敏捷开发，所以我们讲讲敏捷开发及敏捷测试的知识。
敏捷开发：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。也就是需求一直在变更，我们需要拥抱变更。主张的价值观：沟通、简单、反馈、勇气、谦逊。
敏捷宣言：个体和交互 胜过 过程和工具；可以工作的软件 胜过 面面俱到的文档；客户合作 胜过 合同谈判；响应变化 胜过 遵循计划。每项对比中，虽然后者也有价值，但我们认为前者更有价值。
强调从客户的角度，即从使用系统的用户角度，来测试系统。
重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
强调持续反馈，预防缺陷胜过发现缺陷。
敏捷开发的好处：开发和测试人员是紧密合作，大家都有责任对软件负责，所以产品更能符合需求文档的要求。核心系统集成和高频集成是敏捷开发的比较常用的测试方法。
产品经理测试一个产品，不能用产品思维去测试一个产品，因为产品经理是最熟悉产品的人，产品每一功能每一个步都知道操作流程，所以往往只能发现一些不符合产品需求功能上的bug，而会忽略真实用户去使用的问题，比如某个功能点的使用路径过深，导致用户找不到，用户产生挫败感。
所以产品经理测试验收产品，除了验收是否符合产品需求外，还需要发现产品的可用性、可行性、情感化设计的用户体验问题。因此，测试产品过程中，产品经理需要跳出产品思维，转为用户思维，甚至转为测试人员的思维，更广度和深度的测试验收。
那么如何转为测试人员的思维呢？首先需要了解测试人员的职责及工作，这样才能更好地了解到测试人员使用到的测试思维，才能更好地转为测试人员的思维。
下面来看看拉勾的腾讯的测试工程师的招聘的职位要求，如下图所示：
抛开技术层面，只从测试思维考虑，从职位要求可以看出，所以测试工程师的核心能力在于有耐心地提出挑战性的相关问题，从不同的角度，验证产品的可行性，善于找出错误让程序不能正常运行的问题。因为带着问题，才能发现问题，比如他们会问，产品的目的，产品主要在什么平台上使用，如果不符合的数据输入会不会发生程序崩溃，会从各种实用场景中发现问题。
从各种场景发现问题，也就是要求我们要多使用，多问“如果…会怎么样“”为什么”的问题，毕竟找到关键问题的最好办法就是提问。因为多问为什么，发散思维，也使得测试人员会从不同的用户角度（交叉测试）去思考问题，包括毫无经验的用户、很有经验的用户、爱好者、黑客、竞争对手等等，产品的受众越多，不同类型的用户就越多，就需要从更多的用户去思考问题，当然，用户越多，其操作行为和工作流程就越多，比如随意输入、随意点击。
随意输入、随意点击，不断和系统交互，带着问题测试，也就是所谓的探索性测试，探索产品未被发现的bug的存在隐患。探索性测试，完全抛开测试脚本的测试，是一种测试风格、思维而不是一种测试技术，分为局部性测试和全局性测试，局部性测试主要是对某个模块进行输入输出的测试，全局性测试主要是像游客一样使用软件系统。
探索性测试，自由灵活会增加发现新的bug的可能性，执行与设计（思考）并行，减少在简单、繁复上用例的无谓编写时间，不断和系统交互，带着问题测试，但更依赖系统完成可用的情况下才能交互使用探索，且难协调和控制，所以一般都是测试工程师采用monkey自动化测试进行探索性测试。
从上面的职责和测试人员的测试工作，我们不难看出，测试的主要思维就是带着问题以不同用户的不同操作流程去使用产品达到发现bug。
了解了测试思维，那么还需要了解测试的流程是怎样的，毕竟流程是规范性的要求，保证测试能有序有目的的进行。测试的流程主要为测试计划-测试用例-测试执行-测试报告。
测试用例主要是测试人员根据PRD、流程图、原型图、UI、收集的资料来编写，通过需求文档了解需求背景，用户画像、使用场景、用户故事，通过流程图、原型图了解功能需求，站在用户角度和项目实情去思考，尽可能地覆盖全面使用路径。测试用例编写之前，产品经理都是最熟悉产品，知道产品的目的，即用户故事同理心，知道产品主要是在什么系统、平台运行，知道数据是什么类型，知道调用哪些外部的接口，知道哪些是关键模块，知道产品的规划，可以更快速地测试是否符合产品需求文档的要求，所以产品经理应该和测试人员详细地宣讲产品，也就是所谓的必须进行的产品宣讲，这样测试人员能好地理解编写测试用例，产品经理也能借助测试人员的经验更好地进行测试验收产品。
编写好测试用例时，根据需求文档的需求优先级和风险级别定义测试优先级别，重点测试核心模块，比如电商网站的搜索浏览商品和下单的完整流程是优先级别的测试模块。开始测试产品过程中，详细写好步骤和具体问题，问题很多类型，所以记好问题类型，当然很多问题是可以被预先确定和测试的，所以注意操作步骤及操作环境，比如是否按照正常流程操作，用户是否打开数据网络。
产品经理一般是根据测试用例来测试验收产品，符合验收标准即可。测试用例可以从测试人员那里要，或者自己根据谁、怎么做、结果的用户操作流程编写一个符合规则的测试用例去测试，最后去思考问题的原因和解决方案，以及把测试的问题反馈给测试人员跟进和开发人员解决。测试模块尽量独立，覆盖全面，减少耦合。
这里我们以微信手机号登录功能模块的功能测试为测试案例，讲讲测试步骤和测试用例。当然，不同公司的测试步骤和测试用例会有些不一样，不过相差不大。
测试前需要准备一些测试的硬性需求，比如测试的相关数据（比如是否后台创建测试账号）、测试设备（比如iphone5、6、7）、测试需要的软件（比如操作系统，浏览器）。
这里微信登录功能测试的需求：数据（一个已注册的用户账号密码，一个未注册的手机号码），设备（一部手机），需要的软件（android/ios）。
根据带着问题以不同用户的不同操作流程去使用产品达到发现bug的测试思维，编写测试用例。
首先用脑图列出模块的不同用户的不同操作流程，这样可以覆盖功能全面路径。这里只列举主要使用场景，如下图所示：
根据PRD的用户故事或者原型图的规则说明列出每个功能点的验收标准，列出每个操作流程的验收标准，即预期结果（预期结果以微信实操的结果模拟，吐槽一下微信手机号码输入框没限制号码长度的等一系列的低级体验问题）。在操作流程的脑图基础上补上每个故事点的验收标准，如下图所示：
最后根据上述的脑图，我们可以写出大概的测试用例列表，当然，测试列表需要补充说明一些相关信息。如下图所示：
编写完测试用例后，我们就可以根据测试用例逐项测试产品，并根据测试结果填写测试用例列表中的测试结果，并根据预期结果和测试结果的差异，填写是否存在缺陷，并反馈给测试人员和开发人员进行跟进和修改缺陷。至此，一个模块功能测试就完整了，当然，修改缺陷后跟进还需要回归测试。
补充说明：上述的基础测试知识只是产品经理经常涉及到的测试知识，测试还有很多概念，比如冒烟测试、AB测试、自动化测试，测试的未来会自动化，对技术要求越来越高，所以测试是一门大学问，如果有兴趣学习的产品经理，可以找套教程学学。
