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

測試是交付成功的優質的產品的保證 (from www.csai.cn)


我們每個人,不會都是軟體測試人員,但都是某些軟體的用戶。缺省或默認情況下,用戶都會覺得買到的軟體是沒有問題的,一般不會去想這樣的軟體可能會有問題,用戶只要使用這些軟體來解決他們需要解決的問題就可以了。當他們發現問題的時候,甚至會感到震驚。


存在的問題很多都和測試的成效有關係,一般的軟體產品存在的問題確實比較少,但我覺得即使是以前買的正版的金山快譯2000都有著一些顯而易見的bug。如果測試不充分,那麼這些問題會潛伏在軟體中,等到用戶發現以後,再有開發人員進行維護,改正錯誤的費用一般是開發階段的40倍到60倍。


人們對測試存在著一些誤區,例如:



1 測試是想像到可能出現的問題,然後試圖驗證這些問題。
實際上能想像到的只是一部分的情況,隨意性太大,還要取決於開發人員的經驗,對業務的熟悉程度和他想像到的程度。

2 讓時間充裕的員工去做一些測試
表面上看這體現了管理的效率和靈活性,但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關係。測試工作人員應該是勤奮並富有耐心,善於學 習、思考和發現問題,細心有條理,總結問題,如果具備這樣的優點,做其他工作同樣也會很出色,因此這裏還有一個要求,就是要喜歡測試這項工作。

如果他是專職的,那麼肯定更有經驗和信心。國內的小夥子好像都喜歡做程式師,兩者工作性質不同,待遇不同,地位不同,對自我實現的價值的認識也不同,這是行業的一個需要改善的問題。如果只是為了完成任務而完成任務,或者發現了幾個問題就覺得滿意了,這在任何其他工作中都是不行的。



3 測試是相對簡單的工作。
實際上並非如此,要真正做好一件事都不容易。測試也有很多相關技術和工具。而對測試的輕視問題,也許要通過痛苦的經歷和結果才可能確切體會到。很多專家都在對測試的理論進行深入的探討和研究。

測試的基本知識


讓我們一起快速過一遍:


什麼是軟體測試:在軟體投入運行前,對軟體需求分析、設計規格說明和編碼的最終復審,是軟體品質保證的關鍵步驟。


測試的目標:以較少的案例、時間和人力找出軟體中潛在的各種錯誤和缺陷,以確保系統的品質。



從測試的類型來看,測試分為2種:黑盒測試和白盒測試。
黑盒測試又稱為功能測試或資料驅動測試,把系統看成一個黑盒子,不考慮程式的內在邏輯,只根據需求規格說明書的要求來檢查程式的功能是否符合它的功能說明。

白盒測試又稱為結構測試和邏輯驅動測試,允許測試人員對程式內部邏輯結構及有關資訊來設計和選擇測試用例,對程式的邏輯路徑進行測試。


測試案例由測試輸入資料以及與之對應的輸出結果組成。測試案例設計的好壞直接決定了測試的效果和結果。


從測試實際的前後過程來看,軟體測試上是由一系列的不同測試所組成,這些軟體測試的步驟分為:單元測試、組裝測試(集成測試)、確認測試和系統測試。軟體發展的過程是自頂向下的,測試則正好相反,以上這些過程就是自底向上,逐步集成的。


單元測試(模組測試):針對每個模組進行的測試,可從程式的內部結構出發設計測試用例,多個模組可以平行地對立地測試。通常在編碼階段進行,必要的時候要製作驅動模組和樁模組。


集成測試:在單元測試的基礎上,將所有模組按照設計要求組裝成為系統,必須精心計畫,應提交集成測試計畫、集成測試規格說明和集成測試分析報告。


確認測試:驗證軟體的功能和性能及其它特性是否與用戶的要求一致。


系統測試:將軟體放在整個電腦環境下,包括軟硬體平臺、某些支援軟體、資料和人員等,在實際運行環境下進行一系列的測試。


測試工作的文檔主要有:測試計畫、測試模型和案例設計或規格說明、測試分析報告等。從軟體工程上說,這是屬於軟體配置的一部分。(我不知道,如果什麼報告都沒有,只是不斷地擺弄執行程式,看到錯誤和問題就記下來,算不算真正的測試?)


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


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


黑盒測試案例設計包括:



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

功能圖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 準備測試案例,確保基本路徑集中的每一條路徑的執行


2.5 圖形矩陣:是在基本路徑測試中起輔助作用的軟體工具,利用它可以實現自動地確定一個基本路徑集。


程式的靜態分析方法:


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


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


3 軟體測試工具:包括靜態分析工具、動態測試工具、測試資料自動化生成工具、模組測試台、測試合成環境


3.1 靜態分析工具:語言程式的預處理器、資料庫工具、錯誤分析器和報告生成器。直接掃描所測試的正文,對程式的資料流程和控制流進行分析,然後送出測試報告。


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


3.3 測試資料自動化生成工具:包括路徑測試資料生成程式、隨機測試資料生成程式以及根據資料規格說明生成測試資料


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


3.5 測試合成環境:包括環境類比程式,代碼檢查程式,測試文檔生成程式,測試執行嚴整程式,輸出比較程式,程式正確性證明程式等,以及各種調試工具。而且還有集成系統,集成了多種工具,如SADATMicrosoft Test for WindowsPureArtria等。


測試的管理


作為專案或產品開發的一個必要的組成部分,需要良好的組織和管理。使用軟體品質規範,編寫和實現測試用例和模型,可以有效地組織測試。


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


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


測試經理要管理好團隊,很多人認為測試是枯燥乏味的事情,而且似乎低級的事情,所以測試經理應該不斷地激勵小組成員,為他們爭取利益。在時間進度上保證穩步前進。就象賽跑,一開始就加班加點,只會導致極限的過早到來。


作為測試經理,應該有足夠的品質意識。評價品質風險的方法是失敗模式和效果分析”(Failure Mode and Effect Analysis, FMEA)。這種方法可以允許您在特定的品質風險和結果上映射需求、規範,以及專案小組假設。然後,按照風險級別進行分類,並按序排列。


實際上如果能得到充分的資源已是很困難的了,能用好臨時的測試人員也已經不錯了。一般企業的主管和技術經理都並不怎麼真正重視測試工作的意義和價值。也許他們認為臨時的投入一次性的強力測試足以發現絕大部分問題,而實際上這對產品的長遠發展,以及品質改進都沒有太大好處。


測試過程中軟體功能可能進行調整和變化,測試發現問題也會導致變化,需要重新的測試。對這些變更也需要進行管理。


另外,由於上層管理部門的不重視,必須想辦法與之進行清楚而有效的溝通;同開發部門的溝通也非常重要,因為開發和測試在性質上是有些對立的,很容易在相互之間產生一些不必要的矛盾。和開發部門不同的是,一般品質或測試部門和市場或銷售部門的立場倒是比較一致的,如果雙方都認為高品質的產品是市場戰略中重 要的品牌戰略,徹底的測試對於達到這樣的目標來說意義重大。因此,有必要和市場部門保持協作和交流。


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


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


測試小組:


測試小組有多大的規模,一般取決於專案規模、測試人員與開發人員的比例、專案經理對品質保證的認識和期望等,也取決於你的準確的測試計畫。


對一些項目來說,最好是在開始階段就有測試人員有所介入。



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

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


測試方案、測試模型和測試用例


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


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


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


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


以下是關於測試的一些技巧和經驗:



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

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


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


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


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


有時有經驗的測試人員憑藉直覺就可以發現一些問題,這可稱為錯誤猜測


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


最後,我忽然想,測試實際上可以覆蓋到硬體,甚至非電腦產品的測試,也許可以相互借鑒。


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



相關文章

如何將電腦畫面經由 Chromecast 投放到電視螢幕上

Chrome 的檔案續傳功能

Mac與Android裝置傳輸檔案的方法

使用 Vysor 在電腦上控制 Android 裝置