软件测试中的自动化测试的风险点
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
今天和原来公司的老大聊了一会天，不禁让我想起了，当年刚进入自动化测试领域，从一无所知到小有成就的点点滴滴。如今离开功能自动化测试领域差不多有一年多的时间了，我想有必要对过去两年多的时光，在自动化测试领域学到的知识做一些总结。因为这个时候还能记得的东西，肯定是经过沉淀的东西。
自动化测试的引入成本都是相当巨大的。一般自动化测试工程师的薪水和程序员相当于甚至高于中高级程序员。而自动化测试从投入到产出整个周期也是比较长的。一般从测试工具引入，到初步测试用例可以使用(起到探路预研作用)，需要3个月的时间。而能形成比较完整的测试体系，能完成冒烟测试，集成回归测试，测试报告产生，错误用例自动回放等功能需要一年的时间，所以投入一定要谨慎。这就需要引入的单位能清楚的知道自动化测试能解决什么问题，在引入过程中有哪些风险。合理的期望，才能引导测试人员开发出有价值的可以持续发展的自动化测试框架。
自动化测试能解决的问题在很多书上都有描述。即能解决相对固定，变化不大的功能模块的测试，在这里我就不要详细描述了。我想描述的是在实施过程中可能遇到的风险。
1.自动化测试离不开对业务的熟悉精通的测试人员。做测试的需要两条腿走路，一条是测试技术，一条是对业务的熟悉，而任何测试用例它的灵魂都是业务。而自动化测试团队往往是由技术出身的程序员组成的，所以往往不懂业务。要解决这个问题，有两种方法，一个是引入一个超强的业务测试人员，对公司所有的模块都比较熟悉，这对于ERP这样的产品几乎是不可能的。除非产品比较简单，而比较简单的产品也不需要自动化测试了。第二种方法，是由业务测试人员来写测试用例，而这种测试用例是可以被自动化测试人员读懂的。当然比较高的境界就是让程序自动能够读懂。
通常最简单的办法就是由自动化测试人员编写一个测试用例编写工具，让业务测试人员在上面编辑，程序自然有办法转换成自动化测试工具可以辨识的脚本语言。而实际上这种方法投入的成本很大，而对于业务测试人员也需要投入比较多的资源来学习这种编辑工具，个人认为不是一种很好的方法。
而实际上最有效的方法，是不改动原有的测试用例编写方法，将它转换为测试工具可以辨识的语言，这样才能使业务测试人员的测试用例顺利的向自动化测试用例转换。
2.自动化测试工具的选择
现在市面上比较流行有QTP,Rational Robot等琳琅满目的测试工具，那么选择什么样的测试工具来进行测试呢。其实在我看来商业的测试工具其实差别不大，所以成本往往是最主要的选择原因。而开源的工具，目前我还不太提倡，因为开发投入成本实在太大，而且有太多不可控制的因素，不是很靠谱。需要强调的是测试工具起到的只是辅助功能，重要的是测试思想、自动测试框架、测试套件、测试用例的设计 ，在更多的时候还要测试工程师发挥他们的经验和智慧实施有效的测试。现在QTP和RationalRobot里边几乎都体现了以下两个思想。
A.业务逻辑和测试数据分离。
业务逻辑和测试数据分离，这样一套业务逻辑由于他的测试数据的千变万化，就可以变出很多的测试用例出来。
B.测试组件概念的提出。测试功能模块化，封装化。
原本模块和封装是程序设计范畴的概念，而现在它在自动化测试领域也同样适用。一个测试用例可以由不同的测试组件组成。如下图将不同功能点的测试步骤封装成组件
那么根据上面的组件我们就可以组成下面的测试用例
组件A->组件B->组件C
组件A->组件D->组件B-组件C
组件A->组件C->组件B
组件A->组件D
….
可见测试用例设计人员只要设计了四个测试组件，就可以完成丰富的测试用例组合。
这两个测试思想是自动化测试对测试用例设计方法创新的最大贡献。
3. 在自动化测试引入过程中，最容易被忽略的一个环节测试执行。由于测试执行是自动化测试各个环节中最晚一个环节，所以他往往是最容易被忽略的。然而实际上他和测试用例设计，测试脚本编写一样重要。它就如果足球比赛的临门一脚，如果比赛过程中，前面的传接配合做的很好，而临门一脚不行，一切也都是白搭。测试执行，需要注意的问题。
A.需要考虑是否能够夜间自动执行，这涉及到一些如计划任务如何启动等技术细节，只要花功夫还是可以解决的
B.需要考虑脚本版本和测试对象的匹配性。测试脚本也需要做严格的版本控制
C.需要考虑在各种操作系统上的兼容性测试问题。
文章来源于领测软件测试网 https://www.ltesting.net/
