我们的自动化测试为什么这么难？(3)

　　自动化测试平台的搭建需要考虑其各方面的表现，因为它是一个较为通用的应用程序，故而，它的兼容性和健壮性要求很高。在一个测试组织或者一个公司内部，一般自动化测试平台应该可以做到通用于所有的系统测试，即便它们所采用的技术乃至理念会有所不同。就像我们通过测试平台STAF可以实现调度像QTP、SELENIUM这种UI层的自动化测试，也可以完成对JUNIT测试用例的运行调度和管理。而测试结果的分析也可以通过相应的报表系统来完成，按照我们自己的需求，把调度管理和分析管理等其他功能模块有机组合在一起，形成一个功能较为完整的测试平台。平台建设得好，无论是单纯的UI层验证测试还是敏捷测试，我们应该都能够支持得好。

　　我们知道，并不是一个自动化测试框架就能够应用于所有系统的自动化开发，因为被测程序的特点本身就本不相同，即便在同一个公司，也会因不同的开发风格和开发技术而要求有不同的测试方法。所以自动化测试框架虽不需要每个系统单独开发一套，但是也很难做到用一个框架支持所有系统的测试，最好的办法就是根据开发技术划分所需要使用的测试框架种类，例如QTP测试的纯WEB型、GUI型和各种插件开发型(如dotNet、JAVA等)。

　　关于自动化测试平台和框架的异同等方面，笔者曾在另外一篇自己的学习总结《软件测试自动化的探索与管理》中曾有过阐述，这里不再赘述。在完成这些基础建设之后我们才能够开始我们的大规模的人力投入，来进行针对每一个项目和系统的具体实施，否则如果先后颠倒或者本末倒置，势必会让我们面临纠结的重复建设和开发投入。而另一方面，在自动化测试实施的过程中，我们可能会随时面临很多的问题和困扰，但是在解决这些问题之后，我们测试人员的技能又能够得到提升。在技能提升的前提下，后续又可以进行新的改进和新需求的达成，这是一个循环的过程，也是自动化测试建设本身的持续优化。

　　从上图可以看到，这一系列的过程都是围绕着一个中心进行的，那就是自动化测试的KPI指标。前文曾简单提到过KPI的导向作用，我们千万不要小看那么几组小小的数字，更不要指望测试人员能够“跳出考核指标，为真理而奋斗”。所以如果我们的指标指向偏离我们的核心目标，那么自动化建设就会被引入误区，可能产生形式化、教条化甚至作假问题的产生。我们核心的目标是系统可用率和缺陷消除率(在一个分层扁平式管理的大型IT公司里，考核除了依赖对这些基础的贡献度的考察，我们还真没有想到其他更好的办法，虽然有敏捷思想的冲击和新考核建议的提出，但是在体制下和运营方式没有发生大的变化之前，或许只有这种考核方式才能勉强应付用户的资金投入和期许了)，既然缺陷的消除对我们如此重要，那么我们的自动化测试行为就应该围绕着应可能多的发现应用缺陷这个主题来进行。所以自动化测试的覆盖率、运行通过率等指标都只是过程中的参考数据，根本不能用来考核自动化的成果，这些指标的作用在自动化测试实施层面上还不如同行专家评审，虽然它们对中高层管理者来说有一定的参考意义。虽然很多人一再强调，UI自动化测试只是用来验证系统的正常运行，增加测试人员的信心，但是我始终不以为然。如果一个版本周期只在版本即将封版的时候运行一两次，或许可以这么说;但是自动化测试是可以投入系统测试阶段中使用的，至少可以进行基本的冒烟测试执行。如果在自动化应用于冒烟测试却发现不了缺陷，而手工执行能够发现一些严重问题，那么这个系统的自动化测试程序绝对是不合格的。依托自动化测试管理平台，我们适当提高运行频率，通过大面积自动化的页面操作，一定能够发现很多问题——如果我们愿意为脚本灌入足够多的测试数据，愿意在运行结束之后仔细地分析测试结果，那么自动化测试绝对是有产出的。

　　自动化测试的指标也是可以持续优化的，通过不同阶段的现状，适当调整自动化测试的KPI，用以指导自动化测试工作的开展。笔者认为无论高层的KPI如何定制，但是拆解到自动化测试实施的过程中，就需要更加有可行性并且具备正确的引导作用。例如我们可以考虑采集如下数据进行分析，来判断的自动化脚本开发的有效性和自动化测试建设对于我们的系统测试的帮助有多少：

　　脚本评审通过率：通过评审的测试脚本/所有通过开发、调试的测试脚本

　　脚本同步及时率：在应用缺陷修复之后指定时间内完成的测试脚本数/所有运行失败脚本数

　　测试缺陷发现率：通过自动化测试发现的缺陷数/所有系统测试缺陷数

　　功能选择活动率：三个月内涉及功能变更的测试脚本数/所有测试脚本数

　　资源占用超标率：平均运行时间超过手工测试用例平均执行时间的脚本/所有测试脚本数

　　如是种种，各位不妨结合自己的实际进行参考或者设置，笔者这里只是简单举例，并不具备通用性;只是希望大家可以多参与交流、多思考，组织头脑风暴神马的都可以，只是千万不要闭门造车。

　　结束语

　　测试人员需要能够胜任重复性的工作，但是测试人员绝不需要胜任被引导着去重蹈覆辙的行为，自动化测试建设成功与否，完全取决于参与建设的人的素质。本文标题里有个“要”字，是因为笔者认为自动化测试建设的成败、自动化测试之路走得是否通顺完全在人，而并非测试工具等其他外在因素。

　　可一败，不可再败!慎!慎!

　　万事开头难，但绝不该始终都难!三思!三思!

原文转自：http://www.ltesting.net