换句话说,我们无法相信自动化测试的结果。
这真是要把人折磨死的节奏啊。
我们想了很多办法,比如每一轮自动化测试,同一个脚本都反复执行几次(如执行5次),然后设置一个脚本执行失败的“容错值”(比如设置容错值为2,即执行5次这个脚本,脚本失败只要不超过2次就都算通过,OMG这个想法也真是见招拆招,见洞补洞,丧心病狂啊)。想办法保存所有的测试执行记录,然后再手工再从测试记录里面去抽检一定比例的测试脚本的执行结果,看抽检的结果和脚本运行结果的差异,再以此来决定脚本出现误判的概率(OMG,我都服了我们小组的惊人的数学功底,但这真的是完全跑偏了好吗)…….
其实这些问题,归根到底就是脚本的check部分写得有问题。
如果我们把自动化测试比作一个机器人。让自动化测试来模拟执行某个功能并不难,这就像是机器人的手一样。难的是机器人的“脑子”,如何让自动化脚本来聪明的确认脚本的执行结果就变得非常重要,这才是自动化测试真正的难点。
首先我们要梳理自动化check的使用规范,根据的业务的实际情况和使用的自动化工具来确定要怎样进行check才不会遗漏,来最大程度的保证自动化测试在结果检查上的准确性。
对high level的自动化测试来说(对low level的自动化测试,如接口、单元测试来说,这个问题并不明显),无论是UI界面的,还是CLI(命令行)的用户接口的,都隐含了一个情况,就是自动化测试只能check到预期有的东西,却不能check到预期外的东西。
以下面这个web页面为例。假如我的自动化判定的是“秒杀”,但实际“秒杀”后面却多了一些别的东西,比如多了个“:)”。在手工测试下,我们很容易发现这个问题,但自动化测试却往往测不出这个问题。
原文转自:http://gitbook.cn/books/58d23ddcfa7558521a30277a/index.html