自动化测试的7个步骤(10)

　　启发式确认： 我曾经看到很多测试自动化没有真正意义上的结果校验，其原因有两个，一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的，另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过，采用手工校验测试结果的方法是真正意义上的测试校验。标准文件( Gold file )是另外一中校验测试结果的方法。首先，捕获被测试程序的输出，并检视程序的输出，然后，把输出信息文档化，并归档，作为标准文件。以后，自动化测试结果与标准文件作比较，从而达到结果校验的目的。采用标准文件的方法，也有弊端。当产品发生变化，自动化测试的环境配置发生变化，产品的输出发生变化的时候，采用标准文方法，会上报大量的误报告警。做好的测试结果校验方法是，对输出结果的特定内容作分析，并作合理的比较。有时候，很难知道正确的输出结果是什么样的，但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法，是因为担心如果结果校验漏掉了任何信息，可能导致自动化测试自身出现错误。不过，我们在测试过程中往往采用折衷的做法，没有采用大而全的测试结果校验方法，这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法，那么他必须找相关人员咨询，寻找一种合适的测试结果校验策略，这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下，找到被测试产品的缺陷。

　　把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，你将进一步迈向成功的自动化测试。

　　步骤六：有计划的部署

　　在前面的故事中，当自动化工程师没有提供打包后的自动化测试程序给测试执行人员，会影响到测试执行，测试执行人员不得不反过来求助自动化工程师指出如何使用自动化测试程序。

　　作为自动化工程师，你知道如何利用自动化方法执行测试和分析执行失败的结果。不过，测试执行人员却未必知道如何使用自动化测试。因此，需要提供自动化测试程序的安装文档和使用文档，保证自动化测试程序容易安装和配置。当安装的环境与安装的要求不匹配，出现安装错误的时候，能够给出有价值的提示信息，便于定位安装问题。

　　能够把自动化测试程序和测试套作为产品对待，那真是太好了。你应该对自动化测试程序和测试套开展测试，保证它们不依赖于任何专用的库或者是设备上的任何其他程序。

　　保证其他测试人员能够随时利用已经提供的自动化测试程序和测试套开展测试工作;保证自动化测试是符合一般测试执行人员的思维习惯的;保证测试执行人员能够理解测试结果，并能够正确分析失败的测试执行结果;这需要自动化工程师提供自动动化测试相关的指导性文档和培训。

　　作为测试管理者，你希望在自动化工程师离开前，能够识别并修改测试套中的所有问题。自动化工程师迟早会离开的，如果你没有及时的把测试套中的问题提出来，就会面临废弃已有的测试套的决定。

　　良好的测试套有多方面的用处。良好的测试套支持对产品新版本的测试;良好的测试套在新的软件平台上可以很方便的验证产品的功能;良好的测试套支持每天晚上开始的软件每日构造过程;甚至开发人员在代码 check in 之前，用良好的测试套验证代码的正确性。

　　测试套的共享也很重要。很难预见以后什么人会继续使用你开发的测试套。因此，尽量让产品开发测试团队中的成员都很容易获得你的测试套。可以把测试套放在公司的内部网络上，这是个很好的办法。这样，大家就不必为了获取一份需要的测试套而四处打听。有些人总是感觉自己的测试套还没有最终完工或者不够完美，而没有拿出来与人分享，这种做法一定要改变，共享出来的测试套不一定非常完美，共享才是关键。

　　有计划的自动化测试部署，保证你的测试套能够被产品相关人员获取到，你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。

　　步骤七：面对成功的挑战

　　当你完成了所有的事情，测试套已经文档化了，并且文档已经交付了。测试执行人员能够理解要开展的测试，并知道如何完成测试执行。随着你所负责产品的进一步开发和维护，测试被反复重用。虽然，在自动化使测试变简单的同时，也总是使测试过程复杂化。测试人员需要学习如何诊断自动化测试执行失败的情况，如果不这样做，测试执行人员会认为执行失败的情况是由自动化引起，然后，自动化工程师被叫过来帮助诊断每一个执行失败的情况，开发人员往往也会认为执行失败是由于自动化测试自身引起的问题，这样，测试执行人员就不得不学习通过手工的方式，或者通过采用少量脚本的方式重现自动化测试发现的问题，以证明他们确实发现了产品当中的 BUG 。

　　测试套的相关工作还没有结束，为了提高测试覆盖率或者测试新的产品特性，需要增加更多的测试。如果已有的测试不能正常工作，那么需要对之修改;如果已有的测试是冗余的，那么需要删除这部分测试。

　　随着时间的推移，开发人员也会研究你设计的测试，改进产品的设计并且通过模拟你的测试过程对产品做初步测试，研究如何使产品在第一次测试就通过，这样，你设计的测试很可能无法继续发现新的问题，这种现象被称为一种杀虫剂悖论。这时候，会有人对你的测试有效性提出质疑，那么，你必须考虑是否应该挖掘更严格的测试，以便能够发现开发人员优化之后的产品中的缺陷。

　　以前，我提到过一个基本上无法实现的设想，设想通过按下一个按钮就完成了所有的测试工作。自动化测试是不是全能的，手工测试是永远无法完全替代的。

　　有些测试受测试环境的影响很大，往往需要采用人工方法获取测试结果，分析测试结果。因此，很难在预先知道设计的测试用例有多大的重用性。自动化测试还需要考虑成本问题，因此，千万不要陷入到一切测试都采用自动化方法的错误观念中。

　　我曾经主张保证给与测试自动化持续不断的投入。但是，在开展自动化测试的时候，一个问题摆在面前，测试自动化应该及时的提供给测试执行人员，这个不成问题，但是如何保证需求变更后，能够及时提供更新后的自动化测试就是个大问题了。如果自动化测试与需求变更无法同步，那么自动化测试的效果就无法保证了，测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。识别项目计划中的软件发布日期，然后把这个日期作为里程碑，并计划达到这个里程碑。当达到这个里程碑后，自动化工程师应该做什么呢?如果自动化工程师关注当前产品版本的发布，他需要为测试执行人员提供帮助和咨询，但是，一旦测试执行人员知道如何使用自动化测试，自动化测试工程师可以考虑下一个版本的测试自动化工作，包括改进测试工具和相关的库。当开发人员开始设计产品下一个版本中的新特性的时候，如果考虑了自动化测试需求，那么自动化测试师的设计工作就很好开展了，采用这种方法，自动化测试工程师可以保持与开发周期同步，而不是与测试周期同步。如果不采用这种方式，在产品版本升级的过程中，自动化测试无法得到进一步的改进。

原文转自：http://www.ltesting.net