軟件測試中基于狀態轉換的測試

測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。

　　測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。

　　不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個個測試用例。

　　隨著中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷發展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，并有向第三方專業測試公司發展的趨勢。

　　要使最終用戶對軟件感到滿意,最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實并確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式并由不同的測試員來實施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個測試員采用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。

　　既然可能無法（或不必負責）核實所有的需求，那么是否能為測試挑選最適合或最關鍵的需求則關系到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。

　　確定測試用例之所以很重要，原因有以下幾方面。

　　測試用例構成了設計和制定測試過程的基礎。 測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。 判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。 測試設計和開發的類型以及所需的資源主要都受控于測試用例。 測試用例通常根據它們所關聯關系的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：

　　·一個測試用例用于證明該需求已經滿足，通常稱作正面測試用例； ·另一個測試用例反映某個無法接受、反?；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。

世間萬物，緣起緣滅，每天都在經歷著各種各樣的狀態轉換。

作為一個測試人員，在工作過程中，經常會碰到軟件中事物具有多個狀態，各個狀態在滿足某些條件時，實現狀態的轉換。

軟件中事物狀態間的轉換一般可分為兩類：一類是各個狀態之間轉換有一定的序列關系，如工作流，必須先發生A狀態，才能到B狀態，狀態A和B之間有先后順序；一類是各個狀態是并列關系，各個狀態間可以相互轉換，如狀態C和D，可以由C轉換成D，也可以由D轉換成C。這兩種類型的狀態轉換，都需要注意用戶角色權限。

所謂狀態轉換的測試，是指在測試過程對于軟件中事物狀態的轉換，我們需要模擬使狀態發生轉換的各種用戶操作場景，以及通過一些非正常手段來校驗不允許發生的狀態流轉?；旧蠈顟B轉換的測試，我們設計的用例需要涵蓋允許的狀態轉換和不允許的狀態轉換、以及用戶角色權限的校驗。

對于那些只有2個狀態轉換的情況，往往在基于主流程或備選流程的用例中添加狀態校驗項來實現；而對于那些有復雜的流轉過程或者有多種狀態的情況，只是通過用例中添加的狀態校驗項來，很容易遺漏狀態的轉換關系，更主要的各個狀態的轉換被拆分到各個功能模塊的用例中，非常的零碎，如果希望就針對狀態轉換的一個回歸，篩選用例將會是一件非常麻煩的事情，而不存在的狀態轉換校驗則沒有辦法體現，由此我們很是需要專門針對狀態的流轉做一個測試設計。

無論是序列關系還是并列關系的狀態轉換，我們都可以從需求說明書（PRD）中獲取狀態的流轉信息，為了更清晰的描述這種狀態流轉，我們可以通過狀態圖來表達。有了狀態圖，我們就可以從用戶使用的角度、結合用戶的實際需求去考慮，這些狀態的流轉是否符合用戶的操作習慣，檢查是否有冗余或者缺失的狀態；程序的實現是否可以讓用戶操作盡可能的簡單易用；狀態流轉路徑末端節點是否是終結狀態，終結狀態是否存在逆向的狀態流轉。

下面就這兩種類型的進行實例說明。

序列關系的狀態轉換：spu編輯狀態的轉換。

Spu編輯狀態的轉換，是一個有序的過程，在一個生命周期內，某個狀態下，滿足要求才會流轉到下一個狀態，大部分狀態的流轉是單向的，任意一個狀態流轉分支都是從初始狀態出發，到終結狀態終止。

并列關系的狀態轉換：商品狀態的轉換。

商品各個狀態間的轉換，也有起始狀態和終止狀態，不同于序列狀態，幾乎每個狀態都和多個狀態存在在轉換關系，且狀態之間的轉換是相互的，猶如蜘蛛網一樣，面對這種網狀的狀態圖，測試的時候需要特別注意狀態之間不允許發生的轉換是否存在。

從兩個實例，根據狀態圖，我們可以看到我們需要關注的內容：

狀態：狀態圖中的每一個狀態，都必須進行測試，校驗該狀態下，向其他狀態的轉換是否如狀態圖中展示的一致。

狀態之間允許的轉換：可能是如下情況，相同數據，不同操作引起不同轉換；不同數據（前置條件不一樣），相同操作引起的不同轉換；不同數據，不同操作引起的不同轉換。對每一個允許的狀態轉換進行驗證，設置狀態轉換的前置條件，操作使狀態發生轉換的功能，驗證操作是否正常、狀態是否如預期變化。對使用頻率特別高、或者特別容易出錯的轉換、以及最不常使用的轉換，需要構造更多的測試數據，做盡可能多的覆蓋。

狀態之間不允許的轉換：狀態之間不允許的轉換測試，關注系統返回的錯誤信息和狀態值是否變更，不需要對所有的不可能進行驗證，應該挑選那些特別容易發生的轉換進行測試。

狀態轉換的角色權限：狀態之間的轉換操作，是有用戶角色要求的，我們不僅要驗證有權限的角色能夠正常操作，還需要驗證沒有權限的角色是否能操作，對于沒有權限的角色驗證，在不可能全部驗證的情況下，也是挑選相對容易出錯的操作進行。

狀態的轉換，在軟件中是非常普遍的，通過狀態圖梳理各個狀態轉換的關系，并在狀態圖的基礎上按照狀態和狀態轉換的覆蓋原則進行測試設計，可以有效的保證軟件狀態轉換的正確性。測試過程中，還可以進行隨機的狀態轉換測試。