2）问题和缺陷来自各个方面

　　为客户或者用户及时提供高质量的产品或者服务，是整个项目团队的非常重要的目标。根据JerryWeinberg对质量的描述：质量是可以为一些人提供的价值，因此，任何影响或者降低价值的地方，都应该是测试人员需要仔细考虑和斟酌的关注点。

　　测试对象中没有代码错误或者功能错误，并不代表它是高质量的产品，例如：有的产品在测试过程中没有发现什么缺陷和问题，而且完全满足了需求规格说明中定义的需求条目，但用户在验收测试过程中却并不能接受这样的产品，因为开发团队认为的高质量产品，并不是用户所期望的产品；或者开发团队觉得可以使用的产品，用户觉得其易用性非常差而拒绝接受这样的产品。因此，测试人员在测试过程中，其关注点不能仅仅局限在于软件工作产品本身，例如：需求规格说明，因为产品的问题和缺陷可以来自很多方面。测试人员假如只是查找代码中的缺陷和错误，那么他们会遗漏所有其他导致产品质量低下的缺陷。

图1 被测系统失效的不同来源

　　图1是Doug Hoffman提出的被测对象可能的失效来源。从图中可以看出，系统的失效可能来自程序状态、系统状态、系统的输入、配置和系统资源、与系统协同工作的其他部分，例如：终端或者服务器的问题等。脚本化测试将更多的关注点放在测试设计上面，而在测试过程的早期，测试人员将这些不同来源的系统失效全部考虑进去是非常困难的。

　　3）需要考虑的其他问题

　　除了环境因素的多样性和缺陷来源的多样性之外，脚本化测试本身的特点还存在一些其他方面的问题。

　　首先，脚本化测试在测试过程的早期，通过脚本的方式确定了测试范围、测试步骤和预期结果等内容。而对于任何一个测试人员而言，其对测试对象的了解都是一个渐近的过程，并且每个人对信息的处理能力也是有限的。在某个时间段内，测试人员对信息的处理必定存在盲区，即测试人员通过脚本化测试关注在某个测试范围或者测试点上，脚本化测试本身已经忽略了测试对象的某些其他方面。

　　其次，脚本化测试在前期设计测试用例，在后续时间内执行和重用这些测试用例，并将测试结果和测试用例中的预期结果进行比较。脚本化测试相对严格的测试活动时间顺序，将导致出现这样的问题：测试用例设计的越早，测试人员对被测系统可能的风险信息了解的越少，对测试对象的测试内容理解更少。脚本化测试过程中，通常是比较有经验的测试人员设计测试用例，而其他测试人员根据测试用例中的步骤和期望结果来不断的执行测试用例。也是说，脚本化测试中将更高认知的工作放在了设计阶段，而不是执行阶段，而实际测试过程中的情况则刚好相反：测试执行中应该有更高的认知水平，以敏锐观察其中的风险变化和环境因素的变化。

　　第三，在测试过程的早期详细描述测试用例，本身存在很多的不确定性和风险，主要表现在：

　　● 在整个软件开发生命周期中，需求的变更几乎是不可避免的。假如每次需求变更发生之后，测试人员进行测试用例的修改和更新，其中的工作量将是不可估量；假如不对测试用例进行相应的修改，那么测试用例中无法体现需求的变更，因此无法保证测试的正确性和覆盖率；

　　● 不同的开发人员在开发过程中会犯不同的错误，而脚本化测试并不能覆盖开发人员可能出现的各种错误。脚本化测试中可能会强调某些潜在错误和缺陷，而低估了某些其他开发人员可能容易范的错误；

　　● 产品或者软件运行的测试环境也经常随着时间而发生变化，例如：测试平台、工具，甚至客户的期望都可能发生变化，同样，脚本化测试无法对这些变更进行及时的跟踪。