第6章 探索式軟件測試設計方法

       「探索式軟件測試」是軟件測試專家Cem Kaner博士於1983年提出的，並受到語境驅動軟件測試學派（Context Driven Testing School）的支持。因爲符合快速提交的理論，且隨着近年來敏捷開發的出現，探索式軟件測試被從新提出，而且受到普遍重視。

       探索式測試Exploratory Testing是一種自由的軟件測試風格，它沒有不少實際的測試方法、技術和工具，可是倒是全部測試人員都應該掌握的一種測試思惟方式。探索性強調測試人員的主觀能動性，拋棄繁雜的測試計劃和測試用例設計過程，強調在碰到問題時及時改變測試策略。

6.1 探索式軟件測試中用到的一些方法

6.1.1 表單輸入的測試探索

1.超長或不符合格式的字符輸入的測試探索

      因爲表單輸入的數據最終通常都存入到數據庫中，因此對於輸入的數據，必定要對其長度或類型進行限制。輸入一個超長或不符合格式的字符串，通常有如下4種處理方式。

（1）在輸入界面中被鎖定

      如，表單要求輸入的字符串最長長度爲40，當輸入第41個字符時，頁面是不容許輸入的。

      再如，表單只容許輸入阿拉伯數字，若是輸入了一個字符「A」，頁面也是不容許的。

（2）在鼠標失去焦點後，利用Ajax和JavaScript技術當即給出錯誤提示

（3）輸入後，在提交表單時，輸入界面會提示表單中有超長或不符合格式的字符，而且表單不容許被提交

（4）輸入後，在提交表單時，會在另外的頁面中提示表單中有超長字符或不符合格式的字符被輸入，而且表單不容許被提交

      若是在表單輸入了超過長度或不符合格式的字符串，提交後界面沒有任何提示信息，甚至出現系統奔潰，或者出現數據庫發生異常的英文日誌顯示在頁面上，那麼這顯然是一個Bug。

      若是符合以上4中處理，從安全性角度考慮，需經過開發工程師查看對應的代碼，尤爲是數據存儲到數據庫以前，確認程序是否對輸入字符的長度或類型進行再一次校驗。舉個例子，輸入頁面的文件名爲table.html，後臺存入數據庫操做的文件名爲insert.jsp。一個黑客爲了破壞這套系統，它用其餘軟件製造了一個表單頁面代替table.html。在他的頁面中輸入超過長度或者不符合格式的數據，而後經過insert.jsp提交到數據庫中，因爲insert.jsp沒有對輸入字符進行校驗，從而形成系統癱瘓。

案例6-1 文本框的輸入

      某文本框只容許輸入長度爲5-20的字符串，請設計超長或不符合格式的文本框的測試用例。

輸入數據	指望結果
4個'a'	給出出錯提示
5個'a'	數據正確錄入
20個'a'	數據正確錄入
21個'a'	給出出錯提示
4個'我'	給出出錯提示
5個'我'	數據正確錄入
19個'我'	數據正確錄入
20個'我'	數據正確錄入
1個空格+4個'a'	給出出錯提示
1個空格+5個'a'	數據正確錄入
1個空格+4個'我'	給出出錯提示
1個空格+5個'我'	數據正確錄入
1個空格+20個'a'	數據正確錄入
1個空格+21個'a'	給出出錯提示
1個空格+20個'我'	數據正確錄入
1個空格+21個'我'	給出出錯提示
1個空格在4個'a'中間	數據正確錄入
1個空格在3個'我'中間	給出出錯提示
1個空格在19個'a'中間	數據正確錄入
1個空格在20個'我'中間	給出出錯提示

2.保留字符輸入的軟件測試探索

     表單輸入的數據，除了存儲倒數庫中，還會顯示在界面上。例如在修改我的信息的案例中，系統會把之前輸入到數據庫中的數據顯示到界面上，這樣便於用戶對信息中不合適的地方進行修改。要對這種類型的軟件測試進行探索，首先要搞清楚這套產品對錶單輸入數據使用的是何種方式輸出？這種輸出方式中存在哪些保留字符？輸出的方法是用HTML語言顯示的，HTML保留字符有：<、>、「、‘、&、空格、回車等。HTML顯示這些字符時能夠用其餘字符進行替換。一個正常的操做是從數據庫中輸出保留字符之後，程序對這些保留字符經過正則替換轉碼爲HTML重對應的能夠顯示的字符串，如「<」轉換爲&lt;，空格轉爲&nbsp……若是在表單中輸入了這些字符，或者輸入一段含有這些字符的HTML代碼或者JavaScript代碼，如<a href="http://www.sina.com.cn">進行新浪</a>，而後在顯示頁面中查看輸出的格式是否正確，若是不正確，或者出現顯示頁面錯亂，甚至執行了JavaScript語句，這屬於XSS注入，確定一個Bug。保留字符的測試用例舉例以下表。

輸入數據	指望結果
<script>alert(document.cookie)</script>	顯示'<script>alert(document.cookie)</script>'，不執行javascript語句alert(document.cookie)

6.1.2 模糊查詢輸入框輸入數據的測試探索

      目前除了一些專業的搜索引擎（如Google、百度）以及流行的大數據存儲方式採用非關係型數據庫或者NoSQL技術進行存儲，對於大多數軟件系統，一般仍是採用傳統的關係型數據庫進行存儲。若一個用戶想查詢標題中含有「雲計算」的標題，再經過單擊相應標題查看文章內容，一般對應的SQL查詢語句爲：select url,title,content from paper where title like "%$title%';（$title爲模糊查詢文本框提交過來的字符串，這裏爲「雲計算」）。下面深刻討論一下SQL語句中%這個關鍵而特殊的模糊查詢字符，假設用戶在模糊查詢輸入框中輸入%，而程序沒有對%進行特殊處理，上述的SQL語句就變味select url,title,content from paper where title like '%%%'，這樣的查詢輸出結果不是把文章標題中含有%字符的標題輸出，而是把這個數據庫表中全部的記錄都給輸出來了，這屬於SQL注入，也是一個Bug。

      案例：模糊搜索。某文本框爲根據關鍵字進行模糊搜索，能夠設計測試用例以下表所示。

數據	指望結果
「軟件測試」	顯示含有「軟件測試」標題的全部文章
「  軟件測試」	顯示含有「軟件測試」標題的全部文章
「軟件測試  」	顯示含有「軟件測試」標題的全部文章
「軟件  測試」	顯示含有「軟件  測試」標題的全部文章
"%"	顯示含有「%」標題的全部文章，不顯示全部文章
10萬個a	系統不奔潰，給出友好的提示信息
空字符串	按照系統要求，什麼都不輸出，或輸出全部記錄

6.1.3 對文件的探索

      系統中須要上傳文件，有以下兩種情形。

（1）選擇文件直接上傳。

（2）選擇文件，按【上傳】鍵，而後完成上傳任務。

      案例：考慮（2）情形的上傳文件，測試用例以下表。

描述	指望結果
選擇的文件被刪除： 1.選擇文件a.txt 2.刪除文件a.txt 3.按【上傳】鍵	提示信息：a.txt已經被刪除
文件的內容被損壞： 1.創建文件a.txt 2.將文件名改成a.jpg 3.選擇文件a.jpg（這裏要求只能上傳圖片格式文件） 4.按【上傳】鍵	提示信息：a.jpg格式不正確
使用空文件 1.創建一個文件名爲a.txt的空文件 2.選擇文件a.txt 3.按【上傳】鍵	提示信息：文件不能爲空的信息
系統要求文件不能超過2MB 1.創建一個符合格式的超過2MB大小的文件 2.選擇這個文件 3.按【上傳】鍵	提示信息：文件大小不能超過2MB
用其餘軟件打開須要上傳的文件 1.用photoshop打開a.jpg 2.選擇a.jpg 3.按【上傳】鍵	根據用戶需求 1.a.jpg倍上傳 2.提示信息：a.jpg已經被其餘軟件打開，請關閉後再上傳

6.1.4  登陸界面的測試探索

     對於登陸頁面，除了可使用以前介紹的方法外，還須要對SQL注入進行測試。若是用戶知道或者猜到系統數據庫的代表，那就更可怕了，如在密碼欄中輸入：「*;DROP TABLE USER;」，若是程序中沒有作合適的處理，這樣的數據庫中的數據表就會被刪除。改進後的登陸頁面測試用例見下表。

編號	用戶名	密碼	驗證碼	指望結果
1	Tom	khnygh	243546	提示：用戶名或密碼錯誤
2	Kenny	oooo	243546	提示：用戶名或密碼錯誤
3	Kenny	khnygh	12345	提示：驗證碼有錯誤
4	Kenny	khnygh	243546	進入系統
5	1111	2222' or 1=1;--	123456	提示：用戶名或密碼錯誤

6.1.5  根據機器的聲音探索

      經過機器的聲音有些時候也能夠發現一些軟件缺陷。

      案例：測試中的望聞問切。

      甲同窗晚上加班進行一個模塊的性能測試，測試數據的結果總不能令他滿意，他不斷地進行復測，但總找不出緣由。因爲當時已經接近21:00，公司裏只剩下他一我的，很是安靜。他忽然發現每通過一段時間，硬盤老是發出一種單調而且奇怪的聲音，他馬上意識到時硬盤的問題，通過排查，是硬盤操做太頻繁形成。次日他讓開發工程師查看後，發現這是因爲開發人員修改一個缺陷所引發的，這個缺陷是數據常常從緩存中讀取，準確性不高，而改爲從硬盤中讀取，當準確性上去後，性能卻就成爲另一個問題。

      對於某些測試，須要經過「切」的方法進行測試，如摸機箱或者摸嵌入式設備的外部查看是否過熱等方式。

6.1.6  經過查看Log日誌探索

      通訊系統、嵌入式系統等是沒有用戶界面的，對這類系統進行探索式測試時，查看系統日誌是一種最好的選擇。在Linux/UNIX系統中，能夠對日誌文件進行如下操做（假設log日誌爲a.log）：

>tail a.log | grep error
>tail a.log | grep fail

       若是有查詢結果，就能夠順藤摸瓜，查找問題所在。固然，並非通訊系統、嵌入式系統中才能夠用這種方法，其餘系統也可使用，甚至會挖掘出一些隱藏的、沒有爆發的缺陷。

       案例：java.net.SocketException。

       在某網站接口測試中發現一個自動化測試用例沒有經過，通過使用>tail a.log | grep error，發現以下結果：

java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:531)
at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:121)
at org.apache.jk.core.MsgContext.action(MsgContext.java:301)

       經過這個結果，開發人員進一步查詢，發現到問題的根本緣由是MySQL的連接超過8小時，MySQL自動斷開鏈接形成的。

6.1.7  在開頭/結尾處進行探索

       在文件開頭或者結尾處進行操做每每也會發現缺陷。

       案例：文章結尾的輸入。測試一個文本編輯軟件，在編輯的文本中的其餘地方插入一些文字都沒有問題，可是在文本的最後插入一些文字，再保存後從新打開，被插入的文字不見了。

       案例：移動記錄到第一條。經過上下箭頭試圖把記錄上下移動一個單位，測試發現當移動到非第一條時沒有問題，可是移動到第一條時，系統管理科卡主沒有任何反應。通過排查，發現是因爲開發人員在計算時把第一個標記爲的「0」記爲「1」形成的問題。

6.1.8  屢次執行一樣操做進行探索

      這也是一種常常發現缺陷的情形。好比，軟件能夠打開任意多個窗口，你試圖打開這樣的10個、20個、50個，甚至100個窗口，而後進行操做，看系統會有什麼反應。這樣的問題每每會致使響應速度變慢，甚至系統宕機。

      案例：ERP軟件多窗口操做。某ERP軟件能夠同時打開多個窗口來編輯庫存信息。測試工程師小張打開1-30個窗口沒有問題，可是打開第31個窗口後，系統發生了死機的情形。後來經需求、設計、項目經理、開發、測試等一塊兒討論，綜合各方面因素決定，最多隻容許打開20個窗口，當用戶試圖打開第21個窗口時，系統將給出「本系統最多隻容許打開20個窗口」的提示信息。

6.1.9  經過複製/粘貼進行探索

       在文本框中編輯時，每每會用鍵盤手工進行輸入，若是經過複製/粘貼進行操做，也許會發現一些缺陷。一種類型的缺陷是在複製時複製了字符串先後的空格，而程序沒有對其進行判斷，顯示時把先後空格顯示出來。

       另一種情形如圖3-1所示。

      這種類型的文本框不容許經過鼠標進行復制和粘貼，必須使用Ctrl+C、Ctrl+V。對於這種情形，須要認真測試。另外，這種狀況下，從安全角度考慮：能夠輸入簡單的HTML標記符，如<a href="...">、<b>、</b>、<br>、<font size="1">、<font>……，可是不容許輸入存在安全風險性的標記，如<script>、</script>、document.cookie、alert……等。

      案例：富文本編輯器安全性測試。

操做	期待輸出
進入HTML編輯框，輸入「<a href="https://www.baidu.com」>百度</a>	顯示「百度」，點擊百度超連接後進入百度網站
輸入「<font size="4」>百度</font>	「百度」顯示爲4號字體
輸入<script>alert(document.cookie)</script>	顯示提示信息：<script>，</script>，document，cookie，alert等敏感字符不容許輸入
輸入<a href="#?id=1&drop table customer">	顯示提示信息：drop table等明恩字符不容許輸入

6.1.10  經過測試結果進行探索

      經過某個測試的測試結果，還能夠設計出更多、更深刻的測試用例。好比，在用戶註冊時，發現【取消】按鍵的功能沒有起做用，這樣就必須對系統中全部表單提交功能中，對含有的【取消】按鍵都進行測試。再如，在對電子商務測試過程當中發現，用支付寶存款存在問題，那麼就必須測試微信、銀行借記卡、銀行信用卡付款是否一樣存在問題。另外，根據軟件缺陷的80/20法則，若是在某個模塊中測試出不少問題，那麼就須要對這個模塊進行更詳盡的測試，以便發現更多的缺陷。

      案例：關於刪除的缺陷。測試某個網站。

      測試步驟：

（1）登陸系統；

（2）對某一篇文章非本人提交的評論點擊刪除；

（3）提示：你沒有權限進行刪除操做；

（4）該評論沒有被刪除；

（5）跳轉到其餘頁面；

（6）返回到剛纔試圖刪除的文章頁面。

      結果：該評論已經不存在。

     根據這個測試結果，考慮到本網站還有BBS模塊，因而測試工程師對BBS帖子的刪除進行了相似的操做，發現了一樣的問題。

剩餘部分