原因四：测试脚本不够健壮，缺乏必要的容错性。这个就不多说了，写过自动化测试的人对这一点应该都有感触。没有感触的人可以去写上一两百行的脚本每天执行，跑上一个月，很快你就能明白我说的意思了。
原因五：公司对自动化测试的定位。在我们的虚拟场景中，大家是因为受不了重复工作才想到自动化测试，其实这已经晚了。自动化测试应该未雨绸缪，早做准备，但是这个也不多说了，按照国内软件公司的风格和做事习惯，这一点说了也白说……
OK，总结完了，现在我们重新来做自动化测试：
1、首先，我们明确了测试目标是逐步实现核心功能的自动化.
2、其次根据这个目标我们明确了这周自动化测试要实现的测试点是表格数据的保存和运算，
3、然后根据这个测试点我们设计了N条测试用例以检查正向和反向的情况；
4、接着我们规划了我们的测试脚本，我们重新设计了操作步骤以防止脚本之间互相影响；我们准备了测试数据以支持脚本的验证，我们甚至参考IBM的ITCL框架，决定将脚本划分成对象层、操作层、用例层，
5、我们明确了团队的工作模式：我们挑选了几个编程基础比较好的人去负责专职实现自动化测试，
6、我们也和项目经理沟通好了，他也同意抽出一两个专职的测试人员来实现自动化测试，并且要求开发人员不得随意更改界面，以保证自动化测试在发版阶段的稳定性。
7、最后在工具的选择方面，为了提高脚本的开发效率，我们决定使用RFT，并且约定不再使用录制功能以提高脚本的可维护性（其实录制用好了脚本一样很好维护）。
8、我们确定了脚本的运行模式，决定每天晚上下班前开始执行自动化测试，第二天来看结果。至于自动构建，决定放到下一个阶段再考虑（量力而行，第一次不要贪多贪全）
现在所有的事情看起来都井井有条了，但是貌似还是有很多的问题没考虑清楚，或者我们由于缺乏经验不知道应该怎么做。那么这个时候我们应该开始做自动化测试了？我的回答是完全可以~！因为我们已经在自己的能力范围内考虑了所有的问题，做了尽可能充足的准备，现在就要迈出最关键的一步：按照我们对自动化测试规划，完成我们第一个有意义的测试脚本，并且能让它执行起来。想知道水有多深，唯一的办法就是踩下去
于是接下来的一段时间，每天就是上班、写脚本、调试、下班、执行脚本……上班、写脚本、调试、下班、执行脚本……
两个星期以后，第一阶段的测试用例完成了，我们实现了核心功能中表格数据的保存和运算的自动化测试，终于再发版本的时候，不用再苦逼的盯着屏幕像僵尸一样录数据了。节省的时间我们可以去规划下一阶段要实现的功能点，补充测试用例，然后再提交给写脚本的那几个人，一起看起来都步入正轨，并且开始变得美好了。这可以说是自动化测试一个比较成功的开始。
正所谓万事开头难，第一次做自动化测试也是这样，切忌一上来就拿着测试工具昏天黑地的录脚本，我们应该也必须先做规划，想清楚要做什么了，考虑一下怎么做，然后剩下的事情就是去做，just do it.
版权声明：本文欢迎转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
