呵呵，关于题目，从某个角度讲其实也可以叫自动化产生的原因，当然从中也可以提取出一点引入自动化的时机问题（引入条件）

1、重复、无创造性的测试工作。这其中包括迭代开发中的重复测试，回归测试和修改BUG后的验证测试。

　　（PS：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

　　回归测试包括两部分：函数本身的测试、其他代码的测试。在对被修改的函数重新测试。如果函数的设计功能没有变化，直接运行函数测试就可以了。如果修改了设计功能，则要根据增减的功能点，增加或删除测试用例。另外，还要完成白盒覆盖。

　　函数代码的修改可能导致调用该函数的代码产生错误，所以需要测试其他代码。如果函数是私有函数并且未涉及到全局变量，应运行类测试，否则应运行工程测试。在函数列表中选择类测试或工程测试，编译运行测试工程，即可执行对其他代码的回归测试。）

2、技术上可以互补的测试工作。诸如程序执行状态或路径跟踪，大负载的模拟测试，断点跟踪等等。

　　对于这些一般是人自身能力比如手工不能容易获得的。程序是在执行还是死掉，其当前是什么状态；通过我的操作具体都走过所有流程路径了吗？没有的话都走过哪些？哪些是经常走的路径？如果没有模拟大负载的测试，不知道我们该找多少人花多少时间和金钱能完成一个测试内容了。

3、管理复杂的测试工作。测试用例的执行管理和问题的生命周期管理。

　　这涉及了自动处理测试用例的统计方面，比如执行了多少用例？哪些是自动化完成的？覆盖率如何？最主要的是带数据的测试用例，诸如用户注册需要处理不同长度，不同名称的1000条数据，如果手工一般是等价类抽样测试，而自动化会大大提高你的覆盖率。

　　跟踪问题走向，一个完好的并被有力执行的跟踪系统是自动化不可缺少的一部分

4、手工执行效率低的测试工作。比如需要覆盖系统工作量大的工作内容，迭代开发过程中的多次覆盖，还有测试资源缺乏的情况。

　　需要说明的是，根据具体情况来分析测试资源缺乏是否要使用自动化，因为自动化本身还需要一些前提条件以及准备时间，如果人力少，时间紧则实行自动化价值不大，因为准备自动化的时间都够手工跑几次了。对于自动化的前提条件，下一次说。

　　针对上面的几点也可以做为是否做自动化的参考，比如当前测试工作枯燥了乏味了，再有其他条件也符合的情况下，就可以考虑做自动化测试，起码能给测试人员一点挑战性，因为看起来好象技术含量提高了 呵呵