针对上一篇提到的问题，如果想要执行自动化测试，就会遇到一些麻烦。比如因为测试用例的设计问题导致测试执行过程不正确或者不完善，又或者针对需要变更到会的功能会变化或配置过程变化，都会引起相应的自动化测试用例的修改，这无疑增加了本阶段测试人员的工作量。
尤其是新功能不稳定的问题，更会导致自动化测试遇到一定的障碍。比如，一个严重问题导致系统的挂起会阻塞所有接下来的还行用例，又或者一些无法预料的异常会影响部分测试用例的执行。这就使得自动化测试变得不那么自动，也就是说，需要测试工程师值守，在遇到一定问题之后手动介入去解决，即便能不断在测试用例里面加入分支代码来处理这种异常，也不是高效的手段。
！！！很多团队的最佳实践就是，在新功能测试中，自动化测试只是一个辅助的操作，用来覆盖一些简单的功能测试。比如接口测试，只需要验证接口的输入和输出，而这种自动化测试用例也相对容易开发和调试。对于复杂功能，基本还是依赖手工测试，只有到功能相对稳定的阶段，测试开发人员才会逐渐将测试用例转化为自动化测试用例。所以对于新功能测试，很多团队实际上还是会大量依赖手工测试。
对于新功能测试来讲，如果需要引入更多的自动化测试，那么测试用例本身的构建和修改一定要非常迅速，并且自动化测试工具要提供快速生成测试用例的能力，以此来应对需求的变更。而测试工具本身应该足够健壮和灵活，可以应对由于新功能的不稳定而产生的阻塞其他用例执行的情况，并且能够对灾难性的错误进行测试环境上的自动恢复。
如果我们把测试用例也看成软件开发，那么测试用例也是一个软件产品，其质量本身也需要一个完善的过程。在新功能阶段，测试用例也是新开发的，当遇到问题之后，会使测试用例本身的问题和产品的问题纠缠在一起，这会让问题的排查变得复杂。
