關於軟體測試

因為測試時從來不希望檢測被測系統所有可能的輸入、路徑和狀態，那麼應該選擇什麼？什麼時候應該停止測試？什麼時候應該暫停測試？怎樣編寫乙個測試包，它可以檢測足夠多的訊息和狀態的組合來說明沒有失敗的操作，但是從實用性來說它又足夠的小？

測試提出了許多基本的但卻令人困惑的難題，帶著這些問題，參加了幾次實用軟體測試培訓。

由於軟體的複雜導致了測試的複雜，所以不能指望培訓能給我們很多任務作中的實際指導。偏重理論是肯定的，但並非沒有意義，雖然理論同樣可以從相關的文獻資料上得到。

有一些心得，零零散散，記錄下來，與大家交流。

一，軟體測試員的目標是盡可能早地找出軟體缺陷，並確保其得以關閉。仔細思考後，我覺得此目標包含三個含義。

1．軟體測試員的基本目標是發現軟體缺陷。

這似乎是個不言而喻的事實，但有必要再次強調。因為有時開發小組要測試員只是為了證實軟體可以執行，而不是找缺陷。在這種情況下，測試人員也就缺乏不懈努力發現缺陷的探索精神和熱情。所以做好測試的首要條件是明確軟體測試員的基本目標是發現軟體缺陷。

2．軟體測試員追求的是盡可能早地找出軟體缺陷。

因為軟體的修復費用，隨著時間的推移，將數十倍的增長，所以軟體測試員應盡可能早地找出軟體缺陷。對於大型的軟體，在軟體開發的同時，就應該有緊隨其後的測試，如果等到產品已經開發完畢才開始測試，非常有可能引起大量耗時費力的返工。而如何盡可能早的找出缺陷？理論上有一些測試方法：靜態黑盒測試、動態黑盒測試、靜態白盒測試、動態白盒測試；配置測試、相容性測試、易用性測試……，怎樣才能有效的用這些方法盡早的發現軟體缺陷，需要在工作實踐中不斷的摸索、總結，不斷的提高測試能力。針對公司的情況，如果軟體的規模不是很大，開發中的測試工作可能由開發人員完成比較合適。

3．軟體測試人員必需確保找出的軟體缺陷得以關閉。

並不是每個軟體缺陷都有必要修復的。可能是由於沒有足夠的時間、不算作真正的軟體缺陷、修復的風險太大等原因，產品開發小組決定對一些軟體缺陷不作修復。但是，測試人員必需確保找出的軟體缺陷得以關閉，也就是說一旦登記了軟體缺陷，就要跟蹤其生命週期，監視其狀態，提供必要的資訊確保其得到修復和關閉。

二，關於testware。

有個很簡潔明瞭的定義，software development engineers produce software, software test engineers produce testware. 那麼testware包含哪些內容呢？test strategy, test plan, test specifications, test procedures, test cases, test reports, test data, test scripts, defects data等等。同軟體一樣，testware也需要很好地維護。例如，由於修復缺陷改變了軟體的介面，那麼case和自動測試指令碼script都要做相應的修改。

三，對產品說明書的測試。

軟體的產品功能說明書對產品最終需要實現的功能作了描述。這些功能是最終確定的需要滿足的客戶需求，也包括軟體必須具備的能力。在規範的軟體開發流程中，產品功能說明書應在確定使用者需求後，進行系統概要設計前確定。

至於為什麼要進行產品說明書的測試，統計資料表明，很多軟體的缺陷都是因為產品功能說明書不夠全面，經常更改造成的；另外，只有詳細的閱讀了產品功能說明書，確認產品需要實現的功能，才能擬定切實可行的測試方案。

其方法，具體地說有以下幾種。

1．參照需求說明，檢查產品功能說明書描述的產品將要實現的功能是否已經完整、準確、一致、合理的描述了產品的功能，並確保這些功能是可測試的。

2．研究產品說明書是否符合現有的軟體設計開發的標準或規範。

3．研究同類軟體，**產品的最終結果。

可是如果應用到實際的開發流程中，又有著一定的困難。因為很難做到讓軟體測試人員在專案的初期就參與專案，一般要等到軟體的雛形出來後才會讓軟體測試人員著手進行測試。即便是在初期測試人員參與專案，也只是根據產品說明書和設計計畫制定測試計畫。測試人員沒有被賦予責任去檢查產品說明書。

四，經濟的測試。

測試是一項複雜的工作。因此要考慮其效率。經濟的測試有幾個原則。

1．如果乙個case（x）依賴另乙個（y），如果y失敗，那麼x可以不要測試。

2．針對乙個子集，如果乙個輸入導致了失敗，那麼剩下的輸入可以不要測試。

3．針對乙個case，如果乙個測試子集產生了失敗，那麼其他的子集可以不要測試。

由此，聯想到乙個實際問題。開發人員一次送測，按流程，應進行一輪全面的測試。但如果在測試初期發現了缺陷，此輪測試是否要繼續？不繼續，則此輪測試不完整，無法產出測試報告。繼續到完全測試，如果發現的缺陷是嚴重的必須解決的缺陷，則後面的測試是不經濟的，因為此缺陷修復後仍要進行全面的測試。

按照測試的原則，發現缺陷要及時地反饋給開發人員，以便及時了解軟體狀態。但在實際操作中，開發人員得到反饋後常常隨即給出乙個修復版，然後再一輪測試。造成的情況是，到專案結束，發現多少個缺陷，往往就經過多少輪測試，每一輪測試僅僅是驗證對乙個缺陷的修復。

所以我覺得，對於什麼時候暫停測試，是否需要暫停，開發人員什麼時候送測新的修復版本，應該有乙個良好的控制。

五，自動測試

我們是用rational robot編寫自動測試指令碼進行自動測試。主要用與一些ap的ui測試。由於編寫sqa basic代價較高，所以應用於稍具複雜度的程式或需多輪回歸測試的專案是比較經濟的，如果是簡單的ui，或不需進行多輪回歸測試的專案，就要比較編寫指令碼的投入和實施自動測試的經濟了。

如果多輪回歸測試間程式變化比較多，改寫指令碼也是負擔很重的工作。

以上是一點點心得，零散寫下。

關於軟體測試

關於軟體測試關於軟體測試

關於軟體測試

關於軟體測試

相關推薦