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.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']
print(sorted(1)) 
# 結果：
traceback (most recent call last):
file "et_for_pyinte***ce.py", line 10, in print(sorted((1)))
typeerror: 'int' object is not iterable

排序只包含乙個元素的元組失敗了。

元組肯定是可以被迭代(iterable)的,最典型的就是用for迴圈的方式取每乙個元素

排序的元組的元素》1時是可以被排序的：

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

嘗試到這裡，我基本上認為python的 sorted()介面是存在坑的，或者是有缺陷的

同樣是只包含乙個元素的元組，如果包含","是能夠被排序的：

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

通過列印發現問題所在：

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

只剩乙個元素時如果沒有,號，元組自動轉換了型別,而列表等卻不會進行轉換

我們通過et發現了乙個python的bug至少可以認為是乙個trap。由於元組在只剩1個元素時會自動將元組可迭代型別轉換當前元素型別（可能是不可迭代的型別）導致了排序的報錯，如果將這個函式介面運用在應用程式中沒有做相應的檢查或保護，程式就會出錯。

實踐中發現在python3.x中，乙個可迭代型別比如列表［］的元素由多種不同型別組成，那麼排序都將出錯而 python 2.x系列卻是可以的

例如：

python 3.x:

print(sorted(['a', 1]))
# 結果:
traceback (most recent call last):
file "/users/hellfire/documents/pyproject/inte***ceet/etsort.py", line 6, in 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: pass
print sorted(['a',a()])
＃ 結果：
[<__main__.a instance at 0x10dd7ccb0>, 'a']

表示物件在記憶體中的儲存位置的字串與『a』進行排序，『<』的ascii 60，'a』的ascii 97 排序結果符合預期

對由字串型別和集合型別構成的列表進行排序，探索情況如下：

（python 2.7.2環境）

print sorted(['b',,'a'])
＃ 結果：
traceback (most recent call last):
file "", line 1, in print sorted(['b',,'a'])
typeerror: can only compare to a set

這個結果比較意外，在前面的探索中已經確認過集合型別可以被迭代的也可以進行排序的，而這裡的錯誤提示是集合型別只能compuare？對於這個問題，我自己解釋不了，只是懷疑是不是當前採用的python版本有問題，於是決定在其他目前常用的python版本中探索一下，看情況如何：

python 2.7.10：

print sorted(['b', , 'c']) 
# 結果：
[set(['a']), 'b', 'c']

＊能夠正常進行排序＊

python 2.7.11：

print sorted(['b', , 'c']) 
# 結果：
[set(['a']), 'b', 'c']

能夠正常進行排序

python 2.6.2:

print sorted(['b',,'c'])
# 結果：
syntaxerror: invalid syntaxsyntaxerror: invalid syntax

直譯器認為是語法錯誤。調查後發現{}語法是在python 2.7後才支援的2.7以前只能使用set()

python 2.5.1:

print sorted(['b',,'c'])
# 結果：
syntaxerror: invalid syntaxsyntaxerror: invalid syntax

直譯器認為是語法錯誤。調查後發現{}語法是在python 2.7後才支援的2.7以前只能使用set()

做low level testing的et有價值嗎？

我是這麼看的:

1> 從專案的階段來說：

在不同階段的面臨的壓力是不一樣的，在專案初期專案應該聚焦功能交付，做這樣的et確實代價比較高。但是在專案後期產品功能趨於穩定難道我們不該對軟體的質量提出更高的要求，發現更多的隱藏問題嗎？

2> 從團隊性質來說：

並不是所有的團隊都是端到端的團隊，在大專案中會存在元件團隊，他們的交付物就是元件就是api，對於他們來說，他們的客戶和端到端的團隊是不在乙個層次的，他們對函式介面的et，可能就相當於是st。再打個比方，python提供給使用者（開發人員）的產品就是他們的api，難道非得要求他們在真實的軟體產品的環境下st的方式測試他們的api嗎？那他們要覆蓋多少場景才算ok?對於這樣的元件團隊來說，我認為是有價值的。

測python 提供的函式介面？直接看文件不就夠了？

1> 本次實踐只是為了鑑證low level testing是可以做et的，並且用真實工作中的**來展示也不合適。

2>本次實踐的是python提供的乙個功能非常單一和內聚的功能介面，確實官網上也提供了文件(但即使是這樣的也並不一定在文件上展現了所有的細節或坑),但是在真實的專案中的**，有些介面為相當複雜，而且在需求迭代的一定程度，模組與模組間可能存在一些微妙的關聯可能研發人員自己也沒有意識到，更別提展現到文件上。我們做et可以摸清當前軟體功能的坑是哪些？軟體的規格和侷限性是哪些。

ET 在low layer testing中的應用

ET流程規範

LT模式 ET模式

探索式測試 ET

ET 在low layer testing中的應用

ET流程規範

LT模式 ET模式

探索式測試 ET

相關推薦