第42贴【2004－6－28】：什么是应首先被自动化的测试？

天网

软件测试的自动化过程是一个渐进的过程，并不需要一开始就对所有的测试进行自动化，这通常也是不现实的。如何选择首先被自动化的测试成了最先遇到的问题。

    有些测试，完全没有必要进行自动化，因为自动化它们所需的时间比手工运行它们全部的次数所需的时间总和还长。例如，手工运行一个测试要10分钟，而且一般每个月运行1次，那么一年需要120分钟。但如果自动化这测试需要10小时，那么这个测试需要连续不断运行5年才能收回成本。

    有些测试，虽然执行的时间不长，但过程繁琐，需要执行的动作非常多。比  如，一个运行10分钟的测试，可能需要击键150次，打开4～5个窗口，切换操作。如果将其自动化，可以提高可靠性，也是值得的。

    对软件进行的功能性测试，是测试软件系统在做什么。这些测试可以明确的知道应该在什么情况下输入什么，会有什么样的输出。这样的测试是非常容易被自动化的，也能从自动化中获得较大的收益。

    对软件进行的性能测试，包括在不同的系统负载下进行的测试。这些测试需要采用工具辅助完成，非常适合进行自动化。

     如果在测试中，运行10%的测试需要花费90%的时间，那么将这10%的测试自动化是值得的。

     以下列出了选择首先进行自动化时要考虑的因素：
     非常重要的测试
     涉及范围很广的测试
     对主要功能的测试
     容易自动化的测试
     很快有回报的测试
     运行最频繁的测试

     应该注意避免一口气自动化太多的测试。太多的工作导致参与人员工作积极性下降，可维护性下降，增加工作的风险。寻找可快速制胜的测试，尽快让大家看到工作成果，有助于获得更多的工作支持。

hyjsnbb

da ge na dou yp uni ya

jackei

容易自动化的测试
     很快有回报的测试

其实在实际工作中，个人感觉上面两条是判断那些工作需要实现自动化最简单的方法。自动化本身是一个逐步引入的过程——你也可以认为它是迭代引入。因为自动化测试不仅仅需要调整测试过程，而且还需要调整开发过程以与之配合，所以在考虑是可以从最容易实现的部分开始。比如有些不需要参考太多文档，不需要考虑自动化测试框架的引入，不需要自定义application map，不需要自己设计公共函数库，不需要自动化脚本太可靠，等等等等。
举个简单的例子，我只是想在新版本发布时通过自动化脚本简单的跑一下最基本的流程，看看是否能够通过，那么这个就很容易实现。不用参考设计文档，不用考虑自动化工具是通过什么方法来识别对象，假定不需要进行数据的验证，甚至不用专门进行自动化测试设计，通过简单的录制脚本——如果有需要再简单的修改，就可以使用了。