軟件測試培訓(xùn)筆記

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

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

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

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

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

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

7、；軟件配置管理。） CMM3：已定義級：Defined，過程被描述，并得到良好理解；（關(guān)鍵過程區(qū)域：組織過程定義；組織過程焦點；培訓(xùn)大綱；集成軟件管理；軟件產(chǎn)品工程；組際協(xié)調(diào)；同行評審。）CMM4：已管理級：Managed，過程被測量并受控；（關(guān)鍵過程區(qū)域：定量的過程管理；軟件質(zhì)量管理。）CMM5：優(yōu)化級，Optimizing，關(guān)注過程改進。（關(guān)鍵過程區(qū)域：缺陷預(yù)防；技術(shù)變更管理；過程變更管理。）7、 CMM的用途：a. 評估組用來識別組織中的強處和弱處； b. 評價組用來識別選擇不同的業(yè)務(wù)承包商的風(fēng)險和監(jiān)督合同； c. 管理者用來了解其組織的能力，并了解為了提高其能力成熟度而進行軟件過程改進

8、所需進行的活動； d. 技術(shù)人員和過程改進組用來作為指南，指導(dǎo)他們在組織中定義和改進軟件過程。8、 ISO9001和CMM的關(guān)系： 相似點：強調(diào)管理、過程、規(guī)范化和文檔化； 不同點：CMM把焦點對準(zhǔn)軟件；ISO9001的范圍包括：硬件、軟件、流程性材料和服務(wù)； 兩者關(guān)系：CMM2級與ISO9001強相關(guān)；CMM的每個關(guān)鍵過程域至少按某種解釋與ISO9001弱相關(guān)。9、六西格瑪?shù)膶嵤┓绞剑篋efine： 定義-提出問題，確定目標(biāo) Measure：測量-收集資料，尋找原因 Analyse：分析-研究資料，確定原因 Improve：改進-優(yōu)化解決方案 Control：控制-推行控制系統(tǒng)10、軟件質(zhì)量

9、模型: 功能性：當(dāng)軟件在指定條件下使用時，軟件產(chǎn)品提供滿足明確和隱含需求的功能的能力。包括：適合性；準(zhǔn)確性；互操作性；保密安全性；功能性的依從性。 可靠性：在指定條件下使用時，軟件產(chǎn)品維持規(guī)定的性能級別的能力。包括：成熟性；容錯性；易恢復(fù)性；可靠性的依從性。 易用性：在指定條件下使用時，軟件產(chǎn)品被理解、學(xué)習(xí)、使用和吸引用戶的能力。包括：易理解性；易學(xué)性；易操作性；吸引性；易用性的依從性。 效 率：在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品可提供適當(dāng)性能的能力。包括：時間特性；資源利用性；效率依從性。 維護性：軟件產(chǎn)品可被修改的能力。修改可能包括修正、改進或軟件對環(huán)境、需求和功能規(guī)格說明變化的

10、適應(yīng)。包括：易分析性；易改變性；穩(wěn)定性；易測試性；維護性的依從性。 可移植性：軟件產(chǎn)品從一種環(huán)境遷移到另外一種環(huán)境的能力。包括：適應(yīng)性；易安裝性；共存性；易替換性；可移植性的依從性。11、 SQA與測試的關(guān)系：測試從技術(shù)的角度來保證軟件質(zhì)量SQA從流程的角度保障軟件質(zhì)量組織用來保障SQA和測試的活動12、 SQA的主要工作范圍：· 指導(dǎo)并監(jiān)督項目按照過程實施； · 對項目進行度量、分析，增加項目的可視性； · 審核工作產(chǎn)品，評價工作產(chǎn)品和過程質(zhì)量目標(biāo)的復(fù)合度； · 進行缺陷分析，缺陷預(yù)防活動，發(fā)現(xiàn)過程的缺陷，提供決策參考，促進過程改進。13、 度量：對事

11、物屬性的量化表示；軟件度量：是指計算機軟件中范圍廣泛的測度，包括對軟件系統(tǒng)、構(gòu)建或生命周期過程具有的某個給定屬性的度的一個定量測量。目的：· 提高軟件生產(chǎn)率，縮短產(chǎn)品研發(fā)周期，降低研發(fā)成本、維護成本； · 提高軟件產(chǎn)品質(zhì)量，提高用戶滿意度； · 為組織持續(xù)改進提供量化的指標(biāo)和反饋。14、 軟件度量的作用：1) 理解；預(yù)測；評估；改進。2) 分類：規(guī)模；工作量；進度；質(zhì)量 15、如何將度量的知識應(yīng)用于實際工作中：建立測試工作的度量數(shù)據(jù)，目的是作為預(yù)測和改進的基礎(chǔ)a. 熟悉需求：進度、工作量、規(guī)模；b. 設(shè)計用例：工作效率、覆蓋率；c. 執(zhí)行用例：工作效率、缺陷密度；

12、）第三章 測試方法1、 什么是白盒測試： · 白盒測試是依據(jù)被測軟件，分析程序內(nèi)部構(gòu)造，并根據(jù)內(nèi)部構(gòu)造設(shè)計用例，來對內(nèi)部控制流程進行測試，可完全不顧程序的整體功能實現(xiàn)情況； · 白盒測試是基于程序結(jié)構(gòu)的邏輯驅(qū)動測試； · 白盒測試又可以被稱為玻璃盒測試、透明盒測試、開放盒測試、結(jié)構(gòu)化測試、邏輯驅(qū)動測試。2、 為什么進行白盒測試： · 一般在測試前期進行，通過達到一定的邏輯覆蓋率指標(biāo)，使得軟件內(nèi)部邏輯控制結(jié)構(gòu)上的問、難題能基本得到消除； · 能保證內(nèi)部邏輯結(jié)構(gòu)達到一定的覆蓋程度，能夠給予軟件代碼質(zhì)量更大的保證； · 發(fā)現(xiàn)問題后解決問題的

13、成本較低。3、 白盒測試的常用技術(shù)： · 靜態(tài)分析：控制流分析、數(shù)據(jù)流分析、信息流分析等； · 動態(tài)分析：邏輯覆蓋測試（分支測試、路徑測試等）、程序插裝等。4、 控制流相關(guān)概念：程序元素、控制流關(guān)系、控制流圖、控制流矩陣。（步驟：5）5、 控制流分析能發(fā)現(xiàn)的問題：1) 轉(zhuǎn)向并不存在的標(biāo)號；2) 沒有用的語句標(biāo)號；3) 從程序入口進入后無法達到的語句；4) 不能達到停機語句的語句。6、 數(shù)據(jù)流相關(guān)概念：數(shù)據(jù)的定義；數(shù)據(jù)的引用。（步驟：3）7、 數(shù)據(jù)流分析的作用：分析代碼中關(guān)于數(shù)據(jù)定義和引用方面的錯誤；進行代碼優(yōu)化。（賦值語句運算效率高）8、 信息流分析：輸入變量和語句關(guān)系；語

14、句和輸出變量關(guān)系；輸入和輸出變量管理。（步驟：4）9、 覆蓋率工具的作用： · 分析被測試代碼控制結(jié)構(gòu)，決定插裝位置；· 實施插裝；· 將插裝代碼重新編譯；· 執(zhí)行被測對象，根據(jù)插裝的監(jiān)控哨信息統(tǒng)計覆蓋率。10、 白盒測試的特點：· 測試人員需要了解軟件的實現(xiàn)；· 可以檢測代碼中的每條分支和路徑；· 揭示隱藏在代碼中的錯誤；· 對代碼的測試比較徹底；· 實現(xiàn)代碼結(jié)構(gòu)上的優(yōu)化；· 白盒測試投入較大，成本高；· 白盒測試不驗證規(guī)格的正確性。11、 什么是黑盒測試： · 黑盒測試把

15、被測對象看成一個黑盒，只考慮其整體特性，不考慮其內(nèi)部具體實現(xiàn)； · 黑盒測試針對的被測對象可以是一個系統(tǒng)、一個子系統(tǒng)、一個模塊、一個子模塊、一個函數(shù)等。 · 黑盒測試又可以被稱為基于規(guī)格的測試。12、 常見的黑盒測試類型：功能性測試；容量測試；負載測試；恢復(fù)性測試。13、 常見的黑盒測試方法：等價類、邊界值、因果圖、判定表、狀態(tài)遷移、正 交分解、錯誤猜測、輸入/輸出域覆蓋、14、 系統(tǒng)測試的時候，如果沒有SRS時，有兩類BUG無法發(fā)現(xiàn)：1）需求遺漏；2）需求偏差 15、 黑盒測試的優(yōu)點：· 對于更大的代碼單元來說（子系統(tǒng)甚至系統(tǒng)級）比白盒測試效率要高；·

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

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

18、：· 自動化測試不具備想象力，不能夠檢查腳本中給定的觀察點之外的錯誤；· 自動化測試只能提高測試效率，不能提高測試效果，不能發(fā)現(xiàn)比人工測試更多的問題；如被測對象不穩(wěn)定，存在變動性的話不適合開展自動化測試，否則腳本的編寫和維護所耗費的時間可能遠大于人工測試；· 只有手工測試積累到一定程度（提供更多的觀察點），才能做好自動化測試。第四章 測試過程1、 各階段測試的目的：1) 單元測試：檢測軟件模塊對詳細設(shè)計說明書的符合程度2) 集成測試：檢測軟件模塊對概要設(shè)計說明書的符合程度3) 系統(tǒng)測試：通過與需要規(guī)格說明書作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符或與之矛盾的地方。2、 單元

19、、集成、系統(tǒng)測試的比較：測試類型目的考察范圍評估基準(zhǔn)測試方法單元測試消除局部模塊的邏輯和功能上的錯誤和缺陷（消除單元、模塊內(nèi)部的邏輯和功能上的錯誤與缺陷）單元內(nèi)部的數(shù)據(jù)結(jié)構(gòu)、邏輯控制、異常處理等邏輯覆蓋率大量采用白盒測試方法集成測試找出與軟件設(shè)計相關(guān)的程序結(jié)構(gòu)，模塊調(diào)用關(guān)系，模塊間接口方面的問題（找出與軟件架構(gòu)設(shè)計相關(guān)的程序結(jié)構(gòu)，單元/子模塊間的調(diào)用關(guān)系，單元/子模塊間接口方米那的問題）接口和接口數(shù)據(jù)傳遞關(guān)系、模塊組合后的整體功能接口覆蓋率結(jié)合使用白盒與黑盒測試方法，較多采用黑盒方法構(gòu)造測試用例（也有說法叫灰盒測試方法）系統(tǒng)測試對整個系統(tǒng)進行一系列的整體、有效性測試（對系統(tǒng)規(guī)格中的功能與性能進

20、行一系列的有效性測試）整個系統(tǒng)對需求的符合度測試用例對需求規(guī)格的覆蓋率黑盒測試3、 回歸測試策略：完全重復(fù)測試；選擇性重復(fù)測試（覆蓋修改法；周邊影響法； 指標(biāo)達成方法；選擇重要級別高的測試用例）4、 回歸測試流程：1) 在測試策略制定階段，制定回歸測試策略2) 確定需要回歸測試的版本3) 回歸測試版本發(fā)布，按照回歸測試策略執(zhí)行回歸測試4) 回歸測試通過，關(guān)閉缺陷跟蹤單（問題單）5) 回歸測試不通過，缺陷跟蹤單返回開發(fā)人員，開發(fā)人員重新修改問題，再 次提交測試人員回歸測試5、 有用戶參與的其他一些測試：驗收測試、測試、測試6、 測試與測試的比較：Alpha測試Beta測試比較測試環(huán)境開發(fā)環(huán)境或者

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

22、；測試報告；測 試日報8、 驗證與確認V&V：驗證（VERIFICATION）強調(diào)過程；確認（VALIDATION）強調(diào) 結(jié)果。9、 V&V模型優(yōu)點： · 實現(xiàn)了測試設(shè)計和測試執(zhí)行相分離；· 揭示了軟件測試活動分層和分階段的本質(zhì)特性：測試執(zhí)行的順序與開發(fā)活動相反10、 V&V模型： 系統(tǒng)測試執(zhí)行集成測試執(zhí)行單元測試執(zhí)行代碼審查需求分析SRS評審SRS基線化概要設(shè)計HLD評審HLD基線化詳細設(shè)計LLD評審LLD基線化CODE系統(tǒng)測試計劃系統(tǒng)測試方案設(shè)計系統(tǒng)測試用例設(shè)計集成測試計劃集成測試方案設(shè)計集成測試用例設(shè)計單元測試計劃單元測試方案設(shè)計單元測試用例設(shè)

23、計11、 系統(tǒng)測試分為幾個階段，每個階段的輸入 /輸出是什么？系統(tǒng)測試階段輸入輸出系統(tǒng)測試計劃階段1.軟件開發(fā)計劃2.軟件測試計劃3.需求規(guī)格說明書系統(tǒng)測試計劃設(shè)計階段1.系統(tǒng)測試計劃2.需求規(guī)格說明書系統(tǒng)測試方案實現(xiàn)階段1.系統(tǒng)測試計劃2.系統(tǒng)測試方案3.需求規(guī)格說明書1.系統(tǒng)測試用例2.系統(tǒng)測試規(guī)程3.系統(tǒng)測試預(yù)測試項執(zhí)行階段1.系統(tǒng)測試計劃2.系統(tǒng)測試方案3.系統(tǒng)測試用例4.系統(tǒng)測試規(guī)程5.系統(tǒng)測試預(yù)測試項 6.集成測試報告1.系統(tǒng)預(yù)測試報告2.系統(tǒng)測試報告3.缺陷報告4.測試日報集成測試計劃階段1.軟件測試計劃2.概要設(shè)計說明書集成測試計劃設(shè)計階段1.概要設(shè)計說明書2.集成測試計劃集成

24、測試方案實現(xiàn)階段1.概要設(shè)計說明書2.集成測試計劃3.集成測試方案1.集成測試用例2.集成測試規(guī)程執(zhí)行階段1.集成測試計劃2.集成測試方案3.集成測試用例4.集成測試規(guī)程1.集成測試報告2.缺陷報告單元測試計劃階段1.軟件測試計劃2.詳細設(shè)計說明書單元測試計劃設(shè)計階段1.詳細設(shè)計說明書2.單元測試計劃單元測試方案實現(xiàn)階段1.詳細設(shè)計說明書2.單元測試計劃3.單元測試方案1.單元測試用例2.單元測試規(guī)程執(zhí)行階段1.單元測試計劃2.單元測試方案3.單元測試用例4.單元測試規(guī)程1.單元測試報告2.缺陷報告第五章 單元測試1、 單元的基本屬性：1) 明確的功能2) 可定義的規(guī)格3) 與其他單元接口的清

25、晰劃分2、 單元測試的目的：在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯誤，主要是基于白盒測試。a) 驗證代碼是與設(shè)計相符合的；b) 發(fā)現(xiàn)設(shè)計和需求中存在的錯誤；c) 發(fā)現(xiàn)在編碼過程中引入的錯誤。（和設(shè)計不相符或和設(shè)計相符，但是由于編碼疏漏引起）3、 單元測試關(guān)注的重點：出錯處理體現(xiàn)軟件的成熟性和容錯性、單元接口、局部數(shù)據(jù)結(jié)構(gòu)、獨立路徑、邊界條件 4、 單元測試的主要關(guān)注點：1) 參數(shù)的屬性、順序、個數(shù)是否與LLD一致2) 不能修改只做輸入用的形參，否則可能導(dǎo)致數(shù)據(jù)的錯誤修改3) 約束條件是否通過形參來傳送5、 驅(qū)動和樁的功能：1) 驅(qū)動單元：被測函數(shù)的主函數(shù)，能接受輸入數(shù)據(jù)，輸出實際測試結(jié)果2） 樁單

26、元：用來代替所測單元調(diào)用的子單元6、 單元測試策略：孤立的測試策略、自頂向下、自底向上的單元測試策略1) 孤立的測試策略：· 方法：不考慮每個模塊與其他模塊之間的關(guān)系，為每個模塊設(shè)計樁模塊和驅(qū)動模塊。每個模塊進行獨立的單元測試。 · 優(yōu)點：該方法是最簡單，最容易操作的?？梢赃_到高的結(jié)構(gòu)覆蓋率。該方法是純粹的單元測試。 · 缺點：樁函數(shù)和驅(qū)動函數(shù)工作量很大，效率低。2) 自頂向下的單元測試策略：· 方法：先對最頂層的單元進行測試，把頂層所調(diào)用的單元做成樁模塊。其次對第二層進行測試，使用上面已測試的單元做驅(qū)動模塊。如此類推直到測試完所有模塊。· 優(yōu)

27、點：可以節(jié)省驅(qū)動函數(shù)的開發(fā)工作量，測試效率較高。 · 缺點：隨著被測單元一個一個被加入，測試過程將變得越來越復(fù)雜，并且開發(fā)和維護的成本將增加。3) 自底向上的單元測試策略：· 方法：先對模塊調(diào)用層次圖上最低層的模塊進行單元測試，模擬調(diào)用該模塊的模塊做驅(qū)動模塊。然后再對上面一層做單元測試，用下面已被測試過的模塊做樁模塊。以此類推，直到測試完所有模塊。· 優(yōu)點：可以節(jié)省樁函數(shù)的開發(fā)工作量，測試效率較高。 · 缺點：不是純粹的單元測試，底層函數(shù)的測試質(zhì)量對上層函數(shù)的測試將產(chǎn)生很大的影響。5、 單元測試的四個階段：· 測試計劃：完成單元測試計劃； &#

28、183; 測試設(shè)計：完成單元測試方案； · 測試實現(xiàn)：完成單元測試用例、單元測試規(guī)程、單元測試腳本及數(shù)據(jù)文件； · 測試執(zhí)行：執(zhí)行單元測試用例，修改發(fā)現(xiàn)的問題并進行回歸測試，提交單元測試報告。² 單元測試：樁&驅(qū)動舉例：無論是單元測試還是集成測試都涉及到以下三個函數(shù)：主控函數(shù)：int ctrl(int x, int y)加法函數(shù)：int add(int x, int y)減法函數(shù)：int sub(int x, int y)注意：進行單元測試時，設(shè)計用例時依據(jù)的是LLD；進行集成測試時，設(shè)計測試用例依據(jù)的是HLD。下面給出來的是需要測試的實際的代碼。int

29、ctrl(int x, int y)int temp=0;if(x>=y) temp=add(x, y);else temp=sub(x, y);return temp;int add(int x, int y) return(x+y);int sub(int x, int y) return(x-y);² 自頂向下單元測試策略不同測試步驟中的驅(qū)動可以寫到一起，也可以分開寫，這里是寫到一起了。ü 測試ctrl函數(shù)需要寫一個驅(qū)動和兩個樁。Ø 驅(qū)動函數(shù)void driver()int ret=0;ret=ctrl(2,1); /x>yif(ret=3) p

30、rintf(“testcase JISUAN_UT_CTRL_001 pass”);else printf(“testcase JISUAN_UT_CTRL_001 fail”);ret=ctrl(1,1); /x=yif(ret=2) printf(“testcase JISUAN_UT_CTRL_002 pass”);else printf(“testcase JISUAN_UT_CTRL_002 fail”);ret=ctrl(1,2); /x<yif(ret=-1) printf(“testcase JISUAN_UT_CTRL_003 pass”);else printf(“t

31、estcase JISUAN_UT_CTRL_003 fail”);Ø 樁函數(shù)int stub_add(int x, int y)if(x=2 && y=1) return 3;if(x=1 && y=1) return 2;return 999999;int stub_sub(int x, int y)if(x=1 && y=2) return -1;return 999999;Ø 修改代碼為了讓樁能體現(xiàn)在測試過程中，需要修改ctrl函數(shù)：int ctrl(int x, int y)int temp=0;if(x>=y

32、) temp=stub_add(x, y);else temp=stub_sub(x, y);return temp;ü 測試add函數(shù)Ø 驅(qū)動函數(shù)同測試ctrl函數(shù)時的驅(qū)動Ø 樁函數(shù)同測試ctrl函數(shù)時sub函數(shù)對應(yīng)的樁Ø 修改代碼int ctrl(int x, int y) int temp=0;if(x>=y) temp=add(x, y); if(x=2 && y=1 && temp=3) printf(“testcase JISUAN_UT_ADD_001 pass”); else printf(“test

33、case JISUAN_UT_ADD_001 fail”); if(x=1 && y=1 && temp=2) printf(“testcase JISUAN_UT_ADD_002 pass”); else printf(“testcase JISUAN_UT_ADD_002 fail”);else temp=stub_sub(x, y);return temp;測試sub函數(shù)Ø 驅(qū)動函數(shù)同測試ctrl函數(shù)時的驅(qū)動Ø 樁函數(shù)無Ø 修改代碼int ctrl(int x, int y) int temp=0;if(x>=y) te

34、mp=add(x, y);else temp=sub(x, y); if(x=1&&y=2 && temp=-1) printf(“testcase JISUAN_UT_SUB_001 pass”); else printf(“testcase JISUAN_UT_SUB_001 fail”);return temp; 第六章 集成測試1. 集成測試的目的：確保各組件組合在一起后能夠按照既定意圖寫作運行，并確保增量的行為正確（屬于灰盒測試）1) 驗證接口是否與設(shè)計相符2) 發(fā)現(xiàn)設(shè)計和需求中存在的錯誤2. 集成測試關(guān)注的重點：單元間的接口、集成后的功能3. 集成測

35、試的層次：模塊內(nèi)集成、子系統(tǒng)內(nèi)集成、子系統(tǒng)間集成4. 集成測試策略：1) 大爆炸集成2) 自頂向下集成3) 自底向上集成4) 三明治（混合式）集成重要5) 基干集成6) 分層集成7) 基于功能的集成8) 基于消息的集成實際中應(yīng)用較多9) 基于進度的集成10) 基于風(fēng)險的集成5. 各種集成測試策略的優(yōu)缺點：優(yōu)點缺點適用范圍大爆炸集成1.只要極少數(shù)的驅(qū)動和樁2.可并行工作，人力、物力資源利用率較高1.一次運行成功的可能性不大2.定位和修改錯誤比較困難3.會有很多接口錯誤進入到系統(tǒng)測試1.維護型項目（增強型）2.每個函數(shù)都經(jīng)過了充分單元測試的小規(guī)模系統(tǒng)（特別是接口函數(shù)）自頂向下1.較早驗證了主要的控

36、制點和判斷點2.選用按深度方向組裝的方式，可首先實現(xiàn)和驗證一個完整的軟件功能3.功能可行性較早得到證實（帶來信心）4.最多只需一個驅(qū)動，減少驅(qū)動開發(fā)費用5.支持故障隔離1.樁的開發(fā)和維護成本大2.底層組件行為的驗證被推遲了3.底層組件的測試不充分1.產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定2.產(chǎn)品高層接口變化較小3.產(chǎn)品底層接口未定義或經(jīng)?？赡鼙恍薷?.產(chǎn)品控制組件具有較大的技術(shù)風(fēng)險，需要盡早被驗證5.希望盡早看到產(chǎn)品的系統(tǒng)功能行為自底向上1.允許對底層組件行為的早期驗證2.工作初期可以并行進行集成3.減少了樁的工作量4.支持故障隔離1.驅(qū)動的開發(fā)和維護成本高2.對高層的驗證被推遲到了最后，設(shè)計上的錯誤不能

37、被及時發(fā)現(xiàn)1.底層接口比較穩(wěn)定、變動較少的產(chǎn)品2.高層接口變化較頻繁的產(chǎn)品3.底層組件較早被完成的產(chǎn)品三明治集成集合了自頂向下和自底向上策略的優(yōu)點中間層在被集成前測試不充分大部分軟件開發(fā)項目基干集成具有三明治集成的優(yōu)點1.必須對系統(tǒng)的結(jié)構(gòu)和相互依存性進行仔細分析2.必須開發(fā)驅(qū)動和樁3.有些接口可能測試不充分大型復(fù)雜項目基于功能集成/基于消息集成1.可盡快看到關(guān)鍵功能的實現(xiàn)，并驗證正確性2.進度上要短3.可減少驅(qū)動的開發(fā)1.對有些接口測試不充分，會丟失許多接口錯誤2.可能會有較大的冗余測試基于進度集成1.具有比較高的并行度2.能有效縮短項目開發(fā)的進度1.許多接口要到后期才能驗證，無法發(fā)現(xiàn)有效的接

38、口問題2.樁和驅(qū)動開發(fā)工作量大3.由于進度，組件很不穩(wěn)定且會不斷變動，導(dǎo)致測試的重復(fù)和浪費進度優(yōu)先級高于質(zhì)量的項目基于風(fēng)險集成最具有風(fēng)險的組件最早進行驗證，有助于系統(tǒng)的快速穩(wěn)定需要對各組件的風(fēng)險有一個清晰的分析第七章 系統(tǒng)測試1. 系統(tǒng)測試目的：1) 通過與需求做比較，發(fā)現(xiàn)與系統(tǒng)定義不符合或與之矛盾的地方2) 系統(tǒng)測試的用例應(yīng)根據(jù)需求分析說明書來設(shè)計，并在實際使用環(huán)境下運行2. 系統(tǒng)測試對象1) 軟硬件集合在一起的系統(tǒng)2) 驗證時應(yīng)盡可能模擬實際的運行環(huán)境與條件3. 系統(tǒng)測試常用類型：功能、性能、壓力、容量、安全性、GUI、可用性、安裝、配置、異常（恢復(fù)性）、備份、健壯性、文檔、在線幫助、網(wǎng)絡(luò)

39、、穩(wěn)定性測試4. 功能測試：1) 概念：根據(jù)產(chǎn)品的SRS和測試需求列表，驗證產(chǎn)品的功能實現(xiàn)是否符合產(chǎn)品的需求規(guī)格2) 目標(biāo)：為了發(fā)現(xiàn)以下幾類錯誤a) 是否有不正確或遺漏了的功能b) 功能實現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計的隱藏需求c) 輸入能否正確接受？能否正確輸出結(jié)果？5. 性能測試：1) 概念：用來測試軟件在集成系統(tǒng)中的運行性能2) 目標(biāo)：度量系統(tǒng)相對于預(yù)定義目標(biāo)的差距3) 工具：LoadRunner、WebLoad、SilkPerformer4) 重要性：a) 性能是質(zhì)量的重要組成部分b) 給用戶樹立良好形象c) 節(jié)省成本的重要手段6. 性能測試的關(guān)鍵：有效的協(xié)調(diào)、正確的模型、瓶頸的定位、合

40、理的建議7. 性能需求五大特性：需求行、代表性、完整性、可測試性、可用性8. 壓力測試：關(guān)注穩(wěn)定性和破壞性1) 目的：調(diào)查系統(tǒng)在其資源超負荷的情況下的表現(xiàn)2) 目標(biāo)：通過極限測試方法，發(fā)現(xiàn)系統(tǒng)在極限或惡劣環(huán)境中自我保護能力，主要驗證系統(tǒng)的可靠性。9. 容量測試：1) 目的：使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理2) 關(guān)注點：a) 整體的業(yè)務(wù)流量（一般關(guān)注靜態(tài)容量） b) 數(shù)據(jù)庫的容量 c) 最大文件數(shù)目 d) 最大事務(wù)數(shù)10. 安全性測試：口令認證、加解密技術(shù)、權(quán)限管理、安全日志11. GUI測試：1) 關(guān)注點：界面實現(xiàn)與界面設(shè)計的吻合情況、確認界面處理的正確性2) 對象：簡單界面元

41、素、組合類界面元素、完整界面（窗口）3) 內(nèi)容：外觀、界面元素行為、布局、友好功能12. 可用性測試：關(guān)注點：1) 過分復(fù)雜的功能或指令2) 困難的安裝過程3) 錯誤信息過于簡單4) 用戶被迫去記住太多的信息5) 語法、格式和定義不一致13. 配置測試：概念：測試系統(tǒng)在各種軟硬件配置、不同的參數(shù)配置下系統(tǒng)具有的功能和性能目標(biāo)：驗證全部配置的可操作性和有效性，特別需要對最大配置、最小配置或特殊配置進行測試14. 異常測試：概念：又叫系統(tǒng)容錯和可恢復(fù)性測試，通過人工干預(yù)手段使系統(tǒng)產(chǎn)生軟、硬件異常，通過驗證系統(tǒng)異常前后的功能和運行狀態(tài)，達到檢驗系統(tǒng)的容錯、排錯和恢復(fù)的能力。它是系統(tǒng)可靠性評價的重要手

42、段。容錯處理：系統(tǒng)自動處理、人工干預(yù)處理系統(tǒng)可靠性指標(biāo)：平均失效時間間隔（MTBF）、平均恢復(fù)時間（MTTR）系統(tǒng)可靠性設(shè)計技術(shù)：1) 避開錯誤2) 容錯技術(shù)：結(jié)構(gòu)冗余（動、靜態(tài)）、信息冗余、時間冗余、硬件冗余、附加冗余技術(shù)15. 健壯性測試：Robustness Testing用于測試系統(tǒng)在出現(xiàn)故障時，是否能夠自動恢復(fù)或忽略故障繼續(xù)運行16. 網(wǎng)絡(luò)測試：概念：在網(wǎng)絡(luò)環(huán)境下和其他設(shè)備對接，進行系統(tǒng)功能、性能與指標(biāo)方面的測試，保證設(shè)備對接正常。內(nèi)容：考察系統(tǒng)的處理能力、系統(tǒng)兼容性、系統(tǒng)穩(wěn)定可靠性及用戶使用等方面。1) 一致性測試：檢測系統(tǒng)與協(xié)議規(guī)范符合程度2) 性能測試：檢測協(xié)議實體或系統(tǒng)的性能

43、指標(biāo)3) 互操作性測試：4) 堅固性測試：檢測協(xié)議實體或系統(tǒng)在各種惡劣環(huán)境下運行的能力17. 系統(tǒng)穩(wěn)定性測試：目的是評價系統(tǒng)在一定負荷情況下、長時間的運行情況。第八章 測試覆蓋率1. 覆蓋率概念：· 覆蓋率是用來度量測試完整性的一個手段。覆蓋率是測試技術(shù)有效性的一個度量。覆蓋率=（至少被執(zhí)行一次的item數(shù)）/item的總數(shù)；· 覆蓋率大體可以劃分為兩大類：邏輯覆蓋和功能覆蓋；· 測試用例設(shè)計不能一味追求覆蓋率，因為測試成本雖覆蓋率的增加而增加。2. 邏輯覆蓋主要類型：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、路徑覆蓋。3. 語句覆蓋率：（Statement

44、Coverage），在測試時運行被測程序后，程序中被執(zhí)行到的可執(zhí)行語句的比率； 語句覆蓋率 = （至少被執(zhí)行一次的語句數(shù)量）/（可執(zhí)行的語句總數(shù)）4. 分支覆蓋率：（Branch Coverage）也叫判定覆蓋（Decision Coverage），它的含義是：在測試時運行被測程序后，程序中所有判斷語句的取真分支和取假分支被執(zhí)行到的比率；判定覆蓋率=（判定結(jié)果被評價的次數(shù)）/（判定結(jié)果的總數(shù)）5. 條件覆蓋率：（Condition Coverage）的含義是，在測試時運行被測程序后，所有判斷語句中每個條件的可能取值（真值和假值）出現(xiàn)過的比率；條件覆蓋率=（條件操作數(shù)值至少被評價一次的數(shù)量）/（

45、條件操作數(shù)值的總數(shù)）6. 分支-條件覆蓋率：（Branch Condition Coverage）也叫判定條件覆蓋（Decision Condition Coverage），它的含義是，在測試時運行被測程序后，所有判斷語句中每個條件的所有可能值（為真為假）和每個判斷本身的判定結(jié)果（為真為假）出現(xiàn)的比率；分支條件覆蓋率=（條件操作樹枝或判定結(jié)果至少被評價一次的數(shù)量）/（條件操作數(shù)值總數(shù)+判定結(jié)果總數(shù)）7. 路徑覆蓋率：（Path Coverage）的含義是，在測試時運行被測程序后，程序中所有可能的路徑被執(zhí)行過的比率；路徑覆蓋率=（至少被執(zhí)行到一次的路徑數(shù)）/（總的路徑數(shù)）8. 其他覆蓋率：功能覆

46、蓋率；面向?qū)ο蟮母采w率；函數(shù)覆蓋；指令塊覆蓋；判定路徑覆蓋。第九章 測試用例舉例測試用例編號BOSS_ ST_ MARKETING_NEW_01P重要級別高（還有“較高、中、較低、低”幾個等級）測試項目新增營銷記錄測試標(biāo)題新增10元的營銷記錄用例類型基本事件（對應(yīng)還有“備選事件”、“異常事件”）用例設(shè)計者songfun設(shè)計日期2005-04-25對應(yīng)需求編號REQ_ MARKETING_NEW_01對應(yīng)UIMarketing.htm對應(yīng)UCUC_ MARKETING_NEW_01版本號Build v0.1對應(yīng)開發(fā)人員Frank預(yù)置條件操作員登錄營銷管理系統(tǒng)測試方法等價類劃分（對應(yīng)還有“錯誤猜測

47、法”、“邊界值分析”等）輸 入用戶名：51testing 性別：男 金額：10元 描述：aaaaaaa操作步驟. 進入【營銷下發(fā)】頁面；. 點擊增加按鈕；. 輸入相應(yīng)數(shù)據(jù)；. 點擊確定按鈕；. 在后臺數(shù)據(jù)庫(test/testtestDB)輸入查詢語句驗證：select * from MarketingTab where ID='1001'預(yù)期輸出1. 執(zhí)行步驟后，頁面彈出添加成功提示信息框；2. 執(zhí)行步驟后查詢數(shù)據(jù)庫，記錄確實添加成功且數(shù)據(jù)無誤第十章 測試經(jīng)驗和誤區(qū)1. 軟件測試的誤區(qū)：1) 測試和調(diào)試是一樣的2) 測試組應(yīng)當(dāng)為保證質(zhì)量負責(zé)3) 過分依賴BETA測試4) 把測

48、試作為新員工的一個過渡工作5) 把不合格的開發(fā)人員安排做測試6) 關(guān)注于測試的執(zhí)行而忽略測試的設(shè)計7) 自動化測試是萬能的8) 測試是可以窮盡的9) 測試是為了證明軟件的正確性10) 測試是枯燥乏味，缺乏創(chuàng)造力的工作2. 軟件測試的10大原則：1) 測試是一個持續(xù)改進的過程，而不是一個階段2) 測試必須被計劃、被控制、并且被提供時間和資源3) 測試應(yīng)當(dāng)分級別4) 測試應(yīng)當(dāng)有重點5) 測試不是為了證明程序的正確性，而是為了證明程序不能工作6) 測試是不可能窮盡的，當(dāng)測試出口條件滿足時就可以停止測試7) 測試是開發(fā)的朋友，不是敵人8) 測試人員應(yīng)當(dāng)站在公正的立場上進行測試，如實的記錄和報告缺陷9)

49、 自動化測試能解決一部分問題，但不是全部10) 測試不能僅僅包括功能性的驗證，還應(yīng)當(dāng)包含性能、可靠性、可維護型、安全性等方面的驗證3. 軟件測試的10個最佳實踐：1) 盡早的、頻繁的進行測試-降低成本、提高質(zhì)量2) 盡早的產(chǎn)生一個綜合的主測試計劃3) 對質(zhì)量要求較高的產(chǎn)品或大型復(fù)雜的產(chǎn)品成立獨立的測試組4) 在每個開發(fā)階段，使用測試和評價的結(jié)果作為是否可以通過的標(biāo)準(zhǔn)5) 開發(fā)和維護一個測試需求和目標(biāo)的風(fēng)險優(yōu)先級列表6) 把測試作為產(chǎn)品的一部分等同起來，使用相同的評價標(biāo)準(zhǔn)和過程7) 提供集成化的測試工具和測試技術(shù)支持8) 加強測試度量工作和缺陷分析工作，不斷地改進測試9) 加強測試的培訓(xùn)并且為測

50、試人員提供技能發(fā)展的通道10) 加強溝通和交流，讓項目組內(nèi)所有人員都了解測試的重要性和測試的工作a) 同 行 評 審1. 同行評審：（Peer Review）是一種通過作者的同行來確認缺陷和需要變更區(qū)域的檢查方法。需要進行同行評審的特定產(chǎn)品在定義項目軟件過程的時候被確定并且作為軟件開發(fā)計劃的一部分被安排了進度。a) · 需要前期準(zhǔn)備、計劃和時間進度表b) · 越早越好2. 同行評審的作用： · 早期發(fā)現(xiàn)缺陷；· 去除缺陷；· 降低成本；· 提高質(zhì)量。3. 同行評審的類型： · 正規(guī)檢視：（Inspection）最嚴格，要求有

51、規(guī)范的流程，參加者經(jīng)過正式培訓(xùn)；· 技術(shù)評審：（Technique Review）以技術(shù)方案的比較、裁決為目的，嚴格程度介于正規(guī)檢視和走讀之間；· 走 讀：（Walk Through）最（自由）松散的形式，無流程要求，有評審團隊，評審流程無要求。4. 通用評審流程步驟（正規(guī)檢視流程）：YY出 口5.第三小時會議6.返工階段N7.跟蹤階段第三小時會議？入口準(zhǔn)則N介紹會議？1.計劃階段2.介紹會議3.準(zhǔn)備階段4.Review會議計劃階段：· 項目負責(zé)人指定組織者；·作者自檢工作產(chǎn)品；· 組織者規(guī)劃本次評審；· 檢查入口準(zhǔn)則：是否符合文檔標(biāo)

52、準(zhǔn)？是否已用工具檢查？代碼<=500行； 文檔<=40頁；· 準(zhǔn)備評審包：工作產(chǎn)品（HLD）；參考資料（SRS-檢查一致性）；評審表（Review Form）；查檢表（Checklist）。· 指定評審專家（3-6人）；· 組織者將評審包、評審?fù)ㄖ獑伟l(fā)給相關(guān)人員。介紹會議：· 被評審對象采用新技術(shù)、新方法；· 被評審對象第一次被評審 à（作者介紹被審對象以及相關(guān)技術(shù)）· 評審專家第一次參加評審 à （評審者介紹評審流程）· 介紹會議的召開距接到評審?fù)ㄖ臅r間大于5小時；· 介紹會議的時間不超過1小時，30-60間為宜，關(guān)注講解。3. 準(zhǔn)備階段：（最重要、發(fā)現(xiàn)缺陷最多）· 評審專家個人獨立完成工作產(chǎn)品的審視，提出缺陷；· 準(zhǔn)備時間 大于 會議時間，且應(yīng)于會議前2天開始；· 評審者：收到組織者發(fā)來的評審包；審核工作產(chǎn)品、發(fā)現(xiàn)缺陷；填寫評審表單；反饋評審表單給組織者； 組織者：檢查評審表單；裁決是否需要增加評審評審?fù)度耄ㄔ黾訙?zhǔn)備時間；增加評審專家人數(shù)；更換評審專家）4. 會議階段（2小時內(nèi)；只提出問題，不關(guān)注解決）：· 組織者召開評審會議；· 講解員講解工作產(chǎn)品；（盡量不要由作者兼任）&#