关于蜕变测试文献REST ful 的Web API的翻译与思考

关于蜕变测试REST ful 的Web API文献的翻译与思考

今天读了一篇文献

Metamorphic Testing of RESTful Web APIs

Sergio Segura , Jos e A. Parejo , Javier Troya , and Antonio Ruiz-Cort es

先放上一个文中所列资源

https://gestionproyectos.us.es/projects/restfulmt/wiki

[^为了验证,我们提供了一个在线附录,包括学术Web API的源代码,变体和变形关系的描述]:

这篇文献有17页。。。看了一下午。。废话不说,先梳理一下大概框架

文献使用案例来自Spotify和YouTube

1.提出了一个概念

**Metamorphic Relation Output Patterns (MROPs):**即六种抽象的关系模式,可以捕获RESTful Web API中的蜕变关系。(通常蜕变关系都是由人工想想想,就是得有发现的能力,本文提出了一些模式或许可以帮助你发现更多的蜕变关系)

2.关于RESTful Web API

这个我没有深入了解过,不过有一篇博写的还可以,贴这:http://www.cnblogs.com/developersupport/p/aspnet-webapi.html

针对RESTful Web API的语义特点:CRUD操作以及非常一致地使用参数进行标准操作,例如过滤,排序和分页。

大多数RESTful Web API实现标准的HTTP方法如下

   GET. 获取一个或多个资源
   POST.创建一个资源,如果创建成功,则返回新创建的资源
   PUT.更新一个资源,如果更新成功,则返回更新后的资源
   DELETE. 删除资源(文献中没讨论)

3.MROPs(六种)

源输出(source output):S=f(x 0 _0 0)

后续输出(follow output):F i _i i=f(x i _i i)

MROP可以表示为:P=(S,F 1 _1 1,F 2 _2 2,F 3 _3 3,…,F n _n n)

因此,在实例化模式之前,测试输入仍未定义。更具体地说,通过定义源和后续输入以及它们如何相关来实例化MROP,其方式是期望产生满足由模式P定义的关系的输出。(划重点)

MR:源输入和后续输入关系

Equivalence(等效性)

任意i ∈ \in [1,n],S ! = != !=F i _i i

如果它们包含相同的项目,将两个或多个输出定义为等效,但不一定按相同的顺序排列.

eg.比如说在YouTube搜索视频的时候,关键字相同,但是排序条件不同。但搜索结果中都应该返回相同的视频。

Equality(等价性)

任意i ∈ \in [1,n],S=F i _i i

此模式表示源和后续输出必须包含相同项目且顺序相同的那些关系,该模式以表示那些源输出必须等于至少一个后续输出的变形关系。

Subset(子集)

S ⊃ \supset F 1 _1 1 ⊃ \supset F 2 _2 2 ⊃ \supset ⊃ \supset F n _n n.

后续输出必须是源输出的子集或者严格子集

eg.源测试用例在YouTube上搜索"marathon"的视频,在纽约50km以内。

后续测试用例在使用相同的查询和限制条件但范围限制在纽约20km以内。

Disjoint(非交集)

任意i,j ∈ \in [1,n],S ∩ \cap F i _i i= ∅ \emptyset ∧ \wedge (i!=j)->(F i _i i ∩ \cap F j _j j= ∅ \emptyset )

此模式表示源和后续输出之间的交集应为空的那些关系,这个模式应用于查询结果分为不相交的两部分。

eg.YouTube上的视频分为2D和3D两类,源测试用例为查询2D的部分,后续测试用例为相同搜索条件但是搜索结果限制在3D部分。

即执行这两个测试用例的结果不能同时出现2D和3D。

Complete(并集)

S=F 1 _1 1 ∪ \cup F 2 _2 2 ∪ \cup ∪ \cup F n _n n

此模式包括后续输出的并集应包含与源输出相同的项目的那些关系。这种模式通常应用于搜索结果可以分为非交集和并集两部分。

eg.比如YouTube的音频可以分为short,medium,long

源测试用例是一次输入关键字“testing”搜索。

三个后续测试用例即限制在音频的分组。

后续用例的输出结果中应该包含有与源测试用例相同的输出结果。

Difference(差集)

F i _i i\S=D

这种模式包括那些蜕变关系,其中源输出和后续输出应该在特定的项目集D中不同。这种模式通常存在于Web API的创建与更新操作中。

eg.向YouTube上传一个音频,输入是要上传的音频和一些元数据属性(例如视频描述等)

源测试用例描述“ICSE video”,并上传一段长视频

后续测试用例描述"TSE video",并上传一段两分钟的视频

直观地说,两个测试用例的输出应仅在视频描述和属性视频持续时间和视频大小上有所不同,其余属性保持不变,例如与视频质量,视频维度,默认语言和位置相关的属性

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值