自动化脚本的check list

过去的三个月一直在做光传输的自动化测试，底层API和自动化脚本也写了不少，但一直都感觉没有一个标准指导自己去写脚本，总是按着自己的习惯去做。前天参加了一个测试大牛的培训，他结合自己的工作经历，讲了很多方面，包括自动化测试，系统测试，测试管理和评估等等。给我的感觉是，如果测试能做到他那样的程度，真的是一件很享受的事情。因为自己是做自动化测试的，所以对他说到的脚本质量比较关心，如何能保证一个脚本的质量和减少后期维护成本呢？他的做法是规定一个脚本的check list，每个脚本出来后，都要和团队其他成员按照check list来review脚本，我觉得这样不错。他说的check list很长，结合我们当前的状况，下面几点确实应该作为我们后期努力的目标：51Testing软件测试网(A%\#b:ViL8h;Yi#G5m

V%@fBo01 清晰的title。一个清晰简明的case title能帮助我们了解脚本的大致功能，这个很重要。

{-qeK [o0L02 丰富的日志。他的要求是，脚本出问题后，通过日志就能发现脚本的测试逻辑和出错原因。我觉得这点很重要。平常为了提高开发效率，往往只在关键步骤后加日志，而且表述也不是很清晰，导致一旦脚本出错，就需要结合日志和脚本一起debug，虽然debug几次后，也可以做到只看日志来找原因，但对于日后维护脚本的人就是个麻烦了。而且脚本的数量会越来越多，在紧张的回归测试里面，为了能更快的定位出错的脚本，一份详细清晰的日志就显得更为重要了。所以我们前期偷懒养成的坏习惯，其实最后都追加到项目成本里面了，而且还降低了脚本的质量，确实很惭愧。对于以后的脚本，我想我能够做到只通过日志就可以了解脚本的测试逻辑和出错原因。51Testing软件测试网]uf0B_['p2d~

3 回归脚本的数量会越来越多，为了在紧张的regression test中准确高效的定位问题，我们需要保证，在脚本进入regression train之前，要完成一次clean run report。report包括两个方面：a 测试结果中只有pass 和 fail两种情况；b fail的脚本必须要有清晰的出错原因描述。clean run对于回归测试中定位是软件版本更新的问题还是脚本的问题很有帮助，为了降低大量脚本可能带来的调试和维护成本增加，我们有必要在开始regression test之前，完成这么一个环节。51Testing软件测试网Y:A`3N&s.N

,[L;n+z#W`wj04 脚本的版本管理。面对较为频繁的软件版本release，我们需要对脚本进行版本管理，使得每一个软件版本都有其对应的脚本。但如何做到脚本的版本管理，暂时还没有太好的办法！？