蜕变测试

蜕变测试-曾参加过蜕变测试研讨会2018-7-10

关于蜕变测试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$)

后续输出（follow output）:F$_i$=f(x$_i$)

MROP可以表示为：P=(S,F$_1$,F$_2$,F$_3$,…,F$_n$)

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

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

Equivalence（等效性）

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

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

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

Equality（等价性）

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

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

Subset（子集）

S$\supset$F$_1$$\supset$F$_2$$\supset$….$\supset$F$_n$.

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

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

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

Disjoint（非交集）

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

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

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

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

Complete（并集）

S=F$_1$$\cup$F$_2$$\cup$…$\cup$F$_n$

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

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

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

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

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

Difference（差集）

F$_i$\S=D

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

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

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

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

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

Metamorphic Testing:A Review of Challenges and Opportunities

来源：ACM

软件测试所面临的两个基础性问题:oracle问题和可靠的测试集问题。

oracle[测试结果参照物]:在测试时确定与实际结果进行比较的预期结果的源。它可能包括现有系统（作基准）、用户手册、或个人的专业知识等，但不是代码。

解决可靠的测试集的策略：

random testing;
coverage testing;
search-based testing;
symbolic execution.

解决oracle问题目前有的策略：

assertion checking
N-version programming

当oracle问题也发生的时候，有关解决可靠测试集问题的策略限制了适用性和有效性。

MT(Metamorphic Testing)可以用来产生测试用例和测试结果的验证。因此可以同时解决上述问题。

有几个术语了解一下：

MRs(Metamorphic Relations):目标函数或者算法与多个输入和他们所期望的输出之间的关系。
source inputs:我翻译为源输入
source test cases:源测试用例
follow-up test cases:基于MR产生的新的测试输入作为后续测试用例集

MT根据相应的MR验证源和后续测试用例及其输出。

一些定义：

MR定义：

f为目标函数，(x$_1$,…,x$_n$)输入序列。对应输出(f(x$_1$),…f(x$_n$))。

源输入集与后续测试集定义:

MG定义：

MT的优势：

概念简单(这个优势我有点不太懂…)
直接实现
对于给定的MRs的可用性易于自动化
低代价

通常对于MT的一些误解：

不是所有的必须属性都是MRs
并非所有MR都分为仅输入和仅输出子关系
并非所有的MR都是相等关系
无论是否有oracle测试，MT都可以应用

在测试领域的MT：

MT是一种缓和oracle问题的方法
MT作为一个新的策略用于生成测试用例

MT其他的扩展应用：

证明MRs
验证(Verification)、确认(Validation)以及质量评价的框架。验证和确认这两个词值得细细揣摩哈，验证是指通过提供客观证据对规定要求已得到满足的认证。确认是指满足预期用途。
整合其他技术