自动化测试闲言杂语

项目的自动化测试有了一个比较理想的结果，易于扩展、维护和使用的测试架构，接近80%的 覆盖率，项目组积极的反馈结果，半年的努力没有白费。回想起刚到公司时接下这个重任，自己并没有把握，甚至有些心虚，毕竟自动测试并不是我所擅长的，而 且，陌生的测试工具、庞大而复杂的测试系统，对我来说都是一种挑战。心里没有把握自然不能跟老板说，打电话给一个在这方面经验很丰富的朋友，他告诉我“要自信，要靠自己”，于是，摒弃了所有的杂念和依赖，一头扎进了自己底气不足的自动化测试。51Testing软件测试网I;V FI'qo

很感激我的mentor，在刚进公司的前两周，没有马上让我接手自动化测试，使我有足够的时间熟悉系统的基本功能，就这么一个缓冲，了解了系统的基本功能，也研究了一个基本的自动化测试架构的组成，对测试系统、对自动化测试自己有了感觉。熟悉测试系统，这是软件自动化测试的第一步。51Testing软件测试网oq7|c{ j

我的一些刚来的新同事或实习生，总是迫不及待地想学习自动化测试或者是想通过自动测试脚本学习业务，我总会告诉他们，熟悉业务是自动测试的基础，不要小看手工测试过大夸大自动化测试。如果一个系统你都没有亲自手工测试过，又怎会做好自动化测试呢？51Testing软件测试网4w!af ?.zF

 用 什么工具，我没有选择，因为项目组在我来之前就已经决定了。关于工具的选择，我看重的首先是它是否能够满足项目的需要，是否容易扩展，可以满足系统任何功 能的测试自动化；其次是它是否易用，能否容易上手；当然最重要的是它的稳定性，是否不需要人工干预就能稳定地批量运行所有的自动化测试脚本。这三点，项目 组所选择的工具都满足了，我自然乐于接受。选择合适的测试工具，是软件测试自动化的第二步。

 开始做自动化测试，是从系统的基本功能开始，目标是每次出built都需要花半小时以上的手工smoke test cases测 试自动化。在我接手前，已经有同事做了页面相关的功能测试，看了一些以前的脚本，只是简单的录制、回放，因为没有整理过，也就没有业务逻辑和注释，花了很 大的精力才弄清一个脚本的步骤和功能。而且，这些脚本中，关键字的参数化做得不好，每次运行都需要手工修改，需要手工来干预的脚本，只能算是半自动化。最 严重的问题是，同样的功能，同样的脚本，会被重复地拷贝，当这个功能或业务流程被改变的时候，所有相关的脚本都需要修改，那将会是很大的维护代价。思考了 一天，我决定放弃原有的所有脚本，重新设计系统的架构。放弃原有的两百多个脚本，有些可惜，但如果按照原来的思路走下去，我将会付出更大的维护代价。有舍 才会有得。

问题我看到了，知道要改，但至于怎样改，心里并没有把握，我知道自己需要时间去研究。我将用于smoke test的系统最基本的功能挑出来，作为设计的研究对象。Web测 试自动化，无非就是录制、整理和回放，录制和回放都是简单的事情，关键是整理，好的脚本，应该容易扩展、维护和使用。这十几个脚本，我花了很多心思，不断 地思考、不断地改进、不断地与我的同事讨论。慢慢地，自己的思路清稀了起来，做出了自己想要的架构。首先是容易扩展，能够满足现在的功能需求，也能满足以 后需要测试的功能的需求。第二，容易维护，当业务流程、接口或页面变动的时候，只需要做一些简单的修改就可以实现。第三，可读性强，别人能够容易读懂和接 手维护。第四，容易使用，项目组的其他人想要使用的时候能够简单地搭建和运行。第五，有统一的编码规范、存储规范和编写风格。最后，是最重要的一点，是脚 本具有很高的可信性以及自动运行的稳定性。51Testing软件测试网'DW7V0J,@!cc

我像绣花一样一点一点地将这个自动测试架构绣了出来，比别人多花了N倍的心思和时间，晚上从公司走出来，傻傻的望着夜空数星星，虽然累很仍然很快乐。51Testing软件测试网eh/?|_`$l

从 系统的基本功能入手，设计自动测试架构，这是软件测试的关键一步。架构的好与坏很重要，它影响到系统的扩展、维护和使用，如果想要系统容易扩展和维护，一 定要多花心思在设计上。很多同行问我使用什么测试工具，我会告诉他们，用什么测试工具其实并不那么重要，不同的人使用同样的测试工具，会做出效果完全不一 样的东西，那是因为他们的架构不同，设计比工具重要得多。

 架 构出来之后，就是系统功能的自动化脚本编写，因为项目的原因，当时的自动测试团队已经解散，我面临的是只有一个人的自动测试团队，怎样将上千个测试案例自 动化，成了我头疼的问题。至今仍然很感激我的老板和项目经理，调配给我足够的资源，真正的打开了项目的软件测试自动化之门。团队中的其它成员，都是没有自 动化测试经验的同事，给他们足够的培训和技术支持很关键。他们所负责的功能，我都会写一个例子，他们可以参照例子按照我们自动测试架构编写规范写脚本，遇 到技术问题或业务问题，我会协助解决，在整体的架构上，我会全局把握。那一段时间，特别忙，架构的扩展、业务的熟悉、问题的跟踪解决，有时候同时有好几个 问题在等着我解决，但就是这么一段忙碌的日子，从对系统基本业务的理解到系统业务的全面理解，从原来的只有十几个测试案例的自动化测试脚本到上千个自动化 测试脚本的实现。很感激我的这些同事，现在他们大部分都回到了他们原来的角色，我也将要开始担任新的角色，但那一段一起工作的日子，我会记在心里。也是因 为大家一起的努力，老板原要求实现web页面自动测试或系统30%功能的自动化测试，我们最终实现的是几乎所有接口所有检查点的自动化测试，接近80%的测试覆盖率。

自动化脚本的编写，当然要注意全局的把握和review，不同的人会有不同的风格，稍不注意就会问题多多。51Testing软件测试网 f*|6x]:K(]

 脚本编写完成之后，自然是使用。脚本在前期的使用是功能测试和数据准备，在项目稳定之后的最大价值就是回归测试。我将脚本分为了三个级别：基本流程测试脚本，用于每次出新built安装后做smoke test；关键功能测试脚本，每次出新built后 对所有重要功能进行回归测试，确保改动不会对原有功能的造成影响；全面回归测试脚本，一般每周跑三次或者是系统经过比较大的修改后作回归测试。自动测试脚 本在回归测试中发挥了出色的作用，特别是系统在上线前夕，为了适应客户的需求，功能不断修改，对于原有的功能，自然不可能都手工测试，脚本在这个时候的意 义特别大。

 同事或朋友经常问我，自动化测试应该在什么时候介入？如果系统的功能需求和接口定义都很清晰，系统开发完成并且基本功能手工测试成功后，就可以开始编写自动化测试脚本了，一方面可以利用脚本做功能测试和bug验证，另一方面也可以用来做回归测试。但如果系统的变化比较大或接口的定义不够清晰，最好还是先手工测试，待功能比较稳定之后再写脚本，因为如果功能的变化太大，维护脚本的付出可能远远小于脚本可以带来的效益。51Testing软件测试网 a"F
c,tl;MR:x/m

当 然，并不是所有的系统都适合做自动测试，如果只是一些短期的项目，或者是脚本不会被重复利用，就没有做自动化测试的必要，成本会远远大于收益，也就没有做 自动化测试的必要了。反之，如果是产品的测试或长期的项目或是自动化测试脚本会被反复使用，自动化测试就显得很有必要了，做完一套脚本之后就会反复被使 用，当然可以节省很多成本，也可以提供测试的效率。51Testing软件测试网-@ |
g b:A w(`'Q

 这个架构，自己付出了很多心思，付出所得到的回报找到了自动测试的感觉，底气不足变成了胸有成竹。项目组的其它团队也看到了自动化测试的好处并打算参考我们的架构实现自动化测试，再做设计，扬长避短、一气呵成。51Testing软件测试网&V/Nd%c\'zop ]jk

 敲完这些文字，也就意味着我的自动化测试工作暂告一段落，下周开始，因为项目的需要，将会开始我的另一个全新的角色。这个架构，绝对不是完美的，肯定还存在可以改进的空间，希望接替我自动化测试工作的同事，也能像绣花一样用心去完善它。