測試基礎總結

1、測試基礎總結第1章 軟件測試基礎1、軟件測試概論1)測試是為了度量和提高被測軟件的質量，對測試軟件進行工程設計、實施和維護的整個生命周期過程。2)軟件標準有：IEEE：（電氣和電子工程師協(xié)會）是一個國際性的電子技術與信息科學工程師的協(xié)會，是目前全球最大的非營利性專業(yè)技術學會； ANSI：美國國家標準學會，是非贏利性質的民間標準化團體； ISO：國際標準化組織，是國際標準化領域中一個十分重要全球性的非政府組織。3)軟件測試與軟件項目的關系：軟件測試是為軟件項目服務的，是為了發(fā)現(xiàn)軟件中存在的錯誤，其根本目的是提高軟件質量，降低軟件項目的風險（QA人員是保證軟件質量）；軟件的質量風險表現(xiàn)為內(nèi)部風險、

2、外部風險（風險更大）。軟件測試只能證明軟件存在錯誤，而不能證明軟件沒有錯誤，（軟件公司對軟件項目的期望是在預計的時間、合理的預算下，提交一個可以交付的產(chǎn)品），測試目的是把軟件的錯誤控制在一個可以進行產(chǎn)品交付/發(fā)布的程度上，可以交付/發(fā)布的產(chǎn)品并不是沒有錯誤的產(chǎn)品，而是將錯誤控制在一個合理的范圍內(nèi)4)第三方測試是指獨立于軟件公司自身測試的測試，第三方測試機構是通過自己專業(yè)化的測試手段為客戶提供有價值的服務。（一般進行的是系統(tǒng)測試）2、軟件測試的定義：使用人工和自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結果與實際結果之間的差別。是對軟件形成過程中的文檔、數(shù)據(jù)

3、和程序進行的測試。3、軟件測試的目的：一個成功的測試是(發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤)的測試。1）以最小的代價找出軟件中潛在的各種錯誤和缺陷，通過修正錯誤和缺陷來提高軟件質量，回避商業(yè)風險；2）度量與評估軟件的質量，為用戶選擇提供依據(jù)；3）測試是以評價一個程序或者系統(tǒng)屬性為目標的活動。通過分析錯誤，發(fā)現(xiàn)開發(fā)過程中的缺陷，以便進行改進，并為軟件可靠性分析提供依據(jù)；4）通過驗收測試（主要由用戶組織），證明軟件滿足了用戶的需求，樹立用戶的信心。4、軟件測試的主要工作：檢視代碼、評審開發(fā)文檔測試設計、寫作測試文檔（測試計劃、測試方案、測試用例等）執(zhí)行測試，發(fā)現(xiàn)軟件缺陷，提交缺陷報告，并確認缺陷得到了修正通過

4、測試度量軟件的質量5、軟件生命周期1）計劃：確定軟件開發(fā)總目標，相關設想（功能、性能、可靠性、接口）、方案（項目的可行性，問題的解決方案）、預估（資源、成本，效益，開發(fā)進度），制定實施計劃。2）需求分析：對開發(fā)的軟件進行詳細的定義，由需求分析人員和用戶共同討論決定，哪些是可以滿足的，并給予確切描述，寫出軟件需求說明書SRS。3）設計：設計是軟件工程的技術核心。概要設計（HLD，High level design），在設計階段把各項需求轉換成相應的體系結構，每一部分是功能明確的模塊；詳細設計（LLD，Low level design）,對每個模塊要完成的工作進行具體的描述。設計流程：SRS HL

5、D LLD 測試流程：UT IT ST 。4）編碼：寫源程序清單，建立數(shù)據(jù)庫。5）測試：檢驗軟件是否符合客戶需求，達到質量要求，一般由獨立小組執(zhí)行，分為單元測試（UT，參照LLD，對象是每一個函數(shù)）；集成測試（IT,參照HLD，函數(shù)與函數(shù)的集成，模塊與模塊的集成）；系統(tǒng)測試（ST，參照SRS，整個系統(tǒng)）。 6）運行和維護。（軟件修改原因：軟件錯誤、系統(tǒng)軟件升級、增強軟件功能、提高性能等）6、項目組架構7、常見的軟件研發(fā)流程：1）瀑布模型：應用最廣泛的一種模型，也是最易理解和掌握的。 2）螺旋模型：瀑布模型與快速原型模型結合起來，突出了風險分析。 3）RUP流程：統(tǒng)一軟件開發(fā)過程，利用商業(yè)的可靠

6、方法開發(fā)和部署軟件，是一種重量級過程，特別適用于大型軟件團隊開發(fā)大型項目。 4）敏捷模型：敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法，目標是提高開發(fā)效率和響應能力。提交新版本（敏捷）1、缺陷驗證只針對缺陷現(xiàn)象2、冒煙測試 3、新功能測試 4、回歸測試（非第一次），有無缺陷都叫回歸。迭代：把一個復雜且開發(fā)周期很長的開發(fā)任務，分解為很多小周期可完的任務，這樣一個周期就是一次迭代的過程。（用戶提出需求，開發(fā)人員開發(fā)出樣品，供用戶體驗與提出改進意見，再由開發(fā)人員改進，如此往復，直到開發(fā)出用戶滿意的軟件產(chǎn)品。） 8、軟件缺陷和bug軟件缺陷：既指靜態(tài)存在于軟件工作產(chǎn)品（文檔、代碼）中的錯誤，也指

7、軟件運行時由于這些錯誤被激發(fā)引起的和軟件產(chǎn)品預期屬性的偏離現(xiàn)象。Bug：代碼中的缺陷。所有缺陷可分為四類： 遺漏：規(guī)定的或預期的需求未體現(xiàn)在產(chǎn)品中 錯誤：未將規(guī)格說明正確實現(xiàn) （設計錯誤、編碼錯誤） 額外的實現(xiàn)：規(guī)格說明并未規(guī)定的需求被納入產(chǎn)品，得到實現(xiàn) 改進：軟件難以理解、不易使用、運行緩慢，或者從測試工程師的角度來看最終用戶會認為不好9、其他 60%以上的軟件錯誤是分析和設計錯誤，而不是程序錯誤。性能測試：（同時在線的）用戶數(shù)，響應時間，穩(wěn)定性。測試是公司內(nèi)部（邀請用戶到公司）進行的測試，測試是將軟件試用版本給用戶試用，一般測試先于測試執(zhí)行。調試：開發(fā)階段對代碼的調試（已知錯誤范圍，找出錯

8、誤并改正）。第2章 需求分析與管理1、軟件需求的定義：1）用戶解決某一問題或達到某一目標所需的軟件功能；2）系統(tǒng)或系統(tǒng)構件為了滿足合同、規(guī)約、標準或其他正式實行的文檔而必須滿足或具備的軟件功能。測試需求：明確項目中要測什么，要達到的目標是什么；力求詳細明確，避免測試遺漏與誤解 ；細化測試范圍與內(nèi)容，明確擬采用的測試技術。（見第6章 測試計劃與方案）2、需求的分類：功能需求：描述系統(tǒng)預期提供的功能或服務； 描述方式為文字描述、圖表表示； 功能需求描述應該完整、一致、準確。非功能需求：對實際使用環(huán)境所做的要求，主要與系統(tǒng)的總體特征有關（關心的是系統(tǒng)整體特征而不是個別特征）。是一些限制性要求：性能要

9、求，可靠性要求，安全性要求，可用性要求，移植性要求。3、軟件需求規(guī)格說明書（SRS，software requirement specification）：是需求定義任務的最終“產(chǎn)品”，描述了系統(tǒng)的數(shù)據(jù)、功能、行為、性能需求、設計約束、驗收標準，以及其他與需求相關的信息。軟件需求分為：用戶需求，開發(fā)需求，測試需求。4、軟件需求變更·合理范圍內(nèi)的變化：用戶不了解自己的需求，需求本身易變。·不合理的變化：需求文檔質量不高，分析技能、技術和管理上的缺陷。·需求變化的原因：未受控制的需求變更，遺漏需求，用戶交流不夠，需求規(guī)約質量差，低效的需求分析。5、需求變更管理的原則：

10、1）認識到變更是不可避免的，為變更指定計劃；2）確定需求基線；3）建立控制變更的唯一渠道；4)使用變更控制系統(tǒng)來控制變更過程；5）分層次的管理變更。6、軟件需求變更流程7、軟件需求跟蹤：跟蹤過程的主要活動是對RTM的維護，維護中建立以下四種跟蹤關系：1）分配給項目的需求項目的軟件需求規(guī)格概要設計詳細設計代碼2）項目的軟件需求規(guī)格系統(tǒng)測試項系統(tǒng)測試子項系統(tǒng)測試用例3）概要設計集成測試項集成測試子項集成測試用例4） 詳細設計單元測試項單元測試子項單元測試用例8、軟件需求規(guī)則定義1） 需求項 把任務分解為可以實現(xiàn)的符合要求的具體需求項，需求項落實到SRS。2） 概要設計項 將SRS中的需求項分解為多

11、個模塊，模塊間有明確接口，模塊的功能獨立（符合高內(nèi)聚低耦合原則），標識每一個模塊的項目即概要設計項，最終落實到概要設計說明書中。高內(nèi)聚：模塊內(nèi)部各個元素彼此結合的緊密程度；低耦合：軟件結構內(nèi)不同模塊之間互連程度，模塊之間盡可能使其獨立存在。3） 詳細設計項 把概要設計模塊細化到函數(shù)或函數(shù)組，函數(shù)或函數(shù)組即詳細設計項，最終落實到詳細設計說明書中。9、需求評審的重要性需求調研是最開始、最重要的工作。如何保證需求調研過程內(nèi)容的正確、準確性，成了決定軟件項目成敗的關鍵因素。軟件需求分析說明書的正確性必須得到徹底的驗證，利益相關方必須徹底理解需求，并達成一致；要達成這一目標、降低需求風險，需求評審是一個

12、行之有效的方法。10、如何有效進行需求評審：1）充分準備評審2）分層次評審 目標性需求（整個系統(tǒng)要達到的目標，企業(yè)高管關注），功能性需求（清楚需求邊界，中層管理人員關注），操作性需求（定義具體的人機交互，具體操作人員關注）。3）評審要控制時限4)跟蹤評審中問題的結果5）評審的結果基線11、內(nèi)部評審中評審文檔的目的：1）及時檢測出軟件需求文檔中具有不可測試性的需求點（如淘寶中第三方提供的物流信息）。2）及時發(fā)現(xiàn)需求文檔的不完整性，找出用戶提出的但未被完整描述的需求點，提醒需求分析人員描述完整。3）熟悉業(yè)務需求，與需求人員保持理解一致，及時發(fā)現(xiàn)文檔中有歧義、二義性、模糊的描述，從而提醒需求分析人員

13、以精確的文字來描述需求點。12、需求分析1）功能點梳理 根據(jù)SRS和產(chǎn)品界面原型梳理功能點，整理成功能矩陣列表。以功能點為基本采用等價類、邊界值等法設計用例。 功能分解法：業(yè)務功能，輔助功能，數(shù)據(jù)約束，易用性需求，編輯約束，參數(shù)需求，權限需求。2）業(yè)務流程 根據(jù)SRS，梳理并整理出系統(tǒng)所有業(yè)務流程(流程的完整性，數(shù)據(jù)傳遞的正確性，狀態(tài))。步驟如下： a. 在對整個軟件功能較熟悉的基礎上梳理業(yè)務流程（分析并了解軟件的業(yè)務流、數(shù)據(jù)流） b.畫出業(yè)務流程圖（工具有visio、word）13、其它1） SOW：工作說明書，AR：驗收要求，RTM：需求跟蹤矩陣。2）越早發(fā)現(xiàn)錯誤，修復錯誤所花代價越小。第

14、3章 測試過程與方法1、軟件測試階段分類測試階段 簡稱測試方法考察范圍測試目的評估基準單元測試UT白盒測試單元內(nèi)部的數(shù)據(jù)結構、邏輯控制、異常處理檢驗軟件模塊對詳細設計說明書的符合程度邏輯覆蓋率集成測試IT灰盒測試模塊之間的接口和接口數(shù)據(jù)傳遞，以及模塊組合后的整體功能對概要設計說明書的符合程度接口覆蓋率系統(tǒng)測試ST黑盒測試整個系統(tǒng)相對于需求的符合度對SRS的符合程度測試用例對 需求規(guī)格的覆蓋率2、回歸測試發(fā)現(xiàn)缺陷經(jīng)過修改后，應進行回歸測試，目的是驗證缺陷得到了修復，同時對系統(tǒng)的變更沒有影響以前的功能（未發(fā)現(xiàn)缺陷的模塊也應進行回歸測試）。可發(fā)生在任何階段。軟件配置：軟件需求規(guī)格、設計文檔、代碼、配

15、置數(shù)據(jù)等；測試配置：測試計劃、測試方案、測試用例、測試驅動；測試工具：自動化測試工具、相關自動化腳本、驅動測試的測試數(shù)據(jù)。回歸測試策略：·完全重復測試（執(zhí)行所有的測試用例，缺點是耗時長，易枯燥） ·選擇性重復測試：覆蓋修改法，周邊影響法，指標達成法。3、驗收測試（軟件正式發(fā)布前）1）（ALPPHA）測試 由用戶在開發(fā)環(huán)境下（或開發(fā)機構內(nèi)部用戶模擬實際操作環(huán)境下）進行的測試，目的是評價軟件產(chǎn)品的功能、局域化、可用性、可靠性、性能和技術支持。2）（BETA）測試 多個用戶在實際使用環(huán)境下進行的測試（開發(fā)者通常不在測試現(xiàn)場）。用戶試用。3）驗收測試 以用戶為主，原則上在用戶所在地

16、進行，測試依據(jù)為合同、SRS、驗收測試計劃。有時也包含、?？蛻趄炇?，第三方代驗收。4、測試過程階段 測試計劃階段測試計劃（做什么） 測試設計階段測試方案（怎么做） 測試實現(xiàn)階段測試用例、測試規(guī)程 測試執(zhí)行階段測試報告5、常見測試模型1）瀑布模型：應用最廣，最易理解和掌握的模型；缺點是遺漏或不斷變更的需求會使得該模型無所適從。2）V模型：反映測試活動與分析和設計的關系，需求分析等前期產(chǎn)生的錯誤直到后期的驗收測試才能發(fā)現(xiàn)。3）W模型：開發(fā)與測試同步，能較早發(fā)現(xiàn)軟件中的缺陷；局限是串行實施，前后依賴性較強，不利于變更。4）V&V模型：測試設計與測試執(zhí)行相分離。驗證 保證軟件正確實現(xiàn)特定功能，

17、檢測每一階段的產(chǎn)品是否與前一階段定義的規(guī)格相一致。確認 保證軟件可追溯到用戶需求，檢測每一階段的產(chǎn)品是否與最初定義的軟件需求規(guī)格相一致。6、測試方法1）白盒測試：依據(jù)是軟件分析程序內(nèi)部構造；對內(nèi)部控制流程進行測試；是基于程序結構的邏輯驅動測試?？砂l(fā)現(xiàn)80%的缺陷。靜態(tài)分析：控制流分析、數(shù)據(jù)流分析、信息流分析；動態(tài)分析：邏輯覆蓋（語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、路徑覆蓋）、程序插裝。2）黑盒測試：把對象看成一個黑盒，只考慮整體性，不考慮其內(nèi)部具體實現(xiàn)；基于規(guī)格的測試。軟件質量特性：功能性、可靠性、易用性、效率（性能）、維護性、可移植性。功能測試是驗證產(chǎn)品能否實現(xiàn)客戶需求的功能；性能測

18、試中產(chǎn)品性能主要受以下因素影響：同時在線用戶數(shù)、響應時間、穩(wěn)定性。常用黑盒測試方法：等價類、邊界值、因果圖等方法（詳見第7章 測試用例與設計）。方法優(yōu)點缺點白盒測試可檢測代碼中每條分支、路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比較徹底；優(yōu)化代碼結構。投入大、成本高；不驗證規(guī)格的正確性。黑盒測試比白盒測試效率高；不需要了解實現(xiàn)的細節(jié)，包括編程語言；從用戶視角測試，易被理解和接受；有助于暴露不一致或有歧義的問題；不能控制內(nèi)部執(zhí)行路徑，使很多路徑?jīng)]有被測試到；不能直接針對特定（很復雜）的程序段（可能隱藏更多問題）。3)靜態(tài)測試：不運行被測軟件。（如代碼走讀、文檔評審、程序分析）4)動態(tài)測試：按預先

19、設計的數(shù)據(jù)和步驟去運行被測軟件系統(tǒng)。（路徑測試、分支測試、性能測試）5)人工測試：測試活動由人來完成，這是最基本的測試形式。手工測試是自動化測試的基礎。6)自動化測試：通過計算機模擬人的行為，替代人的測試活動（重復性高、枯燥的工作）。不能取代手工測試，只能提高測試效率，不具有智能，不能發(fā)現(xiàn)更多缺陷。7、其它 1）測試規(guī)程：測試活動序列的文檔。 2）灰盒測試：既利用被測對象的整體特性信息，又利用被測對象的內(nèi)部具體實現(xiàn)信息，就可采用此法。第4章 系統(tǒng)測試與分類1、系統(tǒng)測試的定義與目的定義：將集成好的軟件系統(tǒng)，與計算機硬件、外設、支持軟件等結合起來進行的測試。目的：與SRS比較，發(fā)現(xiàn)軟件與其不相符的

20、地方。測試對象：軟硬件結合起來的系統(tǒng)。驗證時盡可能模擬實際運行環(huán)境。2、系統(tǒng)測試常用類型1) 功能測試 驗證產(chǎn)品功能是否符合SRS。2) 性能測試 測試軟件在集成系統(tǒng)中的運行性能，在功能測試后等功能穩(wěn)定后再進行。目標是度量系統(tǒng)相對于預定義目標的差距。 包括負載測試、壓力測試、容量測試（又稱大數(shù)據(jù)量測試）。3) 安全性測試 驗證系統(tǒng)內(nèi)的保護機制是否能夠保護系統(tǒng)不受非法侵入，保證系統(tǒng)數(shù)據(jù)的完整性和保密性。4) GUI測試 用戶界面測試 驗證界面實現(xiàn)是否吻合界面設計，確認界面處理的正確性。測試對象包括界面整體和界面中的元素5) 可用性測試 檢測用戶是否容易理解和使用系統(tǒng)。6) 可安裝性測試 檢測安裝

21、過程簡單程度，安裝時長的長短。主要進行安裝前、中、后的測試。7) 配置測試 測試系統(tǒng)在各種軟硬件、不同參數(shù)配置下系統(tǒng)的功能和性能。驗證配置的可操作性和有效性，特別需要對最大、最小、或特殊配置進行測試。8) 可靠性測試 軟件在規(guī)定條件下、規(guī)定時間內(nèi)完成規(guī)定功能的能力。指標有系統(tǒng)平均失效時間間隔MTBF、系統(tǒng)平均恢復時間MTTR。9) 備份測試 恢復性測試的補充。備份后驗證一下。10) 異常測試又叫系統(tǒng)容錯和可恢復性測試。通過人工干預使軟硬件產(chǎn)生異常，驗證異常前后的功能和狀態(tài)，達到檢驗系統(tǒng)容錯、排錯和恢復的能力。有計劃、可設計。11) 健壯性測試測試系統(tǒng)自動運行時出現(xiàn)故障，能否自動恢復或繼續(xù)運行。

22、如瀏覽器非正常關閉后可恢復。12) 文檔測試用戶文檔包括用戶手冊、操作手冊、維護手冊。保證用戶文檔的正確性、完整性、一致性、易用性。13) 在線幫助測試 保證在線幫助的準確性、完整性、易用性。14) 網(wǎng)絡測試 網(wǎng)絡環(huán)境下和其他設備對接，進行功能、性能、指標測試，保證設備對接正常。15) 穩(wěn)定性測試 評價系統(tǒng)在一定負荷下、長時間的運行情況。16) 兼容性測試 程序與軟、硬件之間兼容性的測試，包括硬件兼容、軟件兼容、數(shù)據(jù)庫兼容、數(shù)據(jù)兼容。Web兼容考慮三方面：操作系統(tǒng)平臺兼容、瀏覽器兼容、分辨率兼容。3、系統(tǒng)測試過程計劃階段：完成系統(tǒng)測試計劃（需要做什么）設計階段：完成測試方案（具體怎么做）實現(xiàn)階

23、段：測試用例、測試規(guī)程、預測試項執(zhí)行階段：執(zhí)行預測事項、測試用例，修改問題、回歸測試，提交（預測試、系統(tǒng)、缺陷）報告預測試的目的：驗證軟件系統(tǒng)基本功能或預測主要的系統(tǒng)功能。通常比冒煙測試時間長。冒煙測試只在系統(tǒng)測試中（因其需要運行環(huán)境，而單元測試和集成測試沒有運行環(huán)境）用于確認代碼中的更改會按預期運行，且不會破壞整個版本的穩(wěn)定性。冒煙測試是確定和修復軟件缺陷的最經(jīng)濟有效的方法。4、系統(tǒng)測試環(huán)境要素1）硬件環(huán)境：服務器、客戶端、網(wǎng)絡設備、測試儀器等；2）軟件環(huán)境（主、輔測試環(huán)境）：操作系統(tǒng)、數(shù)據(jù)庫、共存軟件、測試工具、相關手冊等。5、系統(tǒng)測試數(shù)據(jù)以消息、事務、記錄、文件等形式存在。數(shù)據(jù)來源有：產(chǎn)

24、品數(shù)據(jù)、手工構造、生成、捕獲、隨機。6、其它痛點：對用戶有用，讓用戶離不開；癢點：抓人眼球，讓人從心里喜歡。第5章 軟件質量與管理1、軟件質量質量的定義：實體基于實體特性滿足需求的程度。軟件質量的三個層次：符合需求規(guī)格（開發(fā)者明確定義的目標），符合用戶顯式需求（用戶明確說明的目標），符合用戶實際需求（用戶明確說明的和隱含的需求）。軟件質量的影響因素：2、軟件質量管理體系ISO9000（最寬泛，最易通過），CMMCMMI（最難通過），六西格瑪（適合服務行業(yè)）。（1）ISO9000：2000版主要由ISO9000（理論基礎）、ISO9001（明確規(guī)定）、ISO9004（改進）三個核心標準組成。20

25、00版八項質量管理原則： 以顧客為中心 領導作用 全員參與 過程方法 管理的系統(tǒng)方法 持續(xù)改進 基于事實的決策方法 互利的供方關系（2）軟件能力成熟度模型CMM（只有階段式表示）初始級，可重復級，已定義級，已管理級，優(yōu)化級。CMM的用途：1）評估組用來識別強處、弱點；2）評價組用來識別風險和監(jiān)督合同；3）管理者用來了解其組織的能力；4）技術人員和過程改進組用來指導定義和改進軟件過程。（3）軟件能力成熟度集成模型CMMI 完成級，已管理級，已定義級，量化管理級，優(yōu)化管理級。連續(xù)式表述可達到能力度等級（03），描繪特定流程領域中的狀態(tài)（如開發(fā)能力、測試能力、過程管理）。階段式表述可達到成熟度等級（

26、15），描繪整體狀態(tài)。（4）六西格瑪管理法以質量為主線，以客戶需求為中心，利用對事實和數(shù)據(jù)的分析，改進提升一個組織的業(yè)務流程能力，從而增強企業(yè)競爭力的管理方法體系。六西格瑪要求企業(yè)完全從外部客戶角度（而不是從自己角度）來看待企業(yè)內(nèi)部的各種流程。 原則：注重客戶，注重流程，全員參與，預防為主。3、軟件質量模型 6大特性，27個子特性。4、質量管理PDCA循環(huán)：Plan計劃，Do執(zhí)行，Check檢查，Action改進。5、軟件度量度量是對事物屬性的量化表示。 規(guī)模：軟件產(chǎn)品的大小； 工作量：完成各軟件產(chǎn)品和活動 所用人時； 進度：各軟件產(chǎn)品和活動 開始、結束的時間； 質量缺陷：在各軟件產(chǎn)品和活動中

27、產(chǎn)生的缺陷數(shù)。 缺陷密度、生產(chǎn)率、測試執(zhí)行效率、用例密度等度量指標可由以上四項基本度量項分析、計算得到。第6章 測試計劃與方案1、測試計劃測試計劃是從宏觀上反映項目的測試任務、階段等，不一定要太過詳細，但一定要切合實際，且不是一成不變（軟件需求、開發(fā)、人員流動等）的，需根據(jù)實際情況不斷調整。避免測試的“事件驅動”（消防式應對，哪里出現(xiàn)問題，就奔向哪里去解決）。測試計劃編寫6要素：why為什么要進行這些測試；what測試哪些方面，各階段的工作內(nèi)容；who項目組成人員有哪些，安排哪些測試人員測試；when測試中各階段的起止時間；where相應文檔，缺陷存放位置，測試環(huán)境等；how如何去做，使用哪些

28、測試工具及方法進行測試。測試計劃的內(nèi)容：測試目標，測試概要，測試范圍，重點事項，測試策略，資源需求，人員組織，測試進度安排，測試開始/完成/延遲/繼續(xù)的標準，質量目標，成果物，風險分析。2、測試需求和任務測試需求就是明確項目中要測什么，要達到的目標是什么；力求詳細明確，避免測試遺漏與誤解 ；細化測試范圍與內(nèi)容，明確擬采用的測試技術。需求分析三方面：質量模型，系統(tǒng)交互，用戶使用場景。測試需求分為軟件功能測試需求和非功能性的系統(tǒng)測試需求（性能要求、容錯處理、兼容性要求、安全性要求）測試需求通常以軟件需求轉變而來，但測試需求不等同于軟件需求。3、測試工作量估算工作分解結構表法（WBS）：以可交付成果

29、為導向對項目要素進行的分組，歸納和定義了項目的整個工作范圍每下降一層代表對項目工作的更詳細定義。工作量估算因素：效率（人員效率、自動化水平），測試動作（動作數(shù)、用例時間），階段（設計、開發(fā)、執(zhí)行等不同階段），復雜度（維數(shù)越高越復雜），風險（工作量的10%-20%），測試工作量的估計（W=W0+W0*R1+W0*R2+ W0*R3）。4、測試資源需求5、測試里程碑：項目中完成階段性工作的標志，定義當前階段完成的標準和新階段啟動的條件或前提。甘特圖（Gantt chart）：以圖示的方式通過活動列表和時間刻度表示出任何特定項目的活動順序與持續(xù)時間。6、測試風險分析 第7章 測試用例與設計1、黑盒測

30、試用例設計方法等價類劃分法邊值分析法因果圖法判定表法狀態(tài)遷移法流程分析法正交實驗法異常分析法錯誤猜測法2、等價類劃分法等價類：某個輸入域的集合，在這個集合中每個輸入條件都是等效的，如果其中一個的輸入不能導致問題發(fā)生，那么集合中其他輸入條件進行測試也不可能發(fā)現(xiàn)錯誤。有效等價類：程序規(guī)格說明有意義，合理的輸入數(shù)據(jù)，（設計一個測試用例使其盡可能多的覆蓋所有尚未覆蓋的有效等價類）。無效等價類：程序規(guī)格說明無意義，合理的輸入數(shù)據(jù)，（設計一個測試用例使其只覆蓋一個無效等價類）。設計用例步驟：為輸入劃分等價類，為每個等價類規(guī)定一個唯一編號。設計一個測試用例使其盡可能多的覆蓋所有尚未覆蓋的有效等價類，重復步驟

31、使所有有效等價類均被覆蓋。設計一個測試用例使其只覆蓋一個無效等價類，重復步驟使所有無效等價類均被覆蓋。3、邊值分析法上點：邊界上的點，封閉域的范圍內(nèi)，開放域的范圍外離點：離上點最近的一點。內(nèi)點：范圍內(nèi)的任意一點。設計用例步驟：分析輸入?yún)?shù)的類型等價類劃分確定邊界相關性分析形成測試項4、因果圖法因果圖提供了把規(guī)格轉化為判定表的系統(tǒng)化方法。適合于檢查輸入條件的各種組合情況。因果圖基本符號輸入條件的約束： E約束（異）： a、b中至多有一個可能為1。 I約束（或）： a、b、c至少有一個必須是1。 O約束（唯一）：a、b有且只有一個是1。 R約束（要求）：a是1時，b必須是1。輸出條件的約束： M約

32、束（強制）：a是1時，b強制為0。設計用例的步驟： 把大的系統(tǒng)規(guī)格分解成可測的規(guī)格片段 分析分解后的系統(tǒng)規(guī)格，找出原因、結果 畫出因果圖 把因果圖轉化成判定表 簡化判定表 將判定表中的每一項生成測試用例5、判定表法（最完善的）條件樁：列出了問題的所有條件（條件的次序無關緊要）。動作樁：列出了問題規(guī)定可能采取的操作（操作的排列順序沒有約束）。條件項：列出針對它左列條件的取值（所有可能下的真假值）。動作項：在條件項的各種取值下應該采取的動作。設計用例的步驟： 確定規(guī)則的個數(shù)填入條件項填入動作樁和動作項化簡，合并相似規(guī)則將每條規(guī)則轉化為用例判定表的優(yōu)缺點優(yōu)點：能把復雜的問題按各種可能的情況一一列舉出

33、來。缺點：合并存在漏測的風險。6、狀態(tài)遷移法 需求用狀態(tài)機的方式來描述，狀態(tài)機的測試主要關注在測試狀態(tài)轉移的正確性上面。通過測試狀態(tài)機驗證其在給定的條件內(nèi)是否能夠產(chǎn)生需要的狀態(tài)變化，常用于協(xié)議測試，可設計逆向的測試用例。設計用例的步驟： 畫出狀態(tài)遷移圖 列出狀態(tài)事件表 從狀態(tài)轉換樹推導出測試路徑 根據(jù)測試路徑編寫合法的測試用例 編寫非法的測試用例7、流程分析法把流程看成路徑，用路徑分析的方法來設計用例。設計用例的步驟：畫出業(yè)務流程圖確定測試路徑選取測試數(shù)據(jù)構造測試用例 8、測試用例綜合設計策略1）任何情況下都必須使用邊界值分析法2）必要時用等價類劃分法補充一些用例3) 用錯誤推測法追加一些用例

34、4）對照程序邏輯，檢查邏輯覆蓋程度5）程序功能說明中有輸入條件的組合情況，一開始就可選用因果圖法。設計用例的步驟：1） 構造基本功能測試用例2） 邊界值測試用例3） 狀態(tài)轉換測試用例4） 錯誤猜測測試用例5） 異常測試用例6） 性能測試用例7） 壓力測試用例9、 測試用例的寫法（注意質量，不要盲目追求效率）（1）測試用例編號 具有唯一性（不能重復）、易識別性。舉例：項目名稱_ST_FUN_功能模塊_TC001，Ecshop_ST_FUN_login_TC001 （2）測試項目 軟件需求項（ST）/集成后的模塊名或接口名（IT）/被測函數(shù)名（UT） （3）測試用例標題 用概括的語言描述該用例的出

35、發(fā)點和關注點。測試用例編號和標題不能重復。（4）測試用例優(yōu)先級：高：保證系統(tǒng)基本功能、核心業(yè)務、重要特性、使用頻率高的用例；中：介于高和低之間的用例；低：實際使用頻率不高、對系統(tǒng)業(yè)務功能影響不大的模塊或功能的用例。（5）測試用例預置條件 執(zhí)行當前測試用例需要的前提條件。（6）測試用例輸入 手工輸入、文件、數(shù)據(jù)庫記錄等。（7）測試用例操作步驟 明確給出每一個步驟的描述，測試用例執(zhí)行人員可以根據(jù)該操作步驟完成測試用例執(zhí)行。（8）測試用例預期結果 包括返回值內(nèi)容、界面相應結果、輸出結果的規(guī)則符合度等。第8章 配置管理與工具1、配置管理相關概念配置管理：對軟件生命周期不同時間點上的軟件配置進行標識，對

36、這些軟件配置項的更改進行系統(tǒng)控制，以達到保證軟件產(chǎn)品的完整性、可塑性的過程。配置：在技術文檔中明確說明并最終組成軟件產(chǎn)品的功能或物理屬性。包括產(chǎn)品特性、內(nèi)容與相關文檔，軟件版本，變更文檔，支持數(shù)據(jù)，保證軟件一致性的組成要素。 配置項：一組軟件功能或者物理屬性的組合，在配置管理中被作為一個單一的實體對待。（一臺電腦或服務器的配置參數(shù)等（關于硬件的）不叫配置項）2、基線配置項在其生命周期的不同時間點上通過評審而進入正式受控的一種狀態(tài)，而這個過程被稱為“基線化”?；€屬性： 通過正式的評審過程建立； 存在于配置庫中，基線的變更由CCB控制； 基線是進一步開發(fā)和修改的基準。3、軟件版本與配置項版本 （

37、1）軟件版本 表示一個配置項具有一組定義的功能的一種標識（版本號）。以xx.yy.zz.pp（主、次、維護、補丁版本號）的形式標識。一般項目只有主、次版本號；維護版本的產(chǎn)品可帶著不重要的缺陷上線，但這些缺陷最終還是要修復；補丁版本：一般的軟件是誰提出問題就把補丁版本發(fā)給誰，而操作系統(tǒng)一般因為使用人員多而統(tǒng)一更新補丁。（2）配置項版本 單個配置項在每次修改后都會發(fā)生變化，為了標識配置項在兩次修改之間的不同，需要對配置項的版本進行標識。 每個配置項（xx.yy，發(fā)生重大修改，xx從1遞增；只有小修改，yy從0遞增）都必須被唯一地標識。4、配置計劃與標識 PM制定配置管理計劃，是開展所有配置管理活動的基礎。 配置標識是對軟件配置進行管理的前提和基礎。5、基線變更請求：生在任何階段。6、配置管理工具SVN：服務器端與客戶端。服務器端主要熟悉以下操作：import（導入）,checkout（導出）,commit（提交）, update（更新）,add（新增）。7、配置庫的備份 務器與備份庫服務器最好放在不同的位置。 熱備份：一邊工作一邊備份； 冷備份：工作結束后再備份。第9章 缺陷管理1、缺陷相關術語Bug：電腦系統(tǒng)或程序中存在的破壞正常運轉