浅谈自动化测试

tomzhang

对于自动化测试，我始终有一种特殊的感情，围绕它的事情让我最终选择了开发这条路。如今5年过去，我想以更加客观的态度评价一下自动化测试（功能的回归测试）。主要涉及3个问题：
1.自动化测试适用的场景
*版本的冒烟测试
*功能的回归测试
这2个是公认的自动化测试的最佳场景。
2.自动化测试的实施
自动化测试的实施包括：自动化测试工具的选择，自动化测试环境的搭建，人员的培训等。
3.自动化测试的成效
5年前，当测试行业还没有像如今这样繁荣的时候，我已经误打误撞的进入了测试领域，其中也经历过和大家一样的兴奋期，迷茫期和痛苦期；让我感触最深，也让我最为得意和失意的就是自动化测试了。在当时的我看来，自动化测试就好比测试领域的“九阴真经”，没有什么能与之媲美；带着一腔热情，我负责起了公司的自动化测试工作。公司想通过“每日版本构建”和“每日自动回归测试”2种手段来提高产品的质量。基于这个目标，我们选择了Vss+Vs2003+Nant+QTP+TD等工具，
Vss：版本控制工具，我们使用它来获取源代码。
Vs2003：.net的开发工具，我们使用它来编译源代码。
Nant：我们使用它将前2步的工作写成脚本，每晚自动获取代码，自动编译代码，自动发布程序。
QTP：web平台的自动化测试工具，我们使用它将手工的回归测试录制成脚本并执行。
TD：bug提交工具，我们使用它来定时运行QTP脚本，达到每晚自动执行测试的目的。
待环境搭建完成，并尝试几次小范围的自动化测试后，自动化测试就全面开展了起来了。
每晚下班前，我们把自动化测试的策略设置好，如：何时获取源代码，需要测试哪些QTP脚本...待第二天上班就查看自动化测试的运行报告。开始实施的1个月时间里，几乎每天晚上，自动化测试都没有按照我们之前设想的那样顺利进行过，其中出现的问题五花八门：
1.运行自动化脚本的客户端pc内存耗尽
2.客户端pc操作系统的屏保造成了验证问题(运行时截屏与录制时截屏不一致)
3.客户端浏览器的设置有问题（自动完成表单上的用户名和密码）
4.网络问题，如：获取服务器上代码时，访问web服务器时，网络掉线
5.QTP脚本间的时间间隔太短，造成前1个脚本未执行完（失败了），后1个脚本已经开始执行了。
6.TD无法调用QTP脚本
7.源代码编译失败，造成系统部署失败
8.QTP脚本突然不识别某个控件
...
后来，经过大量的实验和google，上面有一些问题解决了，有一些问题找到了临时的解决方案，自动化测试的成功率最终也能达到70%-80%。可是问题又出现了，前期投入了大量的人力，精力录制脚本，通过它实际上并没有发现几个bug（仅发现开发人员对某些页面有过修改，但这并不能确定是bug），由于没有人力作手工测试，一时间软件非常的脆弱。小领导为了政绩不许暂停自动化测试，于是手工回归，自动回归并驾齐驱，于是抱怨声，埋怨声四起。对于自动化测试，我有如下建议：
1.不要把自动化测试期望得过高
2.自动化测试需要开发人员配合，比如：第7点，开发人员提交的代码连编译都无法通过，如何发布？如何测试？还有第8点。
3.自动化测试要选择时机，过早，过晚开展都不好。过早，系统太不稳定，导致
前期录制的脚本会大量返工；过晚，系统已经上线，回归测试已经没有必要。
4.不是所有的测试用例都有必要做自动化测试。
5.自动化测试需要依据人手而定，测试人员较少的团队开展自动化测试，只会影响正常的测试工作。
最后，领导需要明确的指出自动化测试成功的标志。

msnshow

自动化测试的确是要通过多方面考虑，看是否适合自己的业务，是否是时候推行，并不能跟风