漫谈自动化测试（五）——实施过程

唉，换了个工作，需要学习很多新知识和技能，这么久才完善这个博文，实在感觉惭愧啊。现在立马补充完整，不能让这篇文章太监了。。。。

需求分析

需求分析的重要性无需多言，但在实际实施过程中，是我们容易忽视的地方。因为需求分析说难吧，它其实挺简单的；说简单吧，它其实挺难得。（你是在说禅语吗？）

且容我稍微解释一下。其实在我们做任何事情之前，都必须要有目标，就像每个人都人生目标不一样，各个公司、团队的需求目标也不一样。人人都想迎娶白富美、攀上高富帅，

关键你也得照照镜子，自己长得怎样，口袋里有多少米啊。同样的道路，大家都想一个高大上的自动化测试框架，最好能够一键把所有的测试全部搞定，自己喝杯咖啡坐等测试报告。那也是理想的情况，如果真是这样，搞测试的全部都得下岗，老板还留着你干嘛？他不知道按下键盘执行吗？

正因为各个公司、团队资源上的差异（资金、人力、设备等等）以及产品的特性（分布式、变化性、底层驱动、视频图像等等），甚至是公司的长期战略等，都决定了我们的需求做到什么程度。如果公司资金短缺，人力不够，我们就首先考虑开源免费框架和工具；如果公司资金雄厚，人员充足或具有长远规划，我们可以考虑定制适合自己的自动化测试平台。

总而言之，需求分析得因地制宜，关键在于分析到适合自己，满足当前和未来的需求，考虑到开发成本、可扩展性、可维护性、稳定性等方面的问题，一般来说就成功了一半了。

编码实现

自动化测试的开发，离不开编码。测试工具、测试框架、测试用例编写等等，都需要编程语言来实现，无论是用shell、perl、ruby、python、php、java、c/c++ 还是c#，都需要制定一套相应的编码规范。对于“崇尚自由”的程序员来说，编码规范就像一个紧箍咒，怎么都不想它戴在自己头上，但却希望别人都遵守规范。如果你对这话没啥感触，说明你还没遇到过各种奇葩的编程风格，没有阅读过“像一坨屎”一样的代码。 当你评论人家的代码“像坨屎”一样时，希望自己也该好好反省，某一天别人阅读你的代码时，是否会有同样的感触？

自动化测试的开发，也是软件开发的一部分，必须严格按照编码规范，通过review等机制保证代码质量，做到可阅读性、可维护性、健壮性、可扩展性等。测试工具，本身如果有bug，怎么去测试被测产品的正确性？自身不稳定，怎么去验证产品的稳定性？所以说，对于自动化测试相关工具，编码应该更加严格，杜绝自身的问题。

测试验收

如果自动化测试框架比较大，涉及的功能点比较多，可以采用持续集成的方式，增量式开发交付高优先的功能模块。对于每个新增功能模块，自动化测试开发人员和手工测试人员（有可能是同样的一批人员）需要协调合作，互相验证正确性、稳定性、容错性等。

我们要始终牢记，自动化测试套件（框架、工具、脚本等）是一个整体，它们也是相互协作的，必须要进行完整的集成测试，通过最终用户的验收测试，才能进行最后交付。