软件测试策略与过程

软件测试的对象

软件测试==程序测试？？？

软件测试的分类

（1）按照测试阶段分类

（2）按照测试覆盖分类

（3）按测试方法分类

（4）按质量属性分类

按测试阶段划分

单元测试

定义

对单个软件单元或者一组相关的软件单元所进行的测试，是代码级别的测试。

在编写代码时，虽然会反复调试保证能够正常运行程序或编译成功，但是编译只能保证语法正确，而无法保证它的语义正确。

实施阶段

在功能需求实现过程中，可以同步完成单元测试代码的编写

如果单元测试用例的编写是在功能需求实现之前，那么这可认为是TDD（测试驱动开发）。但是要实现开发人员在进行功能需求实现前，完成单元测试用例编写，需要开发人员对需求有深入的分析，也需要测试人员能够对开发进行测试相关的辅导与指引。

测试过程

基本单元本身并不是一个独立的程序，自己并不能运行，要靠其他部门来调用和驱动

驱动模块

相当于被测基本单元的主程序，它接收测试数据，并把测试数据传输给被测单元，最后输出给测试结果

遵循原则

1. 应该尽早地进行软件单元测试

2. 应该保证单元测试的可复用性、

3. 尽可能采用自动化的手段来支持单元测试

优势

1. 单元测试尽早发现缺陷、收益比较好

2. 有利于以后的重构，最大限度地保证后续工作的重构

3. 简化集成，保证最小单元模块的稳定性和正确性，为以后的集成测试简化

4. 文档，尽可能的减少文档的存在

5. 用于设计，把设计思路体现在单元测试中

劣势

1. 对测试人员的学习成本要求较高

2. 对开发人员的质量意识要求较高

3. 对项目的开发成本较高（尤其是互联网企业要求快速发布）

集成测试

目的

检查软件单元之间的接口是否正确

定义

在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试

优势

（a)数据经过接口可能丢失，通过集成测试能够发现

（b）一个模块对另一个模块可能会产生影响，通过集成测试能够发现

（c）几个子模块组合起来之后功能可能不能用，通过集成测试能够发现

原则

(a)集成测试是产品研发中的重要工作，需要为其分配足够的资源和实践。

(b)集成测试应该经过严密的计划，并严格按照计划执行

(c)应采取增量的分布集成方式，逐步进行软件部件的继承和测试

(d)重视测试自动化技术的引入与应用，不断提高集成测试效率

(e)注意测试用例的积累与管理，方便进行回归并进行测试用例的补充

测试内容

(a)集成功能测试

(b)接口测试

(c)全局数据结构测试

(d)资源测试

(e)性能和稳定性测试

系统测试

定义

经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境中对计算机系统进行一系列严格有效地测试，以发现软件中潜在的问题，保证系统正常运行。系统测试一般要进行功能测试。

以嘀嘀打车为例：

优势

1. 数据经过接口可能丢失

2. 一个模块对另一个模块可能造成不应有的影响

3. 功能组合起来不能实现主功能

4. 误差不断积累达到不可接受的程度

5. 系统测试可以100%保证系统性能，因为它涵盖了系统的端到端功能

验收测试

目的

确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

定义

针对用户要求、需求和业务流程的正式测试，用以确认系统是否满足验收准则。可让最终用户、客户或者其他授权实体判断是否可接收该系统。

*（a)alpha测试（在公司内部）

a测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，a测试不能由程序员或测试员完成。a测试发现的错误，可以再测试现场立即反馈给开发人员，由开发人员及时分析和处理。

*（b）beta测试（非公司内部）

Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场

beta测试版本必须通过alpha的测试

测试内容

验证系统是否达到了用户需求规格说明书中的要求，测试试图尽可能发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档测试等几方面的内容。

验收标准

(a)完全执行了验收测试计划中所有的测试用例

(b)在验收测试初期中发现的错误已经得到修改并且通过测试或者经过评审遗留到下一版本中修改

(c)完成软件验收测试报告

*按测试覆盖分类

测试覆盖率：取值从0%-100%，根据经验，划分三个区间：冒烟测试（1-5%）、回归测试（5%-100%）、全量测试（100%）

*冒烟测试

定义

软件冒烟测试（BVT），起源于微软，即开发工程师在调试版本的软件上执行冒烟测试用例，以确定新的程序代码不出故障。具体来说，冒烟测试是在每日构建建立之后，对系统的基本功能进行简单测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。一般花费0.5-4h

测试内容

1. 核心业务：保证核心业务链路通畅

2. 基本工作流：保证基本流程运转通畅，至于流程步骤的内容是否正确则不关注

3. 关键功能：保证系统关键功能正常运转

4. 平台功能：如对核心业务有影响的数据库增删改操作

停止标准/通过标准

1. 致命和严重的缺陷数均为0

2. 冒烟测试用例集测试通过率=100%

失败标准

1. 致命或严重的缺陷数>0

2. 冒烟测试用例集测试通过率<100%

*回归测试

背景

在软件生命周期的任一阶段，只要软件代码发生改变，就有可能会给软件质量带来潜在风险

软件的变更通常由以下三个因素产生：

(a)产品经理偷偷增加了新需求

(b)产品经理修改了需求

(c)修复用户对软件的吐槽

定义

指修改了代码后，重新进行测试以确保是否引入新BUG或导致其他代码产生bug

在整个软件测试过程中占据了很大的工作比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行更加频繁，因此选择正确的回归测试策略来提升回归测试效率和有效性是非常有意义的。

目的

1. 验证开发工程师对代码的变更是否达到了预期

2. 验证新功能是否得到实现，能否适应新环境

3. 验证原有功能是否被污染/受到影响

全量测试

背景

在产品发布前夕，或者即将给客户演示，由于项目上的种种原因导致产品质量风险较大，因此在制定策略时，应该更加谨慎，甚至需要对产品进行全量的测试。

定义

在回归测试或产品发布前，尤其是新产品，为确保质量而对所有功能开展的全量覆盖验证的测试活动，以确认是否存在遗留bug

影响因素

使用全面测试时，我们同时需要结合实际的情况，综合考虑时间成本和人力成本。