【转】软件测试自动化的现状分析和自动化引入条件

因想多了解关于测试方面的资料，转发留作参考。

原文地址：http://www.51testing.com/html/80/612780-3578933.html

 

软件测试自动化，已经成为国内软件工程领域一个众所周知的课题；不言而喻，软件测试从业者都意识到软件测试这项工作走向**化、标准化的一个必经之路就是要实施自动化测试。也许您认为实施自动化测试不是必须，也许您认为测试的思想是开展该工作的精髓、而工具只是辅助，那么我要告诉你我的想法：从计算机这一庞大学科发展至今，它最根本的意义是解决人类手工劳动的复杂性，成为替代人类某些重复性行为模式的最佳工具；我们不可推翻测试思维在测试工作中的指导思想地位，但如何将思想转化成可操作的方案，本文也许会给您一些启示。 　　以前听过北京中软的一个业内专家讲一句话，觉得挺经典：凡是说既是科学又是艺术的学科，就是说明它是不**的学科！他将软件工程和建筑行业做类比，让我们深深体会到软件工程走向**化的任重与道远。而软件测试，更是一个新兴的领域，虽然近几年得到了快速发展，也随着该领域从业者数量的与日俱增，培养了一批高级的人才；但是依然有多少企业和个人工作在迷茫中：这种困惑是因为工程师们手中的测试工作与理想的测试模式造成的强烈反差，这种无奈是因为他们和开发人员一样的努力却有不同的待遇，这种迷茫是因为测试工作者不知道这个领域里是否还有自己的发展空间和人生价值的体现！笔者认为：如今的软件测试行情，正处在群雄逐鹿的混战岁月，每个人、每个有测试部门或从事测试业务的企业，都该发扬百花齐放、百家争鸣的精神，多多借鉴国内外先进的测试经验，参考业界流行的行业标准，找到适合自己团队的测试方法和模式，创造更大的社会价值，发挥更大的人生价值。

 

　　实施软件测试自动化的理由分析

 

　　首先，测试人员的工作比以往任何时候都更加困难，因为公司和组织希望以更快的速度和更低的成本开发出高质量的应用程序。 　　此外，在很多项目中，测试人员的所有任务实际上都是手动处理的，而实际上，有很大一部分重复性强的测试工作，是可以独立开来自动实现的。 　　还有，在大型项目中测试团队和其他的团队之间没有足够的合作，无法促进彼此的工作。 　　最后，从个人角度来说，测试人员通常很难花费大量时间来学习新技能；这是目前国内测试从业者的现状，太多的企业为了节约成本而将刚刚走出校门的毕业生作为测试工程师，他们每日做着繁忙的重复工作，又基于自身技能的不深，虽怀博览群书的心愿却不知从何出入手。所谓光阴似箭，因为一转眼我们就说到未来的5年、10年后，我们这些技能不深的测试工程师能做什么呢？而软件测试自动化，也是未来测试工程师或即将成为测试工程一项强有力的工作技能。 　　可以说，实施测试自动化是软件行业一个不可逆转的趋势，如果在这个领域走在了前列，无论从企业的核心竞争力还是个人的工作技能来说，都有巨大的优越性，而国内众多的软件厂商也的确在纷至沓来的着手开展着这项工作。

 

　　国内软件测试自动化实施现状分析

 

　　随着众多具有了一定优秀实施自动化测试经验的企业陆续出现，也伴随着很多组织对这项工作依然是丈二的和尚－摸不着头脑。对当前国内软件企业实施或有意向实施测试自动化时面临的主要问题，按实施的不同层次来说： 　　——干脆认为测试自动化是个遥不可及的事情，我们这样的小公司不必实施，人员、资金、资源都不足，以后再说吧！ 　　——热血沸腾的实施测试自动化，购买了工具，推行了新的测试流程；几个月后，工具放在那里成了共享资源，测试流程又涛声依旧，回到原来的模式。 　　——公司实施了自动化测试；然而开发与测试之间，甚至与项目经理之间矛盾重重，出了事情不知如何追究责任；虽然还在勉强维持的自动化测试，但实施的成本比手工测试增加了，工作量比从前更大了，从而造成项目团队人员怨声载道，更怀念起那段手工测试的悠闲岁月，唉！那一场风花雪月的事，既然要结束又何必开始… 　　——自动化测试实施相对比较成功，但或多或少还有些问题，比如工具选择不准确，培训不到位，文档不完备，人员分配不合理，脚本可维护度不高等等，造成一种表面上的自动化测试流程，是一幅空架子，如同山间竹笋,嘴尖皮厚腹中空。

 

　　国内软件测试自动化实施不成功原因分析

 

　　——公司高层意识不到软件测试自动化的重要性；殊不知，其他竞争对手们都大张旗鼓的开展这方面研究和策划的时候，自己还对此持漠视态度，等到整个行业都提高到一个新的层次，那时再着手做，可能就是热锅上的蚂蚁了。 　　——所谓凡事预则立，不预则废。一个软件企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。 　　——软件开发是团队工作，在这一领域要尤其注重以人为本；所以人员之间的配合、测试组织结构的设置非常重要，每个角色一定要将自己的责任完全担负起来，这也是减少和解决前述团队矛盾的必要手段。 　　——对开展自动化测试的监督和评估相当重要，也包括对工作产品的检查和人员的考核。一定要将自动化测试全面深入的贯彻到测试工作中，不能敷衍了事，不能做表面工作。这项工作在CMM三级里规范的很好，只可惜我们的很多公司对CMM真的只是“过级”！

 

　　正确认识国内未实施软件测试自动化的根源

 

　　目前国内的软件公司，很多还是处于获取资本的原始积累阶段，我们不能说公司领导完全不重视测试，而是测试整体行业都没有被重视起来，这是其一；其二是公司高层有更需要重视的环节，例如寻找客户签订单，或者开发，这些是直接关系公司存亡的命脉性东西。 　　即便企业重视测试，如果公司做一番比较全面的评估（在后续的测试自动化引入入条件里，再详细说明），也不一定非要实施自动化测试。笔者认为一些中小软件公司在大刀阔斧推行自动化测试之前，在测试流程管理、测试缺陷流程、测试人员技能培训等方面做工作，这样可以用比较少的成本投入来获取相对较大且长期的收益回报。 　　最后，针对普通测试工程师的一些建议，在这样的公司里，其实有着很多意想不到的优越性： 　　（一）这样的公司测试如果不正规，那么你就有更大更多的发挥空间。 　　（二）你可以单独学习自动化测试技术，自己先试着应用到日常工作的软件项目中。 　　（三）你可以直接和开发人员沟通，甚至向他们学习开发技术，这对将来的自动化测试中开发脚本很有好处。 　　（四）每个优秀测试工程师的成长都是个循序渐进的过程。我遇到很多测试界的新手向我发牢骚，很惭愧我没有什么可以告诫他们的，只是希望这样的新人克服浮躁情绪，稳扎稳打练好基本功，想成为优秀的测试专家，就要经历这个阶段。

 

　　软件测试自动化的引入条件

 

　　如果你的测试部门有意向引入自动化测试，那么首先要从思想上统一认识。 　　一、 软件测试自动化的正确认识 　　1） 自动化测试能大大降低手工测试工作，但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标，实际上想要达到 100% 的自动化测试，不仅代价相当昂贵，而且操作上也是几乎不可能实现。一般来说，一个 40-60% 的利用自动化的程度已经是非常好的了，达到这个级别以上将过大的增加测试相关的维护成本。 　　2） 测试自动化的引入有一定的标准，要经过综合的评估，绝对不能理解成测试工具简单的录制与回放过程。实际上，从实现**度来说，自动化测试分五个级别：

级别	说明	优点	缺点	用法
一级	录制和回放	自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识	拥有大量的测试脚本，当需求和应用发生变化时相应的测试脚本也必须被重新录制	当测试的系统不会发生变化时，实现小规模的自动化
二级	录制、编辑和回放	减少脚本的数量和维护的工作	需要一定的编程知识；频繁的变化难于维护	回归测试时，用于被测试的应用有很小的变化
三级	编程和回放	确定了测试脚本的设计，在项目的早期就可以开始自动化的测试	要求测试人员具有很好的软件技能，包括设计、开发	大规模的测试套件被开发、执行和维护的专业自动化测试
四级	数据驱动的测试	能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据	软件开发的技能是基础，并且需要访问相关的测试数据	大规模的测试套件被开发、执行和维护的专业自动化测试
五级	使用动作词的测试自动化	测试用例的设计被从测试工具中分离了出来	需要一个具有工具技能和开发技能的测试团队

 

3） 自动化测试能提高测试效率，快速定位测试软件各版本中的功能与性能缺陷，但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑，要求测试设计者将测试中各种分支路径的校验点进行定制；没有定制完整，即便事实上出错的地方，测试工具也不会发觉。因此，制订全面、系统的测试设计工作是相当重要的。 　　4） 自动化测试能提高测试效率，但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大，将企业级自动化测试框架应用到一个项目中也要评估其合适性，因此决不能盲目的的应用到任何一个测试项目中，尤其不适合周期短的项目，因为很可能需要大量的测试框架的准备和实施而会被拖跨。 　　5） 实施测试自动化必须进行多方面的培训，包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱；如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化测试，那将肯定会以失败告终。 　　如果软件企业有意向实施自动化测试，那么应该具备什么样的条件才可以引入自动化测试呢，才可以最大可能的减少引入风险，并能够可持续性的开展下去呢？ 　　二、对企业自身现状的评估分析 　　第一，从企业规模上来说，没有严格限制。无论公司大小，都需要提高测试效率，希望测试工作标准化，测试流程正规化，测试代码重用化。所以第一要做到的，就是企业从高层CTO开始，直到测试部门的任何一个普通工程师，都要树立实施自动化测试的坚定决心，不能抱着试试看的态度。一般来说，一个这样的软件开发团队可以优先开展自动化测试工作：测试－开发人员比例合适，比如1：1到1：1.5；开发团队总人数不少于10个。当然，如果你的公司只有三五个测试人员，要实施自动化测试绝非易事；不过可以先让一个、两个测试带头人首先试着开展这个工作，不断总结、不断提高，并和层层上司经常汇报工作的开展情况，再最终决定是否全面推行此事。 　　第二，从公司的产品特征来说，一般开发产品的公司实施自动化测试要比开发项目的公司要优越些。原因很简单，就是测试维护成本和风险都小。产品软件开发周期长，需求相对稳定，测试人员可以有比较充裕的时间去设计测试方案和开发测试脚本；而项目软件面向单客户，需求难以一次性统一，变更频繁，对开发、维护测试脚本危害很大，出现问题时一般都以开发代码为主，很难照顾到测试代码。但决不是说做项目软件的公司不能实施自动化测试，当前国内做项目的软件公司居多，有很多正在推行CMM等级标准，这是好事情；只要软件的开发流程、测试流程、缺陷管理流程规范了，推行自动化测试自然水到渠成。 　　第三，说说标准化的开发和管理流程。不管是CMM还是ISO，不管是开发流程、测试流程还是缺陷管理流程，这里不能一一阐述，可以参考RUP（RationalUnified Process， Rational 统一过程），可以参考很多业界文献，我只说明一点，也是我们IT从业人员甚至任何从业人员一个很好的工作原则： 　　a、 把你想做的写下来（计划管理） 　　b、 按照你写下来的去做（行为管理） 　　c、 把做的事情记录下来（报告管理） 　　d、 出现的问题要设法解决（跟踪管理） 　　在测试流程里，这几个要点都一一有所落实；如果你的软件开发团队据此开发软件，那么完全具备实施自动化测试的条件。当然，也许一些公司的测试管理比较混乱，出了问题不知道谁负责，测试人员或开发人员整日唉声叹气。 

 

测试阶段	描述	备注
单元测试/组件测试	这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试，当测试通过时，代码也被完成了。	通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码，而且能够是软件的整体质量更加的好。
集成测试	这里的测试工作集中在验证不同的组件之间的集成上。	这种类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。
系统测试	这种测试是通过执行用户场景模拟真实用户使用系统，以证明系统具有被期望的功能。	这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。
其它两种非常重要的测试
回归测试	回归测试实际上是重复已经存在的测试，通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。	这里完全有潜力应用自动化的测试，你能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。
性能测试	性能测试包括以下不同测试形式： - 负载测试 -压力测试 - 并发测试 -.....	如果没有自动化的测试工具，你将不能执行通过模拟用户的负载实现的高密集度的性能测试。

 

 

　　其三是软件自动化测试切入方式的风险。正如前面所言，一定要记住将自动化测试与手工测试结合起来使用，不合理的规划会造成工作事倍功半。首先，对于自动化测试率的目标是 10/90 （10% 的自动化测试和 90% 的手工测试）。当这些目标都实现了，可以将自动化测试的使用率提高。对于何种测试情况下引入自动化测试，何时依然采用手工测试，我们分开阐述。 　　一般这样的测试条件下使用自动化测试： 　　· 项目没有严格的时间压力 　　· 具有良好定义的测试策略和测试计划（知道要测试什么 ，知道什么时候测试 ） 　　· 对于自动化测试你拥有一个能够被识别的测试框架和候选者 　　· 能够确保多个测试运行的构建策略 　　· 多平台环境需要被测试 　　· 拥有运行测试的硬件 　　· 拥有关注在自动化过程上的资源 　　· 被测试系统是可自动化测试的 如下条件是宜采用手工测试： 　　· 没有标准的测试过程 　　· 没有一个测试什么、什么时候测试的清晰的蓝图 　　· 在一个项目中，你是一个新人，并且还不是完全的理解方案的功能性和或者设计 　　· 你或者整个项目在时间的压力下 　　· 在团队中没有资源或者具有自动化测试技能的人· 没有硬件 　　其四是企业软件的开发语言风险。当前业界流行的测试工具有几十种，相同功能的测试工具所支持的环境和语言各不相同，这里笔者总结了当前国际上流行的几个软件测试工具生产厂商及一些主要IDE产品，读者可根据参考网址去了解列举工具和更多工具的详细资料。 

 

生产厂商	工具名称	测试功能简述	网址链接
Mercury Interfactive Corporation	Winruner	功能测试	http://www.Mercury.com/ us/products
	Loadrunner	性能测试
	QuickTest Pro	功能测试
	Astra LoadTest	性能测试
	testdirector	测试管理
IBMRational	Rational root	功能测试和性能测试	http://www.900.ibm.com /cn/software/rational/ us/products
	Rational XDE tester	功能测试
	Rationaltestmanager	测试管理
	Rationalpurifyplus	白盒测试
Compuware Corporation	QARun	功能测试	http://www.compuware.com/products
	QALoad	性能测试
	QADirector	测试管理
	DevPartner Studio Professional	白盒测试
Seque software	SilkTest	功能测试	http://www.Seque.com/products/index.asp
	Silk	性能测试
	SilkCentral Test /Issue Manager	测试管理
Empirix	e-Tester	功能测试	http://www.Empirix.com/Empirix/ /Web+Test+Monitoring/Testing+Solutions/ Integrated+Web+Testing.html
	e-Load	性能测试
	e-Monitor	测试管理
parasoft	Jtest	Java白盒测试	http://www.parasoft.com/jsp/ products.jsp?itemID=12
	C++test	C/C++白盒测试
	.NETtest	.NET白盒测试
RadView	WebLOAD	性能测试	http://www.radview.com/products
	WebFT	性能测试
MicroSoft	WebApplication Stress Tool	性能测试	http://www.microsoft.com/technet/archive/ itsolutions/downloads/webtutor.mspx
Quest Software	benchmark Factory	性能测试	http://www.quest.com/benchmark_factory
Minq Software	Pure	功能测试	http://www.minq.com/products/
	Pure	性能测试
	Pure	测试监控
Seapine Software	QA Wizard	功能测试工具	http://www.seapine.com/products
	TestTrack Pro	缺陷管理工具

 

 

　　其五还要做时间估算。在评估完前面几项指标后，需要估算实施测试自动化的时间周期，以防止浪费不必要的时间，减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后，会起到事半功倍的效果，但前期的投入巨大，要全面考虑各种因素，明确实施计划并按计划严格执行，才能最大限度降低风险。 　　其六是工作流程变更风险。测试团队乃至整个开发组织实施测试自动化，或多或少会因为适应测试工具的工作流程，带来团队的测试流程、开发流程的相应变更，而且，如果变更不善，会引起团队成员的诸多抱怨情绪；所以应该尽量减少这种变更，并克服变更中可能存在的困难。 　　其七是人员培训与变更风险。简单而言，就是测试团队人员的培训具有风险性，例如每个角色的定位是否准确，各角色人员对培训技能的掌握程度是否满意，尤其实施途中如果发生人员变更等风险，都要事先做出预测和相应的处理方案。 　　一个企业或软件团队实施测试自动化，会有来自方方面面的压力和风险，但是凭借团队成员的聪明才智和公司高层的大力支持，事先做好评估，做好风险预测，那么可以告诉你一个激动人心的消息：你的团队成功引入了测试自动化！有了测试自动化，我们即可享受它带来的超凡价值和无穷魅力：我们的测试工作变得更简单、更有效，我们工作在一个专家级的团队里，因此我们每天都在享受这种成功的喜悦！