软件测试流程和规范¶
第 4 章¶
软件测试流程和规范¶
标准和规范是成熟工业的标志。在手工作坊时代，每样东西都是独一无二的，即使是同一类产品，比较相似，但或多或少都有差异。而在现代工业化生产中，机器配件都是统一规范起来，例如，显示器接口、USB 接口等。再比如，家中某个电器或家具丢了个螺丝钉，在街上很容易买一个，回家安装上，这说明什么？制造业的标准在起作用。家用电器是依据标准制造的，所以随之而来的各种标准配件也会很容易找到。
标准与规范大都是行业几十年甚至上百年的经验与技术的结晶，是人类宝贵的财富。软件行业也一样，需要关注软件过程规范、软件质量标准和规范，而且也是在随着时间的推移不推更新与完善，持续改进软件过程。
本章将从软件过程模型出发，讨论传统的测试过程和敏捷测试过程，进而扩展到基于脚本的测试和探索式测试，然后讨论测试过程改进模型 TMMi、TPI, 最好讨论软件测试和质量标准、软件测试规范等。
4.1 传统的软件测试过程¶
在 2.2 节讨论软件测试分类时，已简单提到软件测试阶段，为了更清楚地了解测试过程，从两条线分别展示软件测试的基本过程，如图 4-1 所示。
即使是传统的软件开发，也提倡每日构建或持续集成，如果仅从软件代码角度看，单元测试和集成测试是同时进行的，没有单独的集成测试阶段。但如果考虑和其他子系统的集成、和第三方系统集成、和硬件集成等工作，集成测试的阶段还是独立存在的。过程的描述尽量简单，从而使读者一目了然，基本知道各个环节主要的工作，但实际许多工作是交替进行或同时进行，甚至在项目早期就已经开始。例如，系统测试和验收测试的计划、设计工作分别在需求评审、设计评审阶段就开始启动了，而系统测试和验收测试阶段，主要是测试执行的工作。
在长期的研究与实践中，人们越来越深刻地认识到，建立简明准确的表示模型是把握复杂系统的关键。为了更好地理解软件开发过程的特性，跟踪、控制和改进软件产品的开发过程，就必须为软件开发过程建立合适的模型。模型是对事物的一种抽象，人们常常在正式建造实物之前，首先建立一个简化的模型，忽略细节，剔除那些与问题无关的、非本质的东西，从而使模型与真实的实体相比更加简单明了，以便更透彻地了解它的本质，抓住主要的问题。总的来说，使用模型可以防止人们过早地陷入各个模块的细节，使人们从全局上把握系统的全貌及其相关部件之间的关系。
4.1.1 W 模型¶
Evolutif 公司针对 V 模型进行了改进，提出了 W 模型的概念，W 模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图 4-2 所示，W 模型由两个 V 字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系，测试伴随着整个软件开发周期，而且测试的对象不仅是程序，还包括需求定义文档、设计文档等，这和上面所扩展的 V 模型有相同的内涵。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
从图 4-2 可以看出，软件分析、设计和实现的过程，同时伴随着软件测试、验证和确认的过程，而且包括软件测试目标设定、测试计划和用例设计、测试环境建立等一系列测试活动的过程程。也就是说，项目一启动，软件测试的工作也就启动了，避免了瀑布模型所带来的误区 —— 软件测试是在代码完成之后进行的。测试过程和开发过程都贯穿软件过程的整个生命周期，它们是相辅相成、相互依赖的关系，概括起来有以下三个关键点。
4.1.2 TMap NEXT¶
TMap (Test Management Approach, 测试管理方法) 是一种业务驱动的、基于风险策略的、结构化的测试方法体系 (http://eng.tmap.net/Home/), 目的是更早地发现缺陷，以最小的成本，有效地、彻底地完成测试任务，以减少软件发布后的支持成本。TMap 所定义的测试生命周期由计划和控制、基础设施、准备、说明、执行和完成等阶段组成，如图 4-3 所示。这个过程目前也被 ISTQB (International Software Testing Qualification Board, 国际软件测试资质认证委员会) 所采用，成为测试过程的标准。
（6）完成阶段包括对测试资料的维护以便于再利用，创建一个最终的报告以及为了更好地控制将来的测试过程对测试过程进行评估。
TMap 提供了一个完整的、一致的、灵活的方法，可以根据特定环境创建量身订制的测试方法，以及在不同的特定环境中可以采用的通用方法，从而适合于各种行业以及各种规模的组织。TMap 通过下列三项基石：O、I、T，支持整个生命周期（L），从而构成其稳固的方法体系，如图 4-4 所示。
为了实现一个结构化良好的测试过程，各个基石应该达到一个平衡。生命周期基石是其他的中心 —— 生命周期的每个阶段都要求有特定的组织、基础设施和技术的支持。测试不仅是计算机屏幕后的测试用例执行。在真正的测试执行之前，在过程早期阶段的计划和准备活动都是必需的。这使得项目关键路径上的测试过程尽可能的短。TMap 方法体系就是基于上述思想建立起来的，其详细内容见表 4-1。
表 4-1 TMap 方法模型基本内容
| 序号 | 阶段/类别 | 活动 |
| 1 | 计划 | 完成任务安排 |
| 2 | 全局的评审和研究 | |
| 3 | 建立测试基线 | |
| 4 | 确定测试策略 | |
| 5 | 建立测试组织 | |
| 6 | 明确说明需提交的测试结果 | |
| 7 | 明确说明测试基础设施 | |
| 8 | 组织管理和控制 | |
| 9 | 建立进度表 | |
| 10 | 合并测试计划 | |
| 11 | 控制 | 维护测试计划 |
| 12 | 控制测试过程 | |
| 13 | 报告 | |
| 14 | 建立详细的测试进度表 | |
| 15 | 基础设施 | 建立测试执行、测试件管理、缺陷管理等所需的环境,包括自动化测试框架 |
| 16 | 准备 | 测试基线的可测试性评审 |
| 17 | 定义测试单元 | |
| 18 | 指定测试规格说明书的技术 | |
| 19 | 说明 | 准备测试规格说明书 |
| 20 | 定义初始的测试数据库 | |
| 21 | 开发测试脚本 | |
| 22 | 设计测试场景 | |
| 23 | 测试目标和基础设施的评审说明 | |
| 24 | 构建测试基础设施 | |
| 25 | 执行 | 测试目标和基础设施的评审 |
| 26 | 建立初始的测试数据库 | |
| 27 | 执行测试 | |
| 28 | 比较和分析测试结果 | |
| 29 | 完成 | 解散测试团队 |
TMap 为实现有效的和高效的测试过程提供了一个途径，使得软件组织可以实现关键的商业目标。
在 TMap 的基础上，还开发了一些其他的方法。所有这些方法都可以单独使用或综合起来使用。例如:
4.2 敏捷测试过程¶
什么是敏捷测试？简单地说，敏捷测试是符合敏捷测试宣言的思想、遵守敏捷开发原则，在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践。敏捷测试作为敏捷开发的组成部分，能够适应敏捷开发的流程，有效地帮助敏捷开发实现对质量的控制或促进软件产品的质量提升。敏捷测试强调测试人员的个人技能，始终保持与客户 / 用户、其他成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更关注被测系统的本身而不是测试文档（如测试计划、测试用例等）。
4.2.1 敏捷测试的特征¶
敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发 (Test-Driven Development, TDD)、验收测试驱动开发 (Acceptance Test Driven Development, ATDD)。测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化，也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，软件测试更依赖整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务、代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试 —— 一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员。敏捷测试的实践具有鲜明的敏捷开发的特征，与传统测试的区别，可以概括如下。
4.2.2 敏捷测试流程¶
在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员应尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续地对软件产品质量进行反馈。简单地说，在敏捷开发流程中，阶段性不够明显，持续测试和持续质量反
馈的特征明显，这可以通过图 4-5 来描述。
如果再具体一些，使流程更具可操作性，这里以敏捷 Scrum 为例，来介绍敏捷测试的流程。先看看 Scrum 流程，从图 4-6 中可以看出，除了最后 “验收测试” 阶段，其他过程似乎没有显著的测试特征，但隐含的测试需求和特征还是存在的。
(1) Product Backlog (发布计划，需求定义阶段), 在定义用户需求时测试要做什么？测试除了需要考虑客户的价值大小 (优先级)、工作量基本估算之外，还需要认真研究与产品相关的用户的行为模式、产品的质量需求，哪些质量特性是需要考虑的？有哪些竞争产品？这些竞争产品有什么特点 (优点、缺点等)?
(2) Sprint Backlog (迭代计划，阶段性任务分解和安排), 这时需要明确具体要实现的功能特性和任务，作为测试，这时要特别关注 “Definition of Done”, 即每项任务结束的要求 —— 即任务完成的验收标准，特别是功能特性的设计和代码实现的验收标准。ATDD 的关键一步也体现在这里，在设计、写代码之前，就要将验收标准确定下来。一方面符合测试驱动开发思想，第一次就要把事情做对，预防缺陷；另一方面持续测试和验收测试的依据也清楚了，可以快速做出测试通过与否的判断。
（3）在每个迭代 (Sprint) 实施阶段，主要完成 Sprint Backlog 所定义的任务，这时除了 TDD 或单元测试之外，应该进行持续集成测试或通常说的 BVT (Build Verification Test, 版本验证测试)。而且开发人员在设计、写代码时应认真考虑每一组件或每一代码块都具有可测试性。如果有专职的测试人员角色，一方面可以完善单元测试、集成测试框架，协助开发人员进行单元测试；另一方面可以针对新实现的功能特性进行更多的探索式测试，同时开发验收测试的脚本。如果没有专职的测试人员角色，这些事情也是要完成，只是由整个团队共同完成。虽没有工种 (开发、测试) 的分工，但也存在任务的分工。
（4）验收测试可以由自动化测试工具完成，但一般情况下，不可能做到百分之百的自动化测试。例如，易用性测试就很难由工具完成。即使对性能测试，是由工具完成，但还需要人来设计测试场景，包括关键业务选择、负载模式等。敏捷的验收测试和传统的验收测试不同，侧重对 “Definition of Done” 的验证，但基本的思想和传统开发是一致的，任何没有经过验证的产品特性是不能直接发布出去的。
4.2.3 基于脚本测试和探索式测试¶
在传统测试中受传统软件开发模型的影响，测试的流程经过测试计划、设计测试用例、执行测试用例这样经典的过程。类似于拍电影时需要剧本一样，测试用例可以看作手工执行的脚本，而工具执行测试需要像程序代码那样的自动化测试脚本，把测试用例和自动化测试脚本都可归为测试的 “脚本”。所以，传统测试多数情况都是先设计脚本，之前也没有可执行的程序，这段时间先完成设计，一旦程序可以运行，就可以进行大规模测试 (执行)—— 基于脚本的测试执行 (Scripted Test,ST)。而探索式测试 (Exploratory Test,ET) 强调测试的学习、设计和执行同时展开，也就是没有测试用例，而是靠头脑想，一面想一面测试。这里的 “想 (思考)” 就是设计，在头脑中设计，但不需要通过文字来描述出来。
无论是在传统测试还是在敏捷测试中，测试人员或多或少都会进行探索式测试，虽然在敏捷测试中探索式测试会占有更大的比重，甚至成为主导的方式，但不可能完全代替基于脚本的测试。因为，探索式测试和基于脚本的测试有各自的优势，相互补充、相互配合，才能发挥各自优势，使测试团队获得更大的收益。
1. ST 为主，ET 为辅¶
在传统开发方法中，有较为严格的需求规范和设计文档，有充分的时间去设计足够的测试用例，这时宜采用基于脚本的测试，探索式测试只是作为一种辅助的手段发现更多隐藏较深的缺陷，并成为前期阶段产品学习的途径以完善测试用例。因为在产品设计和编程阶段，测试人员拿不到可以正常工作的软件，不能进行有意义的测试执行，而把主要精力放在测试的设计上，而且有足够的需求和设计文档的支持。一旦开发完成系统集成测试，测试人员就可以全心做测试执行，由于绝大部分测试用例已就绪，测试执行效率高。
2. ET 为主，ST 为辅¶
然而，在敏捷测试中，由于迭代快、开发周期短、需求不明确、需求变化相对频繁，缺乏需求和设计的详细描述文档，探索式测试发挥更大的作用，在新功能测试中发挥主导的作用。这是因为：
（1）如果需求不明确，无法建立明确的测试结果判断准则，也就无法写成测试用例或自动化测试脚本，而是需要靠测试人员综合运用启发式判断准则，在执行过程中根据上下文 (Context) 做出判断。
(2) 如果需求变化快，脚本化的测试用例维护成本也过高，甚至是极大的浪费。
(3) 把测试过程写下来 (脚本化) 需要时间，在敏捷测试中，时间显得更为珍贵。
（4）探索式测试的倡议者还认为，测试执行过程应该是智力活动的过程，这一过程越善于思考、越流畅，越有机会发现缺陷。而用例测试方法，有太多的停顿、不够流畅，会破坏这一过程。
探索式测试都是手工方式进行 (虽然有工具支持，如辅助录制、合成报告等), 不适合工作量越来越大的回归测试。回归测试是不断重复的，在极有限的时间内完成越来越多的测试任务，回归测试绝对依赖基于脚本的自动化测试。
3. ET 与 ST 相互融合¶
探索式测试缺乏良好的系统性、复用性，可以通过角色扮演、基于场景的探索式测试来改善其系统性，也就是在执行探索式之前加入设计，即大颗粒度 Mission 和 Charter 的设计，如图 4-7 所示，说明 ET 和 ST 也是可以融合的，甚至 ET 还可以为 ST 服务。例如，在 ET 过程中，有些 ET 的执行是没有价值的，而有些 ET 的执行是有价值的，而我们关注有价值的 ET 执行，将它们记录下来，使之成为固定的测试用例，用于将来的回归测试。这样将 ET 转化为 ST，最终也能支持自动化执行，提高 ET 的复用性。
ET 对团队有更高的要求，包括测试人员的责任感、个人的能力、信任度。如果团队人员素质不满足 ET 的要求，在对团队进行培训的同时，有一段时间需要依赖 ST。如果项目测试部分是外包出去的，如果没有测试用例也是不可接受的。无论是在传统开发模式还是敏捷开发模式，都应该综合运用 ET 和 ST。根据项目、产品、团队的实际情况，确定采用什么策略，是以 ET 为主导还是以 ST 为主导；是先进行 ET 测试、后 ST 测试，还是先进行 ST 测试、后进行 ET 测试；测试团队中由哪几个人进行 ET 测试、哪几个人进行 ST 测试等等，都需要根据上下文做出明智的抉择。
4.3 软件测试学派¶
近几年，敏捷测试、探索式测试、精益测试、基于模型的测试等越来越受到人们的关注。
《软件测试：经验与教训》一书的作者 Bret Pettichord 在 2003 年将软件测试归为 4 大学派，4 年后（2007 年）又增加了一个敏捷测试学派，将软件测试分为 5 个学派，如图 4-8 所示。
（1）分析学派 (Analytic School)：认为软件是逻辑性的，将测试看作计算机科学和数学的一部分，结构化测试、代码覆盖率就是其中一些典型的例子。他们认为测试工作是技术性很强的工作，侧重使用类似 UML 工具进行分析和建模。
（4）上下文驱动学派 (Context-Driven School)：认为软件是人创造的，测试所发现的每一个缺陷都和相关利益者 (Stakeholder) 密切相关；认为测试是一种有技巧的心理活动；强调人的能动性和启发式测试思维。探索性测试就是其典型代表。
（5）敏捷学派 (Agile School)：认为软件就是持续不断的对话，而测试就是验证开发工作是否完成，强调自动化测试。TDD 是其典型代表。
标准学派和质量学派相对比较成熟，流程、过程规范等基本已建立，包括 TPI、TMMi 等比较成熟，虽然未来会有一些修改。而上下文驱动是比较自然的思路，其他学派也或多或少会从上下文去考虑，存在融合的可能性。虽然分析学派和上下文驱动学派、敏捷学派有一定对立关系，但它们相互之间又会有更多的交融，而且敏捷方法主要以实践为基础，敏捷测试不是原发性的，而是先有敏捷开发。然后人们被动地寻求测试方法和技术来适应敏捷开发。敏捷测试缺乏自己独立的理论根基，更多地依赖于上下文驱动学派的支持，包括探索式测试和自动化测试。其中，自动化测试是敏捷测试主打的王牌，没有自动化测试就没有敏捷测试，而自动化测试和持续集成、持续测试也相当吻合。
也有其他学者提出不同的看法，把软件测试学派分为工厂学派、控制学派、测试驱动学派、分析学派和上下文驱动学派。其中，分析学派和上下文驱动学派和上面那种划分基本重合，不同的是前面三个学派，但也有一定的映射关系。
（1）工厂学派 (Factory School)：强调将测试任务演化为一系列的操作过程，然后这些操作过程自动化以后，获得廉价的劳动力来执行测试。
(2) 控制学派 (Control School): 强调标准和依据标准建立的流程，相当于上面的标准学派。
（3）测试驱动学派 (Test-driven School)：强调以代码为焦点的测试，且程序员执行测试，相当于敏捷测试。
（4）分析学派：为了评估软件质量而采用分析的方法，其中包括通过提高需求规格说明书的准确性、各种建模来提高可测试性。
(5) 上下文驱动学派：强调适应软件开发及应用所处的环境。
展望未来，测试的学派还会发生一些变化。工厂学派可以发展成全自动化测试生产线，形成基于模型的自动化测试：以传统测试的分析学派为基础，强调从需求分析开始，为需求或用户行为构建模型，然后基于模型自动产生和执行测试用例，它更适用于关键系统的验证。基于模型的测试也会促进自动化测试的发展，这两者之间是相辅相成的。没有测试建模的支持，自动化测试靠完全模拟手工的操作方式来实现，其实现和维护代价将相当大，使之投入产出比 (ROI) 总是不够理想，阻碍自动化测试的发展。当自动化测试能够借助基于模型的测试，那么自动化测试将事半功倍、如鱼得水，ROI 自然也会很高。基于模型的测试，最终也需要工具的支持，如 Pairwise、因果分析法等。如果没有工具支持，测试人员就会感觉很累而不愿应用。
基于云服务的测试模式：非关键系统在前期系统架构设计和代码实现上可借助良好的开发框架与工具、单元测试和持续集成等工作，在没有专职测试团队的工作情况下，也能保证产品质量处在一个基本可用的水平。然后，利用上述的公有云服务模式来完成更深度的测试，如可用性测试、配置测试、兼容性测试、性能测试都可以在云平台上自动完成。剩余的功能测试（包括业务流测试、场景测试等）就可以交给大众，通过远程服务完成测试。这些测试人员可能是业余志愿者，也可能是在家工作的专业测试人员，按任务领取报酬。
测试公有云提供公共的、开放的测试服务，像 UTest、SOASTA、SauceLab 和 Testin 等，可以完成手机应用、Web 应用或其他应用的功能测试、兼容性测试、配置测试和性能测试等。
而测试私有云是某个企业为自己建立的云测试服务，将测试机器资源、测试工具等都放在云端，公司的各个团队都可以共享所有测试资源，完成从自动分配资源、自动部署到测试结果报告生成的测试过程，而且还能将测试流程、测试管理等固化在私有云内。
4.4 基于风险的测试策略¶
从质量风险维度来看，软件测试可以被定义为 “对软件系统中潜在的各种风险进行评估的活动”。软件测试自身的风险性是公认的，测试的覆盖度不能做到 100%。测试的这种风险定义一方面源于这层含义，另外软件测试的标准有时不清楚，“软件规格说明书 (Specification/Spec)” 是其中的一个标准，但也不是唯一的，因为 Spec 中有些内容完全有可能是错误的，软件的社会性、用户的心理特性、用户直觉体验等都很难在 Spec 中被描述说明。所以，常常强调软件测试人员应该站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对产品的 Spec 去报 Bug。但是，测试在大多数时间 / 情况下，是由工程师完成，而不是客户自己来做，所以又怎么能保证工程师和客户想得一样呢？
有人把开发比作打靶，目标明确，就是按照 Spec 去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞；如果只捞大鱼 (严重缺陷), 网眼就可以大些、撒网区域相对比较集中 (测试点集中在主要功能)。如果想把大大小小的鱼都捞上来，网眼就要小、普遍撒网，不放过任何一块区域 (测试点遍及所有功能)。
基于风险的测试是指评估测试的优先级，先进行高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。基于风险的测试，也就是根据事情的轻重缓急来决定测试工作的重点和工作的顺序，而影响测试优先级的因素主要是:
(1) 该功能出问题对用户的影响有多大？对用户的影响越大，其优先级越高。
（2）出问题的概率有多大？概率越大，优先级越高。这种概率受功能模块的复杂性、代码质量的影响。复杂性越高或代码质量越低，问题发生的概率就越大。
还有其他一些影响因素，例如，新功能或修改的功能对该功能是否有很高的依赖性？依赖性越高，优先级越高。影响测试优先级的两个关键因素，可以通过图 4-9 来表示。横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到
的功能，出问题的概率很小，就算出了问题的影响也不是很大，如果时间比较紧，就可以考虑不测试。软件产品的风险度可以通过出错的影响程度和出现的概率来计算，测试可以根据不同的风险度来决定测试的优先级和测试的覆盖率。基于风险的测试过程可以归纳为以下几个步骤。
4.5 测试过程改进¶
随着软件产业界对软件过程的不断研究，美国工业界和政府部门开始认识到，软件过程能力的不断改进才是增强软件组织的开发能力和提高软件质量的第一要素。在这种背景下，由美国卡内基・梅隆大学软件工程研究所 (SEI) 研制并推出了软件能力成熟度模型 (Software-Capacity Maturity Model,SW-CMM),CMM 逐渐成为评估软件开发过程的管理以及工程能力的标准。现在，形成了以个体软件过程 (Personal Software Process,PSP)、团队软件过程 (Team Software Process,TSP)、过程成熟度集成模型 CMMI 等为主导的软件开发过程改进体系。
但是，CMMI 没有提及软件测试成熟度的概念，没有充分讨论如何改进测试过程，所以，许多研究机构和测试服务机构从不同角度出发提出有关软件测试方面的能力成熟度模型，作为对 SEI-CMMI 的有效补充，比较有代表性的成功案例有以下几个。
下面首先讨论 TMM, 然后再讨论其他测试过程改进模型，如 TPI 等。
4.5.1 TMMi¶
过程能力描述了遵循一个软件测试过程可能达到的预期结果的范围。了解过程能力对于预测产品质量是十分关键的。组织的过程能力为组织承担新项目时能否达到期望结果提供了预测依据。一个稳定的、可预测的过程必须具有一致的执行，而当一个过程不稳定时，通常由检查过程一致性开始来找出问题的根本原因。经验表明，过程一致性检查可从下面三个方面来实施。
测试是软件开发过程中一个重要组成部分，并为高质量的软件产品开发提供大力支持。许多组织都没有意识到测试流程的全部潜力，因为这些过程往往不成熟。伊利诺斯技术研究所 (Illinois Institute of Technology) 的 TMM 正是解决这个问题，借助这个测试成熟度模型，可以协助评估和改善其软件测试流程软件组织。TMM 的建立，得益于以下三点。
TMM 也将测试过程成熟度分为 5 个等级 —— 初始级、定义级、集成、管理 & 度量、优化等，如图 4-10 和表 4-2 所示。每一个等级都包括已定义的过程域，组织在升级到更高一个等级之前，需要完全满足前一个等级的过程域。要达到特定的等级需要实现一系列的预先定义好的成熟度目标和附属目标。这些目标根据活动、任务和责任等进行定义，并依据管理者、开发人员、测试人员和客户或用户的特殊需求来进行。TMM 由以下两个主要部分组成。
表 4-2 目前测试成熟度模型的基本描述
| 级别 | 简单描述 | 特征 | 目标 |
| 1 | Initial(初始级)测试处于一个混乱的状态,缺乏成熟的测试目标,测试处于可有可无的地位 | 还不能把测试同调试分开;编码完成后才进行测试工作;测试的目的是表明程序没有错;缺乏相应的测试资源 | |
| 2 | Phase Definition(阶段定义级)测试目标是验证软件符合需求,会采用基本的测试技术和方法 | 测试被看作是有计划的活动;测试同调试分开;但编码完成后才进行测试工作 | 启动测试计划过程;为基本的测试技术和方法制度化 |
| 3 | Integration(集成级)测试不再是编码后的一个阶段,而是把测试贯穿在整个软件生命周期中。测试是建立在满足用户或客户的需求上 | 具有独立的测试部门;根据用户需求设计测试用例;有测试工具辅助进行测试工作;没有建立起有效的评审制度;没有建立起质量控制和质量度量标准 | 建立软件测试组织;制定技术培训计划;测试在整个生命周期内进行;控制和监视测试过程 |
| 4 | Management and Measurement(管理和度量级)测试是一个度量和质量控制过程。在软件生命周期中评审作为测试和软件质量控制的一部分 | 进行可靠性、可用性和可维护性等方面的测试;采用数据库来管理测试用例;具有缺陷管理系统并划分缺陷的级别;还没有建立起缺陷预防机制,且缺乏自动地对测试中产生的数据进行收集和分析的手段 | 实施软件生命周期中各阶段评审;建立测试数据库并记录、收集有关测试数据;建立组织范围内的评审程序;建立测试过程的度量方法和程序;软件质量评价 |
| 5 | Optimization(优化级)具有缺陷预防和质量控制的能力;已经建立起测试规范和流程,并不断地进行测试过程改进 | 运用缺陷预防和质量控制措施;选择和评估测试工具存在一个既定的流程;测试自动化程度高;自动收集缺陷信息;有常规的缺陷分析机制 | 应用过程数据预防缺陷;统计质量控制;建立软件产品的质量目标;持续改进测试过程;优化测试过程 |
（1）5 个别级的一系列测试能力成熟度的定义，每个级别的组成包括到期目标、到期子目标活动、任务和职责等。
(2) 一套评价模型，包括一个成熟度问卷、评估程序和团队选拔培训指南。
TMMi 基础 (参见 www.tmmifoundation.org) 定义了 TMM 的接替标准 TMMi。TMMi 是基于 TMM 框架延伸的、针对测试过程改进更细节化的模型。TMMi 是由伊利诺斯州的技术组织开发的，总结了 TMM 和 CMMI 当中相应过程域的实践经验，包含以下两个主要文档。
4.5.2 TPI NEXT¶
TPI 是业务驱动的、基于连续性表示法的测试过程改进的参考模型，是在软件控制、测试知识以及过往经验的基础上开发出来的。TPI 模型用于支持测试过程的改进，包括一系列的关键域、生命周期、组织、基础设施、工具及技术，并可以用于了解组织内测试过程的成熟度。在这个基础上，该模型帮助我们定义了渐进的、可控的改进步骤。TPI 模型的构成如图 4-11 所示。
1. 关键域¶
TPI 模型考虑了测试过程的各个方面，如测试工具的使用，设计技术或报告。通过对不同方面的评估，测试过程的优点和缺点都变得清晰，这些方面被称为关键域。测试过程分为 16 个测试组织需要明确的关键域，基线和改进建议都是基于以下 16 个关键域进行的。
2. 级别¶
为了了解过程在每个关键域所处的状态，即对关键域的评估结果，通过级别来体现。模型提供了 12 个级别，由 A 到 M,A 是最低级。根据测试过程的可视性改善、测试效率的提高或成本的降低以及质量的提高，级别会有所上升。例如，对于关键域 “报告”,4 个级别分别如下。
对于部分关键域的某些级别描述，如表 4-3 所示 (仅供参考，来自 TPI, 非 TPI NEXT)。如果关键领域非常不成熟，也有可能达不到初始 A 级的要求。有些关键领域可能只能评为 A 或者 B (如 “估算和计划”), 而其他 (如 “度量与分析”) 的评级范围可以是 A、B、C 或者 D。对于给定的关键领域评估，可通过对 TPI 模型所定义的检查点进行评估实现。例如，当关键领域所要求的检查点都满足了 A 级和 B 级的要求，那么这个关键域就达到了 B 级。
TPI 模型定义了众多过程和等级之间的依赖关系。这些依赖关系保证了测试过程的均衡发展。例如，如果关键域 “报告” 没有相应地达到 A 级，那么关键领域 “度量与分析” 也就不可能达到 A 级，因为如果没有测试报告，度量与分析就没有意义。对于依赖关系的使用，在 TPI 模型当中是可选的。
表 4-3 TPI 部分关键域不同级别的要求
| 关键域\级别 | A | B | C | D |
| 测试策略 | 单个高层测试的策略 | 高层测试的组合策略 | 高层测试和底层测试或评估的组合策略 | 所有测试和评估的组合策略 |
| 介入程度 | 测试基线完成后 | 测试基线开始 | 需求定义开始 | 项目启动 |
| 估算和计划 | 被证实的估算和计划 | 统计意义上被证实的估算和计划 | ||
| 度量 | 项目度量(产品) | 项目度量(过程) | 系统度量 | 组织度量(>1个系统) |
| 测试自动化 | 工具的使用 | 可管理的测试自动化 | 优化的测试自动化 | |
| 测试环境 | 可管理和可控制的环境 | 最适合测试的环境 | 按需的环境(on-demand) | |
| 承诺与动力 | 预算和时间的分配 | 测试和项目组织的集成 | 测试-工程 | |
| 测试方法应用 | 项目特定的 | 组织通用的 | 组织不断优化的(R&D,研发) | |
| 沟通 | 内部通信 | 项目沟通(缺陷、变更控制) | 围绕测试流程质量的组织内沟通 | |
| 报告 | 缺陷 | 进展(测试和产品的状态)、活动(成本、时间和里程碑)、具有优先级的缺陷 | 经过度量数据呈现的风险、建议 | 具有软件过程改进特性的建议 |
| 缺陷管理 | (测试团队)内部的缺陷管理 | 具有灵活报告机制的外部缺陷管理 | 项目缺陷管理 | |
| 测试件管理 | 内部的测试件管理 | 测试基线和测试对象的外部管理 | 可复用的测试件 | 从系统需求到测试用例的可追溯性 |
| 测试过程管理 | 计划和执行 | 计划、执行、监控和调整 | 组织内的监控和调整 |
3. 测试成熟度矩阵¶
测试成熟度矩阵提供了关键域各个等级 (A/B/C/D) 和总体测试过程成熟度等级的映射关系，如表 4-4 所示，这可以很好地帮助我们定义内在的优先级，以及级别和关键域之间的依赖关系。每个级别都关联到测试成熟度一个特定的度量尺度，它被分为 13 种尺度。由这些微小的尺度构成总体等级，总体等级包括：可控的、有效的和不断优化的。
表 4-4 各个关键域不同级别的要求
| 总体等级关键域 | 可控的 | 有效的 | 不断优化的 | |||||||||||
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | |
| 测试策略 | A | B | C | D | ||||||||||
| 生命周期模型 | A | B | ||||||||||||
| 介入时间 | A | B | C | D | ||||||||||
| 估计和计划 | A | B | ||||||||||||
| 测试规格技术 | A | B | ||||||||||||
| 静态测试技术 | A | B | ||||||||||||
| 度量 | A | B | C | D | ||||||||||
| 测试自动化 | A | B | C | |||||||||||
| 测试环境 | A | B | C | |||||||||||
| 办公环境 | A | |||||||||||||
| 承诺与动力 | A | B | C | |||||||||||
| 测试功能与培训 | A | B | C | |||||||||||
| 方法的范围 | A | B | C | |||||||||||
| 沟通 | A | B | C | |||||||||||
| 报告 | A | B | C | D | ||||||||||
| 缺陷管理 | A | B | C | |||||||||||
| 测试件管理 | A | B | C | D | ||||||||||
| 测试过程管理 | A | B | C | |||||||||||
| 评估 | A | B | ||||||||||||
| 底层测试 | A | B | C | |||||||||||
4. 检查点¶
为了能客观地决定各个关键域的级别，TPI 模型提供了一种度量工具 —— 检查点。每个级别都有若干个检查点，测试过程只有在满足了这些检查点的要求之后，才意味着它达到了特定的级别。
例如，关键域 “沟通” 级别 A——“内部沟通” 的检查点有:
（1）测试团队内部是否有一个定期的会议，会议有固定的日程安排并集中讨论测试进度和测试对象的质量？
(2) 每个团队成员是否定期参加会议？
(3) 执行偏离计划是否和团队沟通并记录在案？
而同一关键域 “沟通” 级别 B——“项目沟通” 的检查点，除了上述级别 A 的三个检查点之外，还要检查：
(6) 在定期的缺陷分析和解决会议上，测试团队和其他团队的代表是否都参与？
(7) 变更控制是否认真考虑了对测试工作的影响？
在 TPI 的评估过程当中，将会使用定量的度量和定性的访谈以建立测试过程成熟度等级。
5. 建议¶
检查点帮助我们发现测试过程中的问题，而建议会帮助我们解决问题，最终改进测试过程。建议不仅包含对如何达到下个级别的指导，而且还包括一些具体的操作技巧、注意事项等。例如，针对关键域 “沟通” 级别 A——“内部沟通” 的建议有:
（1）要求每个测试团队的成员定期评估测试流程，提出哪些地方执行得很好、哪些地方需要改进；
(2) 在会议中提出的一些措施要得到一致的处理或一贯的执行；
(3) 项目安排都应该在会议上宣布。
4.5.3 CTP¶
关键测试过程 (Critical Test Process, CTP) 评估模型主要是一个内容参考模型，一个上下文相关的方法，并能对模型进行裁剪，包括:
(1) 特殊挑战的识别。
(2) 优秀过程属性的识别。
(3) 过程改进实施顺序和重要性的选择。
使用 CTP 的过程改进，始于对现有测试过程的评估，通过评估以识别过程的强弱，并结合组织的需要提供改进的意见。CTP 识别了 12 个关键测试过程，通过实施这些关键过程，来改进测试过程，造就成功的测试团队。不同特定背景下的评估不同，但一般而言，CTP 评估将对下列数量相关的度量与分析进行检查。
(1) 缺陷发现率。
(2) 投资回报率。
(3) 需求覆盖率和风险覆盖率。
(4) 测试发布管理费用。
(5) 缺陷报告拒绝率。
CTP 评定过程中通常对下面的质量因素进行评估。
(1) 测试小组角色和效率。
(2) 测试计划效用。
(3) 测试小组测试水平，背景知识和技术。
(4) 缺陷报告效率。
(5) 测试结果报告效率。
(6) 变更管理效率和平衡。
评估过程中识别出薄弱过程域后，需要开始制定改进计划。模型为每个关键测试过程提供了通用改进计划，但评估小组需要对它们进行合适的裁剪。
曾任 ISTQB 主席的 Rex Black 写过一本 CTP 的书，书名就是 Critical Testing Processes。在这本书中，展示了管理测试项目的 4 个关键过程 —— 计划 (Plan)、准备 (Prepare)、执行 (Perform) 和完善 (Perfect), 可以说是 4P。4P 可能受到著名的质量大师 W. E. Deming 的 PDCA (Plan-Do-Check-Act, 计划 - 执行 - 检查 - 改进) 循环的启发，虽然两者有比较大的差异。
4P 关键过程可分成实践和管理这两个部分，计划和完善主要是管理工作，准备和执行是实践工作，强调在早期计划和准备阶段投入了大量的时间与精力，因为认真细致的计划将使测试的实际执行平滑和迅速。
（1）计划 (Plan)，主要关注做好测试的项目管理，包括如何和其他团队达成一致的意见，有效地解决问题，避免冲突。
① 分析风险，决定测试的重点。
② 评估测试的时间和成本。
③ 分析预算并评估测试的投资回报 (减少的劣质成本 / 测试的成本)。
④ 使参与工作的每个成员在评估方面达成一致。
⑤ 计划测试。
(2) 准备 (Prepare), 从管理人员签订总体计划到测试团队开始执行测试用例的过程。这个阶段主要工作是人员聘用、团队建设和培训、建立测试制度和衡量测试覆盖率等问题，包括如何面对不清晰的需求定义，如何在进度、预算和质量之间获得平衡。
（3）执行 (Perform)，讨论测试团队如何与发布工程或者配置管理团队合作，以及产品构建怎样移交到测试团队的信息。因为每一项都很好地计划并预先充分地准备，所以，执行就比较容易，虽然现实中测试执行可能是最长的阶段。
（4）完善 (Perfect)，完成产品的测试和改进测试过程，包括如何发现、报告并响应问题，以及缺陷处理过程中如何有效沟通。
如果进一步细分，软件测试还可以分为如下 12 个子关键过程。
① 测试；
② 建立上下文关系和测试环境；
③ 质量风险评估；
④ 测试估算；
⑤ 测试计划；
⑥ 测试团队开发；
⑦ 测试 (管理) 系统开发；
⑧ 测试发布管理；
⑨ 测试执行；
⑩ 缺陷报告；
⑪ 测试结果报告；
⑫ 变更管理。
4.5.4 STEP¶
STEP (Systematic Test and Evaluation Process, 系统化测试和评估过程) 是一个内容参考模型，认定测试是一个生命周期活动，在明确需求后开始直到系统退役。STEP 提倡通过测试在软件开发生命周期早期介入来改进质量，而不是作为编程结束之后的一项关键活动，以确保更早地发现缺陷，包括发现由需求定义、设计规格说明书和设计等引入的缺陷。
STEP 与 CTP 比较类似，而不像 TMMI 和 TPI, 并不要求改进需要遵循特定的顺序。某些情况下，STEP 评估模型可以与 TPI 成熟度模型结合起来使用。STEP 的实现途径是使用基于需求的测试方针以保证在设计和编码之前，已经设计了测试用例以验证需求规格说明。
该方法识别并关注测试中的以下三个主要阶段。
STEP 方法的基本前提包括以下几个。
STEP 的评估过程中，使用定量的度量和定性的访谈。定量的度量和分析包括以下几方面。
量化的因子包括以下两个。
详细内容，可以参考 Rick Craig 和 Stefan P. Jaski 所著的 Systematic Software Testing (有中文译本《系统的软件测试》)。
4.6 软件测试规范¶
一个完整的软件测试规范，应该包括规范本身的详细说明，比如规范目的、范围、文档结构、词汇表、参考信息、可追溯性、方针、过程 / 规范、指南、模板、检查表、培训、工具、参考资料等。这里主要参考 GBT 15532—2008《计算机软件测试规范》来介绍软件测试规范，包括软件测试的每个子过程中测试人员的角色、职责、活动描述及所需资料。
1. 角色¶
任何项目的实施首先要考虑的是人的因素，对人的识别与确认，软件测试尤其不能例外。在软件测试中，通常会把所有涉及人员进行分类以确立角色，并按角色进行职责划分。通常会按表 4-5 的方式进行划分。
表 4-5 软件测试中最基本的角色定义
| 测试分析人员 | 制定和维护测试计划,设计测试用例及测试过程,生成测试分析报告 |
| 测试人员 | 执行集成测试和系统测试,记录测试结果 |
| 设计人员 | 设计测试需要的驱动程序和桩程序 |
| 编码人员 | 编写测试驱动程序和桩程序,执行单元测试 |
2. 进入准则¶
进入准则也就是对软件测试切入点的确立。通过前几章的学习，我们知道，软件测试实质上是伴随 SQA 整体活动，在软件开发周期的各个阶段都在进行的，因此软件项目立项并得到批准就意味着软件测试的开始。
3. 输入项¶
软件测试需要相关的文档作为测试设计及测试过程判断符合性的依据和标准，对于需要进行专业的单元测试的项目还要有程序单元及软件集成计划相应版本等文档资料。这些文档一并作为测试的输入，如表 4-6 所示。
表 4-6 软件测试输入项
| 软件项目计划 | 软件项目计划是一个综合的组装工件,用来收集管理项目时所需的所有信息 | 《项目开发计划》 |
| 软件需求文档 | 描述软件需求的文档,如软件需求规约(SRS)文档或利用CASE工具建模生成的文档 | 《需求规格说明书》 |
| 软件构架设计文档 | 构架设计文档主要描述备选设计方案、软件子系统划分、子系统间接口和错误处理机制等 | 《概要设计说明书》 |
| 软件详细设计文档 | 详细设计文档主要描述将构架设计转化为最小实施单元,产生可以编码实现的设计 | 《详细设计说明书》 |
| 软件程序单元 | 包括所有编码员完成的程序单元源代码 | |
| 软件集成计划 | 软件工作版本的定义、工作版本的内容、集成的策略以及实施的先后顺序等 | |
| 软件工作版本 | 按照集成计划创建的各个集成工作版本 |
4. 活动¶
1) 制定测试计划¶
角色：测试设计员。
活动描述：
参考文档：《软件测试计划模板》。
2）测试设计¶
角色：测试设计员、设计员。
活动描述：设计测试的目的是为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程。
(1) 设计测试用例。
(2) 开发测试过程。
(3) 设计单元测试和集成测试需要的驱动程序和桩程序。
参考文档：《软件测试用例》模板，《软件测试过程》模板。
3）实施测试
角色：测试设计员、编码员。
活动描述：实施测试的目的是创建可重用的测试脚本，并且实施测试驱动程序和桩程序。
4）执行单元测试
角色：编码员和测试人员
活动描述：执行单元测试的目的是验证单元的内部结构以及单元实现的功能。
参考文档：《测试日志》和《软件单元测试》。
5）执行集成测试
角色：测试员。
活动描述：执行集成测试的目的是验证单元之间的接口以及集成工作的功能、性能等。
6) 执行系统测试
角色：测试员。
活动描述：执行系统测试的目的是确认软件系统工作版本满足需求。
(3) 对修改后的软件系统版本执行回归测试。
7) 评估测试¶
角色：测试设计员和相关组。
活动描述：评估测试的目的是对每一次测试结果进行分析评估，在每一个测试阶段提交测试分析报告。
（1）由相关组对一次测试结果进行分析，并提出变更请求或其他处理意见。
(2) 分析阶段测试情况：
① 对每一个阶段的测试覆盖情况进行评估。
② 对每一个阶段发现的缺陷进行统计分析。
③ 确定每一个测试阶段是否完成测试。
④ 对每一个阶段生成测试分析报告。
5. 输出项¶
软件测试输出项见表 4-7。
表 4-7 软件测试输出项
| 输出项 | 内容描述 | 形成的文档 |
| 软件测试计划 | 测试计划包含项目范围内的测试目的和测试目标的有关信息。此外,测试计划确定了实施和执行测试时使用的策略,同时还确定了所需资源 | 软件测试计划模板 |
| 软件测试用例 | 测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合 | 软件测试用例模板 |
| 软件测试过程 | 测试过程是对给定测试用例(或测试用例集)的设置、执行和结果评估的详细说明的集合 | 软件测试过程模板 |
| 测试结果日志 | 测试结果是记录测试期间测试用例的执行情况,记录测试发现的缺陷,并且用来对缺陷进行跟踪 | 测试日志模板 |
| 测试分析报告 | 测试分析报告是对每一个阶段(单元测试、集成测试、系统测试)的测试结果进行的分析评估 | 测试分析报告模板 |
6. 验证与确认¶
软件测试验证与确认项见表 4-8。
表 4-8 软件测试验证与确认项
| 验证与确认内容 | 内容描述 |
| 软件测试计划评审 | 由项目经理、测试组、其他相关测试计划进行评审 |
| 软件测试用例评审 | 由测试组、其他相关组对测试用例进行评审 |
| 软件测试过程评审 | 由测试组、其他相关组对测试过程进行评审 |
| 测试结果评估 | 由测试组、其他相关组对测试结果进行评估 |
| 测试分析报告评审 | 由项目经理、测试组、其他相关组对测试分析报告进行评审 |
| SQA 验证 | 由 SQA 人员对软件测试活动进行审计 |
7. 退出准则¶
满足组织 / 项目的测试停止标准。
8. 度量¶
软件测试活动达到退出准则的要求时，对于当前版本的测试即告停止。度量工作一般由 SQA 人员通过一系列活动收集数据，利用统计学知识对软件质量进行统计分析，得出较准确的软件质量可靠性评估报告，提供给客户及供方高层领导可视化的质量信息。
小结¶
本章通过介绍软件测试过程模型，帮助读者完整地了解软件测试的过程，包括传统的软件过程和敏捷软件过程，掌控软件测试的全局，能够灵活运用基于脚本的测试和基于探索式测试，有利于以后各章内容的学习，融会贯通。
在了解软件测试过程的基础上，如何借助 TMM、TPI 来改进测试模型，掌握测试过程改进模型的知识是非常重要的，会不断启发我们思考，做好各项测试工作。软件测试规范是测试工作的依据和准则，在测试标准约束下和测试规范指导下，完成测试计划、设计、执行和软件产品的质量评估，从根本上保证软件测试工作的质量，进而保证软件产品的质量，降低企业的成本，最终使企业具有良好的竞争力。
思考题¶
第 2 篇¶
软件测试的技术¶
在实际项目的测试过程中，会面对许多复杂的问题和具体的困难，不仅采用前面所学的方法，还要拥有很好的技术，熟悉业务领域知识，深入系统架构、设计模式和开发框架，灵活运用测试工具，才能真正解决问题。
在这一篇，将详细介绍单元测试与集成测试、系统测试和验收测试中所要掌握的技能，以及软件本地化测试、自动化测试脚本开发技能等内容，共有 5 章。
第 5 章 单元测试与集成测试
第 6 章 系统测试
第 7 章 验收测试
第 8 章 软件本地化测试
第 9 章 测试自动化及其框架