软件测试活动的开展-学习笔记

1.1.1测试计划

软件测试计划是测试活动能够顺利开展、进行的保障。软件测试活动的行进过程中难免出现各种各样的困难和问题，因此软件测试计划也会不时的修改以适应新的问题、新的日程安排。软件测试不是在写好后就一成不变的，因此我们切忌在填写完测试计划后将其束之高阁。

软件测试计划在ANSI/IEEE中被描述为以下几个方面：规定软件测试活动的目的和被测目标、测试范围、测试方法、测试所要用到的资源和测试的进度安排；然后就是要阐明对测试目标进行那些方面的测试、需要执行的测试内容、每个任务的负责人；最后就是列举项目中的风险和防范风险的措施。

*测试活动的目的和被测目标

阐明被测软件需要实现什么样的功能，在功能测试中需要达到多少的覆盖率。在其他非性能测试中需要达到多少指标。

*测试范围

软件产品哪些部分需要测试哪些部分不需要测试、

哪些部分是不在现有的测试范围

测试范围还应该指明测试所处的测试阶段

测试范围还应该指明该测试包含的功能测试或者非功能测试的类型

*测试方法

白盒测试：也称结构测试或逻辑驱动测试，它知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行工作，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按照预定要求正确工作，而不是它的功能。

黑盒测试：是一种从软件外部对软件实施的测试，也称功能测试或者基于规格说明书的测试。它与软件具体实现无关，如果软件实现发生了变化，测试用例仍然可用；设计黑盒测试用例可以和软件实现同时斤西瓜，因此可以压缩项目总开发时间。

灰盒测试：介于白盒测试和黑盒测试之间的一种测试。是按照测试阶段来划分的，整个测试的流程包括单元测试、集成测试和系统测试。

*测试用到的资源

包括人力资源和设备资源

*测试的进度安排

将某一测试的进入条件和退出条件作为该测试阶段的开始和结束。例如在开发测试用例阶段，需要相关的设计文档作为输入，而设计文档若不能如期完成则必定会影响到测试用例的开发，因此可以把设计文档的完成作为开发测试用例阶段的起始点，在此基础上加上时间期限。把能够控制的事情和不能控制的事情分开，从而避免风险。

*测试策略

配和测试阶段来做。

1.1.2测试用例的产生

好的测试用例就是测试活动质量的保障。一个测试用例集合的覆盖率、测试方法的选择以及测试粒度和深度的选择直接影响到了测试活动的质量。

1.何时开始编写测试用例

先阅读分析需求和设计文档，进行编写测试用例预热，使某一需求条目或设计条目的修改可以很快的定位到其对应的测试用例。

2.选定测试方法

3.测试用例的内容

测试目标

测试对象

测试环境设置

前提步骤

输入数据

操作步骤

期望结果

4.测试用例的粒度

在保证测试覆盖面的情况下，粒度越大，测试用例开发编写人员的工作量越小，测试用例执行周期越短，但对软件产品的质量保证能力越差；粒度越小，测试用例开发编写人员的工作量越大，测试用例执行的周期越长，但对软件产品的质量保证能力越强。

5.测试用例的组织方式

自顶向下将测试用例集合用于某一测试阶段的集合，然后将某一测试阶段的测试用例集合按照不同的功能进行划分，之后再将针对某个功能的测试用例按照组件的方式进行划分。

6.测试用例的审查

相关人员意见达成一致的过程。

7.测试用例的有效性验证

在非正式测试版本上进行，测试结果并不作为任何正式测试轮次的报告，其作用只是验证待测产品的一致性及测试用例中所描述的测试环境的有效性，所以测试用例的有效性验证并不需要用到全部的测试用例。

1.1.3开始执行测试

1. 挑选测试用例组成测试轮次用例集合。

2. 正式执行测试前的软件版本验证工作。

（1）开发团队的版本验证工作

（2）测试团队的版本验证工作

3. 何时开始执行测试

1.1.4报告测试缺陷

1. 将软件缺陷进行归档并对其进行跟踪的意义

（1）缩短软件缺陷被修复的周期

（2）反应软件的质量

（3）经验总结

2. 既然软件缺陷归档如此重要，那么当软件测试人员发现有软件缺陷时应当如何有效的对软件缺陷进行报告？

（1）在报告一个软件缺陷时应该尽量避免重复报告

（2）简练准确的在缺陷的标题中描述该缺陷

（3）一个缺陷报告记录一个缺陷

（4）信息完整

（5）直观形象的秒速缺陷，提高缺陷重现率

（6）客观描述

3. 缺陷报告的内容

表1-1 缺陷报告内容

缺陷属性	含义
缺陷唯一标识	缺陷管理跟踪系统中对于每一个缺陷的唯一标识，通常为系统自动生成。
报告时间	缺陷报告生成的时间，通常为系统自动生成
状态	标识一个缺陷当时所处的状态，时缺陷生命周期的一环。通常随着生命周期的演化而变更
缺陷报告人	填写缺陷报告的测试工程师
标题	缺陷的总结，要求简练准确。让开发人员在极短的时间内通过查看缺陷的标题就可以判断该缺陷是否已经有人报告过；如果没有，则能很快的定位软件缺陷产生的位置和现象
所属项目	被测产品的项目名称
产品	被测产品的产品内部名称
组件	缺陷所在的组件
版本	缺陷所在的软件测试版本
严重度	客观的从客户的角度描述缺陷的严重程度。一般分为五级，通常由测试人员确认
优先级	缺陷被修复的优先级别。一般分为3~5级，通常由项目管理人员、开发组长、测试组长共同确定
发现阶段	缺陷被发现时的测试阶段
起源阶段	在缺陷本应该在何测试阶段被发现
当前负责人	缺陷在生命周期中的某一阶段的负责人。随着缺陷状态的改变，缺陷的负责人会从测试组人员变成项目组人员然后变成开发人员，最后又回到测试人员中。
详细描述	直观、形象、完整的描述缺陷。条理清晰，描述精准简练，突出重点。

4. 缺陷的跟踪

当测试人员完成一个缺陷的报告工作时，即表名了这个缺陷的生命周期开始了，此时项目组人员就有义务对这个缺陷进行跟踪。

图1-1 某一缺陷管理跟踪系统中一个缺陷从被报告到被关闭或被终结的所有生命状态及状态的可能变迁路径。