测试反模式-有效规避常见的92种测试陷阱

内容简介

《测试反模式：有效规避常见的92种测试陷阱》是作者35年软件和系统工程经验的结晶，书中分类列出了92条陷阱，告诉测试人员、技术和其他利益相关人员如何避免落入这些陷阱，认识到何时会落入这些陷阱，以及如果从这些陷阱逃出以避免带来更多负面影响。本书专为参与大型或中型项目的测试专业人员和其他利益相关者所写。《测试反模式：有效规避常见的92种测试陷阱》的反模式和解决方案可用于“纯软件”应用和包括了异质子系统、硬件、软件、数据、设备、材料及人员的“软件依赖系统”。对每个陷阱来说，书中介绍了它们的适用性、典型症状、潜在的负面后果和原因，并提供了明确的可执行的建议来避免或者减轻其后果。

目录

本书赞誉
译者序
序
前言
第1章　概述 
1.1　什么是测试 
1.2　测试和V模型 
1.3　什么是缺陷 
1.4　为何测试很关键 
1.5　测试的局限性 
1.6　什么是测试陷阱 
1.7　陷阱分类 
1.8　陷阱描述 
第2章　测试陷阱概要介绍 
2.1　一般测试陷阱 
2.1.1　测试计划和进度陷阱 
2.1.2　利益相关者参与和承诺的陷阱 
2.1.3　管理相关的测试陷阱 
2.1.4　人员配备陷阱 
2.1.5　测试过程陷阱 
2.1.6　测试工具和环境陷阱 
2.1.7　测试沟通陷阱 
2.1.8　需求相关测试陷阱 
2.2　测试类型相关陷阱 
2.2.1　单元测试陷阱 
2.2.2　集成测试陷阱 
2.2.3　专业工程测试陷阱 
2.2.4　系统测试陷阱 
2.2.5　系统的系统（SoS）测试陷阱 
2.2.6　回归测试陷阱 
第3章　测试陷阱的详细描述 
3.1　共同的负面后果 
3.2　一般建议 
3.3　一般测试陷阱 
3.3.1　测试计划和进度陷阱 
3.3.2　利益相关者参与和承诺陷阱 
3.3.3　管理相关的测试陷阱 
3.3.4　人员配备陷阱 
3.3.5　测试过程陷阱 
3.3.6　测试工具和环境陷阱 
3.3.7　测试沟通陷阱 
3.3.8　需求相关的测试陷阱 
3.4　测试类型相关的陷阱 
3.4.1　单元测试陷阱 
3.4.2　集成测试陷阱 
3.4.3　专业工程测试陷阱 
3.4.4　系统测试陷阱 
3.4.5　系统的系统（SoS）测试陷阱 
3.4.6　回归测试陷阱 
第4章　结论 
4.1　将来的工作 
4.2　维护陷阱列表 
附录A　术语表 
附录B　缩略语 
附录C　注释 
附录D　参考 
附录E　计划检查单 

摘要与插图

第1章
Chapter 1
概　　述
1.1　什么是测试
测试是在特定的前提条件下（例如，预测试模式、状态、存储的数据和外部条件）来运行系统、子系统或组件的活动，通过特定的输入，将它的实际行为（输出和后置条件）与要求或预期的行为进行比较。
测试不同于其他验证和确认方法（例如，分析、演示和审查），它是一个动态的（而不是静态的）分析方法，包含了被测试对象的实际运行。
测试有以下目标。
主要目标：
通过以下活动使被测系统（SUT）得到改进：
“打破”它（即通过造成故障和失效）
暴露缺陷，使其可以被修复
次要目标：
基于充足的客观证据，提供对于SUT以下方面的足够信心：
质量
系统的质量不只是没有缺陷或者它的正确性（在满足其需求方面）。系统还必须具备相关的质量特性和属性的必要级别，例如，可用性、容量、可扩展性、可维护性、性能、可移植性、可靠性、健壮性、安全性、保密安全性和易用性。
用途的适用性
装运、部署或投入运行的准备度
1.2　测试和V模型
图1.1展示了一种常见的系统工程建模方式：传统的系统工程活动的V模型。V的左侧是将用户问题分解成小且可管理的部件的分析活动。类似地，V的右侧显示将部件合成（并测试）为能解决用户问题的系统的活动。
图1.1　系统工程活动的传统单V模型
传统的V模型虽然有用，但从测试人员的角度来看，它并不能真正代表系统工程。接下来的3个图展示了3个更加详细的V模型，它们更好地把握了系统工程的测试方面。
图1.2展示了面向工作产品而不是活动的V模型。具体而言，这些是主要的可执行的工作产品，因为测试涉及了工作产品的执行。在这个例子中，V的左侧展示了更加详细的可执行模块的分析，而V的右侧展示了相应的实际系统的增量和迭代的合成。这款V模型显示可执行的东西都是经过测试的，而不是生成它们的通用的系统工程活动。
图1.2　可测试工作产品的单V模型
图1.3展示了双V模型，它在单V模型上增加了相应的测试[Feiler 2012]。关键点有：
每一个可执行的工作产品都需要测试。测试不需要（而且事实上不应该）限制在所实施的系统和它的部件中。测试任何可执行的需求、架构和设计同样重要。这样才可以在转移到实际系统和其部件之前，发现和修复相关的缺陷。这通常包括对以下内容的测试：可执行需求、架构或者通过建模语言（通常是基于状态且充分正式的）建立的被测系统（SUT）的设计模型，如SpecTRM-RL，结构分析和设计语言（AADL）以及程序设计语言（PDL）；SUT的模拟；SUT的可执行的原型。
测试应在相应的工作产品创建时创建和执行。带有双向箭头的短箭头是用来表明：可以先开发可执行的工作产品并用于驱动测试的创建；可以使用测试驱动开发（TDD），在这种情况下，测试在它们所测的工作产品之前开发。
该模型的顶行使用测试来确认系统是否满足其利益相关者的需求（即建立了正确的系统）。相反，模型底部4行使用测试来验证该系统是否正确地建立（即架构符合需求、设计符合架构、实施符合设计等）。
，在实践中，底行的两侧通常被整合，从而使单元设计模型纳入单位，并且编程语言用作程序设计语言（PDL）。同样，单元设计模型测试被纳入单元测试，使得同一单元测试可验证单元设计和它的实现。
图1.4记录了三重V模型，其中增加了额外的验证活动来验证测试活动的正常进行。这是为了提供证据表明测试是充分完整的，不会产生大量的假阳性和假阴性的结果。
虽然V模型看起来是展现一个连续的瀑布开发周期，它们也可以用来展现一个渐近的（即增量、迭代和并发）开发周期，结合许多小的、可能重叠的V模型。然而，在大型、复杂