题记：上周，产品终于Release了，前后历时近两年时间，期间经历了一次需求变动，四次Interation。产品是新版本开发，需要同时在四个平台（window，Linux，Aix，zLinux）开发，每次迭代实现一个feature。在敏捷盛行的，这样的开发周期是很多公司所无法接受的，但作为一个服务器端产品，对软件质量的要求比较高（作为一名资历尚浅的QA，暂浅不评述这种有点类似“螺旋模型”的开发模式的优劣），只想谈谈在每次迭代测试间，我们还有哪些地方可以做得更好！

　　背景：前一版留有测试用例1600+，其中P1的大概200个左右，P2有600多，剩下主要是P3以及少部分P4。在上一版，在没有automation的来做Regression test的情况下，跑完一轮full cycle，即1600+的测试用例， 差不多需要4名QA，10 working day，也是每人每天完成40左右的测试用例。

　　1、自动化测试

　　其实之前的版本留有一套自动化测试，但没有任何文档、不稳定、难以维护，所以在做新版产品开发时决定要投入精力重新开发出一套自动化测试来。作为一个生命周期很长的产品（>5年），有着一套健壮、稳定的自动化测试来做回归测试，以确保代码改动，或新增功能不会影响以前能够正常工作的功能，这是十分又必须要的。需要明确的是：不要期望自动化测试能够帮助你发现新的bug。

　　其次，在写自动化脚本之前需要明确哪些测试用例有自动化的价值，并不是之前1600+的测试用例都需要实现自动化，比如讲，有些测试用例实现起来很简单，但它的优先级很低，或者有个P2的测试用例，如果要实现自动化，在技术上有很大难度，而且即使实现了，也不能保证很稳定，在这个时候，需要考虑投入产出比（ROI）。

　　从技术上讲，自动化框架编码，写自动化脚本并不是十分困难，那难在什么地方呢？我觉得难点在于：

　　● 自动化测试用例能真实全面反映用户场景。同样的关键字，同样的用例，但不同的人写出来的自动化脚本可能是不同的，不同在于对用例的理解，在于经验。

　　● 整个自动化测试完成后的Pass Rate。 如果自动化脚本误报率很高的话，会让人对自动化测试的可靠性大加怀疑了。为了保证准确性，会在一些keyword中，或则自动化脚本中添加一些容错延时机制。

　　● 自动化测试完成的时间是可接受的。如果自动化测试跑完需要两三天时间，这有点无法接受了。要在保证Pass Rate的前提下，尽可能能缩短时间。

　　● 自动化测试用例的tuning。当代码改动导致自动化测试用例Fail，排除了是bug，这时候要及时调整keyword，或则自动化脚本。

　　自动化的开发也分成了两个Interation，第一个阶段完成了自动化框架、大部分的keyword和基本的smoke测试用例的自动化，第二个阶段，补充一些keyword，完成regression测试用例。后，新Feature的自动化。到目前为止，产品的自动化覆盖率差不多40%左右，但覆盖了产品核心功能。

　　这套自动化测试发现了哪些问题呢？这个问题肯定经常被问到，稍微归纳下：

　　● 代码改动导致以前正常工作的功能Fail。举例，之前可以正常处理uuencode编码的邮件（注： UUEncode格式本来比较难处理），因为一次代码改动fail。

　　● 验证HotFix/Patch。一次帮sustain team验证Patch， 打完patch后，没跑几个cases ，系统挂了。

　　● 内存泄露。发现过一次内存泄露，当跑完十几个特定用例后，内存居然被吃光了后Crash。结果发现在跑这十几个cases时，需要reload配置，但每次reload都没释放之前资源。

　　● 多线程竞争资源。这次automation 过程中的crash很难重现，后是RD分析dump文件后找到Root Cause的。

　　自动化开发过程中的一些经验教训：

　　● sync-up meeting（也叫stand up meeting）。每天花上十分钟，sync下进度，讨论下在编码、写自动化用例过程中遇到的问题，这在自动化开发初始阶段还是很有必要的。

　　● 确保每天完成的自动化脚本都能通过，然后把这些没问题的自动化脚本和之前的脚本串起来跑，确保没问题。

　　● 实现好的自动化脚本需要交互检查，看步骤，看检查点是否完备。

　　● 自动化框架源码、实现的关键字、自动化脚本、配置文件、生成的Data 都必须加入到版本控制系统中去，如SVN，Git都可以。确保代码，脚本没问题后，及时Check in。

　　● 每天自动化测试的结果整理统计后，发给team里面的人。

　　● 对于那些Fail的测试用例，需要有人去follow up。

　　● 当发现测试用例的fail是由代码改动引起的，确认不是bug后，需要及时调整自动化代码，自动化测试用例。记得Check in 你的变动。

　　● 自动化环境的部署文档，自动化框架和关键字实现文档。前人栽树，后人乘凉的道理，方便他人接手。