从上面的脚本化测试定义中可以看出，脚本化测试将更多更高认知水平的工作放在了测试设计阶段，而不是测试执行阶段。因此，在测试生命周期的早期，脚本化测试需要测试人员投入大量的时间和工作量，进行测试用例设计工作。脚本化测试的主要优点体现在：
° 在脚本化测试的早期，测试人员通过设计测试用例，可以对软件开发工作产品，如需求规格说明等进行详细的评审，并且对测试的内容进行深入的思考，从而优化测试用例；
° 测试人员设计的测试用例规格说明，可以得到项目其他相关人员的评审，从而可以提高测试用例的质量和覆盖率；
° 评审之后的测试用例可以在后续的测试过程中不断的重用；
° 如果设计得到的测试用例集是完整和完备的，那么它们可作为评估测试覆盖率的度量；
尽管脚本化测试具备前面描述的优点，但是其存在的不足和问题，也随着测试对象越来越庞大和复杂而暴露出来。测试的主要目的是获取测试对象的各种质量信息。但是不同的项目利益相关者对同样的产品，判断其质量的角度是不一样的。因此，假如不同的利益相关者需要在不同的时间阶段，获取不同的质量信息以实现不同的测试目的，那么传统固化的脚本化测试是很难满足要求的。单一的脚本化测试面临问题和挑战主要包括：
1）环境驱动的测试（Context-Driven Testing）
测试并不是一种孤立的活动，它和整个测试过程中的各种因素息息相关，即测试需要考虑各种环境因素，仅仅基于产品本身进行的测试设计和执行是远远不够的。环境驱动的测试中需要考虑的环境因素包括但不局限于：
° 测试过程中各种条件的限制。针对测试对象进行完全测试是不可能的；项目的时间和资金是有限的；测试人员的测试能力是有限的；
° 测试的主要利益相关者。例如：单元测试中，开发人员是测试人员需要考虑的主要利益相关者；验收测试中，客户和最终的用户是测试人员需要面对的利益相关者；
° 测试的主要目的。例如：单元测试过程中发现测试对象中的缺陷和错误是测试的主要目的之一，而在验收测试中，验证测试对象可以正确工作是其主要目的，从而给客户使用产品提供足够的信心；
° 测试对象需要满足的主要质量特性。例如：客户关注的是产品的易用性、稳定性还是可靠性，不同的产品以及不同的利益相关者，对质量特性的要求是不一样的；
° 测试团队掌握的测试技能。例如：测试人员是否熟练掌握了静态测试方法（评审、静态分析等）、对经典测试技术的掌握情况等；
° 测试相关的时间和资源的有效性。例如：整个测试的持续时间是否满足测试进度的要求，测试资源是否充足，测试仪表和测试人员是否满足测试的要求等；
° 产品或者服务的对象。例如：测试对象要实现的功能、它的主要客户等；
° 导致产品失效的原因以及产品失效导致的后果。
° 测试过程中系统行为的多样性。例如：系统性能的变化；
前面描述了测试过程中需要考虑的各种环境因素，这些因素会随着项目的不同、产品的不同、组织结构的不同、测试人员的不同而发生变化。而脚本化测试将更高认知水平的活动放在了测试设计上面，其输出的测试用例规格说明等文档是相对固定的，因此，很难对测试过程中环境因素的变化进行及时的跟踪和更新。
2）问题和缺陷来自各个方面
为客户或者用户及时提供高质量的产品或者服务，是整个项目团队的非常重要的目标。根据JerryWeinberg对质量的描述：质量是可以为一些人提供的价值，因此，任何影响或者降低价值的地方，都应该是测试人员需要仔细考虑和斟酌的关注点。
测试对象中没有代码错误或者功能错误，并不代表它就是高质量的产品，例如：有的产品在测试过程中没有发现什么缺陷和问题，而且完全满足了需求规格说明中定义的需求条目，但用户在验收测试过程中却并不能接受这样的产品，因为开发团队认为的高质量产品，并不是用户所期望的产品；或者开发团队觉得可以使用的产品，用户觉得其易用性非常差而拒绝接受这样的产品。因此，测试人员在测试过程中，其关注点不能仅仅局限在于软件工作产品本身，例如：需求规格说明，因为产品的问题和缺陷可以来自很多方面。测试人员假如只是查找代码中的缺陷和错误，那么他们就会遗漏所有其他导致产品质量低下的缺陷。
图1 被测系统失效的不同来源
图1是Doug Hoffman提出的被测对象可能的失效来源。从图中可以看出，系统的失效可能来自程序状态、系统状态、系统的输入、配置和系统资源、与系统协同工作的其他部分，例如：终端或者服务器的问题等。脚本化测试将更多的关注点放在测试设计上面，而在测试过程的早期，测试人员就将这些不同来源的系统失效全部考虑进去是非常困难的。
3）需要考虑的其他问题
除了环境因素的多样性和缺陷来源的多样性之外，脚本化测试本身的特点还存在一些其他方面的问题。
首先，脚本化测试在测试过程的早期，通过脚本的方式确定了测试范围、测试步骤和预期结果等内容。而对于任何一个测试人员而言，其对测试对象的了解都是一个渐近的过程，并且每个人对信息的处理能力也是有限的。在某个时间段内，测试人员对信息的处理必定存在盲区，即测试人员通过脚本化测试关注在某个测试范围或者测试点上，脚本化测试本身就已经忽略了测试对象的某些其他方面。
其次，脚本化测试在前期设计测试用例，在后续时间内执行和重用这些测试用例，并将测试结果和测试用例中的预期结果进行比较。脚本化测试相对严格的测试活动时间顺序，将导致出现这样的问题：测试用例设计的越早，测试人员对被测系统可能的风险信息了解的越少，对测试对象的测试内容理解更少。脚本化测试过程中，通常是比较有经验的测试人员设计测试用例，而其他测试人员根据测试用例中的步骤和期望结果来不断的执行测试用例。也就是说，脚本化测试中将更高认知的工作放在了设计阶段，而不是执行阶段，而实际测试过程中的情况则刚好相反：测试执行中应该有更高的认知水平，以敏锐观察其中的风险变化和环境因素的变化。
第三，在测试过程的早期就详细描述测试用例，本身就存在很多的不确定性和风险，主要表现在：
° 在整个软件开发生命周期中，需求的变更几乎是不可避免的。假如每次需求变更发生之后，测试人员就进行测试用例的修改和更新，其中的工作量将是不可估量；假如不对测试用例进行相应的修改，那么测试用例中无法体现需求的变更，因此就无法保证测试的正确性和覆盖率；
° 不同的开发人员在开发过程中会犯不同的错误，而脚本化测试并不能覆盖开发人员可能出现的各种错误。脚本化测试中可能会强调某些潜在错误和缺陷，而低估了某些其他开发人员可能容易范的错误；
° 产品或者软件运行的测试环境也经常随着时间而发生变化，例如：测试平台、工具，甚至客户的期望都可能发生变化，同样，脚本化测试无法对这些变更进行及时的跟踪；