題記:測試是交付成功的優質的產品的保證
我們每個人,不會都是軟件測試人員,但都是某些軟件的用戶。缺省或默認情況下,用戶都會覺得買到的軟件是沒有問題的,一般不會去想這樣的軟件可能會有問題,用戶只要使用這些軟件來解決他們需要解決的問題就可以了。當他們發現問題的時候,甚至會感到震驚。存在的問題很多都和測試的成效有關系,一般的軟件產品存在的問題確實比較少,但我覺得即使是以前買的正版的金山快譯2000都有著一些顯而易見的bug。如果測試不充分,那么這些問題會潛伏在軟件中,等到用戶發現以后,再有開發人員進行維護,改正錯誤的費用一般是開發階段的40倍到60倍。 人們對測試存在著一些誤區,例如: 測試的基本知識 讓我們一起快速過一遍: 什么是軟件測試:在軟件投入運行前,對軟件需求分析、設計規格說明和編碼的最終復審,是軟件質量保證的關鍵步驟。 單元測試(模塊測試):針對每個模塊進行的測試,可從程序的內部結構出發設計測試用例,多個模塊可以平行地對立地測試。通常在編碼階段進行,必要的時候要制作驅動模塊和樁模塊。 測試工作的文檔主要有:測試計劃、測試模型和用例設計或規格說明、測試分析報告等。從軟件工程上說,這是屬于軟件配置的一部分。(我不知道,如果什么報告都沒有,只是不斷地擺弄執行程序,看到錯誤和問題就記下來,算不算真正的測試?) 測試需要一定的技術和工具
黑盒測試用例設計包括: 等價類劃分:劃分等價類--確立測試用例--設計用例 功能圖FD:通過形式化地表示程序的功能說明,并機械地生成功能圖的測試用例。 白盒測試用例設計包括: 1 邏輯覆蓋,以程序內在邏輯結構為基礎的測試,包括以下5種類型: 1.1 語句覆蓋:每一條可執行語句至少覆蓋一次;
在程序控制流圖的基礎上,通過分析控制構造的環路復雜性,導出基本可執行路徑集合,從而設計測試用例。包括以下5個方面: 程序的靜態分析方法: 1 生成各種引用表、靜態錯誤分析 2 人工測試:桌前檢查、代碼評審等 3 軟件測試工具:包括靜態分析工具、動態測試工具、測試數據自動化生成工具、模塊測試臺、測試合成環境 3.1 靜態分析工具:語言程序的預處理器、數據庫工具、錯誤分析器和報告生成器。直接掃描所測試的正文,對程序的數據流和控制流進行分析,然后送出測試報告。 3.2 動態測試工具:通過選擇適當的測試用例,實際運行所測程序,比較實際運行結果和預期結果,發現錯誤。 3.3 測試數據自動化生成工具:包括路徑測試數據生成程序、隨機測試數據生成程序以及根據數據規格說明生成測試數據 3.4 模塊測試臺是一種專門的測試用例描述語言,負責將輸入數據傳送到所測試模塊中,然后將實際輸出結果與在描述測試用例的語言中所表述的期望結果進行比較,發現錯誤。另外,也包括其它的功能:語句跟蹤、動態斷句、覆蓋度量、用戶自定義符號表、內容表和輸出格式。 3.5 測試合成環境:包括環境模擬程序,代碼檢查程序,測試文檔生成程序,測試執行嚴整程序,輸出比較程序,程序正確性證明程序等,以及各種調試工具。而且還有集成系統,集成了多種工具,如SADAT、Microsoft Test for Windows和PureArtria等。
***********************************************************
測試的管理 作為項目或產品開發的一個必要的組成部分,需要良好的組織和管理。使用軟件質量規范,編寫和實現測試用例和模型,可以有效地組織測試。 一般的測試工作過程也可以是:計劃-->配置(必要的軟硬件資源下)-->開發(構造或配置測試工具、創建測試套件和測試方案庫、準備適當的報告工具并記錄測試系統如何運轉)-->測試執行(進行測試、記錄測試條件和問題,報告結果)。 測試管理也可以從測試經理和測試小組2個方面去看: 測試經理要管理好團隊,很多人認為測試是枯燥乏味的事情,而且似乎低級的事情,所以測試經理應該不斷地激勵小組成員,為他們爭取利益。在時間進度上保證穩步前進。就象賽跑,一開始就加班加點,只會導致極限的過早到來。 測試過程中軟件功能可能進行調整和變化,測試發現問題也會導致變化,需要重新的測試。對這些變更也需要進行管理。 測試經理可以經常問自己一些問題: 計劃做哪些測試?實際完成了哪些測試?使用了多少用例?其中多少沒有通過?管理部門是否有足夠的支持?他們是否向你要過測試報告?開發部門的聯絡是否及時?等等。如果你是測試管理人員,應該可以想到更多的問題。
測試小組有多大的規模,一般取決于項目規模、測試人員與開發人員的比例、項目經理對質量保證的認識和期望等,也取決于你的準確的測試計劃。 如本文一開始所提到的,在測試小組中測試人員必須具備的素質包括:有效的坦率真誠的交流的能力、清晰簡明的表達能力、一定的好奇心(但不至于太強,以至于花太多精力去探究一個微小的問題),不應害怕提出尖銳問題引起麻煩,一定的責任心, 以下是一些測試的方法和基本工具: 測試方案、測試模型和測試用例 關于測試實驗室,進行測試工作首先要爭取到盡可能好的環境。如果可能,應該建立測試實驗室,實驗室包括必要的裝備、工具軟件(包括測試工具)和各種操作系統平臺,保持實驗室的實用、整潔,避免他人干擾甚至破壞測試環境。 關于測試跟蹤軟件,制作一個簡單的測試問題跟蹤軟件,記錄測試的結果,將測試發現的問題分類,并對測試發現的問題和模塊、開發人員進行關聯,有助于分析問題,并可有效記錄測試的結果,形成測試報告,并從中找出一些規律性的東西來。因此測試問題跟蹤軟件還是有一定的價值的。 關于測試自動化,有一定的風險。對一個穩定的系統,甚至可以自己開發自動化軟件,而對于正處于快速變形中的軟件開發過程,接口、主要功能和支持環境在發展變化中。為測試配置環境也要付出很多的時間。 以下是關于測試的一些技巧和經驗: 在制定測試計劃的時候,就要考慮到測試的風險,并抉擇要執行哪些測試,并放棄哪些測試;測試計劃的評審應該讓開發人員參與; 由于測試發現問題,在解決問題后還要重新測試,因此測試的時間可能會比實際更長一些 識別和注意少數重要的方面,而忽略多數次要的方面,有時候少數的問題足以致命,這些問題將是軟件測試結果中重要性最高的錯誤。 錯誤的定位有時是很難的,要找出必然發生的前因后果,而不至于因為描述錯誤而誤導開發人員。有時候確實存在錯誤不能重建的問題。解決辦法之一是在錯誤報告中給予說明。 對錯誤的描述,應該是準確、完整而簡練。因為描述的問題或者不完整的描述會引起開發人員的誤解,其后果是可以想見的。 有時有經驗的測試人員憑借直覺就可以發現一些問題,這可稱為“錯誤猜測”。 測試人員容易犯2種錯誤:一是測試人員發生判斷錯誤,將本沒有錯誤的系統行為報告為錯誤,或者將錯誤指定了過高的嚴重級別,或者過高估計了問題的嚴重性,這樣會引起開發人員的不信任,產生一種象“狼來了”一樣的效果;二是測試人員將錯誤的嚴重性或優先級定得過低,從而產生“測試逃逸”,這樣會造成產品質量的風險。以上兩種錯誤應該盡量避免。
最后,我忽然想,測試實際上可以覆蓋到硬件,甚至非計算機產品的測試,也許可以相互借鑒。 還有一種很奇特的感想,這種感想使我反而有些困惑不清了。我發現對測試來說,理論和實踐的距離好象非常遙遠,我先看了一本軟件工程的書,然后寫下了前面的一半內容,然后我又匆匆翻看了一本美國人的書,叫做《測試流程管理》,然后整理出了本文后一半的內容,該書中有著比本文多得多的各方面的實踐經驗。歌德說過,理論是蒼白的,生命之樹常青。我稍稍改變一下,就變成了:理論是蒼白的,實踐之樹常青。也許測試是一種實踐性很強的工作,大學教授們一般也不可能熱衷于參加測試工作吧。 |
文章來源于領測軟件測試網 http://www.kjueaiud.com/