測試、測試、測試--軟件測試的理論和實踐

　　　　　　　　　　　　　　　　　　　
　　題記：測試是交付成功的優質的產品的保證

我們每個人，不會都是軟件測試人員，但都是某些軟件的用戶。缺省或默認情況下，用戶都會覺得買到的軟件是沒有問題的，一般不會去想這樣的軟件可能會有問題，用戶只要使用這些軟件來解決他們需要解決的問題就可以了。當他們發現問題的時候，甚至會感到震驚。存在的問題很多都和測試的成效有關系，一般的軟件產品存在的問題確實比較少，但我覺得即使是以前買的正版的金山快譯2000都有著一些顯而易見的bug。如果測試不充分，那么這些問題會潛伏在軟件中，等到用戶發現以后，再有開發人員進行維護，改正錯誤的費用一般是開發階段的40倍到60倍。

人們對測試存在著一些誤區，例如：
1 測試是想象到可能出現的問題，然后試圖驗證這些問題。
實際上能想象到的只是一部分的情況，隨意性太大，還要取決于開發人員的經驗，對業務的熟悉程度和他想象到的程度。
2 讓時間有富裕的員工去做一些測試
表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關系。測試工作人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它工作同樣也會很出色，因此這里還有一個要求，就是要喜歡測試這項工作。如果他是專職的，那么肯定更有經驗和信心。國內的小伙子好象都喜歡做程序員，兩者工作性質不同，待遇不同，地位不同，對自我實現的價值的認識也不同，這是行業的一個需要改善的問題。如果只是為了完成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它工作中都是不行的。
3 測試是相對簡單的工作。
實際上并非如此，要真正做好一件事都不容易。測試也有很多相關技術和工具。而對測試的輕視問題，也許要通過痛苦的經歷和結果才可能確切體會到。很多專家都在對測試的理論進行深入的探討和研究。

測試的基本知識

讓我們一起快速過一遍：

什么是軟件測試：在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。
測試的目標：以較少的用例、時間和人力找出軟件中潛在的各種錯誤和缺陷，以確保系統的質量。
從測試的類型來看，測試分為2種：黑盒測試和白盒測試。
黑盒測試又稱為功能測試或數據驅動測試，把系統看成一個黑盒子，不考慮程序的內在邏輯，只根據需求規格說明書的要求來檢查程序的功能是否符合它的功能說明。
白盒測試又稱為結構測試和邏輯驅動測試，允許測試人員對程序內部邏輯結構及有關信息來設計和選擇測試用例，對程序的邏輯路徑進行測試。
測試用例由測試輸入數據以及與之對應的輸出結果組成。測試用例設計的好壞直接決定了測試的效果和結果。
從測試實際的前后過程來看，軟件測試上是由一系列的不同測試所組成，這些軟件測試的步驟分為：單元測試、組裝測試（集成測試）、確認測試和系統測試。軟件開發的過程是自頂向下的，測試則正好相反，以上這些過程就是自底向上，逐步集成的。

單元測試（模塊測試）：針對每個模塊進行的測試，可從程序的內部結構出發設計測試用例，多個模塊可以平行地對立地測試。通常在編碼階段進行，必要的時候要制作驅動模塊和樁模塊。
集成測試：在單元測試的基礎上，將所有模塊按照設計要求組裝成為系統，必須精心計劃，應提交集成測試計劃、集成測試規格說明和集成測試分析報告。
確認測試：驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
系統測試：將軟件放在整個計算機環境下，包括軟硬件平臺、某些支持軟件、數據和人員等，在實際運行環境下進行一系列的測試。

測試工作的文檔主要有：測試計劃、測試模型和用例設計或規格說明、測試分析報告等。從軟件工程上說，這是屬于軟件配置的一部分。（我不知道，如果什么報告都沒有，只是不斷地擺弄執行程序，看到錯誤和問題就記下來，算不算真正的測試？）

測試需要一定的技術和工具

在用例設計過程中，可以考慮到很多方面，并且也有很多的指導方法和技術。

黑盒測試用例設計包括：

等價類劃分：劃分等價類--確立測試用例--設計用例
邊界值分析：通過分析，考慮如何確立邊界情況
錯誤推測法：靠經驗和直覺來推測程序中可能存在的各種錯誤，從而有針對性地編寫用例?？梢粤信e出可能的錯誤和可能發生錯誤的地方，然后選擇用例。
因果圖：通過畫因果圖，在圖上標明約束和限制，轉換成判定表，然后設計測試用例。這適合于檢查程序輸入條件的各種組合情況。

功能圖FD：通過形式化地表示程序的功能說明，并機械地生成功能圖的測試用例。

白盒測試用例設計包括：

1 邏輯覆蓋，以程序內在邏輯結構為基礎的測試，包括以下5種類型：

1.1 語句覆蓋：每一條可執行語句至少覆蓋一次；
1.2 判定覆蓋（分支覆蓋）：設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次；
1.3 條件覆蓋：設計足夠多的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次；
1.4 判定-條件覆蓋：設計足夠多的測試用例，運行所測程序，使程序中每個判斷的每個條件的所有可能取值至少執行一次，并且每個可能的判斷結果也至少執行一次；
1.5 條件組合測試：設計足夠多的測試用例，運行所測程序，使程序中每個判斷的所有可能的條件取值至少執行一次；
1.6 路徑測試：設計足夠多的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。

2 基本路徑測試

在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例。包括以下5個方面：
2.1 程序的控制流圖：描述程序控制流的一種圖示方法。
2.2 程序環境復雜性：McCabe復雜性度量。從程序的環路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行依次所必須的測試用例數目的上界。
2.3 導出測試用例
2.4 準備測試用例，確?；韭窂郊械拿恳粭l路徑的執行
2.5 圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實現自動地確定一個基本路徑集。

程序的靜態分析方法：

1 生成各種引用表、靜態錯誤分析

2 人工測試：桌前檢查、代碼評審等

3 軟件測試工具：包括靜態分析工具、動態測試工具、測試數據自動化生成工具、模塊測試臺、測試合成環境

3.1 靜態分析工具：語言程序的預處理器、數據庫工具、錯誤分析器和報告生成器。直接掃描所測試的正文，對程序的數據流和控制流進行分析，然后送出測試報告。

3.2 動態測試工具：通過選擇適當的測試用例，實際運行所測程序，比較實際運行結果和預期結果，發現錯誤。

3.3 測試數據自動化生成工具：包括路徑測試數據生成程序、隨機測試數據生成程序以及根據數據規格說明生成測試數據

3.4 模塊測試臺是一種專門的測試用例描述語言，負責將輸入數據傳送到所測試模塊中，然后將實際輸出結果與在描述測試用例的語言中所表述的期望結果進行比較，發現錯誤。另外，也包括其它的功能：語句跟蹤、動態斷句、覆蓋度量、用戶自定義符號表、內容表和輸出格式。

3.5 測試合成環境：包括環境模擬程序，代碼檢查程序，測試文檔生成程序，測試執行嚴整程序，輸出比較程序，程序正確性證明程序等，以及各種調試工具。而且還有集成系統，集成了多種工具，如SADAT、Microsoft Test for Windows和PureArtria等。
　
***********************************************************

測試的管理

作為項目或產品開發的一個必要的組成部分，需要良好的組織和管理。使用軟件質量規范，編寫和實現測試用例和模型，可以有效地組織測試。

一般的測試工作過程也可以是：計劃-->配置（必要的軟硬件資源下）-->開發（構造或配置測試工具、創建測試套件和測試方案庫、準備適當的報告工具并記錄測試系統如何運轉）-->測試執行（進行測試、記錄測試條件和問題，報告結果）。

測試管理也可以從測試經理和測試小組2個方面去看：

測試經理要管理好團隊，很多人認為測試是枯燥乏味的事情，而且似乎低級的事情，所以測試經理應該不斷地激勵小組成員，為他們爭取利益。在時間進度上保證穩步前進。就象賽跑，一開始就加班加點，只會導致極限的過早到來。
作為測試經理，應該有足夠的質量意識。評價質量風險的方法是“失敗模式和效果分析”(Failure Mode and Effect Analysis, FMEA)。這種方法可以允許您在特定的質量風險和結果上映射需求、規范，以及項目小組假設。然后，按照風險級別進行分類，并按序排列。
實際上如果能得到充分的資源已是很困難的了，能用好臨時的測試人員也已經不錯了。一般企業的主管和技術經理都并不怎么真正重視測試工作的意義和價值。也許他們認為臨時的投入一次性的強力測試足以發現絕大部分問題，而實際上這對產品的長遠發展，以及質量改進都沒有太大好處。

測試過程中軟件功能可能進行調整和變化，測試發現問題也會導致變化，需要重新的測試。對這些變更也需要進行管理。
另外，由于上層管理部門的不重視，必須想辦法與之進行清楚而有效的溝通；同開發部門的溝通也非常重要，因為開發和測試在性質上是有些對立的，很容易在相互之間產生一些不必要的矛盾。和開發部門不同的是，一般質量或測試部門和市場或銷售部門的立場倒是比較一致的，如果雙方都認為高質量的產品是市場戰略中重要的品牌戰略，徹底的測試對于達到這樣的目標來說意義重大。因此，有必要和市場部門保持協作和交流。

測試經理可以經常問自己一些問題：

計劃做哪些測試？實際完成了哪些測試？使用了多少用例？其中多少沒有通過？管理部門是否有足夠的支持？他們是否向你要過測試報告？開發部門的聯絡是否及時？等等。如果你是測試管理人員，應該可以想到更多的問題。

測試小組：

測試小組有多大的規模，一般取決于項目規模、測試人員與開發人員的比例、項目經理對質量保證的認識和期望等，也取決于你的準確的測試計劃。
對一些項目來說，最好是在開始階段就有測試人員有所介入。

如本文一開始所提到的，在測試小組中測試人員必須具備的素質包括：有效的坦率真誠的交流的能力、清晰簡明的表達能力、一定的好奇心（但不至于太強，以至于花太多精力去探究一個微小的問題），不應害怕提出尖銳問題引起麻煩，一定的責任心，
注意力能夠高度集中，是職業悲觀主義者（但不是抱怨和憎惡）。

以下是一些測試的方法和基本工具：

測試方案、測試模型和測試用例
測試就象是做實驗一樣，實驗對于象我這樣的理工科畢業生來說真是太熟悉不過了。做實驗之前必然有實驗的方案、內容和步驟，測試似乎也是同樣的。另外，基于測試用例的測試和常見的隨機性的測來測去也是完全不同的，盡管習慣于隨機性測試的人，如果注意力集中的話，他的頭腦里也是有一些測試用例的。

關于測試實驗室，進行測試工作首先要爭取到盡可能好的環境。如果可能，應該建立測試實驗室，實驗室包括必要的裝備、工具軟件（包括測試工具）和各種操作系統平臺，保持實驗室的實用、整潔，避免他人干擾甚至破壞測試環境。

關于測試跟蹤軟件，制作一個簡單的測試問題跟蹤軟件，記錄測試的結果，將測試發現的問題分類，并對測試發現的問題和模塊、開發人員進行關聯，有助于分析問題，并可有效記錄測試的結果，形成測試報告，并從中找出一些規律性的東西來。因此測試問題跟蹤軟件還是有一定的價值的。

關于測試自動化，有一定的風險。對一個穩定的系統，甚至可以自己開發自動化軟件，而對于正處于快速變形中的軟件開發過程，接口、主要功能和支持環境在發展變化中。為測試配置環境也要付出很多的時間。

以下是關于測試的一些技巧和經驗：

在制定測試計劃的時候，就要考慮到測試的風險，并抉擇要執行哪些測試，并放棄哪些測試；測試計劃的評審應該讓開發人員參與；
測試模型的制作應該盡可能貼近用戶，或者站在用戶的使用立場上來觀測軟件，此時應該能發現更多的問題。

由于測試發現問題，在解決問題后還要重新測試，因此測試的時間可能會比實際更長一些

識別和注意少數重要的方面，而忽略多數次要的方面，有時候少數的問題足以致命，這些問題將是軟件測試結果中重要性最高的錯誤。

錯誤的定位有時是很難的，要找出必然發生的前因后果，而不至于因為描述錯誤而誤導開發人員。有時候確實存在錯誤不能重建的問題。解決辦法之一是在錯誤報告中給予說明。

對錯誤的描述，應該是準確、完整而簡練。因為描述的問題或者不完整的描述會引起開發人員的誤解，其后果是可以想見的。

有時有經驗的測試人員憑借直覺就可以發現一些問題，這可稱為“錯誤猜測”。

測試人員容易犯2種錯誤：一是測試人員發生判斷錯誤，將本沒有錯誤的系統行為報告為錯誤，或者將錯誤指定了過高的嚴重級別，或者過高估計了問題的嚴重性，這樣會引起開發人員的不信任，產生一種象“狼來了”一樣的效果；二是測試人員將錯誤的嚴重性或優先級定得過低，從而產生“測試逃逸”，這樣會造成產品質量的風險。以上兩種錯誤應該盡量避免。

　
最后，我忽然想，測試實際上可以覆蓋到硬件，甚至非計算機產品的測試，也許可以相互借鑒。

還有一種很奇特的感想，這種感想使我反而有些困惑不清了。我發現對測試來說，理論和實踐的距離好象非常遙遠，我先看了一本軟件工程的書，然后寫下了前面的一半內容，然后我又匆匆翻看了一本美國人的書，叫做《測試流程管理》，然后整理出了本文后一半的內容，該書中有著比本文多得多的各方面的實踐經驗。歌德說過，理論是蒼白的，生命之樹常青。我稍稍改變一下，就變成了：理論是蒼白的，實踐之樹常青。也許測試是一種實踐性很強的工作，大學教授們一般也不可能熱衷于參加測試工作吧。

原文轉自：http://www.anti-gravitydesign.com