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

发表于:2015-04-24来源:uml.org.cn作者:火龙果软件点击数: 标签:自动化测试
综上所述,应该集中精力关注可以延续使用的测试套,从以下几方面考虑,测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重

  综上所述,应该集中精力关注可以延续使用的测试套,从以下几方面考虑,测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

  可读性: 很多情况下,在测试人员开始测试项目之前,公司已经有了一套测试脚本,并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它,但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性,在具体应用中,那些脚本常常没有多大的实用价值,越来越让人迷惑。因此,测试人员很难确定他们实际在测试什么,反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本,并且理解测试脚本究竟测试了什么,这是很关键的。好的文档是解决问题的手段之一,对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法,我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩,把所有执行的产品相关的命令记录到日志里。这样,当分析日志确定执行了哪些产品命令,命令采用了何种参数配置时,可以提供一个非常好的测试记录,里面记录了自动化测试执行了什么,没有执行什么。如果测试脚本可读性不好,很容易变得过分依赖并没有完全理解的测试脚本,很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后,可以更容易的开展同行评审活动。

  可维护性: 在工作中,我曾经使用过一个测试套,它把所有的程序输出保存到文件中。然后,通过对比输出文件内容和一个已有的输出文件内容的差别,可以称已有的输出文件为 “ 标准文件 ” ( “gold file” )。在回归测试中,用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了,它会产生很多错误的警告。随着时间的推移,软件开发人员会根据需要修改产品的很多输出信息,这会导致很多自动化测试失败。很明显,为了保证自动化测试的顺利进行,应该在对 “ 标准文件 ” 仔细分析的基础上,根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是,每次只检查选定的产品的某些特定输出,而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试,这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改,并研究使测试修改量最小的方法,测试中采用库是解决问题的方法。当产品发生变化的时候,只需要修改相关的库,保证测试与产品的变动同步修改即可。

  完整性: 当自动化测试执行后,报告测试执行通过,可以断定这是真的吗?这就是我称之为测试套的完整性。在前面的故事中,当没有对自动化测试完整性给予应有的关注的时候,发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果?自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败,但是,对于自动化测试误报告警的情况,大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效,当测试发现异常的时候,能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法,分类包括 PASS , FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果,它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分,另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ,这个 BUG 引起测试队列中部分测试用例被跳过,没有执行。当测试队列运行完毕后,没有上报任何错误,我不得不通过走读代码的方式发现了这个 BUG 。如果,我没有关注到这个 BUG ,那么可能在认识到自动化测试已经出现问题之前,还在长时间运行部分测试用例。

  独立性: 采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候,通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化,测试执行是由一台不会说话的计算机完成的,你必须告诉计算机什么样的情况下测试执行是失败的,并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境,因此,保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档,以便一个接着一个有序地完成测试执行,每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误,这个错误源于 “ 多米诺骨牌 ” 测试套,当一个测试执行失败,会导致后续一系列测试失败。更糟糕的是,所有的测试关联紧密,无法独立的运行。并且,这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后,人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式,不过,重要的是在不牺牲测试的可靠性的前提下保证测试的独立性,如果测试可以在无需人看守情况下运行,那么测试的执行效率就不是大问题了。

原文转自:http://www.uml.org.cn/Test/201312093.asp