3、测试比对

　　当测试脚本写好后，如何判断这个脚本是可以替代手工测试的？这个决定着手动测试对自动脚本的信任度的问题，更决定着一个自动脚本好坏的时候。衡量自动化好坏有两个标准：

　　1）测试Pass的，则确实是Pass的

　　2）测试为Fail的，则即为Bug

　　如果这二者都可以达到，那就是个完美的Project了。不过，当前能做到这些的有几个呢？我们还没有找到真理，我们在通向真理的路上……

　　针对第一个，我认为通过努力，是可以实现的。如果测试步骤，数据和检查点都是和手动测试人员确认过的，并且我们在写脚本的时候也有很细致的出入口判断，这个标准是很容易攻破的。但是说起来容易，做起来难，每个人设计Case的思路和步骤都是不一样的，同样的Case，　让不同的人操作，都可能有不同的结果，又如何保证一个机器的操作呢？这里最强调的就是检查点，有时人眼测到这个界面，可以看到有Error　message或者其他，就会认为有问题，但是脚本只看设定的那几个点，如果那几个点都是没有问题的，脚本则会视为成功。所以，在沟通checkpoint时，手动人员要尽量详细说一下哪几个点或者容易出错的地方，否则漏了就是漏了，有些时候，有些检查点是人下意识就去检查了，他并没有意识到这是个checkpoint，就很可能造成遗漏。

　　针对第二个，业界也是不可避免的。不过自动化人员可以通过某些技术手段，使得自己的脚本更健壮一些。也希望手动测试的GGMM们体谅这一点，自动的东西，有些时候会有一些诡异的事情发生，科学所无法解释的，只要这样的问题控制在一定比例，就还可以接受的，不要因为这一点点的瑕疵，而否定所有自动化的成果，这样我们会很伤心的。

　　4、测试执行

　　自动测试脚本全部写好后，需要执行一轮测试时，这个时候又该怎么办呢？我怎么知道哪些Case是自动会跑的，又有哪些是需要手动测试的呢？

　　目前我们的做法是，对已有的测试管理工具进行二次开发，将已经实现自动化的Case做标记和关联。当启动一轮测试时，自动化脚本运行的同时，将会手动执行标记为没有自动化的Case 。当脚本运行完，如果有Failed　case，再手动check是脚本的问题还是Bug。

　　看似完美的一次合作就执行完了，还有什么问题吗？往下看……

　　5、自动化报告的可读性

　　一般情况下，一个自动的Case会涵盖多个手动测试所谓的Case, 当一个自动Case 失败之后，如何判断是哪个手动case失败呢？定位到手动测试case之后，如何判断该 case 是脚本问题还是Bug? 这个问题如果抛给直接开发这个case的人，可能他都要分析很久，那如何让一名手动的测试人员很快的定位问题呢？这就涉及到了自动脚本运行完成后的测试报告了。

　　测试报告的格式和内容也需要和手动测试人员反复沟通确认的，而不是自动人员一厢情愿的写自己认为很不错的报告，其实没有人能看懂。

　　总之，在面对这样合作的问题时，我们多换位思考一下，无论自动手动，我们都是一个名字，叫QA，只要都这样想，无论面对什么样的环境，我们的合作都会很融洽的。

　　以上是我作为一个自动测试人员的看法和观点，希望有手动测试的人员也发表自己的看法，多沟通讨论。

原帖地址：http://bbs.51testing.com/thread-178992-1-4.html

版权声明：本文由会员1316016首发于51Testing软件测试论坛每周一问活动（09-12-29）。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。