自动化测试的风险点(一)

         今天和原来公司的老大聊了一会天，不禁让我想起了，当年刚进入自动化测试领域，从一无所知到小有成就的点点滴滴。如今离开功能自动化测试领域差不多有一年多的时间了，我想有必要对过去两年多的时光，在自动化测试领域学到的知识做一些总结。因为这个时候还能记得的东西，肯定是经过沉淀的东西。

         自动化测试的引入成本都是相当巨大的。一般自动化测试工程师的薪水和程序员相当于甚至高于中高级程序员。而自动化测试从投入到产出整个周期也是比较长的。一般从测试工具引入，到初步测试用例可以使用(起到探路预研作用)，需要3个月的时间。而能形成比较完整的测试体系，能完成冒烟测试，集成回归测试，测试报告产生，错误用例自动回放等功能需要一年的时间，所以投入一定要谨慎。这就需要引入的单位能清楚的知道自动化测试能解决什么问题，在引入过程中有哪些风险。合理的期望，才能引导测试人员开发出有价值的可以持续发展的自动化测试框架。

         自动化测试能解决的问题在很多书上都有描述。即能解决相对固定，变化不大的功能模块的测试，在这里我就不要详细描述了。我想描述的是在实施过程中可能遇到的风险。

1．  自动化测试离不开对业务的熟悉精通的测试人员。做测试的需要两条腿走路，一条是测试技术，一条是对业务的熟悉，而任何测试用例它的灵魂都是业务。而自动化测试团队往往是由技术出身的程序员组成的，所以往往不懂业务。要解决这个问题，有两种方法，一个是引入一个超强的业务测试人员，对公司所有的模块都比较熟悉，这对于ERP这样的产品几乎是不可能的。除非产品比较简单，而比较简单的产品也不需要自动化测试了。第二种方法，是由业务测试人员来写测试用例，而这种测试用例是可以被自动化测试人员读懂的。当然比较高的境界就是让程序自动能够读懂。