七.软件测试的过程管理

1.软件测试的各个阶段

什么是客户  客户需求分析 > 维护

时间、成本和质量

1.1  测试需求的分析和确定

1.2  测试计划

1.3  测试设计

1.4  测试执行

1.5  测试记录和缺陷跟踪

1.6  回归测试

1.7 测试总结和报告

PDCA 戴明循环：

P---Plan（计划）

D---Do（执行）

C---Check（检查）

A---Action（处理）

具体的流程可以概括为：

1.在分析清楚需求的前提下对测试活动进行计划和设计

2.按既定的策划执行测试和记录测试

3.对测试的结果进行检查分析，形成测试报告

4.这些测试结果和分析报告又能指导下一步的测试设计

5.因此形成了一个测试的循环

2.测试需求

2.1需求规格说明书的检查要点（也叫黑盒的静态测试）

检查要点：

   1. 正确性

   2.必要性

   3. 优先级

   4.明确性

   5.可测性

   6.完整性

   7. 可修改性

   8. 一致性

具体以下步骤：

   1. 获取最新版本的软件需求规格说明书，同时尽量取得用户原始需求文档

   2.阅读和尝试理解需求规格说明书中描述的所有需求项

   3.对照需求规格说明书检查列表进行检查并记录

   4.针对检查结果进行讨论、修订需求规格说明书后回到第一步，指到检查列表重点所有项通过

检查列表例子，常用的10个：

第一项需要检查需求规格说明书是否满足了用户提出的每一项需求。需求的完整性

第二项需要检查需求文档的用词用语问题。需求的明确性

第三项检查的是需求规格说明书对需求覆盖是否准确。需求的必要性

第四项检查的是软件使用环境的描述是否清晰。需求的完整性

第五项检查的是需求的规格说明书中的需求编号是否正确。需求的可修改性

第六项主要检查需求是否自相矛盾。需求的统一性

第七项主要检查软件系统允许的输入与预期的输入。需求的可测性

第八项检查的是软件系统的性能需求有没有得到清晰的表述。需求的完整性

第九项检查的是需求的关注重点和实现的先后顺序是否清晰地被描述出来。需求的优先级

第十项检查的是对软件系统的约束条件是否完整描述。需求的可测性

3.测试计划

 3.1 测试计划的作用与测试过程的关系

项目成功的四大要素：

    1. 时间：有项目计划覆盖  ，

    2. 成本：由合同覆盖，

    3.范围：由需求文档覆盖，

    4.质量：由QA计划或测试计划覆盖

测试计划通常作为关于质量的重要文档呈现给管理层。测试计划具有内部作用和外部作用

 测试计划是对测试过程的一个整体上的设计，通过收集与项目和产品相关的信息，对测试范围、测试风险进行分析，对测试用例、工作量、资源和时间等进行评估，对测试采用的策略、方法、环境、资源、进度等做出合理的安排

4.测试设计与测试用例

4.1 基于需求的测试用例设计

  在使用基于需求的测试方法的过程中，保持对需求的可追踪性非常重要。保持需求与测试用例及测试之间的可追踪性有助于监视进度、度量覆盖率，当然也有助于控制需求变更

基于需求的测试是软件测试的本质，是一种最根本的软件测试，重点关注两个问题：

  1. 验证需求是否正确、完整、无二义性，并且逻辑一致

  2. 要从“黑盒” 的角度，设计出充分并且必要的测试集，以保证设计与代码都能符合需求

需要一定的工具支持如从需求转换为测试用例、建立需求跟踪等

测试管理工具QC（Quality Center）：

    可以把需求项转换成测试计划和测试用例

     支持需求与测试用例之间的链接，可方便地统计和跟踪需求覆盖 情况

测试用例的粒度及评价

 测试用例可以写得很简单，也可以写得很复杂

  简单：是测试的纲要，仅仅指出要测试的内容

  复杂：指定输入的每项数据，期待结果以及检验的各种方法，具体到界面元素的操作步骤，指定测试的方法和工具等

方法一：临时的同行评审

方法二：用户参与评审

5.测试的执行

5.1  测试用例的合理选择与测试分工

  测试用例的选择需要考虑本次测试的上下文：

     1.是第一次测试还是回归测试

     2.测试持续的时间有多长

     3.自动化脚本的准备情况怎么样

     4.如果等到最后才能性能测试，是否会加大修改的难度

对于第一次执行的测试，一个基本的测试用例选择策略是：先执行基本的测试用例，再执行复杂的测试用例；先执行优先级高的测试用例，再执行优先级低的测试用例

对于回归测试的测试用例选择则复杂一点，因为大部分测试人员不想花费太多的时间和精力在一些已经执行过的测试用例上，但是又害怕程序员修改的地方会引发已经稳定的模块问题

测试的分工能避免测试人员的思维局限性，及时是同样一个用例，由不同的人来执行，可能会发现不同的问题

测试环境;：测试数据，网络环境，安装包，测试机器，操作系统

BVT测试：编译检查测试：源代码是否能正常编译成一个新的、完整可用的版本，缺点：覆盖率低

冒烟测试： 是对软件基本的功能进行测试，目的是确认软件基本的功能正常，保证软件系统能跑的起来

BVT-----在 build 构建完成是进行

冒烟测试-----各个阶段都有测试

BVT----可以加入自动测试脚本并执行少量固定的自动化测试

冒烟测试------与 build 的验证无关

BVT--结果直接决定新构建的 build是否交付后续测试

冒烟测试---不影响其他日常测试工作

每日构建（每晚自动构建）：

 每天定时把所有文件编译、连接、组成一个可执行的程序的过程

6.软件缺陷分析

软件缺陷分析定义和意义

定义：缺陷分析就是讲软件开发、运行过程中产生的缺陷进行必要的收集、对缺陷的信息进行分类、、汇总和统计

意义：评价开发人员编码质量、评价测试人员质量、评价软件质量、评价软件是否符合交付标准、发现过程开发过程中存在的各种问题等

软件缺陷分析流程：

  1.确定软件分析指标

  2.实施缺陷分析过程

  3.总结缺陷分析结论

缺陷分析方法：

  1. 软件缺陷分布分析（缺陷状态，缺陷类型）

  2. 软件缺陷趋势分析（收敛趋势图）

  3.注入矩阵分析

7.软件测试度量

软件的度量：对软件产品自身的测量，产生软件产品过程的测量

软件测试的度量：对软件测试的产出物，测试过程的度量

软件测试度量的目的是改进软件测试的质量，提高测试效率