环环相扣---近期自动测试经验总结

1.问题的提出
产品开发时的自测是确保产品质量的一个重要的环节,而自动测试也是提升产品质量和提升研发效率的有效途径之一。
在设计自动测试时,我们要考虑的因素包括以下方面:
第一,测试用例的充分性。
第二,代码覆盖率尽量高。
第三,每次触发时要对之前的功能进行回归测试。
第四,新增加的测试用例不能影响老的测试用例。
第五,每个测试用例针对程序的一个小功能进行测试,且各个用例不重复。
要实现对所有软件模块进行自动测试,难度是相当大的。很多开发小组尝试着让一组测试用例触发所有的模块,即将所有模块纳入一次自动测试的构建中。该过程的示例如图1所示。

图1 所有模块纳入一次自动测试的示意图
这样做了之后,大家发现存在以下问题:
第一,在进行自动测试的时候,所有人都要丢下手中的工作来支持测试,只要有一个模块执行失败,整个测试就进行不下去。这严重影响了工作效率。
第二,为了囊括所有的功能,设计测试用例的时候需要求大求全,但某些测试用例明显不重要。这也在无形中降低了工作效率。
第三,由于各个模块之间的耦合比较紧密,当某次自动测试执行失败,需要从头开始排查失败原因。多模块给问题排查带来了困难。
如图2所示,如果模块E的自动测试用例执行失败,那么,需要查看模块A、模块B、模块D、模块G、模块F和模块H的运行情况,这是相当繁琐的。

图2 错综复杂的模块消息交互网

看来,这种“胡子眉毛一把抓”的方式并不适合所有软件开发项目的自动测试。那么,有不有更好的方法呢?

2.解决思路
为了设计出更加合理的自动测试方案,我们研究了本开发项目的软件基线和版本,发现它们有以下特点:
第一,相同功能或为某个局点定制的版本一般是放在同一个基线里面的。
第二,某一个基线的模块可能会与另一个基线中的某个模块有消息交互。
第三,与核心模块进行消息交互的模块数要远远多于与普通模块进行消息交互的模块数。
第四,对于某一个单一的模块来说,其工作方式只有两种:被另外一个模块触发或主动扫描拼装数据执行相关操作。
这样,我们设计了两种自动测试的方案,具体为:
方案一:按照基线来设计
软件基线是软件的某一个正式版本,随后的所有开发工作都是基于此版本开展的。
在此方案中,我们仅仅是针对基线中的模块来进行自动测试,每次设计的测试用例也是仅仅针对本基线中的模块功能。该方案的示例如图3所示。

图3 按照基线来设计自动测试的示意图
在图3中,基线X中有四个模块:模块A、模块B、模块C和模块D。其中,模块B与模块D有消息的交互。一组测试用例要触发模块A、模块B和模块C,模块B再去触发模块D。

方案二:按照基线和模块功能来设计
在此方案中,我们针对不同基线中的有消息交互的模块来进行自动测试,每次设计的测试用例可以触发不同基线中的多个模块。该方案的示例如图4所示。

图4 按照基线和模块功能来设计自动测试的示意图
在图4中,有基线X和基线Y两个基线,基线X中的模块A要和基线Y中的模块C进行消息的交互,基线X中的模块B要和基线Y中的模块D进行消息的交互。
对比方案一和方案二,我们最终选择了方案二,原因是这样的:
第一,方案一只涉及到本基线的模块的自动测试,但并非本基线的所有模块的测试用例的设计模式都是一样的。在方案二中,可以选择处理模式一致的模块来设计测试用例,这样便于统一规范,减少了在编程上的麻烦。
第二,方案二可以在触发本基线进行自动测试的同时,顺带对有消息交互的模块进行测试,相对方案一来说,其覆盖面更广。
第三,方案二的测试可以检验基线接口之间的消息规范是否合理和正确,其测试结果对于系统流程架构的优化也具有参考价值。

3.实践经验总结及相关建议
通过在开发小组推广自动测试,我们总结出的经验有以下几个:
第一,自动测试的顺利进行需要有良好的测试环境予以保障。在实际的执行失败的情况中,很多都是由于环境不稳定造成的。可以通过开发脚本来进行自动测试环境的重新搭建和初始化,进而提升测试环境的稳定性;另外,可以考虑采用独立的自动测试环境,避免被其它模块的自测所影响。
第二,要针对程序的不同分支设计不同的测试用例,以提高代码的覆盖率,对程序进行较为全面的测试。测试用例的设计过程考验的是开发人员的细致和耐心,在此过程中,开发人员的能力水平也得到了提升。
第三,“前事不忘,后事之师”,开发小组要将自动测试过程中的经验教训予以总结,并以文档的形式保存起来,供相关项目组的开发人员参考学习。

按照基线和模块功能来设计自动测试的方法可被用于以下项目中:
第一,基线(包括通用基线和定制基线)众多,各基线包含了很多的软件版本。
第二,基线内部和基线之间的软件模块的消息交互比较频繁和复杂。
第三,软件模块之间的接口协议较为复杂,可通过自动测试来对协议进行优化。

在执行自动测试的过程中,项目组需要做以下事情:
第一,告知项目组成员自动测试的总体流程和测试用例的设置规则,让大家对自动测试的整个过程了然于心。
第二,按照基线和模块来将自动测试任务划分到每一个开发人员头上,有消息交互的模块制定好测试用例的设计规则及确定好覆盖的程序流程。
第三,自动测试可以帮助发现了一些代码中存在的问题,促进开发人员对代码进行优化。当每次自动测试执行完后,发现有用例执行失败,则会分析用例失败的原因。部分是因为代码的实现与预期不一致而导致的,这种情况就要优化代码。部分是因为原来的代码发生了改变,导致用例失败,这种情况就要优化用例。
第四,对自动测试脚本和自动测试工具进行优化,以提升自动测试的稳定性。

在自动测试的过程中,大家要不断地总结开发和测试的经验,并不断优化自动测试的工具和方法,以使得产品的质量更上一层楼。这也是推广自动测试的最终目的。



本人微信公众号:zhouzxi,请扫描以下二维码:

时间: 2024-11-02 17:10:17

环环相扣---近期自动测试经验总结的相关文章

让你提前认识软件开发(49):自动测试

第3部分 软件研发工作总结 自动测试   [文章摘要]        "百年大计,质量为先".质量是企业的生命线,优秀的企业必然会推出高质量的产品,也势必会从产品研发的各个环节去保障产品的质量.产品开发时的自测是确保产品质量的一个重要的环节,而自动测试也是提升产品质量和提升研发效率的有效途径之一.         本文根据作者参与自动测试项目工作的实际经验,介绍了自动测试的步骤及相关注意事项等.本文为相关研发项目的自动测试提供了有益的参考.   1. 自动测试的背景         产

PHPUnit袖珍指南之自动测试

最好的程序员也会犯错误.好程序员和差程序员的区别在于:好程序员能通过测试尽可能的发现错误.你越快测试错误,你就越快发现它们,发现和修正的成本就越低.这解释了为什么只在软件发布前才测试的做法为什么问题那么多.大多数错误根本就没有发现过,修正发现的错误是那么的高,以至于你不得不根据优先级来决定只修正那些错误,因为你根本就承受不起全部修正的费用. 相比你正在使用的方法,采用PHPUnit进行测试并不是一个全然不同的东西.它们只是方法不同.两者之间的不同在于,检查程序行为是否符合正确是通过一批可以自动测

WF4.0实战(五):实现一个直观易扩展的自动测试框架

概述: 这篇文章用WF实现一个软件自动测试框架,这个框架你可以随意扩展.本这个框架根据WF流程去自动地点击你的页面:自动的在你的文 本上输入值:自动的做一些人为的操作.也就是说WF相当于一个测试用户,自动地帮你测试软件.只需要你定制测试流程. 写一个待测试的软件: 这里我写了一个很简单的待测试的软件:一个加法运算.界面如下图,就一个Form. 后台代码如下: 1 public partial class MainForm : Form 2 { 3 public MainForm() 4 { 5

基于JUnit的InstallAnywhere安装程序图形界面自动测试框架

JUnit 简介 JUnit 是一个开源的单元测试框架,用于编写和运行自动测试,由 Erich Gamma 和 Kent Beck 在 1997 年开发完成.它包括以下特性: 提供的 API 可以让你写出测试结果明确的可重用单元测试用例: 提供了三种方式来显示你的测试结果,而且还可以扩展: 提供了单元测试用例成批运行的功能: 超轻量级而且使用简单,没有商业性的欺骗和无用的向导: 整个框架设计良好,易扩展. InstallAnywhere 简介 InstallAnywhere(下文简称 IA)是一

关于ATML自动测试标记语言的问题(官网下的2010的演示版本)

问题描述 关于ATML自动测试标记语言的问题(官网下的2010的演示版本) 我本意是使用TestDescription和TestResult来作为本系统的测试描述和结果描述,但是在使用TestDescription时,对于其operation元素中的子元素td:LocalSensorSignalReference的引用约束搞不太清楚 如: td:Operation xsi:type="td:OperationRead" ID="dsf" name="dfs

MySQL自动测试框架介绍

1.概述 在我们給MySQL打了patch后,不仅需要测试新增的功能,同时更重要的问题是,需要对原有的功能作回归――若新增的patch导致原有其他功能产生bug,就得不偿失. MySQL自动测试框架是一个以MySQL框架和内部引擎为测试对象的工具.主要执行脚本在发布路径的mysql-test目录下.自动测试框架的主要测试步骤,是通过执行一个case,将该case的输出结果,与标准的输出结果作diff.这里的"标准输出结果"指代在可信任的MySQL版本上的执行结果. 如果某个case的执

ios app 自动测试框架

问题描述 ios app 自动测试框架 我现在通过命令行在越狱后的手机上可以安装网上下载的ipa文件 我现在需要模拟运行这些安装好的app,需要 1.启动运行app 2.模拟操作 3.退出应用 我该需要使用什么框架或者工具能够实现啊 我在网上找到的好多都是需要自已的app源码的 没有别的方法了嘛? 求各位大大帮帮忙 解决方案 很高深的样子 mark一下

obotium测试框架-在使用Robotium自动测试框架中遇到问题,求大神解答

问题描述 在使用Robotium自动测试框架中遇到问题,求大神解答 我测试一个Activity,想点击最下方id为video_iv的imageview,代码如下: @Before protected void setUp() throws Exception { super.setUp(); this.solo = new Solo( this.getInstrumentation(), this.getActivity() ); } @After protected void tearDown

从单元测试到基于每日构造的自动测试

1.单元测试 XXXX作为一个新项目,和其他所有项目一样,在开发工作进行之初就在考虑如何保证代码开发的质量.答案很容易找到:充分的单元测试.但是以前真正做得好得项目却不多. 经过分析,总结了一下做好单元测试工作的四个要素: ――思想上的重视 ――计划上保证 ――测试手段保证 ――测试效果的可验证 1.1 思想上重视 从以往的开发过程总结了一些教训: ――开发人员模块在交付联调前,测试不充分,导致联调周期较长 ――代码进入维护期后,修改代码往往引起不可预期的错误.导致开发人员比较害怕在相对稳定的代