6.7 选择自动化工具

大多数人都曾经倾向于自己研究一套“很有效”的测试工具,并努力证明其在目前和将来的项目中可有效运行且节约成本,单从这个角度来看这是件好事,但是从开发中心6000人的总体投入出发来看则并非如此,过多的自动化测试工具在维护和开发着,大家都为了能够争取更多的“用户”和“关注”而展开了一场无休止的“口水战”。仅我们的自动化测试社区、测试社区半年来不断组织的大小讨论,都在讲一个又一个貌似独创但又有几分相似的“最佳工具”。

为了将自己的工具做到“最好”,一些团队不惜投入将工具做得十分“强大”,而此时我们发现,投入已远远超出工具本身带来的收益,甚至影响到了中国区的财报,是时候为自动化测试指出更合理的发展方向了。

借此机会,我即刻拟定了当年开发中心测试社区的首要目标是调查开发中心自动化测试的发展状况;再者就是找到自动化测试的新的指导方向;最后希望可以找到一种科学的方式,在“好”工具中寻找“合适”中国研发中心的自动化工具。这项计划获得了批准。

6.7.1 度量尺度

我们首先重组了测试社区自动化测试的领导团队,选择现有“自动化工具”分布相对集中的三大领域,即自动化执行API测试、自动化执行GUI测试、自动化执行环境配置领域。然后在这三个领域上集结了相关自动化测试专家分成三个团队,分别为API测试、GUI测试和环境配置团队,而每个团队的成员都是相应领域的自动化测试专家,至少都参与设计了一款自动化测试工具。团队的使命是在有限时间内提出尽可能丰富的、可量化的指标对团队内所有人所代表的工具的指标打分,指标一定是具体的,可以但最多有2~3层细分的指标,所有叶子节点指标定义一定是明确的而不是模棱两可的。最后我们鼓励精确的分类技术,每个团队都有7~8人每两个星期利用1~2小时完成对一个工具的详细分析和集体打分过程,被打分工具的代言工程师将竭尽所能向大家展示自己工具的特性,在陈述中只要是之前没有讨论或提及的特性都会转化成一项性能、功能度量指标留下来,相类似的功能或者性能指标又将和以后的性能指标做整合,这样对所有工具都基于一套相同定义、相同尺度的指标打分,每项指标可以是1分或者0分的“有和无”,而不是0~10分的程度分值。

例如,我们研究了GUI自动化测试工具后得到的度量指标矩阵有10大簇集:

·Test Functionality(测试功能)。

·Test Environments Building(测试环境支持)。

·Test Case Creating(测试脚本创建能力)。

·Test Asset Infrastructure(测试资产管理能力)。

·Deployment(部署形式)。

·Test Case Execution(测试脚本执行能力)。

·Test Result Display/Analysis(测试报告展示/分析能力)。

·Test Case Maintenance(测试脚本可维护性)。

·Integration with 3rd party tools(与第三方工具集成能力)。

·Other(其他)。

在10大簇集上分1~2层细分规则,如图6-13所示有关测试功能度量矩阵的细分和对相应工具的打分,我们可以了解FTX、SandBox和PACAS均支持Web2.0JavaScript的测试,除了PACAS都支持Windows操作系统上的测试,以及只有WCM支持全球化测试环境自动化测试。这个簇级指标包含三层指标,其中,第二层分别是Supporting OS(支持的操作系统)、Supporting Browser(支持的浏览器)、Web 2.0Support(是否支持Web 2.0技术)、Support Globalization execution environment(是否支持全球化测试环境),第三层则是各操作系统、浏览器和Web2.0对象。

00102.jpeg

图6-13 基于设计的矩阵为工具打分

有了这个功能矩阵后,团队设想出了有意思的工具选择故事。如图6-14所示,当用户在为自己的项目挑选自动化测试工具、测试工具时,只需要将右表中的功能点(Feature 1~100,etc)拖入对应的“必选”(Mandatory)、“最好有”(Best to have)、“可选”(Optional)三类筛选池,这样系统将会从现有的工具列表中,筛选出满足“必选”(Mandatory)的工具给用户。

00120.jpeg

图6-14 系统根据用户对项目的描述筛选工具

我们来模拟下结果的输出,当用户完成了筛选后,系统自动绘制了当前项目需求下的雷达图,系统会从现有的工具库中选择并展示出满足条件的所有工具的雷达图,用户可以选择任何一个结果集中的工具作为项目的备选自动化测试工具。如果用户还希望选择更好的工具或完全符合需求的工具,那么我们将建议用户选择一个能够尽可能包含项目雷达图的工具作为最优工具。不同雷达图的示例见图6-15。

00007.jpeg

图6-15 不同雷达图示例

6.7.2 量化指标

因为自动化测试工具相似度很高,或者有太多的选择,所以我们推荐另外一种优选方式,即通过工具成熟度、支持能力和投入回报比做进一步筛选。为此,我们研究了行业最好的技术文章,探访了专家,与研究部门合作找到了评价工具的另外三组指标。

·Maturity & Customer Base(MCB),工具成熟度。通过工具的使用时间、用户数量,以及这个工具被运用于有相当大小的项目团队的数量综合计算获得。

·Tool Support(TS),工具支持能力。当工具在使用中出现错误,通过工具支持团队解决问题的平均时间;用户查询相关文档要点的平均时间以及在文档查询时遇到文档错误、误导问题的几率综合计算获得。

·Estimated Return On Investment(EROI),投入回报比。考虑投入使用自动化工具前后,对于测试进度、发现质量缺陷数量的对比,投入维护和开发实践的综合计算获得。

这三个度量指标和计算方法的选择源于两篇非常精彩的文章,分别是James Michael的《Metrics for Measuring the Effectiveness of Software-Testing Tools》和Daniel Rowley的《An Automated-Test-Tool Evaluation and Selection Technology》。而同时度量矩阵还经过了自动化专家组的讨论和修正,下面介绍这些指标的定义。

MCB=M×CB+P

M(Maturity)是自从第一个发布至今的整年数,单位[年]。例如,一个工具有三个版本发布了,第一个版本发布的时间是2000年,假设今年是2013年,那么M=13。

CB(Customer Base)是指使用工具超过1年的经验用户的数量(可以统计在中国开发中心获取、了解、支持和被支持的用户数量)。例如,有20个开发中心的项目团队使用过这个工具,每个团队平均10名工程师,他们都已经使用这个工具超过1年,那么CB=20×10。如果你并不确定有多少团队正在开发中心使用这个工具,则只需估算有多少可能的用户使用这个工具超过1年之久。

P(Project)是以“人年”为参考单位,计算在开发中心总共有过多少人年的使用经验。例如,开发中心有3个项目团队已经采用了这个工具,平均人年数是1.2py,那么P=3×1.2。再如,开发中心有2个项目团队已经采用了这个工具,其中一个项目有3py,另一个项目有2py,那么P=3+2。

00025.jpeg

ART(Average Response Time in Test)指用户刚开始试用测试工具时,工具的支持团队平均解决用户发现问题的时间,单位[天]。例如,在用户测试工具阶段,一个工具错误发生了,并且花去了用户约0.5天来解决这个问题,那么ART=0.5。

ARTAH(Average Response Time After Test Schedule)指当用户经历过测试工具阶段,正式使用工具时,支持团队平均解决用户发现问题的时间,单位[天]。例如,在论证了工具的可行性后,如果用户使用时发现了工具的错误,并且花去用户1天时间来解决这个问题,那么ARTAT=1。

ATSD(Average Time by only Search Documentation)指当用户发现一类问题时,这类问题能够通过查询工具文档、在线帮助解决的平均时长,单位[天]。例如,如果用户花去0.25天查询和阅读文档解决一个问题,那么ATSD=0.25。

DS(Document Insufficiency)指的是多少比例的问题用户无法通过查阅说明文档、在线帮助,而只能通过客服、支持人员解决,单位[无]。例如,如果用户曾发现10个问题,平均评估有4个问题不能够从文档中获得帮助,必须从用户团队、支持团队那里获得帮助才得以解决,那么DS=4/10。

00016.jpeg

EPG(Estimated Productivity Gain)是生产力的增长点,单位[无]。即过去100个真实日历日内,度量项目平均测试的生产力的增长点。若采用了新的工具后,团队或者个人的工作量为过去的120%,那么EPG=0.2。

ETT(Estimated Testing Time without tools)是在没有工具帮助的前提下,以原有的测试生产能力计算可以完成多少个工作量的测试工作,单位[人时]。例如,如果没有这个工具,团队在过去的100个真实日历日内,可以完成300个人时的工作量,那么ETT=300ph。

ACTH(Average Cost of Test per Hour)指测试工程师每小时的生产成本,单位:[$/h]。例如,开发中心主力测试工程师约28.6$/h,辅助测试工程师约18.7$/h,如果一个团队的构成是3个主力测试工程师、2个辅助测试工程师,那么ACTH=24.6$/h。

EII(Estimated Income Increase)是使用了新工具后直接产生的盈收,单位[$]。例如,当我们使用这款工具后,除了生产力得到提高,工具本身给我们的工作带来了直接的盈收$50,那么EII=50(如果并没有直接的盈收,EII可以为0)。

ACMH(Average Cost of one tool Maintenance Hour)是使用新工具后在后台维护工具、二次开发时所需花费的每小时费用,单位[$/h]。我们基本认为ACTH=ACMH。

ETIT(Estimated Tool script Implementation & maintenance Time)是估计的自动化测试脚本开发、工具维护所需花费的时间,单位[人时]。例如,如果过去100天内总共花费了80人时,则ETIT=80。

EQG(Estimated Quality Gain)是使用工具后对比之前工作的质量盈收,单位[无]。例如,使用了新工具后,发现了多余原来10%的质量缺陷,那么EQG=0.1。

EHCS(Estimated Hours of Customer Support per defect)是指每发现一个缺陷所需提供技术支持的平均时间,单位[小时]。例如,每个缺陷平均需要5小时支持服务,则EHCS=5。

ACCS(Average Cost of hour of Customer Support)是每个测试阶段遗留下来并流入到用户手里的质量缺陷将带来的平均用户支持代价。例如,每个用户支持小时都将付出62.5$的代价,则ACCS=62.5。

基于以上算法,我们的团队对所有的142个自动化工具做了综合评分对比,得到每个工具的MCB、TS和EROI,我们将其中几个最有特色的工具进行对比,如图6-16、图6-17和图6-18所示。

00107.jpeg

图6-16 成熟度最高和用户基础最多的自动化测试工具排名

00083.jpeg

图6-17 技术支持最优的自动化测试工具排名

00031.jpeg

图6-18 投入产出比最优的自动化测试工具排名

如图6-19所示,我们将每个工具的三位属性以一体化、直观的方式展示,用户在挑选其工具时将更为简单。

00123.jpeg

图6-19 功能矩阵与属性尺度一体化的展示

至此,我们分享了2008年开发中心的一项调查和研究成果,即“工具能力矩阵”和“可量化指标”,而这个方法的提出本身,其意义已经超出我们最初的期望,它可以指导自动化工具开发回归理性。这项工作从规划到完成,得到各个部门领导和团队的支持,近40名技术专家集思广益保证项目顺利进行。

我们分享这个故事和方法,是希望让更多的同仁有所收获,能够从这群可敬、可爱的人身上感受到向上的精神。这个成果属于IBM中国开发中心自动化测试社区,属于参与其中的每位志愿者。时过境迁,物是人非,这中间的许多人或许已经认不出来了,但我希望留下每一位贡献者的姓名,谢谢这些可爱的人们,与你们共事非常愉快!

姓名随机排列,成绩不分先后,他们是:

00115.jpeg