当以一种工业化的方式执行软件测试时，测试会面对很多困难。高级测试人员应该将描述的以下建议与他们的组织、团队、任务以及软件组件的背景相结合。以下所列的建议包含一些会对测试结果的表现产生消极影响的方面。需要注意的是以下建议并没有包含所有的情况。

• 编写测试计划时只注重功能测试
  缺陷并不仅局限于功能方面或是单一用户。多用户的相互作用可能会对处于测试阶段的软件产生影响。
• 测试环境的配置不充分
  如果有多个类型的处理器、操作系统、虚拟机、浏览器和各种外设可以组合成许多可能的配置，而测试只局限在其中的部分配置组合时，可能会留下大量未被发现的潜在缺陷。
• 直到最后时刻才执行压力和负载测试
  压力和负载测试的结果可能需要软件（包括但不限于基础构架）方面做出重大调整。鉴于这些调整可能会需要相当多的资源来实施，如果这些测试直到计划引入生产之前才进行的，其结果可能会对项目产生极为不利的影响。
• 不对文档进行测试
  用户会得到开发完成的软件以及相关文档，但如果文档与软件不匹配，用户可能不会使用软件的所有潜在功能甚至完全放弃此软件。
• 不对安装程序进行测试
  安装程序，以及备份和恢复程序，都只运行非常有限的次数。然而，这些程序比软件本身更为重要，因为如果不能够安装软件，就不能使用软件。
• 在转向下一项测试任务之前，坚持完全的做完当前的任务
  虽然一些软件开发全生命周期模型建议按次序执行开发任务，但是在实践当中许多任务往往需要（至少部分的）并行。
• 未能正确地识别风险所在的区域
  某些区域会被识别出存在风险并且被彻底地测试。但是，原来没有识别出风险的区域可能由于未被测试或测试不充分而变得风险很高。
• 测试的输入和规程过于细致
  就测试人员主动定义测试的输入和规程而言，如果不给他们足够的发挥余地的话，他们就不会主动的去测试那些看上去没有错误但实际上却可能包含一些潜在缺陷的区域。
• 对“不相关”的异常视而不见
  “不相关”的现象或结果可能指向了潜伏在表象下的缺陷。
• 检查软件期望实现的功能却不检查不期望实现的功能
  如果限制测试人员仅对产品中期望的功能进行测试的话就很有可能错过产品中不期望被实现的部分（例如，额外的和非期望的功能）。
• 测试套件只有它们的所有者才理解
  测试人员可能会由于职责的调整而转换岗位。其他的测试人员会去阅读并理解之前编写的测试。如果该测试人员没有提供可读性和可理解性高的测试规格说明书，那将对整个测试产生消极的影响以至于整个测试对象不能够被理解或者整个测试被作废。
• 测试只针对用户看得见的接口
  软件的结构不只局限于用户接口。进程间通信、批处理和其它中断同样也会影响软件的正常工作甚至导致缺陷。
• 缺乏缺陷报告和配置管理
  事件报告和管理以及配置管理对于确保整个项目（包括开发和测试）取得成功是非常重要的。一个优秀的测试人员会去考虑修正发现的缺陷而不是发现很多缺陷后却没有详细的记录它们以至于不能修正。
• 只增加回归测试
  随着时间的推移测试套件的更新不能局限于检查以前发现的缺陷是否再次出现。随着代码的升级，测试套件需要覆盖到那些新的功能并对软件的其它部分做回归。
• 没有为下一次测试做好经验总结
  当软件交付给用户或在市场上发售时，并不意味着测试任务的结束。因为很有可能发行一个新的软件版本或发布，所以应保存好相关的测试记录并传递给测试人员负责的下一次测试。
• 尝试对所有的测试进行自动化
  自动化测试看上去是一个好主意，但是自动化测试本身就是一个开发项目。并不是所有的测试都可以进行自动化测试，有些测试手工执行比自动执行还要快。
• 期望重复运行所有的手工测试
  当再次执行先前的手工测试时，期望执行之前所有的测试是不切实际的。测试人员们的情绪是有起伏的，并且他们往往有意或无意地会倾向于聚焦在软件的特定区域。
• 使用图形化自动测试工具降低测试成本
  一个图形化捕获/回放工具是一笔重要的初期投资，必须根据理解和评估的相关成本，将工具用于支持已经定义的策略。
• 希望回归测试能够发现很多新的缺陷
  回归测试通常不会发现大量的新缺陷，主要因为它们是之前已经做过的测试（例如，为同一个软件之前的版本所做的测试），并且应该在那些之前的测试执行中已经发现了缺陷。但这并不意味着把回归测试全盘否定，仅仅是因为回归测试的效率（指发现新缺陷的能力）要比其它的测试更低。
• 热衷于代码覆盖得到的那些简单的数字
  由于能够提供很多数据和图片，从管理的角度出发代码覆盖和度量是一件很令人感兴趣的事情。但是，数字不能反映一个测试的效率或针对性。例如，对于代码覆盖而言100%是一个不错的目标，但是，它的可行性如何？充分性又如何呢（也就是它的语句、条件或修正的条件判定覆盖）？
• 仅仅因为测试没有增加覆盖率就将它们从回归测试套件中删除
  在回归测试件中，一些测试可以或者应该删除，而另外一些则需要添加。不应该仅仅根据测试是否增加覆盖率来决定是否删除测试，因为很多针对性的测试用例（指其能够检查出的缺陷类型）并不影响测试覆盖率。例如，代码覆盖不是唯一的覆盖类型；测试可能基于多种原因（如：特定的值或一系列事件）而不是简单的覆盖。
• 覆盖率是度量测试完整性的一种方法，而不是工作表现或人力效率的指标。不同的组织和项目可用不同的度量方法来评估他们的效率。在使用这些方法时必须经过深思熟虑，以避免不良影响。
• 彻底放弃覆盖度量
  覆盖的形式多种多样（例如，代码语句覆盖、条件覆盖、模块覆盖、功能覆盖等）。使用一定的工作量去获得充分的度量数据是很有意义的。因为这些数据对测试任务很有用，所以没有理由把所有的覆盖度量都放弃。

来源：ISTQB高级大纲