[Test] Product Testing Knowledge

From: 产品经理必备干货：全面详细的产品测试知识

 

测试的定义

---

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

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

 

 

 

测试何时进行

---

 

 

 

开发模型 - V模型

---

 

单元测试

单元测试：又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。由开发人员实施，用以检验所开发的代码功能符合设计要求。单元测试是其他测试的基础，单元测试用例代码和函数一对一，便于维护和实现条件覆盖与路径覆盖，可以尽早发现缺陷和利于重构，但一行代码需要3-5行测试代码才能完成单元测试，支出较大，典型的空间换取利益，所以需要权衡。

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

集成测试

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

集成测试的主要实施方案：一次性集成方法（big bang），即一次性把所有模块组装起来测试；增殖式集成方式，即一个个模块持续集成测试，最后把所有模块组装起来。

系统测试

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

系统测试主要是从业务角度验证产品是否符合需求文档，所以，产品经理测试产品是否符合需求文档和设计的要求，一般都是在系统测试阶段。当然，测试人员主要针对的也是系统测试阶段。

验收测试

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

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

 

 

 

系统测试细节

---

功能

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

界面

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

可靠性

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

易用性

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

兼容性

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

性能

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

性能测试主要分为：

• • 应用在客户端性能的测试：主要并发性能测试，利用自动化工具通过模拟成百上千用户重复执行和运行应用进行黑盒测试，比如loadrunner。一般测试人员进行性能测试就是应用在客户端性能的测试。
  • 应用在网络上性能的测试：主要网络应用性能监控、网络应用性能分析和网络预测的测试，目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的，性能的问题根源位置，会借助一些工具，比如Application Expert。
  • 应用在服务器性能的测试：目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控。

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

 

 

 

发现并解决Bug

---

发现并解决Bug后的回归测试

软件经过上述主要的测试后提交bug修改bug后，需要再次测试检验软件是否能正常运行，也就是所谓的回归测试。

回归测试

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

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

另外，应该知道测试原则的几个主要特点：软件测试不能保证百分百没有缺陷，缺陷具有群集特性（即缺陷主要出现在有缺陷的模块，重点关注），测试的二八原则（80%时间用在20%的重点模块上，提升效率和资源使用率），测试活动依赖测试背景（依赖软件的应用背景，比如银行金融软件，侧重安全，所以更偏向于安全性测试）。

 

 

 

测试验收产品

---

测试流程

(1) 带着问题以不同用户的不同操作流程去使用产品达到发现bug。

(2) 了解了测试思维，那么还需要了解测试的流程是怎样的，毕竟流程是规范性的要求，保证测试能有序有目的的进行。测试的流程主要为测试计划-测试用例-测试执行-测试报告。

测试用例

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

准备什么？测试用例编写之前，产品经理都是最熟悉产品，知道产品的目的，即用户故事同理心，知道产品主要是在什么系统、平台运行，知道数据是什么类型，知道调用哪些外部的接口，知道哪些是关键模块，知道产品的规划，可以更快速地测试是否符合产品需求文档的要求，所以产品经理应该和测试人员详细地宣讲产品，也就是所谓的必须进行的产品宣讲，这样测试人员能好地理解编写测试用例，产品经理也能借助测试人员的经验更好地进行测试验收产品。

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

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

 

 

Test Driven Development (TDD)

---

Ref: 深度解读 - TDD（测试驱动开发）

基本流程

TDD 的基本流程是：红，绿，重构。
更详细的流程是：

• 写一个测试用例
• 运行测试
• 写刚好能让测试通过的实现
• 运行测试
• 识别坏味道，用手法修改代码
• 运行测试

 

三条规则

1. 除非是为了使一个失败的 unit test 通过，否则不允许编写任何产品代码
2. 在一个单元测试中，只允许编写刚好能够导致失败的内容（编译错误也算失败）
3. 只允许编写刚好能够使一个失败的 unit test 通过的产品代码

 

 

Feature-Driven Development (FDD)

---

Ref: Feature-Driven Development（特征驱动开发）

一个sprint一个任务

软件开发人员喜欢新的事情，使用FDD每两周就有新的事情可做，而且每两周就可以交货完成一些工作，离目标越来越近，这种 Closure感觉在开发队伍中是很重要的，可以让大家万众一心，有一种拧在一起的冲劲，从而潜在地提高开发人员的积极性。

FDD是一个模型驱动( model-driven)、短期遍历(short-iteration)的过程. 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后大概是两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容，features是指小的、以软件用户的视角看是有用的特征功能，一个FDD开发过程都下图（引自FDD和XP一文）。

 

开发过程

 

与XP区别

　　FDD非常类似极限编程XP，但是有如下区别：

1. Team的大小：XP设计成2-10人；而FDD设计成16-20人
2. 建模方式不同：XP是写Story在一个个Index卡片上，项目所有的人（客户经理和开发人员都能知晓系统是如何工作的）；FDD使用domain walkthroughs（业务领域通概介绍）和特征任务来替代Story，最大的不同是，FDD多了一个Domain Model对象的设计和开发，Domain Model成为整个项目的指示灯，就象革命队伍中的宝塔红灯。这可注意：这个Domain Model作用可不小，可以减少误解、驱动开发人员进行更加完整、更加丰富下阶段开发，类似革命航线的引路人。
3. 还有更多区别，可见 FDD和XP一文