自动化测试框架分类与思考

发表于:2017-12-14 08:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:刘冉    来源:思特沃克

分享:
  富文档型
  对于一些场景十分复杂,需要通过富文档的方式来描述软件测试场景,甚至需要一些业务流程图或者系统用户界面等,比如Concordion,Fitnesse,Guage等。
  例子 Condordion:
  测试用例代码,其中包含部分测试代码,比如断言等,其中concordion.css使用的是官方样例代码
<html xmlns:concordion="http://www.concordion.org/2007/concordion">
<link href="concordion.css" rel="stylesheet" type="text/css" />
<body>
<h1>Test Demo</h1>
<p> Test the add function of  the calculator can add two numbers </p>
<p> The Caculator:</p>
<div> <img src="./Calculator.png"/> </div>
<div concordion:example="add">
<h3>Examples</h3>
<table>
<tr>
<th>Number 1</th>
<th>Number 2</th>
<th>Sum</th>
</tr>
<tr concordion:execute="#sum = addWithTwoNumbers(#number1,number2)">
<td concordion:set="#number1">1</td>
<td concordion:set="#number2">2</td>
<td concordion:assert-equals="#sum">3</td>
</tr>
<tr concordion:execute="#sum = addWithTwoNumbers(#number1,number2)">
<td concordion:set="#number1">-1</td>
<td concordion:set="#number2">2</td>
<td concordion:assert-equals="#sum">1</td>
</tr>
</table>
</div>
</body>
</html>
  测试用例呈现文档:
  测试用例中的函数实现代码:
@RunWith(ConcordionRunner.class)
public class CaculatorFixture {
public String addWithTwoNumbers(String number1, String number2) {
//测试实现代码
}
}
  (注:虽然说最新版的Concordion已经支持MarkDown了,从而降低了一些开发成本,但是其对MarkDown的特性支持有待增加。所以如果需要更为丰富的文档形式,仍然需要使用HTML来开发测试用例。)
  富文档型的框架比多领域语言型拥有更为丰富的文档,更容易阅读和理解,从而能做成说明书式的活文档,使得所有角色的人都能审阅。并且其测试用例和测试实现也是分离的。但是当前业界存在的富文档型测试框架的易用性和协作性都还不是很好,导致其开发,管理和维护成本相比前三种是最高的。并且当没有其它各个角色来协同开发,管理和维护时,其投入产出比也是最低的,所以它在行业中的使用率也是很低的。这类测试框架在易用性和协作性方面还有很大的发展空间,并且也是自动化测试框架和活文档系统的一个重要的发展方向。
  思考与选择
  自动化测试的代码实现层一般是与编程语言强相关的,而主流的编程语言比较少,所以选择比较容易:一般建议选择团队大部分成员都熟悉的编程语言(这样可以促使整个团队来对自动化测试进行开发和维护)或者是有特定测试库的编程语言(比如需要使用Scapy时就只能选择基于Python的自动化测试框架)。当确认自动化测试开发语言后,真正的问题是如何在如此众多的自动化测试框架里面选择合适自己的自动化测试框架。选择方法可以根据以上四种类型来进行选择,从而缩小选择范围。
  · 如果团队只是需要快速实现自动化测试,没有知识的传递问题,也不需要与业务分析和产品经历等非技术人员进行协作开发时,可以选择函数型自动化测试框架。
  · 如果为了解决知识传递问题,让测试用例更可读和易懂,并且没有非技术人员参与协作开发,这时可以选择单领域语言型。
  · 如果为了进一步解决和非技术人员协作开发的问题,并且想有一套简版的活文档,可以选择多领域语言型自动化测试框架。
  · 如果为了让测试用例拥有更为丰富的表现力,比如包含一个流程图来说明被测场景的流程,或者使用不同的格式或者表格来描述用例的细节,以及拥有一套丰富的活文档,这时就可以使用富文档型。不过由于当前的富文档型测试框架在编写用例时需要一定的技能,所以非技术人员很难直接参与协作编写。并且其编写以及维护成本更高,可能使得自动化测试开发人员使用的意愿也不是很高。参考自动化测试工具选项金字塔:
  当确认了测试框架类型之后,比如只有一个可选项(Java->函数型->JUnit),那么就直接使用了,但是如果存在多选项(JavaScript-> 单领域语言型->Jasmine vs Mocha),就还需要对其进行深入比较,从而最终选择自己适合的自动化测试框架。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
22/2<12
100家互联网大公司java笔试题汇总,填问卷领取~

精彩评论

  • launcelot
    2017-12-14 17:14:24

    http://bbs.51testing.com/thread-1150457-1-1.html

  • launcelot
    2017-12-14 17:14:01

    http://upload-images.jianshu.io/upload_images/5146600-0c808d1e89d72486.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/669

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2023
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号