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

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

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

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

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

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

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

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