1 一般测试陷阱
这些一般测试陷阱不是主要针对任何单一类型的测试。
1.1 测试计划和进度陷阱
1. 没有单独的测试计划文档（GEN-TPS-1）
没有单独的针对测试的计划文档，只是在总体计划文档中有不完整的、概要的测试概述。
2. 测试计划不完整（GEN-TPS-2）
测试计划及其相关文档对于系统的开发周期的当前点而言是不够完整的。
3. 忽视测试计划（GEN-TPS-3）
一旦开发和交付时，忽视测试计划文档（也就是说，它被“束之高阁”）。既不使用也不维护。
4. 测试用例文档作为测试计划（GEN-TPS-4）
错误地将记录具体测试用例的测试用例文档作为测试计划。
5. 测试进度安排不足（GEN-TPS-5）
测试进度不足以完成适当的测试。
6. 在结束时测试（GEN-TPS-6）
所有测试在开发周期后期进行，很少或根本没有对可执行的模块或单元的测试，或在开发周期的早期和中期阶段进行计划或执行的集成测试。
1.2 利益相关者参与和承诺的陷阱
7. 错误的测试心态（GEN-SIC-1）
一些测试人员和测试利益相关者有不正确的测试心态，如：测试的目的是为了证明该系统工作正常，而不是确定在何处以及如何失败；验证或“证明”系统是工作的是测试人员的责任；系统被假定为工作，所以没有理由去证明它是不工作的；测试被视为成本中心（即费用），而不是作为一种投资（或可以减少日后开支）。
8. 不切实际的测试期望（GEN-SIC-2）
测试利益相关者（尤其是客户代表和管理人员）有不切实际的测试期望，如：测试检测到所有（或甚至大部分）的缺陷；测试证明没有剩余的缺陷，因此该系统按预期工作；测试是可以为所有实际的目的穷尽的；可以依赖测试做所有验证，即使有些需求通过分析、演示、审查能更好地验证；测试（如果是自动的）将保证测试的质量，并且减少测试工作量。
9. 缺乏利益相关者对测试的承诺（GEN-SIC-3）
利益相关者对测试工作的承诺不充分，没有分配给测试工作足够的资源（例如，人、进度时间、工具或资金）。
1.3 管理相关的测试陷阱
10. 测试资源不足（GEN-MGMT-1）
管理层分配给测试的资源不充分，包括进度计划中的测试时间保留不足；充分培训的和有经验的测试人员和评审人员；资金；测试工具、测试环境（例如，集成测试床和测试数据库）和测试设备。
11. 不适当的外部压力（GEN-MGMT-2）
管理人员和其他有权力的人员施加给测试人员不适当的外部压力。
12. 测试相关风险管理不足（GEN-MGMT-3）
在项目正式的风险库中测试相关的风险识别得太少，而且那些识别的风险有不恰当的低概率、低严重程度和低优先级。
13. 测试度量不足（GEN-MGMT-4）
产生、分析、报告并用于决策的测试相关的度量指标太少。
14. 忽视不方便的测试结果（GEN-MGMT-5）
管理层忽视或轻率对待不方便的负面测试结果（尤其是那些对进度、预算或系统质量造成的负面后果）。
15. 忽视测试经验教训（GEN-MGMT-6）
忽视以往项目测试的经验教训，且没有在当前项目中付诸实践。
1.4 人员配备陷阱
16. 缺乏独立性（GEN-STF-1）
测试组织或项目测试团队缺乏足够的技术、管理和财务上的独立性，使其能够承受从开发（行政和技术）管理来的偷工减料的不当压力。
17. 测试职责不清晰（GEN-STF-2）
测试职责不清晰，没有充分明确哪些组织、团队和个人要负责和执行不同类型的测试。
18. 测试专业技能不足（GEN-STF-3）
一些测试人员和测试利益相关者没有足够的测试相关的认识、专业知识、经验或培训。
19. 开发人员负责所有测试（GEN-STF-4）
没有单独的专职测试人员的角色。相反，开发团队的每个成员负责测试他所设计和实施的。
20. 测试人员负责所有测试（GEN-STF-5）
测试人员负责所有系统开发过程中的测试。开发人员甚至没有进行单元测试（要么自己的软件，或者他们同伴的）。
1.5 测试过程陷阱
21. 测试和工程过程没有集成（GEN-PRO-1）
测试过程没有充分地集成到整体系统工程过程，而是被视为独立的专业工程活动，仅与主工程活动有有限的接口。
22. 一刀切测试（GEN-PRO-2）
所有测试都以相同的方式进行，同一严格等级，而不管其关键性。
23. 测试优先级排序不足（GEN-PRO-3）
测试优先级排序不足（例如，所有类型的测试具有相同的优先级）。
24. 过分强调功能测试（GEN-PRO-4）
过分强调对功能的测试，而不是对质量、数据和接口需求的测试，以及对架构、设计和实施约束的测试。
25. 过分强调黑盒系统测试（GEN-PRO-5）
过分强调对于需求的一致性的黑盒系统测试，而很少有白盒单元测试和架构、设计与实现验证的集成测试。
26. 黑盒系统测试重视不足（GEN-PRO-6）
过分强调白盒单元测试和集成测试，而很少时间花在黑盒系统测试上以验证是否符合需求。
27. 不够成熟进行测试（GEN-PRO-7）
产品交付测试时是不成熟的，没有准备好进行测试。
28. 测试资产的评估不足（GEN-PRO-8）
测试资产的质量在使用之前没有充分评估。
29. 测试资产的维护不足（GEN-PRO-9）
测试资产没有适当维护（即充分地更新和迭代），因为缺陷发现后，被测系统或软件就改变了。
30. 测试作为一个阶段（GEN-PRO-10）
将测试视作发生在顺序（也称为瀑布）开发周期后期的一个阶段，而不是不断发生在迭代的、增量和并发（进化或者敏捷）开发周期的持续性活动。[6]
31. 测试人员早期不参与（GEN-PRO-11）
测试人员不是在项目开始时参与，而是只当一个实现存在测试时参与。
32. 测试不完整（GEN-PRO-12）
测试人员不适当地没有测试某些可测的行为、特征或系统的组件。
33. 没有运行测试（GEN-PRO-13）
代表用户没有在实际运行条件下对“完成”的系统进行任何运行测试。
34. 测试数据不足（GEN-PRO-14）
测试数据（包括单独的测试数据和测试数据集）是不完整的或无效的。
35. 测试类型混淆（GEN-PRO-15）
一种测试类型的测试用例在另一种测试类型中冗余重复使用，即使测试类型之间有十分不同的目的和范围。
1.6 测试工具和环境陷阱
36. 过度依赖手动测试（GEN-TTE-1）
测试人员过度依赖手动测试，使得大多数的测试是手动进行的，没有足够的测试工具或者测试脚本的支持。
37. 过度依赖测试工具（GEN-TTE-2）
测试人员和其他测试利益相关者过多依赖商用现成品（COTS）和自主开发的测试工具。
38. 目标平台太多（GEN-TTE-3）
测试团队和测试人员没有充分准备好来测试将要在众多目标平台（例如，硬件、操作系统和中间件）上运行的应用程序。
39. 目标平台难以访问（GEN-TTE-4）
当目标平台没有设计成允许测试时访问时，测试人员没有准备好进行充分的测试。
40. 测试环境不足（GEN-TTE-5）
没有足够的测试工具、测试环境或测试床、测试实验室或设备，所以在进度和人员的限制内不能进行充分的测试。
41. 测试环境的保真度差（GEN-TTE-6）
测试人员建立和使用的测试环境或测试床对于被测软件或系统（SUT）的运行环境的保真度差，这将导致不确定或者不正确的测试结果（假阳性和假阴性结果）。
42. 测试环境质量不足（GEN-TTE-7）
一个或多个测试环境的质量由于缺陷数量过多而不足。
43. 测试资产未交付（GEN-TTE-8）
开发人员交付给维护人员的系统或软件没有相关的测试资产。例如，既不要求也不计划交付测试资产（如测试计划、测试报告、测试用例、测试神谕、测试驱动程序或脚本、测试桩和测试环境）。
44. 测试配置管理不足（GEN-TTE-9）
测试工作产品（例如，测试用例、测试脚本、测试数据、测试工具和测试环境）都没有进行配置管理（CM）。
45. 开发人员忽视可测性（GEN-TTE-10）
因为开发人员在设计和实现他们的系统或软件时不考虑测试，那么开发自动化测试就有不必要的困难。
1.7 测试沟通陷阱
46. 架构或设计文档不足（GEN-COM-1） 3
架构人员和设计人员制作的架构或设计文档（例如，模型和文档）不足以支持白盒（结构）单元测试和集成测试。
47. 缺陷报告不足（GEN-COM-2）
测试人员和其他人员创建的缺陷报告（也称为错误和故障报告）是不完整的、包含不正确的信息或难以阅读。
48．测试文档不足（GEN-COM-3） 4
测试人员创建的测试文档不完整或包含不正确的信息。
49. 没有维护源文档（GEN-COM-4）
开发人员没有妥善维护需要作为开发测试的输入的需求规格书、架构文档、设计文档和相关模型。
50. 关于测试的沟通不足（GEN-COM-5）
测试人员和其他测试利益相关者的关于测试的口头和书面沟通不足。
1.8 需求相关测试陷阱
51. 需求含糊不清（GEN-REQ-1）
测试人员曲解了大量模糊的需求，从而基于对需求的不正确理解进行测试。
52. 需求过时（GEN-REQ-2）
测试人员浪费精力和时间测试被测系统或软件（SUT）是否正确实现了许多过时的需求。
53. 需求遗漏（GEN-REQ-3）
测试人员忽略了许多未文档化的需求，因此没有计划、开发或执行相关忽略的测试用例。
54. 需求不完整（GEN-REQ-4）
测试人员无法检测到很多需求是不完整的。因此，他们开发并运行相应的不完整或不正确的测试用例。
55. 需求不正确（GEN-REQ-5）
测试人员无法检测到很多需求是不正确的，因此开发并运行了相应的不正确的测试用例，产生假阳性和假阴性的测试结果。
56. 需求扰动（GEN-REQ-6）
测试人员浪费大量时间和精力基于许多不足够稳定的需求开发和运行测试用例，并且因此在交付之前变更一次或更多。
57. 不恰当的衍生需求（GEN-REQ-7）
测试人员基于不恰当衍生需求进行测试，导致测试用例遗漏、错误抽象级别的测试用例、基于没有修改就分配到多个架构组件的相互交叉的需求的不正确的测试用例。
58. 未指定验证方法（GEN-REQ-8）
测试人员（或其他开发人员）未就每个需求正确地指定验证方法，从而导致使用不必要的低效或无效的验证方法对需求进行验证。
59. 缺乏需求跟踪（GEN-REQ-9）
测试人员不跟踪需求到单个测试或测试用例，从而使得不必要地难以确定测试是否不足或过量。
2 测试类型相关陷阱
2.1 单元测试陷阱
60. 测试没有驱动设计和实现（TTS-UNT-1）
软件开发人员和测试人员没有先开发测试，然后再使用这些测试来驱动相关的架构、设计和实现的开发。
61. 利益冲突（TTS-UNT-2）
没有采取任何措施来解决当开发人员测试自己的工作产品时存在的利益冲突：从本质上讲，他们被要求证明他们的软件是有缺陷的。
2.2 集成测试陷阱
62. 忽视集成降低可测性（TTS-INT-1）
测试人员没有考虑到集成封装整体的各部分以及它们之间的相互作用，从而使得集成的整体的内部组件具有更少的可观察性和可控性，因此，导致了更少的可测性。
63. 自我监控不足（TTS-INT-2）
由于缺乏系统或软件内部自检，测试人员没有准备好解决测试已封装组件的难度。
64. 组件不可用（TTS-INT-3）
集成测试不得不因系统硬件或软件组件，或测试环境组件的不可用而推迟。
65. 系统测试作为集成测试（TTS-INT-4）
测试人员在应该执行测试组件接口和交互的集成测试时，但实际却执行了系统功能的系统级测试。
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.4 系统测试陷阱
76. 测试钩遗留（TTS-SYS-1）
测试人员在完成测试后，没有删除临时测试钩，所以它们遗留在交付或者上线系统中。
77. 缺乏测试钩（TTS-SYS-2）
测试人员没有考虑到：缺乏测试钩使得通过隐蔽信息测试隐蔽系统部分变得更加困难。
78. 端到端测试不足（TTS-SYS-3）
测试人员执行的测试系统端到端地支持它的任务的系统级的功能测试不充分。
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.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）
测试人员和维护人员只执行确定变更是否引入功能相关的缺陷的回归测试。
扫一扫
108
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
