ET 在low layer testing中的应用

一.实践的背景

以往的ET,更多是在ST的执行过程中开展的，往往基于基于UI或用户可操作的命令行接口。那么是不是只限于此呢？对于low layer testing 是否能做ET？
将视角的放大镜缩小到函数接口，如果将Python提供的函数接口被测软件，那么对于使用它进行编码的开发人员不就可以当作是用户了吗？

二.实践的过程

本次选取Python提供的sorted()排序函数接口作为被测对象，将它的iterable 入参数作为主要探索点：

sorted(iterable[, cmp[, key[, reverse]]])

Return a new sorted list from the items in iterable.

函数接口详细说明参见：sorted

探索性测试开始之前应该制订探索章程，明确探索目的和范围：

—— sorted接口探索章程 探索范围 sorted接口iterable入参 使用 临界和组合类型数据 目的 探索排序是否会出现异常

2.1 探索前从充分理解被测对象的输入、输出

2.2 探索变量的”0”,”1”：

2.2.1 变量的 “0” :

探索，分别对空列表，空元组，空集合,空字符串进行排序：

---

print(sorted([]))print(sorted(()))print(sorted({}))print(sorted(''))

结果如下：

[][][][]

对列表、空元组、空集合、空字符串排序结果均为空列表，符合预期

2.2.1 变量的 “1” ：

探索，分别对只包含1个元素的列表、元组、集合、字符串进行排序，结果如下：

print(sorted([1]))  # 结果:[1]print(sorted('a'))# 结果:['a']print(sorted({'e'}))# 结果:['e']print(sorted(1))    # 结果：Traceback (most recent call last):  File "ET_For_PyInterface.py", line 10, in <module>    print(sorted((1)))TypeError: 'int' object is not iterable

排序只包含一个元素的元组失败了。
- 失败的分析和尝试：
1. 元组肯定是可以被迭代(iterable)的,最典型的就是用for循环的方式取每一个元素

1. 排序的元组的元素>1时是可以被排序的：

print(sorted((2,1,3)))# 结果:[1, 2, 3]

尝试到这里，我基本上认为Python的 Sorted()接口是存在坑的，或者是有缺陷的

1. 同样是只包含一个元素的元组，如果包含”,”是能够被排序的：

print(sorted((1,)))# 结果：[1]

1. 通过打印发现问题所在：

print((1))print((1,))print([1])# 结果：1(1,)[1]

只剩一个元素时如果没有,号，元组自动转换了类型,而列表等却不会进行转换

• 探索总结：

==我们通过ET发现了一个Python的Bug至少可以认为是一个Trap。由于元组在只剩1个元素时会自动将元组可迭代类型转换当前元素类型（可能是不可迭代的类型）导致了排序的报错，如果将这个函数接口运用在应用程序中没有做相应的检查或保护，程序就会出错。==

2.3 探索变量的类型组合:

实践中发现在Python3.x中，一个可迭代类型比如列表［］的元素由多种不同类型组成，那么排序都将出错而 Python 2.x系列却是可以的

例如：

Python 3.x:

print(sorted(['a', 1]))# 结果:Traceback (most recent call last):  File "/Users/hellfire/Documents/PyProject/InterfaceET/ETsort.py", line 6, in <module>    print(sorted(['a', 1]))TypeError: unorderable types: int() < str()

Python 2.x:

print sorted(['a',1])# 结果：[1, 'a']

同一个函数接口在不同的版本对外提供的功能存在差异，我认为这是一个Bug，至少算是Trap!由于Python 3.x的这个问题，下面的探索将在Python2.x中进行：

2.3.1 数字与字符串类型的组合

print sorted(['a',1])# 结果：[1, 'a']

通过ASCII进行排序，把1当作字符的ASCII 49,‘a’的ASCII 97，排序结果符合预期。

2.3.2字符串类型与类类型组合

class A: passprint sorted(['a',A()])＃ 结果：[<__main__.A instance at 0x10dd7ccb0>, 'a']

表示对象在内存中的存储位置的字符串与‘a’进行排序，‘<’的ASCII 60，’a’的ASCII 97 排序结果符合预期

2.3.2字符串类型与结合类型组合

对由字符串类型和集合类型构成的列表进行排序，探索情况如下：
（Python 2.7.2环境）

print sorted(['b',{'a'},'a'])＃ 结果：Traceback (most recent call last):  File "<pyshell#0>", line 1, in <module>    print sorted(['b',{'a'},'a'])TypeError: can only compare to a set

这个结果比较意外，在前面的探索中已经确认过集合类型可以被迭代的也可以进行排序的，而这里的错误提示是集合类型只能compuare？对于这个问题，我自己解释不了，只是怀疑是不是当前采用的Python版本有问题，于是决定在其他目前常用的Python版本中探索一下，看情况如何：

Python 2.7.10：

print sorted(['b', {'a'}, 'c']) # 结果：[set(['a']), 'b', 'c']

＊能够正常进行排序＊

Python 2.7.11：

print sorted(['b', {'a'}, 'c']) # 结果：[set(['a']), 'b', 'c']

能够正常进行排序

Python 2.6.2:

print sorted(['b',{'a'},'c'])# 结果：SyntaxError: invalid syntaxSyntaxError: invalid syntax

解释器认为是语法错误。调查后发现{}语法是在Python 2.7后才支持的2.7以前只能使用set()

Python 2.5.1:

print sorted(['b',{'a'},'c'])# 结果：SyntaxError: invalid syntaxSyntaxError: invalid syntax

解释器认为是语法错误。调查后发现{}语法是在Python 2.7后才支持的2.7以前只能使用set()

• 探索总结：
  ==对于同一个软件的不同发布版本，同一个功能／特性应该具有内在一致性。而我们看到对于Python提供sorted()接口的同一输入，软件对外呈现存在明显差异，对于2.5.1和2.6.2软件认为是语法错误、对于2.7.2排序失败，2.7.10，2.7.11正确，而到了3.x系列版本这个接口又改得压根就无能对组合类型进行排序了。若采用这个接口进行编程，那么程序在进行不同版本移植的时候将存在隐患。若把开发人员当作Python的用户，这样的用户体验是非常糟糕的，因该认为这是一个Bug至少是Trap!==

三.探索到一段落的思考

做low level testing的ET有价值吗？

我是这么看的:

1> 从项目的阶段来说：
在不同阶段的面临的压力是不一样的，在项目初期项目应该聚焦功能交付，做这样的ET确实代价比较高。但是在项目后期产品功能趋于稳定难道我们不该对软件的质量提出更高的要求，发现更多的隐藏问题吗？

2> 从团队性质来说：
并不是所有的团队都是端到端的团队，在大项目中会存在组件团队，他们的交付物就是组件就是API，对于他们来说，他们的客户和端到端的团队是不在一个层次的，他们对函数接口的ET，可能就相当于是ST。再打个比方，Python提供给用户（开发人员）的产品就是他们的API，难道非得要求他们在真实的软件产品的环境下ST的方式测试他们的API吗？那他们要覆盖多少场景才算OK?对于这样的组件团队来说，我认为是有价值的。

四.其他的说明

测Python 提供的函数接口？直接看文档不就够了？

1> 本次实践只是为了鉴证low level testing是可以做ET的，并且用真实工作中的代码来展示也不合适。

2>本次实践的是Python提供的一个功能非常单一和内聚的功能接口，确实官网上也提供了文档(但即使是这样的也并不一定在文档上展现了所有的细节或坑),但是在真实的项目中的代码，有些接口为相当复杂，而且在需求迭代的一定程度，模块与模块间可能存在一些微妙的关联可能研发人员自己也没有意识到，更别提展现到文档上。我们做ET可以摸清当前软件功能的坑是哪些？软件的规格和局限性是哪些。