本节书摘来自华章计算机《 测试反模式：有效规避常见的92种测试陷阱》一书中的第2章，第2.2节,作者：（美） Donald G. Firesmith 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.2 测试类型相关陷阱
以下陷阱主要限于单一类型的测试：
2.2.1 单元测试陷阱
这些陷阱主要与单元测试相关：
60.测试没有驱动设计和实现（TTS-UNT-1）
软件开发人员和测试人员没有先开发测试，然后再使用这些测试来驱动相关的架构、设计和实现的开发。
61.利益冲突（TTS-UNT-2）
没有采取任何措施来解决当开发人员测试自己的工作产品时存在的利益冲突：从本质上讲，他们被要求证明他们的软件是有缺陷的。
2.2.2 集成测试陷阱
以下陷阱主要与集成测试相关：
62.忽视集成降低可测性（TTS-INT-1）
测试人员没有考虑到集成封装整体的各部分以及它们之间的相互作用，从而使得集成的整体的内部组件具有更少的可观察性和可控性，因此，导致了更少的可测性。
63.自我监控不足（TTS-INT-2）
由于缺乏系统或软件内部自检，测试人员没有准备好解决测试已封装组件的难度。
64.组件不可用（TTS-INT-3）
集成测试不得不因系统硬件或软件组件，或测试环境组件的不可用而推迟。
65.系统测试作为集成测试（TTS-INT-4）
测试人员在应该执行测试组件接口和交互的集成测试时，但实际却执行了系统功能的系统级测试。
2.2.3 专业工程测试陷阱
下面的陷阱在本质上高度相似，但是它们在细节上差别显著。这个章节要长得多，因为有许多不同的质量特性和相关的属性，每个都有其相关联的潜在的症状、后果和原因。
66.容量测试不足（TTS-SPC-1）
测试人员很少或根本没有进行容量测试（或他们执行的容量测试是表面的），以确定当接近、达到和超过容量限制时系统或软件能正常降级的程度。
67.并发测试不充分（TTS-SPC-2）
测试人员很少或根本没有进行并发测试（或他们执行的并发测试是表面的），以明确地发现导致常见的并发故障和失效类型的缺陷：死锁、活锁、匮乏、优先级反转、竞态条件、共享内存的视图不一致和无意的无限循环。
68.国际化测试不足（TTS-SPC-3）
测试人员很少或根本没有进行国际化测试（或他们执行的国际化测试是表面的），以确定该系统何种程度上可配置，并在多个国家适当运行。
69.互操作性测试不足（TTS-SPC-4）
测试人员很少或根本没有进行互操作性测试（或他们执行的互操作性测试是表面的），以确定该系统与其他系统成功接口和合作的程度。
70.性能测试不足（TTS-SPC-5）
测试人员很少或根本没有进行性能测试（或他们进行的测试只是表面的），以确定该系统在何种程度上有性能质量属性的足够水准：事件调度性、抖动、延迟、响应时间和吞吐量。
71.可靠性测试不足（TTS-SPC-6）
测试人员很少或没有进行长时间的可靠性测试（也称为稳定性测试），或他们执行的可靠性测试是表面的（例如，它不是在运行配置文件下进行的，并且不是基于任何可靠性模型的结果），以确定该系统可以持续无故障运行一段时间的程度。
72.健壮性测试不足（TTS-SPC-7）
测试人员很少或根本没有执行健壮性测试，或他们执行的健壮性测试是表面的（例如，它不基于任何健壮性模型的结果），以确定在何种程度上系统具有足够的错误、故障、失效和环境容忍性。
73.安全性测试不足（TTS-SPC-8）
测试人员很少或根本没有进行安全性测试，或者他们执行的安全测试是表面的（例如，它不是基于安全或危险分析的结果），以确定系统避免造成或遭受意外伤害的安全程度。
74.保密安全性测试不足（TTS-SPC-9）
测试人员很少或根本没有进行保密安全性测试，或他们执行的保密安全性测试是表面的（例如，它不是基于安全或威胁分析的结果），以确定该系统避免造成或遭受恶意伤害的安全保障程度。
75.易用性测试不足（TTS-SPC-10）
测试人员或易用性工程师很少或没有进行易用性测试，或他们执行的易用性测试是表面的，以确定在何种程度上系统的人机接口满足易用性、人力资源、人员、培训、人因工程（HFE）和可居住性的系统需求。
2.2.4 系统测试陷阱
以下陷阱是主要与完全集成的系统的测试相关：
76.测试钩遗留（TTS-SYS-1）
测试人员在完成测试后，没有删除临时测试钩，所以它们遗留在交付或者上线系统中。
77.缺乏测试钩（TTS-SYS-2）
测试人员没有考虑到：缺乏测试钩使得通过隐蔽信息测试隐蔽系统部分变得更加困难。
78.端到端测试不足（TTS-SYS-3）
测试人员执行的测试系统端到端地支持它的任务的系统级的功能测试不充分。
2.2.5 系统的系统（SoS）测试陷阱
下面的陷阱都与测试系统的系统相关：
79.SoS测试计划不足（TTS-SoS-1）
测试人员和SoS架构人员进行的SoS测试计划不充分，并且未能适当地在SoS测试计划文档中记录计划。
80.SoS测试职责不清晰（TTS-SoS-2）
管理人员或测试人员未能明确界定和文档化执行端到端的SoS测试的职责。
81.SoS测试资源不足（TTS-SoS-3）
管理层未能为系统的系统（SoS）测试提供足够的资源。
82.SoS测试进度安排不妥（TTS-SoS-4）
系统的系统测试没有妥善安排进度并协调各系统的测试和交付时间表。
83.SoS需求不足（TTS-SoS-5）
很多SoS层次的需求缺失、质量较差，或者是从来没有正式批准或资助。
84.来自单个系统项目的支持不足（TTS-SoS-6）
来自单个系统开发或维护项目对进行系统的系统测试的支持不足。
85.跨项目缺陷跟踪不足（TTS-SoS-7）
跨系统开发或维护项目的缺陷跟踪对系统的系统测试支持不足。
86.指责（TTS-SoS-8）
不同的系统开发或维护项目将查找和修复SoS级别的缺陷的责任分配给其他项目。
2.2.6 回归测试陷阱
以下陷阱主要与回归测试相关：
87.回归测试自动化不足（TTS-REG-1）
测试人员和开发人员做的测试自动化的数量不足，以进行充分的回归测试。
88.未执行回归测试（TTS-REG-2）
测试人员和维护人员进行的回归测试不充分，以确定是否在对系统更改时意外引入新的缺陷。
89.回归测试的范围不足（TTS-REG-3）
回归测试的范围不够广泛。
90.只有低级别的回归测试（TTS-REG-4）
只重新运行低级别（例如，单元级和可能集成级）的回归测试，所以没有系统、验收、运行回归测试，且没有SoS回归测试。
91.测试资源未交付维护（TTS-REG-5）
由开发团队所生产的测试资源没有提供给支持测试新功能和对变更做回归测试的维护团队。
92.只有功能性回归测试（TTS-REG-6）
测试人员和维护人员只执行确定变更是否引入功能相关的缺陷的回归测试。
