51testing軟件測試培訓筆記

1、第一章測試基礎1. 軟件測試的目的：證明（表達軟件能夠工作） T檢測（發(fā)現錯誤）T預防（管理質量）2. 測試執(zhí)行：單元測試（UT執(zhí)行）：一個測試用例的測試執(zhí)行；集成測試（IT執(zhí)行）：一個測試用例集的測試執(zhí)行；系統(tǒng)測試（ST執(zhí)行）：不同測試階段的測試執(zhí)行。3. 測試用例（Test Case）:指對一項特定的軟件產品測試任務的描述，體現測試方案、方法、技術和策略。4.測試和調試的區(qū)別：測試調試目的:找出存在的錯誤定位錯誤，修改程序以修正錯誤對象文檔，代碼代碼流程有特定流程，有計劃性無特定流程，不可設計，無計劃性條件從已知條件開始，用預定義過程，有 預知結果從未知條件開始，結束過程不可預計5.回歸測

2、試的目的：a.驗證錯誤是否修復；b.檢測對代碼的修改是否引入了新的錯誤。6. 軟件測試的主要工作：a.檢視代碼，評審開發(fā)文檔；b. 進行測試設計，寫作測試文檔（測試計劃、測試方 案、測試用例等）；c. 執(zhí)行測試，發(fā)現軟件缺陷，提交缺陷報告，并確認 缺陷最終得到了修正；d. 通過測試度量軟件質量。7. 軟件危機的出現主要表現在：a. 由于缺乏大型軟件開發(fā)經驗和軟件開發(fā)數據積累，開發(fā)工作計劃很難制定；b. 開發(fā)早期需求分析不夠明確，造成開發(fā)后期矛盾集中暴露；c. 不遵循開發(fā)規(guī)范，開發(fā)文檔不完整，軟件難以維護；d. 缺乏嚴密有效的軟件質量檢測手段，交付給用戶的軟件質量差。8. 軟件危機的后果：a.軟

3、件質量不高，很難穩(wěn)定；b. 軟件項目延期，進度無法控制；c. 成本增加，無法控制預算。9. 軟件危機的根源：a.根據摩爾定律，硬件發(fā)展很快，相應對軟件系統(tǒng)的期望越來越咼；b. 軟件系統(tǒng)復雜性提高，需多人合作；c. 軟件開發(fā)是人的智力活動，無法用已有的產業(yè)工程方法 來組織管理。10. 軟件生命周期的各個階段：計劃T需求分析T設計T編碼T測試T運行T評價11. 設計：概要設計（HLD）:在設計階段把各項需求轉換成相應的體系結構，每一部分是功能明確的模塊；詳細設計（LLD）:對每個模塊要完成的工作進行具體的描述。12. 軟件研發(fā)三要素：人員、過程、工具13. 軟件項目組人員組成：分析人員、設計人員、

4、開發(fā)人員、測試人員、配置管理 人員、SQA（質量保證人員）14. 軟件研發(fā)流程類型：瀑布模型：無風險控制能力，適合需求變化較小的情況。螺旋模型：基于風險管理的模型， 高風險的優(yōu)先考慮， 對 風險管理人員的要求較高。RVP流程：面向對象的，通用的（4大階段，6大工作流， 8項迭代）。特點：1）基于風險2）用例集驅動3）以架構為中心4）迭代和增量IPD流程：1）產品結構重整（資源重整）2）公共模塊共用15. 軟件研發(fā)中幾個重要的過程：需求管理、配置管理、缺陷管理、同行評審。16.常見的引入缺陷的原因:b.c.d.e.f.a. 開發(fā)過程缺乏有效的溝通，或者沒有進行溝通;軟件復雜度越來越高； 編程中產

5、生錯誤； 需求不斷變更； 項目進度的壓力； 不重視開發(fā)文檔；g.軟件開發(fā)工具本身隱藏的問題。等等17.缺陷類型：遺漏、錯誤、額外的實現。第二章軟件質量1、軟件質量的定義：一個實體的所有特性，基于這些特性可以滿足明顯的或隱含的需求。而質量就是實體基于這些特性滿足需求的程度。2、軟件質量的三個層次：a.符合需求規(guī)格；b. 符合用戶顯示需求；c. 符合用戶實際需求。3、影響軟件質量的因素：流程、技術、組織。流程：一組活動（活動是否都是必須的，活動角色之間的關系） 過程：一組將輸入轉化為輸出的相關聯或相互作用的活動。4、八項質量管理原則：a.以顧客為中心；b.領導作用；c.全員參與；d.過程方法；e.

6、管理的系統(tǒng)方法；f.持續(xù)改進；g.基于事實的決策方法；h.互利的供方關系。5、八項質量管理原則的意義：a.是質量管理的理論基礎；b用高度概括易于理解的語言所表述的質量管理 的最基本，最通用的一般性規(guī)律；c.為組織建立質量管理體系提供了理論依據；d.是組織的領導者有效的實施質量管理工作必須 遵循的原則。6、CMM1 初始級，In Itial，不可預測并且缺乏控制；CMM2 :可重復級：Repeatable,可重復以前的主要經驗；（關鍵過程區(qū)域： 需求管理；軟件項目計劃；軟件項目跟蹤和監(jiān)督；軟 件子合同管理；軟件質量保證；軟件配置管理。）CMM3 :已定義級：Defined，過程被描述，并得到良好

7、理解；（關鍵過程區(qū)域：組織過程定義；組織過程焦點；培訓大綱；集成軟件管理；軟件產品工程；組際協(xié)調；同行評審。）CMM4 :已管理級：Managed ,過程被測量并受控；（關鍵過程區(qū)域： 定量的過程管理；軟件質量管理。）CMM5優(yōu)化級，Optimizing，關注過程改進。（關鍵過程區(qū)域：缺陷預防；技術變更管理；過程變更管理。）7、CMM的用途：a.評估組用來識別組織中的強處和弱處；b. 評價組用來識別選擇不同的業(yè)務承包商的風險和監(jiān)督合同；c. 管理者用來了解其組織的能力，并了解為了提高其能力成熟 度而進行軟件過程改進所需進行的活動；d. 技術人員和過程改進組用來作為指南，指導他們在組織中定 義和

8、改進軟件過程。& ISO9001 和 CMIM勺關系：相似點：強調管理、過程、規(guī)范化和文檔化；不同點：CMM巴焦點對準軟件；ISO9001的范圍包括：硬件、軟件、流程性材 料和服務；兩者關系：CMM瀕與ISO9001強相關；CMM勺每個關鍵過程域至少按某種解釋 與ISO9001弱相關。9、六西格瑪的實施方式：Define：定義-提出問題，確定目標Measure:測量-收集資料，尋找原因An alyse:分析-研究資料，確定原因Improve:改進-優(yōu)化解決方案Co ntrol:控制-推行控制系統(tǒng)10、軟件質量模型：功能性：當軟件在指定條件下使用時， 軟件產品提供滿足明確和隱含需求的功 能的能力

9、。包括：適合性；準確性；互操作性；保密安全性；功能性 的依從性?？煽啃裕涸谥付l件下使用時，軟件產品維持規(guī)定的性能級別的能力。包括： 成熟性；容錯性；易恢復性；可靠性的依從性。易用性：在指定條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力。包括：易理解性；易學性；易操作性；吸引性；易用性的依從性。效 率：在規(guī)定條件下，相對于所用資源的數量， 軟件產品可提供適當性能的第一階段考試重點歸納 能力。包括：時間特性；資源利用性；效率依從性。維護性：軟件產品可被修改的能力。修改可能包括修正、改進或軟件對環(huán)境、 需求和功能規(guī)格說明變化的適應。包括：易分析性；易改變性；穩(wěn)定 性；易測試性；維護性的依

10、從性?？梢浦残裕很浖a品從一種環(huán)境遷移到另外一種環(huán)境的能力。包括：適應性； 易安裝性；共存性；易替換性；可移植性的依從性。11、SQA與測試的關系：測試從技術的角度來保證軟件質量SQA從流程的角度保障軟件質量組織用來保障SQA和測試的活動12、 SQA的主要工作范圍：指導并監(jiān)督項目按照過程實施；對項目進行度量、 分析，增加項目的可視性；審核工作產品，評價工作產品和過程質量目標的復 合度；進行缺陷分析，缺陷預防活動，發(fā)現過程的缺陷，提供決策參考，促進過程改進。13、度量：對事物屬性的量化表示；軟件度量：是指計算機軟件中范圍廣泛的測度，包括對軟件系統(tǒng)、構建或生命周期過程具有的某個給定屬性的度的一個

11、定量測量。目的：提高軟件生產率，縮短產品研發(fā)周期，降低研發(fā)成本、維護成本；提高軟件產品質量，提高用戶滿意度；為組織持續(xù)改進提供量化的指標和反饋。14、軟件度量的作用：1）理解；預測；評估；改進。2）分類：規(guī)模；工作量；進度；質量15、如何將度量的知識應用于實際工作中：建立測試工作的度量數據，目的是作 為預測和改進的基礎a. 熟悉需求：進度、工作量、規(guī)模；b. 設計用例：工作效率、覆蓋率；c. 執(zhí)行用例：工作效率、缺陷密度；）第三章測試方法1、什么是白盒測試：并根據內部構造設計用例,整體功能實現情況；白盒測試是依據被測軟件，分析程序內部構造,來對內部控制流程進行測試，可完全不顧程序的白盒測試是基

12、于程序結構的邏輯驅動測試；白盒測試又可以被稱為玻璃盒測試、透明盒測試、開放盒測試、結構化測 試、邏輯驅動測試。2、為什么進行白盒測試： 一般在測試前期進行，通過達到一定的邏輯覆蓋率指標，使得軟件內部邏 輯控制結構上的問、難題能基本得到消除；能保證內部邏輯結構達到一定的覆蓋程度，能夠給予軟件代碼質量更大的 保證；發(fā)現問題后解決問題的成本較低。3、白盒測試的常用技術：靜態(tài)分析：控制流分析、數據流分析、信息流分析等；動態(tài)分析：邏輯覆蓋測試（分支測試、路徑測試等）、程序插裝等。4、控制流相關概念：程序元素、控制流關系、控制流圖、控制流矩陣。（步驟：5）5、控制流分析能發(fā)現的問題：1）轉向并不存在的標號

13、；2）沒有用的語句標號；3）從程序入口進入后無法達到的語句；4）不能達到停機語句的語句。6、數據流相關概念：數據的定義；數據的引用。 （步驟：3）7、 數據流分析的作用： 分析代碼中關于數據定義和引用方面的錯誤；進行代碼優(yōu)化。（賦值語句運算效率高）8、信息流分析：輸入變量和語句關系；語句和輸出變量關系；輸入和輸出變量管理。（步驟：4）9、覆蓋率工具的作用：-分析被測試代碼控制結構，決定插裝位置；-實施插裝；-將插裝代碼重新編譯；-執(zhí)行被測對象，根據插裝的監(jiān)控哨信息統(tǒng)計覆蓋率。10、白盒測試的特點：測試人員需要了解軟件的實現；可以檢測代碼中的每條分支和路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比

14、較徹底；實現代碼結構上的優(yōu)化；白盒測試投入較大，成本高；白盒測試不驗證規(guī)格的正確性。11、什么是黑盒測試：黑盒測試把被測對象看成一個黑盒，只考慮其整體特性，不考慮其內 部具體實現；黑盒測試針對的被測對象可以是一個系統(tǒng)、一個子系統(tǒng)、一個模塊、 一個子模塊、一個函數等。黑盒測試又可以被稱為基于規(guī)格的測試。12、常見的黑盒測試類型： 功能性測試；容量測試；負載測試；恢復性測試。13、常見的黑盒測試方法： 等價類、邊界值、因果圖、判定表、狀態(tài)遷移、正 交分解、錯誤猜測、輸入/輸出域覆蓋、14、系統(tǒng)測試的時候，如果沒有 SRS時，有兩類BUG無法發(fā)現：1）需求遺漏;2）需求偏差15、黑盒測試的優(yōu)點：對于

15、更大的代碼單元來說（子系統(tǒng)甚至系統(tǒng)級）比白盒測試效率要高;測試人員不需要了解實現的細節(jié)，包括特定的編程語言；從用戶的視角進行測試， 很容易被大家理解和接受；有助于暴露任何規(guī)格不一致或有歧義的問題。16、黑盒測試的缺點：沒有清晰的和簡明的規(guī)格， 測試用例很難設計；不能控制內部執(zhí)行路徑，會有很多內部程序路徑沒有被測試到;不能直接針對特定的程序段，這些程序可能非常復雜（因此可能隱藏 更多的問題）。17、動態(tài)和靜態(tài)測試的分類依據在于：被測對象是否運行起來。18、手工靜態(tài)分析一一同行評審：正規(guī)檢視；技術評審；走查。評審對象：計劃、需求文檔、設計圖、代碼等。19、自動化靜態(tài)分析：靜態(tài)驗證；語法分析器；符號

16、執(zhí)行器。20、自動化測試應該考慮的因素：1）測試進度要求2）人力資源要求3）版本穩(wěn)定度4）版本應用情況5）可自動化率6）版本規(guī)模21、自動化測試的誤區(qū)：1）自動化不能取代手工測試。2）手工測試都做不好，或者經驗積累不夠，就嘗試自動化，很難成功。3）自動化只能保證測試執(zhí)行效率，確保已有的問題不會再發(fā)生，自動化測試不能發(fā)現大量新缺陷。4）進行了自動化測試的軟件不一定就是安全的，質量有保證的。所以手工測試是自動化測試的一個基礎22、自動化五大等級：1）錄制和回放2）腳本3）自動化框架腳本4）數據驅動5）關鍵字驅動自動化測試的限制（板書）：自動化測試不具備想象力，不能夠檢查腳本中給定的觀察點之外的錯誤

17、；自動化測試只能提高測試效率，不能提高測試效果，不能發(fā)現比人工測試更多的問題；如被測對象不穩(wěn)定，存在變動性的話不適合開展自動化測試，否則腳本的編寫和維護所耗費的時間可能遠大于人工測試；只有手工測試積累到一定程度（提供更多的觀察點），才能做好自動化測試。第四章測試過程1、各階段測試的目的:1）單元測試：檢測軟件模塊對詳細設計說明書的符合程度2）集成測試：檢測軟件模塊對概要設計說明書的符合程度3） 系統(tǒng)測試：通過與需要規(guī)格說明書作比較，發(fā)現軟件與系統(tǒng)定義不符 或與之矛盾的地方。2、單元、集成、系統(tǒng)測試的比較：測試 類型目的考察范圍評估基準測試方法單元 測試消除局部模塊的邏輯和功 能上的錯誤和缺陷（

18、消除單 元、模塊內部的邏輯和功能 上的錯誤與缺陷）單元內部 的數據結 構、邏輯控 制、異常處 理等邏輯覆蓋率大量米用白盒測 試方法集成 測試找出與軟件設計相關的程 序結構，模塊調用關系，模 塊間接口方面的問題（找出 與軟件架構設計相關的程 序結構，單元/子模塊間的 調用關系，單元/子模塊間 接口方米那的問題）接口和接 口數據傳 遞關系、模 塊組合后 的整體功 能接口覆蓋率結合使用白盒與 黑盒測試方法， 較多采用黑盒方 法構造測試用例 （也有說法叫灰盒測試方法）系統(tǒng) 測試對整個系統(tǒng)進行一系列的 整體、有效性測試（對系統(tǒng) 規(guī)格中的功能與性能進行 一系列的有效性測試）整個系統(tǒng) 對需求的 符合度測試用

19、例對 需求規(guī)格的 覆蓋率黑盒測試3、回歸測試策略：完全重復測試；選擇性重復測試（覆蓋修改法；周邊影響法；指標達成方法;選擇重要級別高的測試用例）4、回歸測試流程：1）在測試策略制定階段，制定回歸測試策略2）確定需要回歸測試的版本3）回歸測試版本發(fā)布，按照回歸測試策略執(zhí)行回歸測試4）回歸測試通過，關閉缺陷跟蹤單（問題單）5）回歸測試不通過，缺陷跟蹤單返回開發(fā)人員，開發(fā)人員重新修改問題，再 次提交測試人員回歸測試5、有用戶參與的其他一些測試 ：驗收測試、a測試、B測試6、a測試與3測試的比較:Alpha測試Beta測試比較測試環(huán) 境開發(fā)環(huán)境或者模擬實 際操作的環(huán)境下實際使用環(huán)境測試人 員可以是終端

20、用戶也可 以是企業(yè)內部的用戶終端用戶（包括潛在用戶）開發(fā)人 員是否 在場有開發(fā)人員在場，實際 上是一種受控的測試。開發(fā)人員通常不在測試現 場，測試情況通常不受控。關注點Alpha測試關注軟件 產品的FLURP（即功 能、局域化、可使用性、 可靠性、性能和支持）， 尤其注重產品的界面 和特色。Beta測試著重關注產品的 支持性，包括文檔、客戶 培訓和支持產品的生產能 力。共同點1. 都希望從實際終端用戶的使用角度來對軟件的 功能和性能進行測試，以發(fā)現可能只有終端用戶才 能發(fā)現的錯誤；2. 都不能由測試人員和程序員完成；7、主要的測試文檔： 測試計劃；測試方案；測試用例；測試規(guī)程；測試報告；測 試

21、日報& 驗證與確認 V&V:驗證（VERIFICATION強調過程；確認（VALIDATION強調結果。9、V&V模型優(yōu)點：實現了測試設計和測試執(zhí)行相分離；揭示了軟件測試活動分層和分階段的本質特性：測試執(zhí)行 的順序與開發(fā)活動相反10、V&V 模型:11、系統(tǒng)測試分為幾個階段，每個階段的輸入/輸出是什么?系統(tǒng)測試階段輸入輸出計劃階段1. 軟件開發(fā)計劃2. 軟件測試計劃系統(tǒng)測試計劃系統(tǒng)測試3需求規(guī)格說明書設計階段1.系統(tǒng)測試計劃2需求規(guī)格說明書系統(tǒng)測試方案實現階段1. 系統(tǒng)測試計劃2. 系統(tǒng)測試方案3需求規(guī)格說明書1. 系統(tǒng)測試用例2. 系統(tǒng)測試規(guī)程3. 系統(tǒng)測試預測試項執(zhí)行階段1. 系統(tǒng)測試計劃

22、2. 系統(tǒng)測試方案3. 系統(tǒng)測試用例4. 系統(tǒng)測試規(guī)程5. 系統(tǒng)測試預測試項6. 集成測試報告1. 系統(tǒng)預測試報告2. 系統(tǒng)測試報告3. 缺陷報告4. 測試日報集成測試計劃階段1. 軟件測試計劃2. 概要設計說明書集成測試計劃設計階段1. 概要設計說明書2. 集成測試計劃集成測試方案實現階段1. 概要設計說明書2. 集成測試計劃3. 集成測試方案1. 集成測試用例2. 集成測試規(guī)程執(zhí)行階段1. 集成測試計劃2. 集成測試方案3. 集成測試用例4. 集成測試規(guī)程1. 集成測試報告2. 缺陷報告單元測試計劃階段1. 軟件測試計劃2. 詳細設計說明書單元測試計劃設計階段1. 詳細設計說明書2. 單元

23、測試計劃單元測試方案實現階段1. 詳細設計說明書2. 單元測試計劃3. 單元測試方案1. 單元測試用例2. 單元測試規(guī)程執(zhí)行階段1. 單元測試計劃2. 單元測試方案3. 單元測試用例4. 單元測試規(guī)程1. 單元測試報告2. 缺陷報告第五章單元測試1、單元的基本屬性：1）明確的功能2）可定義的規(guī)格3）與其他單元接口的清晰劃分2、單元測試的目的：在于發(fā)現各模塊內部可能存在的各種錯誤，主要是基于白盒測試。a）驗證代碼是與設計相符合的；b）發(fā)現設計和需求中存在的錯誤；c）發(fā)現在編碼過程中引入的錯誤。（和設計不相符或和設計相符，但是由于編碼疏漏引起）3、單元測試關注的重點：出錯處理、單元接口、局部數據結

24、構、獨立路徑、邊界條件4、單元測試的主要關注點：1）參數的屬性、順序、個數是否與 LLD 致2）不能修改只做輸入用的形參，否則可能導致數據的錯誤修改3）約束條件是否通過形參來傳送5、驅動和樁的功能：1）驅動單元：被測函數的主函數，能接受輸入數據，輸出實際測試 結果2）樁單元：用來代替所測單元調用的子單元6、單元測試策略：孤立的測試策略、自頂向下、自底向上的單元測試策略1）孤立的測試策略：方法：不考慮每個模塊與其他模塊之間的關系，為每個模塊設計樁模 塊和驅動模塊。每個模塊進行獨立的單元測試。優(yōu)點：該方法是最簡單，最容易操作的?？梢赃_到高的結構覆蓋率。 該方法是純粹的單元測試。缺點：樁函數和驅動函

25、數工作量很大，效率低。2) 自頂向下的單元測試策略：方法：先對最頂層的單元進行測試，把頂層所調用的單元做成樁模塊。其次對第二層進行測試，使用上面已測試的單元做驅動模塊。如此類推 直到測試完所有模塊。優(yōu)點：可以節(jié)省驅動函數的開發(fā)工作量，測試效率較高。缺點：隨著被測單元一個一個被加入，測試過程將變得越來越復雜， 并且開發(fā)和維護的成本將增加。3) 自底向上的單元測試策略：方法：先對模塊調用層次圖上最低層的模塊進行單元測試，模擬調用該模塊的模塊做驅動模塊。然后再對上面一層做單元測試，用下面已被 測試過的模塊做樁模塊。以此類推，直到測試完所有模塊。優(yōu)點：可以節(jié)省樁函數的開發(fā)工作量，測試效率較高。缺點：不

26、是純粹的單元測試，底層函數的測試質量對上層函數的測試將產生很大的影響。5、單元測試的四個階段：測試計劃：完成單元測試計劃；測試設計：完成單元測試方案；測試實現：完成單元測試用例、單元測試規(guī)程、 單元測試腳本及數據文件；測試執(zhí)行：執(zhí)行單元測試用例，修改發(fā)現的問 題并進行回歸測試，提交單元測試 報告。單元測試：樁&驅動舉例：無論是單元測試還是集成測試都涉及到以下三個函數：主控函數：in t ctrl(i nt x, i nt y) 加法函數：int add(i nt x, i nt y) 減法函數：int sub(i nt x, i nt y)注意：進行單元測試時，設計用例時依據的是LLD;進行集

27、成測試時，設計測試用例依據的是HLD下面給出來的是需要測試的實際的代碼。int ctrl(int x, int y) int temp=O;if(x=y)temp=add(x,y);elsereturn temp;int add(i nt x, int y)return(x+y);int sub(i nt x, int y) return(x-y);temp=sub(x,y);自頂向下單元測試策略不同測試步驟中的驅動可以寫到一起，也可以分開寫，這里是寫到一起了。測試Ctrl函數需要寫一個驅動和兩個樁。驅動函數void driver()int ret=0;ret=ctrl(2,1); xyif(

28、ret=3)printf(“testcase JISUAN_UT_CTRL_001 pass ” );elseprintf(“testcase JISUAN_UT_CTRL_001 fail ” );ret=ctrl(1,1); x=yif(ret=2)printf(“testcase JISUAN_UT_CTRL_002 pass ” );elseprintf(“testcase JISUAN_UT_CTRL_002 fail ” );ret=ctrl(1,2); /x=y)temp= stub_add (x, y);elsetemp= stub_sub (x, y); return tem

29、p;測試add函數驅動函數第一階段考試重點歸納 同測試Ctrl函數時sub函數對應的樁 樁函數修改代碼int ctrl(i nt x, int y) int temp=O;if(x=y)temp=add(x, y);if(x=2 & y=1 & temp=3)printf(“testcase JISUAN_UT_ADD_001 pass ” );elseprintf(“testcase JISUAN_UT_ADD_001 fail ” );if(x=1 & y=1 & temp=2)printf(“testcase JISUAN_UT_ADD_002 pass ” );elseprintf(“

30、testcase JISUAN_UT_ADD_002 fail ” ); elsetemp= stub_sub (x, y); return temp; 測試sub函數驅動函數同測試ctrl函數時的驅動樁函數無修改代碼int ctrl(i nt x, int y)int temp=O;if(x=y)temp=add(x, y);else temp=sub(x, y);if(x=1 &y=2 & temp=-1)printf(“testcase JISUAN_UT_SUB_001 pass ” );elseprintf(“testcase JISUAN_UT_SUB_001 fail” );re

31、turn temp; 第六章集成測試1. 集成測試的目的：確保各組件組合在一起后能夠按照既定意圖寫作運行，并確保增量的行為正確（屬于灰盒測試）1）驗證接口是否與設計相符2）發(fā)現設計和需求中存在的錯誤2. 集成測試關注的重點：單元間的接口、集成后的功能3. 集成測試的層次：模塊內集成、子系統(tǒng)內集成、子系統(tǒng)間集成4. 集成測試策略：1）大爆炸集成2）自頂向下集成3）自底向上集成4）三明治（混合式）集成5）基干集成6）分層集成7）基于功能的集成8）基于消息的集成9）基于進度的集成10）基于風險的集成5.各種集成測試策略的優(yōu)缺點:優(yōu)點缺點適用范圍大爆炸集成1. 只要極少數的驅動和樁2. 可并行工作，人

32、力、物力 資源利用率較高1. 一次運行成功的可能性不 大2. 定位和修改錯誤比較困難3. 會有很多接口錯誤進入到 系統(tǒng)測試1. 維護型項目（增強型）2. 每個函數都經過了充 分單元測試的小規(guī)模系 統(tǒng)（特別是接口函數）自頂向下1.較早驗證了主要的控制 點和判斷點1. 樁的開發(fā)和維護成本大2. 底層組件行為的驗證被推1.產品控制結構比較清 晰和穩(wěn)定2. 選用按深度方向組裝的 方式，可首先頭現和驗證一 個完整的軟件功能3. 功能可行性較早得到證 實（帶來信心）4. 最多只需一個驅動，減少 驅動開發(fā)費用5. 支持故障隔離遲了3.底層組件的測試不充分2. 產品高層接口變化較 小3. 產品底層接口未定義

33、或經?？赡鼙恍薷?. 產品控制組件具有較 大的技術風險，需要盡早 被驗證5. 希望盡早看到產品的 系統(tǒng)功能行為自底向上1. 允許對底層組件行為的 早期驗證2. 工作初期可以并行進行 集成3. 減少了樁的工作量4. 支持故障隔離1. 驅動的開發(fā)和維護成本高2. 對高層的驗證被推遲到了 最后，設計上的錯誤不能被及 時發(fā)現1. 底層接口比較穩(wěn)定、變 動較少的產品2. 高層接口變化較頻繁 的產品3. 底層組件較早被完成 的產品三明治集成集合了自頂向下和自底向 上策略的優(yōu)點中間層在被集成前測試不充 分大部分軟件開發(fā)項目基干集成具有三明治集成的優(yōu)點1. 必須對系統(tǒng)的結構和相互 依存性進行仔細分析2. 必須

34、開發(fā)驅動和樁3. 有些接口可能測試不充分大型復雜項目基于功能集 成/基于消 息集成1. 可盡快看到關鍵功能的 實現，并驗證正確性2. 進度上要短3. 可減少驅動的開發(fā)1. 對有些接口測試不充分，會丟失許多接口錯誤2. 可能會有較大的冗余測試基于進度集 成1. 具有比較咼的并行度2. 能有效縮短項目開發(fā)的 進度1. 許多接口要到后期才能驗 證，無法發(fā)現有效的接口問題2. 樁和驅動開發(fā)工作量大3. 由于進度，組件很不穩(wěn)定且 會不斷變動，導致測試的重復 和浪費進度優(yōu)先級咼于質量的 項目基于風險集 成最具有風險的組件最早進 行驗證，有助于系統(tǒng)的快速 穩(wěn)定需要對各組件的風險有一個 清晰的分析第七章系統(tǒng)測

35、試1. 系統(tǒng)測試目的：1）通過與需求做比較，發(fā)現與系統(tǒng)定義不符合或與之矛盾的地方2）系統(tǒng)測試的用例應根據需求分析說明書來設計，并在實際使用環(huán)境下運行2. 系統(tǒng)測試對象1）軟硬件集合在一起的系統(tǒng)2）驗證時應盡可能模擬實際的運行環(huán)境與條件3. 系統(tǒng)測試常用類型：功能、性能、壓力、容量、安全性、GUI、可用性、安裝、配置、異常（恢復性）、備份、健壯性、文檔、在線幫助、網絡、穩(wěn)定性測試4. 功能測試：1）概念：根據產品的SRS和測試需求列表，驗證產品的功能實現是否符合產品的需求 規(guī)格2）目標：為了發(fā)現以下幾類錯誤a）是否有不正確或遺漏了的功能b）功能實現是否滿足用戶需求和系統(tǒng)設計的隱藏需求c）輸入能否

36、正確接受？能否正確輸出結果？5. 性能測試：1）概念：用來測試軟件在集成系統(tǒng)中的運行性能2）目標：度量系統(tǒng)相對于預定義目標的差距3）工具：LoadRunner、WebLoad SilkPerformer4）重要性：a）性能是質量的重要組成部分b）給用戶樹立良好形象c）節(jié)省成本的重要手段6. 性能測試的關鍵：有效的協(xié)調、正確的模型、瓶頸的定位、合理的建議7. 性能需求五大特性：需求行、代表性、完整性、可測試性、可用性8. 壓力測試：關注穩(wěn)定性和破壞性1）目的：調查系統(tǒng)在其資源超負荷的情況下的表現2）目標：通過極限測試方法， 發(fā)現系統(tǒng)在極限或惡劣環(huán)境中自我保護能力，主要驗證系統(tǒng)的可靠性。9. 容量

37、測試：1）目的：使系統(tǒng)承受超額的數據容量來發(fā)現它是否能夠正確處理2）關注點：a）整體的業(yè)務流量（一般關注靜態(tài)容量）b）數據庫的容量c）最大文件數目d）最大事務數10. 安全性測試：口令認證、加解密技術、權限管理、安全日志11. GUI 測試：1）關注點：界面實現與界面設計的吻合情況、確認界面處理的正確性2）對象：簡單界面元素、組合類界面元素、完整界面（窗口）3）內容：外觀、界面元素行為、布局、友好功能12. 可用性測試：關注點：1）過分復雜的功能或指令2）困難的安裝過程3）錯誤信息過于簡單4）用戶被迫去記住太多的信息5）語法、格式和定義不一致13. 配置測試：概念：測試系統(tǒng)在各種軟硬件配置、不

38、同的參數配置下系統(tǒng)具有的功能和性能目標：驗證全部配置的可操作性和有效性，特別需要對最大配置、最小配置或特殊配置進行測試14. 異常測試：概念：又叫系統(tǒng)容錯和可恢復性測試，通過人工干預手段使系統(tǒng)產生軟、硬件異常，通 過驗證系統(tǒng)異常前后的功能和運行狀態(tài)，達到檢驗系統(tǒng)的容錯、排錯和恢復的能力。它是系統(tǒng)可靠性評價的重要手段。容錯處理：系統(tǒng)自動處理、人工干預處理系統(tǒng)可靠性指標：平均失效時間間隔（MTBF、平均恢復時間（MTTR系統(tǒng)可靠性設計技術：1）避開錯誤2）容錯技術：結構冗余（動、靜態(tài)）、信息冗余、時間冗余、硬件冗余、附加冗余技 術15. 健壯性測試： Robustness Testing用于測試系

39、統(tǒng)在出現故障時，是否能夠自動恢復或忽略故障繼續(xù)運行16. 網絡測試：概念：在網絡環(huán)境下和其他設備對接，進行系統(tǒng)功能、性能與指標方面的測試，保證設 備對接正常。內容：考察系統(tǒng)的處理能力、系統(tǒng)兼容性、系統(tǒng)穩(wěn)定可靠性及用戶使用等方面。1）一致性測試：檢測系統(tǒng)與協(xié)議規(guī)范符合程度2）性能測試：檢測協(xié)議實體或系統(tǒng)的性能指標3）互操作性測試：4）堅固性測試：檢測協(xié)議實體或系統(tǒng)在各種惡劣環(huán)境下運行的能力17. 系統(tǒng)穩(wěn)定性測試：目的是評價系統(tǒng)在一定負荷情況下、長時間的運行情況。第八章測試覆蓋率1. 覆蓋率概念：覆蓋率是用來度量測試完整性的一個手段。覆蓋率是測試技術有效性的一個度量。 覆蓋率=（至少被執(zhí)行一次的i

40、tem數）/item 的總數；覆蓋率大體可以劃分為兩大類：邏輯覆蓋和功能覆蓋；測試用例設計不能一味追求覆蓋率，因為測試成本雖覆蓋率的增加而增加。2. 邏輯覆蓋主要類型：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、路徑覆蓋。3. 語句覆蓋率：（Statement Coverage）,在測試時運行被測程序后，程序中被執(zhí)行到 的可執(zhí)行語句的比率；語句覆蓋率=（至少被執(zhí)行一次的語句數量）/ （可執(zhí)行的語句總數）4. 分支覆蓋率：（Bran ch Coverage ）也叫判定覆蓋（Decision Coverage）,它的含義是：在測試時運行被測程序后，程序中所有判斷語句的取真分支和取假分支被執(zhí)行到的

41、比率；判定覆蓋率=（判定結果被評價的次數）/ （判定結果的總數）5. 條件覆蓋率：（Co ndition Coverage ）的含義是，在測試時運行被測程序后，所有 判斷語句中每個條件的可能取值（真值和假值）出現過的比率；條件覆蓋率=（條件操作數值至少被評價一次的數量） / （條件操作數值的總數）6. 分支-條件覆蓋率：（Branch Condition Coverage ）也叫判定條件覆蓋（ DecisionCondition Coverage ）,它的含義是，在測試時運行被測程序后，所有判斷語句中 每個條件的所有可能值（為真為假）和每個判斷本身的判定結果（為真為假）出現的比率；分支條件覆蓋

42、率=（條件操作樹枝或判定結果至少被評價一次的數量）/ （條件操作數值總數+判定結果總數）7. 路徑覆蓋率：（Path Coverage ）的含義是，在測試時運行被測程序后，程序中所有 可能的路徑被執(zhí)行過的比率；路徑覆蓋率=（至少被執(zhí)行到一次的路徑數）/ （總的路徑數）8. 其他覆蓋率：功能覆蓋率；面向對象的覆蓋率；函數覆蓋；指令塊覆蓋；判定路徑覆蓋。第九章測試用例舉例測試用例編號BOSS_ ST_ MARKETING_NEW_01P重要級別咼（還有“較咼、中、較低、低”幾個等級）測試項目新增營銷記錄測試標題新增10元的營銷記錄用例類型基本事件（對應還有“備選事件”、“異常事件”）用例設計者so

43、ngfun設計日期2005-04-25對應需求編號REQ_ MARKETING_NEW_01對應UIMarketi ng.htm對應UCUC_ MARKETING_NEW_01版本號Build v0.1對應開發(fā)人員Frank預置條件操作員登錄營銷管理系統(tǒng)測試方法等價類劃分（對應還有“錯誤猜測法”、“邊界值分析”等）丁輸入用戶名：51testing性別：男 金額：10元 描述：aaaaaaa操作步驟 .進入【營銷下發(fā)】頁面； 點擊增加按鈕； .輸入相應數據； 點擊確定按鈕； .在后臺數據庫（test/testtestDB）輸入查詢語句驗證：select * from Marketi ngTab

44、where ID=1001預期輸出1. 執(zhí)行步驟后，頁面彈出添加成功提示信息框；2. 執(zhí)行步驟后查詢數據庫，記錄確實添加成功且數據無誤第十章測試經驗和誤區(qū)1. 軟件測試的誤區(qū)：1）測試和調試是一樣的2）測試組應當為保證質量負責3）過分依賴BETA測試4）把測試作為新員工的一個過渡工作5）把不合格的開發(fā)人員安排做測試6）關注于測試的執(zhí)行而忽略測試的設計7）自動化測試是萬能的8）測試是可以窮盡的9）測試是為了證明軟件的正確性10）測試是枯燥乏味，缺乏創(chuàng)造力的工作2. 軟件測試的10大原則：1）測試是一個持續(xù)改進的過程，而不是一個階段2）測試必須被計劃、被控制、并且被提供時間和資源3）測試應當分級別

45、4）測試應當有重點5）測試不是為了證明程序的正確性，而是為了證明程序不能工作6）測試是不可能窮盡的，當測試出口條件滿足時就可以停止測試7）測試是開發(fā)的朋友，不是敵人8）測試人員應當站在公正的立場上進行測試，如實的記錄和報告缺陷9）自動化測試能解決一部分問題，但不是全部10）測試不能僅僅包括功能性的驗證，還應當包含性能、可靠性、可維護型、安全性等方面的驗證3. 軟件測試的10個最佳實踐：1）盡早的、頻繁的進行測試-降低成本、提高質量2）盡早的產生一個綜合的主測試計劃3）對質量要求較高的產品或大型復雜的產品成立獨立的測試組4）在每個開發(fā)階段，使用測試和評價的結果作為是否可以通過的標準5）開發(fā)和維護

46、一個測試需求和目標的風險優(yōu)先級列表6）把測試作為產品的一部分等同起來，使用相同的評價標準和過程7）提供集成化的測試工具和測試技術支持8）加強測試度量工作和缺陷分析工作，不斷地改進測試9）加強測試的培訓并且為測試人員提供技能發(fā)展的通道10）加強溝通和交流，讓項目組內所有人員都了解測試的重要性和測試的工作a)同行評審1. 同行評審：(Peer Review)是一種通過作者的同行來確認缺陷和需要變更區(qū)域的檢查方 法。需要進行同行評審的特定產品在定義項目軟件過程的時候被確定并且作為軟件開發(fā) 計劃的一部分被安排了進度。a) 需要前期準備、計劃和時間進度表b) 越早越好2. 同行評審的作用：早期發(fā)現缺陷；

47、去除缺陷；降低成本；提高質量。3. 同行評審的類型：正規(guī)檢視：(In spection )最嚴格，要求有規(guī)范的流程，參加者經過正式培訓；技術評審：(Technique Review )以技術方案的比較、裁決為目 的，嚴格程度介于正規(guī)檢視和走讀之間；走 讀：(Walk Through )最(自由)松散的形式，無流程要 求，有評審團隊，評審流程無要求。4. 通用評審流程步驟(正規(guī)檢視流程)：計劃階段：項目負責人指定組織者;作者自檢工作產品;組織者規(guī)劃本次評審;檢查入口準則：是否符合文檔標準？是否已用工具檢查？代碼 =500行；文檔=40頁；準備評審包：工作產品(HLD);參考資料(SRS檢查一致性

48、)；評審表(Review Form)； 查檢表(Checklist )。指定評審專家(3-6人)；組織者將評審包、評審通知單發(fā)給相關人員。介紹會議：被評審對象采用新技術、新方法；被評審對象第一次被評審(作者介紹被審對象以及相關技術)評審專家第一次參加評審（評審者介紹評審流程）介紹會議的召開距接到評審通知的時間大于5小時；介紹會議的時間不超過 1小時，30-60間為宜，關注講解。3. 準備階段：（最重要、發(fā)現缺陷最多）評審專家個人獨立完成工作產品的審視，提出缺陷；準備時間大于會議時間，且應于會議前 2天開始；評審者：收到組織者發(fā)來的評審包；審核工作產品、發(fā)現缺陷；填寫評審表單；反 饋評審表單給組

49、織者；組織者：檢查評審表單；裁決是否需要增加評審評審投入（增加準備時間；增加評 審專家人數；更換評審專家）4. 會議階段（2小時內；只提出問題，不關注解決）：組織者召開評審會議；講解員講解工作產品；（盡量不要由作者兼任）大家共同確認問題（評審表單中記錄的問題；會上發(fā)現的問題；當爭執(zhí)不 下時組織者應做出裁決）對已確認的問題進行分類；作者決定是否召開第三小時會議；記錄員記錄所有的問題及分類，并發(fā)給組織者；（記錄員盡量不要由作者和組織者擔任）組織者更新評審表單。5. 第三小時會議有爭議的問題繼續(xù)討論，給出決議；討論解決問題方案； 組織者更新評審表單。6. 返工：發(fā)回作者修改；7. 跟蹤：匯總所有需要

50、的數據到評審表單發(fā)給相關評審專家；（2組織者） -組織評審專家確認各缺陷得到了修改，并且沒有引入新的缺陷；-協(xié)助組織者確認相關問題得到了正確修改并且沒有引入新的缺陷；-確認評審表單中各相關度量數據正確（發(fā)現缺陷數；評審投入時間；評審專家 人數等）（評審專家2）a）配置&需求管理1、配置管理的目的和意義：目的：a.可視性：用戶/買方/賣方詳細知道工作內容；b. 管理層能夠知道產品特性；c. 所有的項目參與者在同一平臺下交流；d. 了解現在和計劃的配置；e. 管理層可看到變更的影響；f. 管理層可選擇參與的節(jié)點；目標：一項目：減少返工，減少工作量；r意義：L公司：節(jié)約成本，積累項目財富;可視性提高

51、； 項目可跟蹤性高;2、配置、基線、版本各自定義及關系:配 置：是軟件生命周期個階段產生的程序、數據、文件、環(huán)境的集合;配置項：是軟件生命周期個階段產生的程序、數據、文件、環(huán)境基 線：配置項在其生命周期的不同時間點上通過評審而進入正式受控的一種狀態(tài)，而這個過程被稱為“基線化”；版 本：是表示一個配置項具有一組定義的功能的一種標識；3、 變更控制的流程（各種角色、職責輸出）：項目成員、客戶代表、市場人員提交CR CMO將CR狀態(tài)表示為已提交，并將 CR根據條件進行判斷，把不需要 CCB進行審核的、決定采納的 CR直接進行簽發(fā)；把不需要 CCB進行審核的、不決定采納的 CR 直接關閉（4 CMO將CR狀態(tài)標識為已拒絕）；將需要CCB評審的CR提交給CCB進 行評估； CCB召開會議對CR進行評估 CMO