關(guān)鍵字：軟件測試 理論 實(shí)踐
題記：測試是交付成功的優(yōu)質(zhì)的產(chǎn)品的保證 我們每個(gè)人，不會(huì )都是軟件測試人員，但都是某些軟件的用戶(hù)。缺省或默認情況下，用戶(hù)都會(huì )覺(jué)得買(mǎi)到的軟件是沒(méi)有問(wèn)題的，一般不會(huì )去想這樣的軟件可能會(huì )有問(wèn)題，用戶(hù)只要使用這些軟件來(lái)解決他們需要解決的問(wèn)題就可以了。當他們發(fā)現問(wèn)題的時(shí)候，甚至會(huì )感到震驚。存在的問(wèn)題很多都和測試的成效有關(guān)系，一般的軟件產(chǎn)品存在的問(wèn)題確實(shí)比較少，但我覺(jué)得即使是以前買(mǎi)的正版的金山快譯2000都有著(zhù)一些顯而易見(jiàn)的bug。如果測試不充分，那么這些問(wèn)題會(huì )潛伏在軟件中，等到用戶(hù)發(fā)現以后，再有開(kāi)發(fā)人員進(jìn)行維護，改正錯誤的費用一般是開(kāi)發(fā)階段的40倍到60倍。
人們對測試存在著(zhù)一些誤區，例如：
1 測試是想象到可能出現的問(wèn)題，然后試圖驗證這些問(wèn)題。
實(shí)際上能想象到的只是一部分的情況，隨意性太大，還要取決于開(kāi)發(fā)人員的經(jīng)驗，對業(yè)務(wù)的熟悉程度和他想象到的程度。
2 讓時(shí)間有富裕的員工去做一些測試
表面上看這體現了管理的效率和靈活性，但實(shí)際上也體現了管理者對測試的輕視。測試和測試的人有很大關(guān)系。測試工作人員應該是勤奮并富有耐心，善于學(xué)習、思考和發(fā)現問(wèn)題，細心有條理，總結問(wèn)題，如果具備這樣的優(yōu)點(diǎn)，做其它工作同樣也會(huì )很出色，因此這里還有一個(gè)要求，就是要喜歡測試這項工作。如果他是專(zhuān)職的，那么肯定更有經(jīng)驗和信心。國內的小伙子好象都喜歡做程序員，兩者工作性質(zhì)不同，待遇不同，地位不同，對自我實(shí)現的價(jià)值的認識也不同，這是行業(yè)的一個(gè)需要改善的問(wèn)題。如果只是為了完成任務(wù)而完成任務(wù)，或者發(fā)現了幾個(gè)問(wèn)題就覺(jué)得滿(mǎn)意了，這在任何其它工作中都是不行的。
3 測試是相對簡(jiǎn)單的工作。
實(shí)際上并非如此，要真正做好一件事都不容易。測試也有很多相關(guān)技術(shù)和工具。而對測試的輕視問(wèn)題，也許要通過(guò)痛苦的經(jīng)歷和結果才可能確切體會(huì )到。很多專(zhuān)家都在對測試的理論進(jìn)行深入的探討和研究。
測試的基本知識
讓我們一起快速過(guò)一遍：
什么是軟件測試：在軟件投入運行前，對軟件需求分析、設計規格說(shuō)明和編碼的最終復審，是軟件質(zhì)量保證的關(guān)鍵步驟。
測試的目標：以較少的用例、時(shí)間和人力找出軟件中潛在的各種錯誤和缺陷，以確保系統的質(zhì)量。
從測試的類(lèi)型來(lái)看，測試分為2種：黑盒測試和白盒測試。
黑盒測試又稱(chēng)為功能測試或數據驅動(dòng)測試，把系統看成一個(gè)黑盒子，不考慮程序的內在邏輯，只根據需求規格說(shuō)明書(shū)的要求來(lái)檢查程序的功能是否符合它的功能說(shuō)明。
白盒測試又稱(chēng)為結構測試和邏輯驅動(dòng)測試，允許測試人員對程序內部邏輯結構及有關(guān)信息來(lái)設計和選擇測試用例，對程序的邏輯路徑進(jìn)行測試。
測試用例由測試輸入數據以及與之對應的輸出結果組成。測試用例設計的好壞直接決定了測試的效果和結果。
從測試實(shí)際的前后過(guò)程來(lái)看，軟件測試上是由一系列的不同測試所組成，這些軟件測試的步驟分為：?jiǎn)卧獪y試、組裝測試（集成測試）、確認測試和系統測試。軟件開(kāi)發(fā)的過(guò)程是自頂向下的，測試則正好相反，以上這些過(guò)程就是自底向上，逐步集成的。
單元測試（模塊測試）：針對每個(gè)模塊進(jìn)行的測試，可從程序的內部結構出發(fā)設計測試用例，多個(gè)模塊可以平行地對立地測試。通常在編碼階段進(jìn)行，必要的時(shí)候要制作驅動(dòng)模塊和樁模塊。
集成測試：在單元測試的基礎上，將所有模塊按照設計要求組裝成為系統，必須精心計劃，應提交集成測試計劃、集成測試規格說(shuō)明和集成測試分析報告。
確認測試：驗證軟件的功能和性能及其它特性是否與用戶(hù)的要求一致。
系統測試：將軟件放在整個(gè)計算機環(huán)境下，包括軟硬件平臺、某些支持軟件、數據和人員等，在實(shí)際運行環(huán)境下進(jìn)行一系列的測試。
測試工作的文檔主要有：測試計劃、測試模型和用例設計或規格說(shuō)明、測試分析報告等。從軟件工程上說(shuō)，這是屬于軟件配置的一部分。（我不知道，如果什么報告都沒(méi)有，只是不斷地擺弄執行程序，看到錯誤和問(wèn)題就記下來(lái)，算不算真正的測試？）
測試需要一定的技術(shù)和工具
在用例設計過(guò)程中，可以考慮到很多方面，并且也有很多的指導方法和技術(shù)。
黑盒測試用例設計包括：
等價(jià)類(lèi)劃分：劃分等價(jià)類(lèi)--確立測試用例--設計用例
邊界值分析：通過(guò)分析，考慮如何確立邊界情況
錯誤推測法：靠經(jīng)驗和直覺(jué)來(lái)推測程序中可能存在的各種錯誤，從而有針對性地編寫(xiě)用例�？梢粤信e出可能的錯誤和可能發(fā)生錯誤的地方，然后選擇用例。
因果圖：通過(guò)畫(huà)因果圖，在圖上標明約束和限制，轉換成判定表，然后設計測試用例。這適合于檢查程序輸入條件的各種組合情況。
功能圖FD：通過(guò)形式化地表示程序的功能說(shuō)明，并機械地生成功能圖的測試用例。
白盒測試用例設計包括：
1 邏輯覆蓋，以程序內在邏輯結構為基礎的測試，包括以下5種類(lèi)型：
1.1 語(yǔ)句覆蓋：每一條可執行語(yǔ)句至少覆蓋一次；
1.2 判定覆蓋（分支覆蓋）：設計若干個(gè)測試用例，運行所測程序，使程序中每個(gè)判斷的取真分支和取假分支至少執行一次；
1.3 條件覆蓋：設計足夠多的測試用例，運行所測程序，使程序中每個(gè)判斷的每個(gè)條件的每個(gè)可能取值至少執行一次；
1.4 判定-條件覆蓋：設計足夠多的測試用例，運行所測程序，使程序中每個(gè)判斷的每個(gè)條件的所有可能取值至少執行一次，并且每個(gè)可能的判斷結果也至少執行一次；
1.5 條件組合測試：設計足夠多的測試用例，運行所測程序，使程序中每個(gè)判斷的所有可能的條件取值至少執行一次；
1.6 路徑測試：設計足夠多的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。
2 基本路徑測試
在程序控制流圖的基礎上，通過(guò)分析控制構造的環(huán)路復雜性，導出基本可執行路徑集合，從而設計測試用例。包括以下5個(gè)方面：
2.1 程序的控制流圖：描述程序控制流的一種圖示方法。
2.2 程序環(huán)境復雜性：McCabe復雜性度量。從程序的環(huán)路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個(gè)可執行語(yǔ)句至少執行依次所必須的測試用例數目的上界。
2.3 導出測試用例
2.4 準備測試用例，確�；韭窂郊械拿恳粭l路徑的執行
2.5 圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實(shí)現自動(dòng)地確定一個(gè)基本路徑集。
程序的靜態(tài)分析方法：
1 生成各種引用表、靜態(tài)錯誤分析
2 人工測試：桌前檢查、代碼評審等
3 軟件測試工具：包括靜態(tài)分析工具、動(dòng)態(tài)測試工具、測試數據自動(dòng)化生成工具、模塊測試臺、測試合成環(huán)境
3.1 靜態(tài)分析工具：語(yǔ)言程序的預處理器、數據庫工具、錯誤分析器和報告生成器。直接掃描所測試的正文，對程序的數據流和控制流進(jìn)行分析，然后送出測試報告。
3.2 動(dòng)態(tài)測試工具：通過(guò)選擇適當的測試用例，實(shí)際運行所測程序，比較實(shí)際運行結果和預期結果，發(fā)現錯誤。
3.3 測試數據自動(dòng)化生成工具：包括路徑測試數據生成程序、隨機測試數據生成程序以及根據數據規格說(shuō)明生成測試數據
3.4 模塊測試臺是一種專(zhuān)門(mén)的測試用例描述語(yǔ)言，負責將輸入數據傳送到所測試模塊中，然后將實(shí)際輸出結果與在描述測試用例的語(yǔ)言中所表述的期望結果進(jìn)行比較，發(fā)現錯誤。另外，也包括其它的功能：語(yǔ)句跟蹤、動(dòng)態(tài)斷句、覆蓋度量、用戶(hù)自定義符號表、內容表和輸出格式。
3.5 測試合成環(huán)境：包括環(huán)境模擬程序，代碼檢查程序，測試文檔生成程序，測試執行嚴整程序，輸出比較程序，程序正確性證明程序等，以及各種調試工具。而且還有集成系統，集成了多種工具，如SADAT、Microsoft Test for Windows和PureArtria等。
***********************************************************
測試的管理
作為項目或產(chǎn)品開(kāi)發(fā)的一個(gè)必要的組成部分，需要良好的組織和管理。使用軟件質(zhì)量規范，編寫(xiě)和實(shí)現測試用例和模型，可以有效地組織測試。
一般的測試工作過(guò)程也可以是：計劃-->配置（必要的軟硬件資源下）-->開(kāi)發(fā)（構造或配置測試工具、創(chuàng )建測試套件和測試方案庫、準備適當的報告工具并記錄測試系統如何運轉）-->測試執行（進(jìn)行測試、記錄測試條件和問(wèn)題，報告結果）。
測試管理也可以從測試經(jīng)理和測試小組2個(gè)方面去看：
測試經(jīng)理要管理好團隊，很多人認為測試是枯燥乏味的事情，而且似乎低級的事情，所以測試經(jīng)理應該不斷地激勵小組成員，為他們爭取利益。在時(shí)間進(jìn)度上保證穩步前進(jìn)。就象賽跑，一開(kāi)始就加班加點(diǎn)，只會(huì )導致極限的過(guò)早到來(lái)。
作為測試經(jīng)理，應該有足夠的質(zhì)量意識。評價(jià)質(zhì)量風(fēng)險的方法是“失敗模式和效果分析”(Failure Mode and Effect Analysis, FMEA)。這種方法可以允許您在特定的質(zhì)量風(fēng)險和結果上映射需求、規范，以及項目小組假設。然后，按照風(fēng)險級別進(jìn)行分類(lèi)，并按序排列。
實(shí)際上如果能得到充分的資源已是很困難的了，能用好臨時(shí)的測試人員也已經(jīng)不錯了。一般企業(yè)的主管和技術(shù)經(jīng)理都并不怎么真正重視測試工作的意義和價(jià)值。也許他們認為臨時(shí)的投入一次性的強力測試足以發(fā)現絕大部分問(wèn)題，而實(shí)際上這對產(chǎn)品的長(cháng)遠發(fā)展，以及質(zhì)量改進(jìn)都沒(méi)有太大好處。
測試過(guò)程中軟件功能可能進(jìn)行調整和變化，測試發(fā)現問(wèn)題也會(huì )導致變化，需要重新的測試。對這些變更也需要進(jìn)行管理。
另外，由于上層管理部門(mén)的不重視，必須想辦法與之進(jìn)行清楚而有效的溝通；同開(kāi)發(fā)部門(mén)的溝通也非常重要，因為開(kāi)發(fā)和測試在性質(zhì)上是有些對立的，很容易在相互之間產(chǎn)生一些不必要的矛盾。和開(kāi)發(fā)部門(mén)不同的是，一般質(zhì)量或測試部門(mén)和市場(chǎng)或銷(xiāo)售部門(mén)的立場(chǎng)倒是比較一致的，如果雙方都認為高質(zhì)量的產(chǎn)品是市場(chǎng)戰略中重要的品牌戰略，徹底的測試對于達到這樣的目標來(lái)說(shuō)意義重大。因此，有必要和市場(chǎng)部門(mén)保持協(xié)作和交流。
測試經(jīng)理可以經(jīng)常問(wèn)自己一些問(wèn)題：
計劃做哪些測試？實(shí)際完成了哪些測試？使用了多少用例？其中多少沒(méi)有通過(guò)？管理部門(mén)是否有足夠的支持？他們是否向你要過(guò)測試報告？開(kāi)發(fā)部門(mén)的聯(lián)絡(luò )是否及時(shí)？等等。如果你是測試管理人員，應該可以想到更多的問(wèn)題。
測試小組：
測試小組有多大的規模，一般取決于項目規模、測試人員與開(kāi)發(fā)人員的比例、項目經(jīng)理對質(zhì)量保證的認識和期望等，也取決于你的準確的測試計劃。
對一些項目來(lái)說(shuō)，最好是在開(kāi)始階段就有測試人員有所介入。
如本文一開(kāi)始所提到的，在測試小組中測試人員必須具備的素質(zhì)包括：有效的坦率真誠的交流的能力、清晰簡(jiǎn)明的表達能力、一定的好奇心（但不至于太強，以至于花太多精力去探究一個(gè)微小的問(wèn)題），不應害怕提出尖銳問(wèn)題引起麻煩，一定的責任心，
注意力能夠高度集中，是職業(yè)悲觀(guān)主義者（但不是抱怨和憎惡）。
以下是一些測試的方法和基本工具：
測試方案、測試模型和測試用例
測試就象是做實(shí)驗一樣，實(shí)驗對于象我這樣的理工科畢業(yè)生來(lái)說(shuō)真是太熟悉不過(guò)了。做實(shí)驗之前必然有實(shí)驗的方案、內容和步驟，測試似乎也是同樣的。另外，基于測試用例的測試和常見(jiàn)的隨機性的測來(lái)測去也是完全不同的，盡管習慣于隨機性測試的人，如果注意力集中的話(huà)，他的頭腦里也是有一些測試用例的。
關(guān)于測試實(shí)驗室，進(jìn)行測試工作首先要爭取到盡可能好的環(huán)境。如果可能，應該建立測試實(shí)驗室，實(shí)驗室包括必要的裝備、工具軟件（包括測試工具）和各種操作系統平臺，保持實(shí)驗室的實(shí)用、整潔，避免他人干擾甚至破壞測試環(huán)境。
關(guān)于測試跟蹤軟件，制作一個(gè)簡(jiǎn)單的測試問(wèn)題跟蹤軟件，記錄測試的結果，將測試發(fā)現的問(wèn)題分類(lèi)，并對測試發(fā)現的問(wèn)題和模塊、開(kāi)發(fā)人員進(jìn)行關(guān)聯(lián)，有助于分析問(wèn)題，并可有效記錄測試的結果，形成測試報告，并從中找出一些規律性的東西來(lái)。因此測試問(wèn)題跟蹤軟件還是有一定的價(jià)值的。
關(guān)于測試自動(dòng)化，有一定的風(fēng)險。對一個(gè)穩定的系統，甚至可以自己開(kāi)發(fā)自動(dòng)化軟件，而對于正處于快速變形中的軟件開(kāi)發(fā)過(guò)程，接口、主要功能和支持環(huán)境在發(fā)展變化中。為測試配置環(huán)境也要付出很多的時(shí)間。
以下是關(guān)于測試的一些技巧和經(jīng)驗：
在制定測試計劃的時(shí)候，就要考慮到測試的風(fēng)險，并抉擇要執行哪些測試，并放棄哪些測試；測試計劃的評審應該讓開(kāi)發(fā)人員參與；
測試模型的制作應該盡可能貼近用戶(hù)，或者站在用戶(hù)的使用立場(chǎng)上來(lái)觀(guān)測軟件，此時(shí)應該能發(fā)現更多的問(wèn)題。
由于測試發(fā)現問(wèn)題，在解決問(wèn)題后還要重新測試，因此測試的時(shí)間可能會(huì )比實(shí)際更長(cháng)一些
識別和注意少數重要的方面，而忽略多數次要的方面，有時(shí)候少數的問(wèn)題足以致命，這些問(wèn)題將是軟件測試結果中重要性最高的錯誤。
錯誤的定位有時(shí)是很難的，要找出必然發(fā)生的前因后果，而不至于因為描述錯誤而誤導開(kāi)發(fā)人員。有時(shí)候確實(shí)存在錯誤不能重建的問(wèn)題。解決辦法之一是在錯誤報告中給予說(shuō)明。
對錯誤的描述，應該是準確、完整而簡(jiǎn)練。因為描述的問(wèn)題或者不完整的描述會(huì )引起開(kāi)發(fā)人員的誤解，其后果是可以想見(jiàn)的。
有時(shí)有經(jīng)驗的測試人員憑借直覺(jué)就可以發(fā)現一些問(wèn)題，這可稱(chēng)為“錯誤猜測”。
測試人員容易犯2種錯誤：一是測試人員發(fā)生判斷錯誤，將本沒(méi)有錯誤的系統行為報告為錯誤，或者將錯誤指定了過(guò)高的嚴重級別，或者過(guò)高估計了問(wèn)題的嚴重性，這樣會(huì )引起開(kāi)發(fā)人員的不信任，產(chǎn)生一種象“狼來(lái)了”一樣的效果；二是測試人員將錯誤的嚴重性或優(yōu)先級定得過(guò)低，從而產(chǎn)生“測試逃逸”，這樣會(huì )造成產(chǎn)品質(zhì)量的風(fēng)險。以上兩種錯誤應該盡量避免。
最后，我忽然想，測試實(shí)際上可以覆蓋到硬件，甚至非計算機產(chǎn)品的測試，也許可以相互借鑒。
還有一種很奇特的感想，這種感想使我反而有些困惑不清了。我發(fā)現對測試來(lái)說(shuō)，理論和實(shí)踐的距離好象非常遙遠，我先看了一本軟件工程的書(shū)，然后寫(xiě)下了前面的一半內容，然后我又匆匆翻看了一本美國人的書(shū)，叫做《測試流程管理》，然后整理出了本文后一半的內容，該書(shū)中有著(zhù)比本文多得多的各方面的實(shí)踐經(jīng)驗。歌德說(shuō)過(guò)，理論是蒼白的，生命之樹(shù)常青。我稍稍改變一下，就變成了：理論是蒼白的，實(shí)踐之樹(shù)常青。也許測試是一種實(shí)踐性很強的工作，大學(xué)教授們一般也不可能熱衷于參加測試工作吧。
延伸閱讀
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/