1.1.1.5 何时避免展开自动化测试
在1.1.1.4节中，归纳了自动化测试的适宜条件，但是万物都有另外一面，自动化测试也有很多禁忌，作为一名测试工程师或者未来的自动化测试工程师来说，如果触犯了禁忌还要执着地做下去，后果也只有一个，就是自讨苦吃，给企业、项目团队带来损失，使得领导以后再也不信任自动化测试，使自己对测试自动化技术更加迷茫！接下来，作者以自己多年自动化测试实战经验以及学习经验，一定要告诉读者，在自动化测试中，哪些是犯了大忌的，读者务必吸取前人的教训，扬长避短，如果以后在项目中和以下任何一条有冲突，千万不要开展自动化测试。
● 项目周期短，需求变更频繁。当你的项目周期不是很长的情况下，请不要引入测试自动化，因为这样的话，不但收不回成本，而且会延长产品的发布时间，并且这样的行为是毫无意义的！作者在1.1.1.3小节中的第一条已经提到了。自动化测试的成本计算方式及其计算实际参照，在这里则不再多加阐述。当然，还有一个问题，相信有项目经验的读者一定会碰到过类似的问题，即使这个项目是一个长期的项目，但是客户经常性地更改需求，甚至时常更改老功能的业务逻辑。这种情况下，即使周期再长的项目也最好别引入测试自动化，因为，即使你有再好的自动化测试方案和执行技术，但你始终赶不上客户变更的速度，最终仍然还是会放弃，因为永远在收拾“烂摊子”！
● 在软件版本还没有稳定的情况下。当你准备引入测试自动化时，请先确定你所在的项目，版本功能是否已经稳定，如果版本功能还不是很稳定，主功能或大量的功能有被重新更改的可能性的话，务必暂时缓一缓，不要随意地开始自动化测试之旅。
● 没有明确的项目测试自动化计划、措施和管理。在这里，作者根据多年的项目自动化测试实战经验可以用很确定的态度与语气告诉读者，软件自动化测试和软件开发工程是一脉相传的！作者在此不阐述软件开发工程的基本概念，但是作者一定会强调，在自动化测试的开发过程中，一样需要通过严格的开发计划、版本管理、代码管理等一系列相关措施，兢兢业业地做好每一步工作，踏实地管理和控制好每一个环节。自动化测试脚本不是一次性的，而是需要长时间维护下去的，如果事先没有制定良好的测试方案，实施过程中不严格根据方案执行，开发完毕后又不做任何改进或提出各种优化方案等，那么你说，最后项目自动化测试会成功吗？
● 领导不支持。目前，较多企业，特别是中小型企业的高级管理人员还是没有能力或者没有信心可以将软件测试自动化做好。在这种情况下，首先，作者认为还是先和领导沟通好，取得他们的支持、理解与信任后再引入测试自动化比较妥当；没有领导的肯定与支持，自动化测试之旅一定是无法顺利展开的，最终也达不到终点，多半情况下会中途不了了之，如果这样的话，还不如不要引入测试自动化呢。
● 多数对象无法识别以及脚本维护频繁与艰难，二者有其一，自动化测试注定失败。又一次提到了这个说法，因为它的确太重要了！希望读者能真正地通过作者一次又一次地重复，真切地了解到这个自动化测试的重大问题。根据前文的不断讲述，作者再总结一下，如果项目中存在大量无法识别的控件（这种情况基本是发生在系统中存在大量的第三方控件）或者没有获得相应的对象识别插件，是没有办法写出自动化测试脚本的。当然，对象的识别不一定要靠插件，还有其他解决方法，比如SDK插件扩展，或者让开发人员提供相应的DLL来识别等，但是，如果有一半的插件不能识别，那么再强行为之，耗费的人力、物力将会有多大？估计能够重新开发一个新项目了。脚本维护频繁是直接和前文所述的需求变更频繁有关的，需求一直在变，自动化测试工程师只能跟着将脚本永无止境地变化下去，直到头晕目眩、直到大量测试开发工程师受不了如此的“虐待”而离职。最终，自动化测试正式宣布“失败”！
本文选自《51Testing软件测试作品系列》之九——《精通QTP——自动化测试技术领航》。
本站经人民邮电出版社和作者的授权，近期将进行部分章节的独家连载，敬请期待！
版权声明：51Testing软件测试网获人民邮电出版社和作者授权独家连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
相关阅读：
