第四章——软件测试流程和规范

第四章 软件测试流程和规范

学完本章应该明白要做测试或者验证应该分几步，每一步应该干什么，明确一个流程。这个流程是比较标准化的。

本章将从软件过程模型出发，讨论传统的测试过程和敏捷测试过程，进而扩展到基于脚本的测试和探索式测试，然后讨论测试过程改进模型

     T 
    
   
     M 
    
   
     M 
    
   
     i 
    
   
     , 
    
   
     T 
    
   
     P 
    
   
     I 
    
   
     , 
    
   
  
    TMMi,TPI, 
   
  
TMMi,TPI,最后讨论软件测试和质量标准、软件测试规范等。

4.1 传统的软件测试过程

第一行是从软件过程来看
第二行是从项目管理来看
在长期的研究与实践中，越来越深刻的认识到，建立简明准确的表示模型是把握复杂系统的关键。为了更好的理解软件开发过程中的特性，跟踪、控制和改进软件产品的开发过程，就必须为软件开发过程建立合适的模型。

4.1.1 W模型

针对V模型进行了改进，提出了W模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示了测试与开发的并行关系，测试伴随着整个软件开发周期，而且测试的对象不仅是程序，还包括需求定义文档，设计文档等。这和上面所扩展的V模型有相同的内涵。

传统的瀑布模型误区：软件测试是在代码完成之后进行的 XXX
测试过程和开发过程都贯穿软件过程的整个生命周期，它们是相辅相成，相互依赖的关系。

1. 测试和开发过程同步，同时开始，同时结束
2. 两者相互依赖，前期测试更多依赖开发，后期开发更多依赖测试
3. 测试过程中的工作重点和开发过程中的工作重点不同，侧重角度不同。

4.1.2 TMap NEXT

Test Management Approach，测试管理方法，是一种业务驱动的，基于风险策略的，结构化的测试方法体系，目的是更早的发现缺陷，以最小的成本，有效的，彻底的完成测试任务。
TMap定义的测试生命周期包括：计划和控制，基础设施，准备，说明，执行和完成等阶段。

接下来这个表格比较重要，大概描述了整个测试的流程。

4.2 敏捷测试过程

4.2.1 敏捷测试特征

敏捷测试具有鲜明的敏捷开发特征。

1. 传统测试将开发和测试分开，而敏捷测试可以是全民测试，强调整个团队对测试负责
2. 传统测试更具有阶段性，一步接着一步，敏捷测试团队每天都在一起工作，全程所有人参与
3. 传统测试强调计划性，敏捷测试强调测试的速度和适应性
4. 敏捷测试以客户需求为中心，每时每刻不离客户需求
5. 敏捷测试关注产品本身，总之就是没有那么流程化，专注于客户需求
6. 敏捷测试要求高度的自动化测试，自动化测试是敏捷测试的基础

4.2.2 敏捷测试流程

在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。简单的说，在敏捷开发流程中，阶段性测试不够明显，持续测试和持续质量反馈的特征明显。

这里以Scrum为例，介绍敏捷测试的流程，先看看Scrum流程，从图4-6可以看出，除了最后验收测试阶段，其他过程似乎没有显著的测试特征，但隐含的测试需求和特征还是存在的。

1. product backlog，发布计划，需求定义阶段。测试要考虑客户的价值大小，工作量基本估算。研究与产品相关的用户的行为模式。
2. Sprint Backlog，迭代计划，阶段性任务分解和安排，作为测试，要关注每项任务完成的验收标准
3. Sprint,迭代实施阶段，除了单元测试外，还有集成测试
4. 验收测试，由自动化工具完成。

4.2.3 基于脚本测试和探索式测试

传统测试多数情况是先设计脚本，之前也没有可执行的程序，，这段时间先完成设计，一旦程序可以运行，就可以进行大规模测试——基于脚本的测试执行（Scripted Test）

而 探索式测试（Exploratory Test） 强调测试的学习，设计和执行同时展开，也就是没有测试用例，靠头脑想一边想一边测试。

传统测试中ST为主，ET为辅
敏捷测试中ET为主，ST为辅

4.3 软件测试学派

软件测试分为了五个学派

1. 分析学派
2. 标准学派
3. 质量学派
4. 上下文驱动学派
5. 敏捷学派

4.4 基于风险的测试策略

软件测试的风险性说公认的，测试的覆盖度不能做到100%。把开发比作打靶，目标明确，就是按照spec去实现系统的功能。而把测试比作捞鱼，目标不明确。
基于风险的测试是指评估测试的优先级，先进行高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。

基于风险的测试过程可以归纳为以下几个步骤：

1. 列出软件的所有功能和特性
2. 确保每个功能出错的可能性
3. 如果某个功能出错或欠缺某个特征，需要评估对用户使用软件产品的影响程度
4. 根据上面两个步骤，计算风险度
5. 根据可能出错的迹象，来修改风险度
6. 决定测试的范围，编写测试方案

4.5 测试过程改进

由美国卡内基梅隆大学软件工程研究所研制并推出了软件能力成熟度模型CMM，CMM逐渐成为评估软件开发过程的管理以及工程能力的标准。现在，形成了以个体软件过程（PSP），团队软件过程（TSP），过程成熟度集成模型CMMI等为主导的软件开发过程改进体系。

但是，CMMI没有提及软件测试成熟度的概念，没有充分讨论如何改进测试过程，所以，许多研究机构从不同角度出发提出有关软件测试方面的能力成熟度模型，作为对SEI-CMMI的补充，

4.5.1 TMMi

将测试分为5个等级，初始级，定义级，集成，管理&质量，优化

4.5.2 TPI NEXT

TPI是业务驱动的，基于连续性表示法的测试过程改进的参考模型，是在软件控制，测试知识以及过往经验的基础上开发出来的。TPI模型用于支持测试过程的改进。包括一系列的关键域，生命周期，组织，基础设施，工具及技术，并可以用于了解组织内测试过程的成熟度。

1. 关键域：通过对不同方面的评估，测试过程的优点和缺点都变得清晰，这些方面称为关键域。
2. 级别：为了了解过程在每个关键域所处的状态，即对关键域的评估结果，通过级别来体现。模型提供了12个级别，由A到M，A是最低级。
3. 测试成熟度矩阵，太过抽象了。
4. 检查点
5. 建议

4.5.3 CTP

关键测试过程评估模型主要是一个内容参考模型，一个上下文相关的方法。

4.5.4 STEP

系统化测试和评估过程是一个内容参考模型，认定测试是一个生命周期活动。

4.6 软件测试规范

一个完整的软件测试规范，应该包括规范本身的详细说明，比如规范目的、范围、文档结构等。

1. 角色：对人员进行分类分工
2. 进入准则：对软件测试切入点的确立
3. 输入项：需要相关的文档作为测试设计及测试过程判断符合性的依据和标准。
4. 活动
5. 输出项目
6. 验证与确认
7. 退出准则
8. 度量

小结

本章介绍了软件测试过程模型，更完整的了解了软件测试的过程，包括传统的软件测试过程和敏捷测试过程，掌控软件测试的全局，能够灵活运用基于脚本的测试和基于探索式测试，有利于以后各章内容的学习，融会贯通。

在了解软件测试过程的基础上，如何借助TMM、TPI来改进测试模型，掌握测试过程改进模型的知识是非常重要的，会不断启发我们思考，做好各项测试工作。软件测试规范是测试工作的依据和准则，在测试标准约束下和测试规范指导下，完成测试计划，设计，执行和软件产品的质量评估，从根本上保证软件测试工作的质量，进而保证软件产品的质量，降低企业的成本，最终使企业具有良好的竞争力。