01.什么是软件测试？

测试，顾名思义就是测试程序保证其可正确运行。而早期的测试定义就是如此，即对程序能够按预期运行建立起一种信心。随着技术的发展，目前测试的经典定义是，在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。即运行程序发现错误。

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

测试可以归为两点：程序做了它应该做的事情；程序没有做它不该做的事情。

软件测试不等于程序测试，测试的对象包括文档、数据、程序。

软件测试的目的

软件测试是为了证明程序有错因为对于一个软件程序来说，永远不可能零BUG，有可能是没有被发现，有可能在迭代之后会因为各种各样的原因出现新的BUG，所以，消除BUG是不存在的，测试要做的就是找到威胁程序正常运行使用的，并进行相应的处理。

为了发现软件程序中的错误。

为了审核程序是否满足了用户的功能需求。

为了提高用户体验。

为了交付更高质量的产品。

02.什么时候开始测试？

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

开发前的测试

需求评审：定位、用户画像、说明规则是否明确；

原型：页面是否完整，信息架构是否清晰；

UE：业务流程是否舒适；

UI：视觉设计是否干净，风格是否一致；

03.测试的观点

风险观点

针对用户最常用的20%功能进行测试，用户不常用的80%功能可以降低测试的要求，减少测试的工作量，因为这样做风险并不大，反而是确保了核心功能的正常使用，这个可以理解为测试的优先级排序。

经济观点

一个好的测试用例的价值体现在能够发现至今未被发现的错误，错误被发现的越早，修正这个错误所需要付出的代价就越小。

(1)测试是为了发现程序中的错误而执行程序的过程。

(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。

(3)成功的测试是发现了至今为止尚未发现的错误的测试。

(4)测试并不仅仅是为了找出错误。通过分析错误产生的原因和错误的发生趋势，可以帮助项目经理发现当前软件开发过程中的缺陷，以便及时改进。

(5)这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。

(6)没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。

04.测试的分类

单元测试

单元的定义：单元就是人为规定的最小的可被测功能模块。

单元测试属于开发者的自检行为，通常由开发者在开发期间完成。

集成测试

集成测试的定义是在单元测试的基础上，将模块进行组装成系统或子系统，进行测试。

集成测试的意义：一些单独的功能虽然可以单独的工作，但是不能保证在组装之后依然能够正常工作运行，在局部来看，可能没有问题，但是通过查看全局就会暴露很多之前都没有看到的问题，这个也是集成测试的意义。

系统测试

系统测试是在实际运行环境在进行的测试，是用来检验软件程序是否满足了功能、性能。安全。兼容性等一系列制定的需求。

系统测试主要有一下四个分类：

功能测试：这个也是我目前主要学习的方向。功能测试就是黑盒测试，说白了就是根据产品的需求说明和测试用例进行验证产品的是否满足了各项功能的制定目标。

性能测试:测试当前的软件程序性能与预想的性能目标有多大的差距，主要是为了验证产品的一系列处理能力。（压力测试就是属于性能测试的一种）

安全测试：验证程序的保护机制是否能够抵御来自外部的攻击。（主要测试方向有：有效性，精确性，生存性，反应时间，吞吐量）

兼容性测试：检测不同的系统对程序的兼容性。

验收测试

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

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

功能测试

对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。测试人员会借助一些功能测试工具，主要是测试业务流程。类

界面测试

也称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

易用性测试

指用户使用软件时是否感觉方便，主要特点为易理解性、易学性、易操作性、吸引性、易用的依从性，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，强调软件可运行性，而易用性是指是否方便使用，强调用户体验，是交互的适应性、功能性和有效性的集中体现。

兼容性测试

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

性能测试

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

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

回归测试

修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试，且尽量实现自动化，作为自动化测试的优先级。测试重心在关键模块和重点功能模块上。

5.敏捷测试

敏捷宣言：个体和交互 胜过 过程和工具；可以工作的软件 胜过 面面俱到的文档；客户合作 胜过 合同谈判；响应变化 胜过 遵循计划。每项对比中，虽然后者也有价值，但我们认为前者更有价值。

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

强调从客户的角度，即从使用系统的用户角度，来测试系统。

重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

强调持续反馈，预防缺陷胜过发现缺陷。

06.产品经理如何测试验收产品

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

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

测试用例主要是测试人员根据PRD、流程图、原型图、UI、收集的资料来编写，通过需求文档了解需求背景，用户画像、使用场景、用户故事，通过流程图、原型图了解功能需求，站在用户角度和项目实情去思考，尽可能地覆盖全面使用路径。

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

产品经理一般是根据测试用例来测试验收产品，符合验收标准即可。测试用例可以从测试人员那里要，或者自己根据谁、怎么做、结果的用户操作流程编写一个符合规则的测试用例去测试，最后去思考问题的原因和解决方案，以及把测试的问题反馈给测试人员跟进和开发人员解决。测试模块尽量独立，覆盖全面，减少耦合。