實用軟件工程課件

1、實用軟件工程寧夏大學數(shù)學計算機學院趙國棟第9章 軟件測試本章導讀 隨著中國IT行業(yè)的發(fā)展，軟件產(chǎn)品的測試和質量保證工作逐漸成為企業(yè)生存與發(fā)展的關鍵。每個IT企業(yè)的產(chǎn)品在發(fā)布前，都需要進行大量的測試工作。 本章首先論述軟件測試的理論基礎。接下來講解軟件測試流程和測試技術。最后介紹軟件測試文檔、軟件測試案例和測試員職業(yè)素質培養(yǎng)。 要求了解 (1) 軟件測試的發(fā)展歷史 (2) 目前國內(nèi)外軟件測試現(xiàn)狀 (3) 軟件測試分類 (4) 軟件測試工具 要求理解 (1) 軟件測試的作用 (2) 軟件質量定義和相關測試標準 (3) 軟件測試原則 要求掌握 (1) 軟件測試的定義 (2) 軟件測試的目的和目標 (

2、3) 軟件測試模型 (4) 軟件測試文檔 9.1 軟件測試概論 軟件測試的輸入是測試計劃、用戶需求報告/需求規(guī)格說明書，輸出是測試報告?；蛘哒f，軟件測試輸入的是測試用例（數(shù)據(jù)），輸出的是測試報告（或Bug報告）。 根據(jù)“五個面向理論”，軟件測試的主要方法是“面向功能測試”。 測試的目的是為了發(fā)現(xiàn)測試對象的問題，而不是證明測試對象沒有問題。 軟件測試技術還不成熟，還大有搞頭！測試對象的“問題”分為哪幾種？ (1) 缺陷。這是輕量級的問題，因為它并不影響系統(tǒng)的正常運行，只是有點美中不足。例如：多了或少了某些次要的功能。有缺陷的產(chǎn)品可降級使用； (2) 錯誤。這是次重量級的問題，因為它影響系統(tǒng)的正常

3、運行，使系統(tǒng)在運行中出現(xiàn)錯誤，但這些錯誤還不是致命性的。有錯誤的產(chǎn)品不能使用； (3) 嚴重錯誤。這是最重量級的問題，因為它不但影響系統(tǒng)的正常運行，而且使系統(tǒng)在運行中出現(xiàn)致命性的錯誤。例如造成系統(tǒng)的死鎖、生命危險或系統(tǒng)崩潰。 有嚴重錯誤的產(chǎn)品絕對不能使用。測試可以提高軟件的質量嗎？ 軟件公司一般都有自己的測試中心或測試部門，他們的職責和作用是什么呢？讀者可能會不加思索地回答：“測試可以提高軟件產(chǎn)品的質量！” 我們說：“回答錯了”，為什么？因為測試只能發(fā)現(xiàn)軟件產(chǎn)品的“不符合項”或錯誤(Bug)，不能改正軟件產(chǎn)品的錯誤，所以不能直接提高軟件產(chǎn)品的質量。這個問題就是軟件測試的作用。 優(yōu)秀的測試團隊可

4、在早期發(fā)現(xiàn)錯誤，使軟件維護的費用降到最低點。 用戶需求(需求規(guī)格)是測試的基準 軟件測試可分為系統(tǒng)軟件測試和應用軟件測試： (1) 系統(tǒng)軟件測試主要是為了發(fā)現(xiàn)Bug，測試報告為“Bug測試報告”。 (2) 應用軟件測試主要是為了發(fā)現(xiàn)“不符合項”，測試報告為“軟件的需求規(guī)格測試報告”。 不管是為客戶定制軟件項目還是開發(fā)通用軟件產(chǎn)品，都是為了滿足客戶的需求。若通過Beta測試滿足了功能、性能和接口的需求，就可以向客戶交付產(chǎn)品，客戶按合同付清全部款項。9.2 軟件測試理論基礎9.2.1 什么是軟件測試 1. 什么是測試 測試的英文單詞為test，即檢驗或考試之意。 【定義9-1】所謂測試，就是通過一

5、定的方法或工具，對被測試對象進行檢驗或考試，以發(fā)現(xiàn)被測試對象具有某種屬性或者存在某些問題的過程。 什么是測試(續(xù)) 【例9-2】要初步測試一個人的智力是否存在嚴重障礙，可以出如下測試題目：12？22？ 如果他的回答全部正確，就可以初步斷定不是智力嚴重障礙，反之可能是智力嚴重障礙。 上述參加測試的人就是被測試的對象；出算術題就是測試方法；“12？”就是測試用例；請他們回答問題和參與測驗的過程就是測試過程；將測試過程得出的結果和我們預期的結果相比較，就能得出測試結論；將測試結論進行分析就可以產(chǎn)生測試報告。2. 什么是軟件測試 軟件測試是測試中的特例，它的測試對象是人類的智力產(chǎn)品-軟件。 【定義9-

6、2】軟件測試是發(fā)現(xiàn)軟件錯誤的過程. 為了深入理解軟件測試的定義，請從下面幾個角度來思考： (1) 從軟件測試的目的來理解。測試的目的是發(fā)現(xiàn)軟件中的錯誤，是為了證明軟件有錯，而不是證明軟件無錯，是在軟件投入運行前，對軟件需求分析、設計和編碼各階段產(chǎn)品的最終檢查，是為了保證軟件開發(fā)產(chǎn)品的正確性、完全性和一致性。 請從下面幾個角度來思考： (2) 從軟件測試的性質來理解。在軟件開發(fā)過程中，分析、設計與編碼等工作都是“建設性的”，惟獨測試是帶有“破壞性的”。 (3) 從軟件開發(fā)角度來理解。軟件測試以檢查軟件產(chǎn)品的內(nèi)容和功能特性為核心，是軟件質量保證的關鍵步驟, 也是成功實現(xiàn)軟件開發(fā)目標的重要保障。 (

7、4) 從軟件工程角度來理解。軟件測試是軟件工程的一部分，是軟件工程過程中的重要階段。 (5) 從軟件質量保證角度來理解。軟件測試是軟件質量保障的關鍵措施。9.2.2 為什么要進行軟件測試1. 軟件質量問題迫在眉睫 軟件發(fā)展史上因為測試不充分，導致嚴重軟件問題： 1991年，美國愛國者導彈防御系統(tǒng)多次在防御戰(zhàn)爭中失利； 1994年，迪斯尼獅子王游戲在一些PC機上不能運行； 1994年，Intel奔騰浮點除法錯誤事件； 1995年，千年蟲問題； 1999年，美國航天局火星失蹤事件 。 歸根到底一句話：軟件質量問題迫在眉睫。 軟件質量問題，能否提前發(fā)現(xiàn)？能！方法就是測試。2. 加強測試是提高質量的有

8、效辦法 客戶對投放市場的軟件產(chǎn)品質量不滿意，從測試角度考慮原因有兩種可能： (1) 一是軟件開發(fā)商采用了非正規(guī)的測試方法和測試過程，對軟件進行測試，或者根本就沒有按照正規(guī)要求進行軟件測試。 (2) 二是軟件開發(fā)商按照現(xiàn)有的正規(guī)做法，對軟件進行了測試，但是，軟件質量仍不能達到客戶的滿意度，這說明現(xiàn)有的軟件測試標準、方法和過程有待改進。 (3) 軟件的缺陷難以根除，但軟件的質量是可以改進的。加強軟件測試是控制和提高軟件質量的一個行之有效的辦法。 9.2.2 軟件測試發(fā)展歷史 在中國的IT企業(yè)，20世紀90年代，軟件公司基本上沒有獨立的軟件測試人員，測試工作都由程序員自己完成。到了20世紀末、21世

9、紀初，獨立的軟件測試部門才開始誕生。 根據(jù)有關職位統(tǒng)計資料顯示，在國外大多數(shù)軟件公司，1個軟件開發(fā)工程師就需要輔有2個軟件測試工程師。 而國內(nèi)目前的平均比例卻是8：1，在這種比例懸殊的情況下，很難通過測試提高軟件質量。隨著我國軟件產(chǎn)業(yè)化的進程，一些企業(yè)內(nèi)部的獨立測試部門，一些第三方測試機構將逐漸發(fā)展壯大，軟件測試將成為比軟件編程更具挑戰(zhàn)性和創(chuàng)造性的職業(yè)。軟件測試發(fā)展歷史(續(xù)) 軟件測試人員分為測試執(zhí)行人員、測試設計人員、測試開發(fā)人員三種角色，我們可以統(tǒng)稱為軟件測試工程師： (1) 測試設計人員制定測試方案； (2) 測試執(zhí)行人員按照測試方案對產(chǎn)品進行測試，并給出測試報告或者質量評測結果； (3

10、) 測試開發(fā)人員編寫測試工具，實現(xiàn)測試工作自動化。 目前，在企業(yè)內(nèi)部，具有四年以上測試經(jīng)驗的軟件測試工程師就可處于“雙高”地位，即地位高、待遇高，有的人月薪可高達8000元。9.2.3 軟件測試目的和目標 軟件測試的目的是什么？就是盡可能早的發(fā)現(xiàn)軟件問題。這里的問題，包括Bug和不符合項。 那么，什么是軟件問題？符合下列五個規(guī)則中的一個，就是軟件問題： (1) 軟件未達到產(chǎn)品說明書（需求報告或需求說明書）標明的功能； (2)軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤； (3)軟件未達到產(chǎn)品說明書未指明但應達到的目標； (4)軟件功能超出產(chǎn)品說明書所指明范圍； (5)軟件測試人員認為軟件難以理解、不

11、易使用、速度緩慢，或者最終客戶認為不好。軟件問題的生命周期 9.2.4 軟件測試原則1. 盡早開展測試工作2. 完全測試不可能，把握最優(yōu)測試量3. 嚴防寄生蟲現(xiàn)象4. 嚴防殺蟲劑現(xiàn)象 5. 并非所有的軟件缺陷都能修復6. 難以說清的軟件缺陷7. 產(chǎn)品說明書不斷變化8. 軟件測試人員在產(chǎn)品小組中不受歡迎 1. 盡早開展測試工作 需求分析時，就要按需求文檔來開展測試準備工作。怎么準備？ (1) 首先要理解用戶需求，然后分析軟件需求定義是否具有可測性，最后把軟件開發(fā)需求轉換（分解）為軟件測試需求。 (2) 針對測試需求，復用或者重新設計與編寫測試用例，定義測試策略。 2. 完全測試不可能，把握最優(yōu)測

12、試量 由于時間、人員、設備和資金等條件的限制，導致完全測試不可能。因此，軟件產(chǎn)品的測試和發(fā)布工作是永遠存在矛盾： (1) 時間有限：各個領域的軟件產(chǎn)品，都有多家開發(fā)商，面對這樣的買方市場，誰先發(fā)布產(chǎn)品誰就可能先搶占大部分市場，所以要提前發(fā)布。 (2) 人員有限：更換或者新聘用人員時，無疑會增加軟件的開發(fā)成本，甚至火上加油。 3. 嚴防寄生蟲現(xiàn)象 軟件問題會像寄生蟲一樣過群居生活： (1) 在一個開發(fā)人員提交的代碼中發(fā)現(xiàn)了一個問題，提交故障單后，應在該程序員提交的其他代碼中（如果此程序員負責幾個開發(fā)模塊的話），驗證一下是否有類似的問題的寄生。 (2)寄生蟲與程序員的脾氣秉性和心情好壞成正比。作為

13、測試人員都要洞察這些潛在的因素，保證盡可能多的發(fā)現(xiàn)寄生蟲群居現(xiàn)象。 4. 嚴防殺蟲劑現(xiàn)象 長時期使用一種藥物，病毒就會產(chǎn)生抗藥性， 這就是殺蟲劑現(xiàn)象。在測試中的表現(xiàn)為： (1) 測試工作開展一段時間后，會出現(xiàn)找不到問題的現(xiàn)象，那么是真的沒有問題了嗎？不是，而是出了殺蟲劑現(xiàn)象。即：測試方法和思路需要更新了，因為一種思路下的大部分問題可能已經(jīng)被發(fā)現(xiàn)了。 (2) 換一個測試執(zhí)行人員或者換一個測試設計人員，即：換一種殺蟲劑，問題就會再次出現(xiàn)。所以產(chǎn)品在進行回歸測試的時候，最好要更換部分測試人員，避免殺蟲劑現(xiàn)象。 5. 并非所有的軟件缺陷都能修復 由于各種客觀條件的限制，軟件缺陷被發(fā)現(xiàn)后，不能都被修復，

14、或者開發(fā)人員不認同是軟件缺陷，認為不值得修復。碰到這種情況怎么辦呢？這就需要分析： (1) 什么樣的缺陷客戶可以忍受？ (2) 什么樣的缺陷可以延遲到發(fā)布之后去打補丁？6. 難以說清的軟件缺陷 軟件測試的復雜性，很大一部分原因是由于標準不明確和不統(tǒng)一，表現(xiàn)在： (1) 測試人員判斷一個缺陷，是以產(chǎn)品說明書（需求說明書）為標準，而產(chǎn)品說明書的需求是要分解成為測試需求后，才能作為測試工作判斷缺陷的標準的，這個轉化過程會有人為理解因素，需要經(jīng)過開發(fā)和測試人員確認后，方可實行。 (2) 最壞的情況是，測試工作開展后，產(chǎn)品說明書還沒有以書面形式定稿，那么測試工作的難度又加大了。7. 產(chǎn)品說明書不斷變化

15、有了書面形式的產(chǎn)品說明書，測試工作可以正常開展，但是不要期望產(chǎn)品說明書是不變的，不變是軟件工程追求的目標，但實際工作中都會有所變化，變動或大或小，這要看需求分析階段的工作質量。 為了應對這種變化，測試計劃應留有一定的應變時間，這是測試經(jīng)理主要負責的工作，但是作為測試人員也要有心理準備，即：測試工作中也要貫徹二八定律。8. 軟件測試人員不受歡迎 挑毛病的人是不受歡迎的，怎么辦呢？ (1) 測試人員要在工作中積累經(jīng)驗，善于溝通，講究提缺陷的技巧。例如，盡早找出軟件缺陷，使改動和影響范圍更小，降低開發(fā)人員修復缺陷的工作量；控制情緒，不要帶有輕視、嘲笑的感情色彩報告軟件缺陷； (2) 不要總是報告壞消

16、息，還要在溝通中對開發(fā)人員代碼質量的提高給予肯定和夸獎，在報告壞消息前，先要報告好消息。9.2.5 軟件測試模型 軟件測試最典型的測試模型是V模型，另外還有X模型、H模型、前置模型和測試驅動模型等等。模型是理論研究的成果，可以指導實際工作，但是不能完全照搬。 V模型左側是開發(fā)階段，右側是測試階段。開發(fā)階段先從定義軟件需求開始，然后要把這些需求不斷地轉換到概要設計和詳細設計中去，最后形成程序代碼。測試階段是在代碼編寫完成以后，先作單元測試開始，然后是集成測試、系統(tǒng)測試和驗收測試。 軟件測試V模型X測試模型 V模型的功勞是：提高了測試工作和測試人員的地位。 因為V模型也沒能體現(xiàn)出測試設計、測試回溯

17、的過程，基于這種思想，出現(xiàn)了X測試模型。 同學們也可提出其他測試模，例如O模型，它可以表達回歸測試的思想。X測試模型 X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執(zhí)行的程序。 X模型右上方還定位了已通過集成測試的成品可以進行封版并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。 X模型右下方還定位了探索性測試。這是不進行事先計劃的特殊類型的測試，這一方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤。軟件測試模型(續(xù)) 不管按照什么模型進行軟件測試，根據(jù)“五個面向”的實施理

18、論，在本質上說，所有的測試都是面向功能的，即測試軟件產(chǎn)品是否滿足客戶的功能需求，這里的功能需求是廣義的，它包括功能、性能、接口和界面等需求。 白盒測試如此，黑盒測試更如此。靜態(tài)測試如此，動態(tài)測試更如此。單元測試如此，集成測試更如此。系統(tǒng)測試如此，驗收測試更如此！9.2.6 軟件測試的分類 1靜態(tài)測試：不通過運行程序來開展測試工作。這里并不局限于直接閱讀、檢測代碼，還包括閱讀和檢測文檔。 2動態(tài)測試：通過運行程序開展測試工作，即軟件測試人員通過使用軟件來找出問題，它包括白盒測試與黑盒測試。 3. 白盒測試：基于程序執(zhí)行路徑的測試。 4黑盒測試：又叫功能測試。盒子指的是被測試的軟件，“黑盒”就是只

19、知道被測軟件的外部情況，被測軟件的內(nèi)部邏輯結構和數(shù)據(jù)結構，對測試人員是不可見的。這是基于規(guī)格說明書的測試。黑盒測試 因為測試建立在模塊間的接口上，所以多采用黑盒測試，適當輔以白盒測試，以便能對主要的控制路徑進行測試。 黑盒測試主要檢查以下錯誤： (1) 功能不正確或者被遺漏; (2) 界面錯誤; (3) 數(shù)據(jù)結構或者外部數(shù)據(jù)庫訪問錯誤; (4) 性能錯誤; (5) 初始化或者終止錯誤.幾種黑盒測試技術(1) 等價分類法 定義：把程序的輸入數(shù)據(jù)集合, 按輸入條件劃分為若干個等價類，每一等價類的一個代表值在測試中的作用，等價于這一類的其他值的測試。 優(yōu)點：減少測試工作量。 (1). 等價分類法(續(xù)

20、) 1). 等價類的劃分方法： 根據(jù)輸入條件，把輸入數(shù)據(jù)劃分為等價類，并定義有效等價類，無效等價類。 例1：如果輸入值的范圍 是從 1到 999 ，則： 1=有效等價類=999，兩個無效等價類為小于 1和大于999。例2：如果一個輸入條件說明標識符的第一個字符必須是字母，則可劃分一個有效等價類(第一字符是字母)，和一個無效等價類(第一字符不是字母)。(2). 邊界值分析法 邊界值分析方法是對等價類劃分方法的補充。 1）.如果輸入條件規(guī)定了值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù). 2）.如果輸入條件規(guī)定了值的個數(shù),則用最大個數(shù),最小個數(shù),比最小個數(shù)

21、少1,比最大個數(shù)多1的數(shù)作為測試數(shù)據(jù). 3）.如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最后一個元素作為測試用例. 4）.如果程序中使用了一個內(nèi)部數(shù)據(jù)結構,則應當選擇這個內(nèi)部數(shù)據(jù)結構的邊界上的值作為測試用例. 5）.分析規(guī)格說明, 找出其它可能的邊界條件. (3).因果圖法 借助因果圖，列出輸入數(shù)據(jù)的各種組合與程序對應動作效果之間的階段聯(lián)系，構造判定表，由此設計測試用例。 因果圖生成測試用例的步驟如下： 1).分析設計規(guī)格說明中的原因（輸入條件或者輸入條件等價類）、效果（輸出可能性），對每個原因效果進行編號； 2).找出原因/效果之間的對應關系，畫出因果圖；

22、3).將因果圖轉換為判定表； 4).對判定表中每一列生成測試用例。因果圖法(續(xù)) 舉例：中國象棋中馬的走法以中國象棋中馬的走法為例子，具體說明：1、如果落點在棋盤外，則不移動棋子； 2、如果落點與起點不構成日字型，則不移動棋子； 3、如果落點處有自己方棋子，則不移動棋子； 4、如果在落點方向的鄰近交叉點有棋子（絆馬腿），則不移動棋子； 5、如果不屬于1-4條，且落點處無棋子，則移動棋子； 6、如果不屬于1-4條，且落點處為對方棋子 (非老將) ，則移動棋子并除去對方棋子； 7 、如果不屬于1-4條，且落點處為對方老將，則移動棋子，并提示戰(zhàn)勝對方，游戲結束。 (4).錯誤推測法 錯誤推測法基于經(jīng)

23、驗和直覺，推測程序中所有可能存在的各種錯誤,從而有針對性的設計測試用例。 例如，如輸入數(shù)據(jù)為0，或輸出數(shù)據(jù)為0是容易發(fā)生錯誤的情形，因此可選擇輸入數(shù)據(jù)為0，或使輸出數(shù)據(jù)為0的例子作為測試用例。 又如，輸入表格為空或輸入表格只有一行，也是容易發(fā)生錯誤的情況。可選擇表示這種情況的例子作為測試用例。 再如，若兩個模塊間有共享變量，則要設計測試用例檢查：當讓一個模塊去修改這個共享變量的內(nèi)容后，另一個模塊的出錯情況等等 。白盒測試技術 可以理解為基于代碼的或程序執(zhí)行路徑的測試。 白盒測試還有多種叫法，如： 玻璃盒測試（Glass Box Testing） 透明盒測試（Clear Box Testing）

24、 開放盒測試（Open Box Testing） 基于代碼的測試（Code-Based Testing） 邏輯驅動測試（Logic-Driver Testing）。 測試人員進行白盒測試之前，必須清楚軟件的內(nèi)部邏輯結構和執(zhí)行路徑，然后根據(jù)它們展開測試的。白盒測試技術(續(xù)) 白盒測試原則： a. 保證模塊中每一個獨立的路徑至少執(zhí)行一次。 b. 保證所有判斷的每一個分支至少執(zhí)行一次。 c. 保證每一個循環(huán)都在邊界條件和一般條件下至少執(zhí)行一次。 d. 驗證所有內(nèi)部數(shù)據(jù)結構的有效性。 白盒測試技術： (1)邏輯覆蓋測試 它以程序的內(nèi)部邏輯結構為基礎, 設計如下測試用例： a. 語句覆蓋 b. 判定覆蓋

25、 c. 條件覆蓋 d. 判定-條件覆蓋 e. 條件組合覆蓋等白盒測試技術(續(xù))(2)循環(huán)測試 注重循環(huán)結構的有效性。存在三種循環(huán)測試 a. 簡單循環(huán)測試。 b. 嵌套循環(huán)測試。 c. 串接循環(huán)測試。(3) 基本路徑測試 基本思想是：以軟件過程性描述為基礎，通過分析它的控制流程計算復雜度，導出基本路徑集合，并設計一組測試用例，確保程序中的每個語句至少執(zhí)行一次，每條路徑都通過一次。 【例9-3】假設一個程序需要3個整數(shù)型的輸入數(shù)據(jù)，計算機的字長為16位，則每個整數(shù)可能取值的個數(shù)有216。3個輸入數(shù)據(jù)的排列組合數(shù)為216216216個，216216216310 14 這就是說，這個程序執(zhí)行的次數(shù)達到

26、了310 14 ，才能做到有窮測試。如果程序每執(zhí)行1次需要1毫秒，那么也需要運行10 000年時間。若將無效的和錯誤的數(shù)據(jù)輸入也計算在內(nèi)，則程序的運行時間還要長。一萬年太久，誰受得了這種測試！ 那么，對于這種程序，到底該怎么測試呢？比較好的辦法是以靜態(tài)代碼測試為主，即用“順序、選擇(if-then-else)、循環(huán)(do-while或do-until)”3種基本結構，一行一行地分析測試其源程序，因為靜態(tài)代碼測試能發(fā)現(xiàn)約60%的錯誤。與此同時，以白盒子測試為輔，選擇幾條典型的程序路徑進行測試。 白盒測試技術(續(xù))白盒測試的優(yōu)點是： 迫使測試人員去仔細思考軟件的實現(xiàn)。 可以檢測代碼中的每條分支和路

27、徑。 揭示隱藏在代碼中的錯誤。 對代碼的測試比較徹底。白盒測試的缺點是： 無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤。 不驗證規(guī)格的正確性。灰盒測試 在白盒測試中交叉使用黑盒測試的方法；在黑盒測試中交叉使用白盒測試的方法。灰盒測試就是這類介于白盒測試和黑盒測試之間的測試。 宏觀上用黑盒子測試，微觀上用白盒子測試，測試員用黑盒子測試，程序員用白盒子測試，這就是常用的測試方法。 通過測試 簡單說就是驗證軟件至少能做什么，而不會考驗其能力有多強。把握這個思想，設計通過測試的測試案例時，就是設計最通常的數(shù)據(jù)，能證明其正確實現(xiàn)了某個功能就可以，不用挖空心思給出破壞性數(shù)據(jù)。失敗測試 純粹是為了驗證軟件在某一

28、條件下，是否會出現(xiàn)異常、停止工作等現(xiàn)象而進行的測試。所以做失敗測試時，設計的測試用例叫做失敗測試用例，執(zhí)行失敗測試用例的過程，叫做失敗測試或者叫做迫使出錯測試。進行失敗測試的指導思想，是找出軟件薄弱環(huán)節(jié)，蓄意攻擊（病毒程序就是比較好的失敗測試用例?。?。負載/壓力測試 一方面，可以通過減少軟件需要的資源（內(nèi)存、磁盤空間、網(wǎng)絡資源等），來測試出軟件運行的最低配置或最低資源需求；另一方面，可以正常提供軟件需要的資源，但是通過不斷加重軟件要處理的任務，來測試軟件在正常配置下能夠具有的能力指標。 在軟件測試V模型中，按照測試過程又可以分出單元測試、集成測試、系統(tǒng)測試和驗收測試四種測試類型。易用性測試 易

29、用性涉及的范圍也比較廣，例如安裝易用性、功能易用性、界面易用性，甚至是針對聽力、視覺、運動和認知有缺陷的客戶，軟件體現(xiàn)出的易用性等等。邊界值測試 專門針對軟件需要從外界（客戶、接口程序）獲取數(shù)據(jù)的地方，提供數(shù)據(jù)的邊界值，驗證程序是否對邊界值進行正確或合理的處理。 兼容性測試 可以測試軟件與軟件之間的兼容性。例如軟件與操作系統(tǒng)、數(shù)據(jù)庫、中間件、瀏覽器和其他支撐軟件的兼容性，同一軟件不同版本之間的兼容性，同一類軟件對不同數(shù)據(jù)格式的兼容性等等。 還可以測試軟件與硬件之間的兼容性。例如軟件與CPU、主版、顯卡、聲卡等硬件的兼容性。進行兼容性測試時，需要對軟硬件環(huán)境有一個規(guī)劃，是購買軟硬件建立測試實驗室

30、，還是臨時租用。如果選擇成立專門測試實驗室，那么對實驗環(huán)境的規(guī)劃、維護、分配和管理也很重要?；貧w測試 在軟件發(fā)生修改之后，重新執(zhí)行原有已經(jīng)執(zhí)行過的測試用例，以保證修改的正確性，為此目的開展的測試工作稱為回歸測試。 理論上，任何時候更改軟件后，都可以進行回歸測試，驗證以前發(fā)現(xiàn)和修復的錯誤是否在新軟件版本上再現(xiàn)，但是實際測試過程中，只有軟件版本相對穩(wěn)定后，執(zhí)行回歸測試的可行性和效率才最高。Alpha測試 有開發(fā)人員或者測試人員在場，客戶在開發(fā)環(huán)境下使用軟件，也稱為受控測試。實際工作中，客戶也可以由公司內(nèi)部的員工充當，但不能由程序員或者測試人員。進行Alpha測試，主要是保證軟件發(fā)布之前，從客戶（非

31、軟件專業(yè)人員）的角度再試圖發(fā)現(xiàn)一些潛在的bug。Beta測試 所謂Beta測試，就是將軟件的Beta版本交給大量典型客戶，由他們從客戶的角度出發(fā)，在實際環(huán)境中使用軟件（沒有開發(fā)人員和測試人員做指導）。軟件開發(fā)商搜集客戶的反饋信息后，對Beta版本進行改進，改進后再由測試部門進行回歸測試，通過后對外發(fā)布正式版本。集成測試 集成測試是組裝軟件的系統(tǒng)測試技術，按設計要求,把通過單元測試的各個模塊組裝在一起之后, 進行綜合測試, 以便發(fā)現(xiàn)與模塊接口有關的各種錯誤。 集成測試的方法可以分為： A. 非增量式系統(tǒng)集成。 B. 增量式系統(tǒng)集成。即一個個模塊逐步接入系統(tǒng)并進行測試，也就是模塊一邊接入系統(tǒng)一邊測

32、試，使系統(tǒng)逐步擴大最后得到一個完整的系統(tǒng)。 可以采用AB兩種方法的結合。9.2.7 軟件質量定義與軟件測試標準 國標GB/T 6583-ISO8404文件在質量管理與質量保證術語中對質量的定義是“反映實體滿足明確的和隱含的需要的能力的特性的總和”。 國標GB/T 18905-ISO 14598文件在軟件工程產(chǎn)品評價中，質量定義為“實體特性的總和，滿足明確或者隱含要求的能力”。 通俗的講，軟件質量的好壞，就是看軟件產(chǎn)品和需求說明書（關于產(chǎn)品功能、性能和接口的明確描述以及隱含要求）的符合程度。完全符合是最好的，少了也不好，多了也不好。軟件測試相關的標準 標準名稱標準的主要內(nèi)容GB/T 18905.

33、1-2002（ISO/IEC 14598-1：1999）軟件工程 產(chǎn)品評價GB/T 162601996（ISO/IEC 9126：1991）信息技術 軟件產(chǎn)品評價 質量特性及其使用指南GB/T 175441998（ISO/IEC 12119：1994）信息技術軟件包質量要求和測試GB/T 938888計算機軟件測試文件編制規(guī)范GB/T 155321995計算機軟件單元測試9.2.8 軟件測試工具 目前，自動化軟件測試工具本身已經(jīng)初步形成了軟件領域的一個產(chǎn)業(yè)。 只有單元測試的自動化測試工具，在IT企業(yè)比較常用。 IT企業(yè)的測試部門，不要對商業(yè)測試工具抱太大期望，還要設計與開發(fā)自己的測試工具。9.

34、2.9 軟件測試文檔 軟件測試文檔包括兩部分：被測試文檔和測試文檔。 提供給客戶的所有文檔都要經(jīng)過測試，從這個角度考慮，被測試的文檔還可能包括聯(lián)機幫助文檔、樣例、模板、常見問題解答、市場宣傳材料、授權/注冊登記表、客戶許可協(xié)議，以及包裝文字、圖片、標簽、不干膠條等等。 文檔測試工作看似簡單，但是容易被忽略。仔細分析起來，很多軟件問題都是由于文檔描述不清楚或有歧意造成的。文檔和代碼同樣重要！好的文檔可以復現(xiàn)代碼！提供各種文檔模板是提高文檔質量的有效方法。 9.3 測試流程和測試技術 軟件測試流程可以分5步展開： 1. 理解、驗證和分解需求； 2. 編寫測試計劃（包括測試設計）； 3. 執(zhí)行測試；

35、 4. 進行專項測試； 5. 編寫測試報告。9.3.1 理解、驗證和分解需求1. 理解需求 應用程序的流程越來越復雜，測試人員不可能很快熟悉，都要經(jīng)歷一個了解、理解的過程。 不要錯過任何不理解的地方，也許那就是隱藏軟件問題(bug)的地方。 不理解就是亂彈琴的測試，就是無目的的測試。2. 驗證和分解需求 (1) 如何驗證需求？ 1) 設身處地為客戶著想： 把自己當作客戶，盡量弄清客戶的需求。 2) 研究現(xiàn)有的標準、規(guī)范： ISO標準、國標、主流產(chǎn)品體現(xiàn)的規(guī)范、客戶已經(jīng)習慣的規(guī)范等等。 3) 審查和測試同類軟件： 市場是生命線，盯住同行對手的同類產(chǎn)品。因為不了解對手，就會被對手戰(zhàn)勝！ 4) 列出

36、需求說明書中產(chǎn)品屬性的檢查清單。2. 驗證和分解需求(續(xù)) (2) 如何分解需求？ 分解原則：將用戶需求分解為測試需求，將測試需求分解為測試用例。 分解需求舉例： 以圖書管理系統(tǒng)中讀者網(wǎng)上登錄這個功能點為例，需求說明書中這樣描述：“核對網(wǎng)上注冊姓名和網(wǎng)上注冊口令，顯示登陸成功或者登陸失敗。” 好，首先理解、驗證通過，現(xiàn)在分解需求。如表9-5所示。分解后的測試功能點的集合，就是測試需求，就是測試用例的設計依據(jù)。需求功能點測試功能點號測試功能點描述1010_1輸入正確的網(wǎng)上注冊姓名和口令，出現(xiàn)系統(tǒng)主頁面10_2輸入正確的網(wǎng)上注冊姓名和錯誤的口令，出現(xiàn)登錄失敗對話框10_3輸入錯誤的網(wǎng)上注冊姓名和正

37、確的口令，出現(xiàn)登錄失敗對話框10_4輸入錯誤的網(wǎng)上注冊姓名和口令，出現(xiàn)登錄失敗對話框10_5什么都沒有輸入，出現(xiàn)登錄失敗對話框10_6登錄失敗對話框能夠顯示對客戶有建議性的提示信息10_7輸入網(wǎng)上能夠注冊姓名和口令后，點擊“登錄”按鈕10_8輸入網(wǎng)上能夠注冊姓名和口令后，敲擊“回車”鍵9.3.2 編寫測試計劃 編寫測試計劃的步驟如下： 1. 確定測試需求 2. 排序測試需求 3. 定義測試策略； 4. 估計測試工作量； 5. 配置測試資源。1. 確定測試需求 在分析測試需求結束后，編寫測試計劃之前，要確定測試需求，即完成并確定測試功能點列表的內(nèi)容，并保證充分了解被測軟件： 1) 產(chǎn)品的運行平臺

38、和應用領域； 2) 產(chǎn)品使用者的特點； 3) 產(chǎn)品的特點和主要的功能模塊； 4) 測試的目的和側重點； 5) 被測軟件的數(shù)據(jù)是如何傳遞、存儲的； 6) 產(chǎn)品采用的實現(xiàn)技術； 7) 同類型產(chǎn)品有哪些，各自的特點和不足； 8) 產(chǎn)品要求哪些特性。2. 排序測試需求 理論上講，測試要覆蓋所有的功能項，但是實際項目中，將按照功能項的重要性和緊迫性排序。 如何排序，沒有統(tǒng)一的標準。一般將客戶需求的重要性作為一個標準，客戶最關心的必須優(yōu)先測試。 表9-6給出了圖書館信息系統(tǒng)14個功能點的測試優(yōu)先級排序，供參考。編號功能名稱功能描述供參考的測試優(yōu)先級1圖書入庫信息錄入給圖書分類編號，并錄入系統(tǒng)12讀者信息錄

39、入錄入讀者基礎信息23圖書借閱信息錄入錄入讀者借閱圖書信息34圖書歸還信息錄入錄入讀者歸還圖書信息45圖書罰款信息錄入錄入讀者罰款圖書信息116圖書注銷信息錄入錄入注銷圖書信息127查詢讀者信息錄入查詢讀者信息58查詢圖書信息錄入查詢圖書信息69讀者網(wǎng)上注冊錄入讀者網(wǎng)上注冊信息810讀者網(wǎng)上登陸錄入讀者網(wǎng)上登陸信息911讀者網(wǎng)上查詢圖書信息錄入讀者網(wǎng)上查詢圖書信息1012圖書訂購錄入訂購圖書信息1313圖書借還統(tǒng)計統(tǒng)計圖書資源的利用情況714補辦借書卡作廢原借書卡并補辦新借書卡143. 定義測試策略和設計測試用例 測試策略主要包括：測試目的、測試用例、測試方法、測試通過標準和特殊考慮。 一個測

40、試功能點，要定義一種測試策略項，測試策略項中包括了詳細的測試信息，測試執(zhí)行人員參照它，就可以進行實際測試了。 表9-7中，是圖書管理系統(tǒng)中，驗證登錄界面，輸入框設置是否合理的測試策略項的具體定義。測試策略測試功能點編號10_18測試策略項編號10_18測試目的測試讀者網(wǎng)上登錄界面的輸入框（用戶名和密碼），大小設置是否合理測試階段系統(tǒng)測試測試類型功能測試測試方法手工測試測試用例輸入允許的最長用戶名和密碼；輸入比允許的最長用戶名和密碼多一位的字符通過標準小于等于允許的用戶名和密碼長度時，輸入框能夠完全顯示內(nèi)容；大于允許的用戶名和密碼長度時，輸入框不給予顯示特殊考慮無4. 估計測試工作量 一個測試項

41、目工作量的粗略估計計算方法為： 其中： i 代表一個測試功能點中一個測試動作； j 代表測試項目中的一個測試功能點； m 代表一個測試功能點有m個測試動作； n 代表測試項目有n個測試功能點。5. 配置測試資源 (1) 人力資源 測試經(jīng)理：為測試項目提供總體方向。開發(fā)測試計劃、征集并監(jiān)督測試人員、申請系統(tǒng)資源、監(jiān)視并匯報工作進程、測試評估、協(xié)調(diào)測試和開發(fā)工作。 測試設計人員：對被測軟件詳細了解、分解測試需求、設計測試方法。 測試開發(fā)人員：熟悉SQL、VB、Java和腳本語言。 測試執(zhí)行人員：負責測試執(zhí)行和記錄結果。需要網(wǎng)絡知識，能夠安裝系統(tǒng)，初始化數(shù)據(jù)庫和其他初始條件。重要的是診斷能力。 測試

42、系統(tǒng)管理人員：測試執(zhí)行人員執(zhí)行測試之前，搭建測試環(huán)境。配置測試資源(續(xù)) ( 2) 物力資源 硬件：顯示器，內(nèi)存，硬盤，鍵盤，鼠標，耳麥、服務器，磁盤陣列等；項目專用的硬件設施，比如通信設備（交換機、電話）。 軟件：操作系統(tǒng)；常用工具軟件；數(shù)據(jù)庫；Web服務器；項目專用的軟件。(主要是平臺的支撐軟件）。9.3.3 測試執(zhí)行 有了詳細、合理的測試計劃，測試執(zhí)行人員按照測試計劃的目的、方法、用例和通過標準，執(zhí)行測試用例，記錄測試結果。 如果測試不通過，就要提交故障單，待開發(fā)人員確認并處理故障單，將問題修復后，測試人員再次驗證，直到測試通過為止。 由于開發(fā)過程中出現(xiàn)的軟件問題，是設計時不能預料到的，

43、所以測試執(zhí)行人員除了嚴格執(zhí)行測試計劃外，還要弄清楚產(chǎn)生問題的原因，明確修復措施，并考慮修復中是否有新的問題會產(chǎn)生。9.3.4 專項測試 專項測試包括易用性測試、兼容性測試、網(wǎng)絡性能測試、軟件安全機制測試、標準化測試、數(shù)據(jù)庫測試、本地化測試。1. 易用性測試 軟件易用性是指軟件容易被理解、學習、使用和吸引客戶的程度，易用性測試可以分為： (1) 安裝易用性測試 提供安裝手冊，對安裝準備、安裝平臺、安裝環(huán)境、安裝過程、注意事項、客戶自定義選項和常見問題給出詳細描述；安裝的自動化程度；手動或者自定義安裝中有提示和回退；修復安裝、卸載。易用性測試(續(xù)) (2) 功能易用性測試 業(yè)務符合性：符合領域的業(yè)

44、務邏輯，符合使用習慣； 減少客戶輸入：使用下拉列表，提供默認值； 約束性：強制業(yè)務流程；阻止非法操作和輸入； 交互性：操作的可見性、錯誤的提示性； 業(yè)務集成度：對現(xiàn)在的辦公軟件進行集成； 功能定制：利用現(xiàn)在的自動化工具，實現(xiàn)功能定制。 (3).客戶界面易用性測試 符合直觀性、一致性、靈活性、舒適性、正確性； 視力損傷的易用性：色盲、近視、弱視； 聽力損傷的易用性：半聾、全聾； 運動損傷的易用性； 認知和語言障礙的易用性。2. 兼容性測試 兼容性測試也可以細分為： (1)硬件兼容性測試：PC機、外設、接口、網(wǎng)絡等； (2)軟件兼容性測試：OS、DB、中間件、瀏覽器； (3)數(shù)據(jù)兼容性測試：以前版

45、本的數(shù)據(jù)，用新的版本是否能打開；是否提供對常用數(shù)據(jù)格式的支持； (4)新舊系統(tǒng)數(shù)據(jù)割接測試：銀行的存款記錄、電信的客戶記錄、話單記錄、稅務的納稅記錄、保險的客戶保險記錄等等這些信息都是客戶方的命脈，當客戶第一次使用信息化系統(tǒng)，或者由一家公司的信息化系統(tǒng)改用另一家公司的系統(tǒng)時，都會發(fā)生數(shù)據(jù)割接。 3. 本地化測試 軟件本地化測試的重點內(nèi)容包括： (1) 功能性測試：基本功能、安裝、卸載、升級等； (2) 翻譯問題測試：完整性、準確性； (3)可用性(適用性)測試：客戶界面、度量衡、時區(qū)、文化、宗教、喜好等； (4)兼容性測試； (5)文檔驗證：聯(lián)機文檔、在線幫助、手冊等一致性； (6)軟件本地化

46、的技術問題測試； (7)文本擴展問題測試； (8)字符集問題測試； (9)數(shù)據(jù)格式問題測試.9.3.5 編寫測試報告 測試報告至少要包括六個方面的內(nèi)容： 1. 測試任務描述 測試報告要能展示一個基線產(chǎn)品的詳細情況，反映測試人員的測試工作量，所以測試報告的第一章被命為“測試任務描述”。該部分需要描述測試基線版本的需求分析、新增功能點和故障點。 2. 測試環(huán)境說明 硬件環(huán)境描述這次測試用的硬件配置情況；軟件環(huán)境描述這次測試用的軟件版本情況；組網(wǎng)結構圖描述測試采用的組網(wǎng)方式邏輯圖。編寫測試報告(續(xù)) 3. 測試版本比較和測試方法說明 測試版本比較，描述這個基線和上次最相鄰的基線版本的重要區(qū)別；測試方

47、法說明，描述主要的測試手段以及采用的測試工具。 4. 功能測試描述 功能測試描述，要詳細說明需求分析中的功能、接口、界面測試情況，以及新增功能點和故障點的測試情況。具體格式可以參考表9-9和表9-10。 編寫測試報告(續(xù)) 5. 性能測試描述 性能測試描述該基線版本的性能測試情況，主要是現(xiàn)有硬件條件下，關鍵節(jié)點的性能指標和處理能力。 6. 確認性測試 確認性測試描述基線確認性測試情況，主要描述模仿現(xiàn)場數(shù)據(jù)的測試情況，安裝程序的測試情況，維護、統(tǒng)計和告警等易用性測試情況，升級測試情況以及可恢復性測試情況。 編寫測試報告(續(xù)) 7. 遺留問題描述 測試人員測試過程中認為某部分存在問題，但是開發(fā)人員

48、認為問題太小不值得修改。明智的選擇就是寫在測試報告的遺留問題部分，由測試經(jīng)理決定是直接暫緩處理呢？還是協(xié)調(diào)各部門的經(jīng)理及相關人員，決定如何解決問題？ 8. 測試總結 測試總結部分的編寫應該從三個層次展開，即總體測試結果分析、測試結論和測試遺留問題。 9. 測試報告編寫參考指南9.4 測試案例分析 下面是一個鑒定測試的真實故事。 （1）測試時間：2000年上半年。 （2）測試地點：北京市某測試中心。 （3）測試課題： 固定電話本地網(wǎng)計費系統(tǒng)(簡稱本地網(wǎng)計費系統(tǒng)) 的實時模擬計費鑒定測試。 （4）測試方法： 黑盒子測試。 測試案例分析(續(xù)) （5）測試背景： 中國是全球第一大電信用戶國家，本地網(wǎng)計

49、費系統(tǒng)是以地、市為單位的固定電話計費系統(tǒng)，每個地市有一個電話區(qū)號，例如煙臺市的區(qū)號為0535，南京市的區(qū)號為025。本地網(wǎng)計費系統(tǒng)的設計思路與運行方式是：“地市集中計費，各縣、市、區(qū)分散營業(yè)；通話一次為一個計費基本單位，每月結算收費一次；每天8小時營業(yè)，724小時客戶熱線服務”。 （6）測試平臺： 網(wǎng)絡平臺包括程控交換機、路由器、高檔服務器、終端PC機、網(wǎng)絡操作系統(tǒng)；數(shù)據(jù)平臺包括數(shù)據(jù)庫管理系統(tǒng)、本地網(wǎng)計費系統(tǒng)的一個月原始話單記錄文件（這就是測試用例數(shù)據(jù)）、正確的計費運算時間和輸出結果（這就是測試結果的比較數(shù)據(jù)）。測試案例分析(續(xù)) （7）測試準備： 各IT企業(yè)將本地網(wǎng)計費程序光盤和文檔資料送到北京，等待審查批準和安排測試日期。 （8）測試過程： 先安裝本地網(wǎng)計費程序光盤，后運行數(shù)據(jù)采集、傳輸、分揀、計費、入庫、客戶化賬單、查詢統(tǒng)計程序，最后查看計費處理時間和輸出結果。 測試結論：若整個計費處理時間和輸出結果在允許的范圍內(nèi)，則通過；反之，根據(jù)實際情況酌情處理：或取消資格，或下一次補測。測試案例分析(續(xù)) （9）計費“許可證”的發(fā)放情況：絕大部分的被測試IT企業(yè)，都先后