章五帶上眼罩測試軟體(2)

jieforest發表於2013-09-13
章五 帶上眼罩測試軟體(2)
三、狀態測試
軟體測試的另一個方面是通過不同的狀態驗證程式的邏輯流程。
軟體狀態是指軟體當前所處的條件或者模式。
注意：軟體測試員必須測試程式的狀態及其轉換。
1、測試軟體的邏輯流程
前面講過，要使測試可以控制，就必須通過建立只包含最關鍵數字的等價劃分來減少候選資料。測試軟體的狀態和邏輯流程有同樣的問題。
對於軟體測試，解決方法是運用等價劃分技術選擇狀態和分支。
（1）建立狀態轉換圖
這種圖可能作為產品說明的一部分被提供出來。繪製狀態轉換圖有幾種技術。可使用方框和箭頭，也可使用圓圈和箭頭。
注意：狀態轉換圖可能會變得非常大，如果預計狀態圖會如此複雜，那麼就找一些商業軟體來繪製和管理。
狀態轉換圖應該表示出以下專案：
（1.1）軟體可能進入的每一種獨立狀態；
如果不能斷定是否為獨立狀態，它就可能是；如以後發現不是，隨時可將其剔除。
（1.2）從一種狀態轉入另一種狀態所需的輸入和條件；
可能是按鍵、選單選擇、感測器訊號或者電話振鈴等。
（1.3）進入或者退出某種狀態時的設定條件及輸出結果。
包括顯示的選單和按鈕、設定的標誌位、產生的列印輸出、執行的運算等。
2、減少要測試的狀態及轉換的數量
為大型軟體產品建立狀態圖是一項艱鉅的任務，但願只測試整個軟體的一部分，使建立狀態圖變成一個可以接受的任務。
遍歷所有的分支是不可能的，需要將大量的可能性減少到可以操作的測試用例集合。有5種實現方法：
（1）每種狀態至少訪問一次；
（2）測試看起來是最常見和最普遍的狀態轉換；
（3）測試狀態之間最不常用的分支；
（4）測試所有錯誤狀態及其返回值；
（5）測試隨機狀態轉換。
3、進行具體測試
確定要測試的狀態及其轉換之後，就可以定義測試用例了。
測試狀態及其轉換包括檢查所有的狀態變數（state variables）——與進入和退出狀態相關的靜態條件、資訊、值、功能等。
把對狀態及其轉換的假定與專案小組的產品說明書作者和程式設計師討論是個好主意，他們可以提供軟體測試員可能想不到的、表面現象背後的狀態內幕。
文件塗改標誌：當文件載入編輯器，一個稱為文件塗改標記（dirty document flag）的狀態變數即被清除，軟體處於“潔淨”狀態。只要文件任何修改，軟體就保持這種狀態。
狀態變數也許看不見，但是很重要。
4、失敗狀態測試
測試包括審查軟體、描繪狀態、嘗試各種合法可能性、確認狀態及其轉換正常。
和資料測試一樣，相反的做法是找到使測試軟體失敗的案例。
（1）競爭條件和時序錯亂
多工（multitasking）是指作業系統設計用來同時執行多個獨立的程式。
設計充分利用多工的軟體才是艱鉅的任務。必須隨時處理被中斷的情況，能夠與其它軟體在系統中同時執行，並且共享記憶體、磁碟、通訊以及其它硬體資源。
可能產生競爭條件問題（race condition）。
競爭條件測試難以設計，最好是首先仔細檢視狀態轉換圖中的每一個狀態，以找出哪些外部影響會中斷該狀態。
（2）重複、壓迫和重負
重複測試（repetition testing）是不斷執行同樣的操作。最簡單的是不停地啟動、關閉程式。
進行反覆測試的主要原因是檢查是否存在記憶體洩漏（memory leaks）。如果計算機記憶體被分配進行某些操作，但是操作完成時沒有完全釋放，就會產生一個常見的軟體問題。結果是最後程式耗盡了它賴以工作的記憶體空間。
壓迫測試（stress testing）是使軟體在不夠理想的條件下執行——記憶體小，磁碟空間少、CPU速度慢、調變解調器速率低等。觀察軟體對外部資源的要求和依賴的程度。壓迫測試是將支援降到最低限度，目的在於儘可能地限制軟體的必要條件。
重負測試（load testing）與壓迫測試相反。壓迫測試是儘量限制條件，而重負測試是儘量提供條件任其發揮。讓軟體處理儘可能大的資料檔案。最大限度地發掘軟體的能力，讓它不堪重負。
注意：重複、壓迫和重負測試應聯合使用，同時進行，這時找出以其它方式難以發現的嚴重缺陷的一個可靠的方法。
軟體測試員的任務是確保軟體在這樣惡劣的條件下仍能正常工作，否則就報告軟體缺陷。
5、其它黑盒測試技術
（1）像笨拙的使用者那樣做
（2）在已經找到的軟體缺陷的地方再找找
（3）像黑客一樣考慮問題
（4）憑藉經驗、自覺和預感 

相關文章