● 缺乏缺陷报告和配置管理

　　事件报告和管理以及配置管理对于确保整个项目（包括开发和测试）取得成功是非常重要的。一个的测试人员会去考虑修正发现的缺陷而不是发现很多缺陷后却没有详细的记录它们以至于不能修正。

　　● 只增加回归测试

　　随着时间的推移测试套件的更新不能局限于检查以前发现的缺陷是否再次出现。随着代码的升级，测试套件需要覆盖到那些新的功能并对软件的其它部分做回归。

　　● 没有为下一次测试做好经验总结

　　当软件交付给用户或在市场上发售时，并不意味着测试任务的结束。因为很有可能发行一个新的软件版本或发布，所以应保存好相关的测试记录并传递给测试人员负责的下一次测试。

　　● 尝试对所有的测试进行自动化

　　自动化测试看上去是一个好主意，但是自动化测试本身是一个开发项目。并不是所有的测试都可以进行自动化测试，有些测试手工执行比自动执行还要快。

　　● 期望重复运行所有的手工测试

　　当再次执行先前的手工测试时，期望执行之前所有的测试是不切实际的。测试人员们的情绪是有起伏的，并且他们往往有意或无意地会倾向于聚焦在软件的特定区域。

　　● 使用图形化自动测试工具降低测试成本

　　一个图形化捕获/回放工具是一笔重要的初期投资，必须根据理解和评估的相关成本，将工具用于支持已经定义的策略。

　　● 希望回归测试能够发现很多新的缺陷

　　回归测试通常不会发现大量的新缺陷，主要因为它们是之前已经做过的测试（例如，为同一个软件之前的版本所做的测试），并且应该在那些之前的测试执行中已经发现了缺陷。但这并不意味着把回归测试全盘否定，仅仅是因为回归测试的效率（指发现新缺陷的能力）要比其它的测试更低。

　　● 热衷于代码覆盖得到的那些简单的数字

　　由于能够提供很多数据和图片，从管理的角度出发代码覆盖和度量是一件很令人感兴趣的事情。但是，数字不能反映一个测试的效率或针对性。例如，对于代码覆盖而言是一个不错的目标，但是，它的可行性如何？充分性又如何呢（也是它的语句、条件或修正的条件判定覆盖）？

　　● 仅仅因为测试没有增加覆盖率将它们从回归测试套件中删除

　　在回归测试件中，一些测试可以或者应该删除，而另外一些则需要添加。不应该仅仅根据测试是否增加覆盖率来决定是否删除测试，因为很多针对性的测试用例（指其能够检查出的缺陷类型）并不影响测试覆盖率。例如，代码覆盖不是的覆盖类型；测试可能基于多种原因（如：特定的值或一系列事件）而不是简单的覆盖。

　　● 覆盖率是度量测试完整性的一种方法，而不是工作表现或人力效率的指标。不同的组织和项目可用不同的度量方法来评估他们的效率。在使用这些方法时必须经过深思熟虑，以避免不良影响。

　　● 彻底放弃覆盖度量

　　覆盖的形式多种多样（例如，代码语句覆盖、条件覆盖、模块覆盖、功能覆盖等）。使用一定的工作量去获得充分的度量数据是很有意义的。因为这些数据对测试任务很有用，所以没有理由把所有的覆盖度量都放弃。