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

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

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

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

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

5、發(fā)工具本身隱藏的問題。等等17. 缺陷類型：遺漏、錯(cuò)誤、額外的實(shí)現(xiàn)。第二章軟件質(zhì)量1、2b.3、軟件質(zhì)量的定義：一個(gè)實(shí)體的所有特性，基于這些特性可以滿足明顯的或隱含的需求。而質(zhì)量就是實(shí)體基于這些特性滿足需求的程度。軟件質(zhì)量的三個(gè)層次：符合用戶顯示需求；c.影響軟件質(zhì)量的因素：a.符合需求規(guī)格;4、符合用戶實(shí)際需求。流程、技術(shù)、組織。流程：一組活動（活動是否都是必須的，活動角色之間的關(guān)系）過程：一組將輸入轉(zhuǎn)化為輸出的相關(guān)聯(lián)或相互作用的活動。八項(xiàng)質(zhì)量管理原則：d.a.5、g.八項(xiàng)質(zhì)量管理原則的意義:bc.d.6、CMM1CMM2:以顧客為中心；b.領(lǐng)導(dǎo)作用；c.全員參與；過程方法；e.管理的系統(tǒng)方

6、法；f.持續(xù)改進(jìn)；基于事實(shí)的決策方法；h.互利的供方關(guān)系。a.是質(zhì)量管理的理論基礎(chǔ)；用高度概括易于理解的語言所表述的質(zhì)量管理的最基本，最通用的一般性規(guī)律；為組織建立質(zhì)量管理體系提供了理論依據(jù)；是組織的領(lǐng)導(dǎo)者有效的實(shí)施質(zhì)量管理工作必須遵循的原則。,不可預(yù)測并且缺乏控制；CMM3:初始級，Initial可重復(fù)級：Repeatable,可重復(fù)以前的主要經(jīng)驗(yàn)；（關(guān)鍵過程區(qū)域：需求管理；軟件項(xiàng)目計(jì)劃；軟件項(xiàng)目跟蹤和監(jiān)督；軟件子合同管理；軟件質(zhì)量保證；軟件配置管理。）已定義級：Defined,過程被描述，并得到良好理解；（關(guān)鍵過程區(qū)域：組織過程定義；組織過程焦點(diǎn)；培訓(xùn)大綱；集成軟件管理；軟件產(chǎn)品工程；組際

7、協(xié)調(diào)；同行評審。）CMM4已管理級：Managed,過程被測量并受控；（關(guān)鍵過程區(qū)域：定量的過程管理；軟件質(zhì)量管理。）CMM5優(yōu)化級，Optimizing,關(guān)注過程改進(jìn)。b. （關(guān)鍵過程區(qū)域：缺陷預(yù)防；技術(shù)變更管理；過程變更管理。）7、CMM的用途：a.評估組用來識別組織中的強(qiáng)處和弱處；評價(jià)組用來識別選擇不同的業(yè)務(wù)承包商的風(fēng)險(xiǎn)和監(jiān)督合同；管理者用來了解其組織的能力，并了解為了提高其能力成熟度而進(jìn)行軟件過程改進(jìn)所需進(jìn)行的活動；技術(shù)人員和過程改進(jìn)組用來作為指南，指導(dǎo)他們在組織中定義和改進(jìn)軟件過程。8、ISO9001和CMM勺關(guān)系：相似點(diǎn)：強(qiáng)調(diào)管理、過程、規(guī)范化和文檔化;不同點(diǎn)：CMM巴焦點(diǎn)對準(zhǔn)軟件

8、；ISO9001的范圍包括：硬件、軟件、流程性材料和服務(wù)；兩者關(guān)系：CMM教與ISO9001強(qiáng)相關(guān)；CMM勺每個(gè)關(guān)鍵過程域至少按某種解釋與ISO9001弱相關(guān)。9、六西格瑪?shù)膶?shí)施方式：Define:定義-提出問題，確定目標(biāo)Measure:測量-收集資料，尋找原因Analyse:分析-研究資料，確定原因Improve:改進(jìn)-優(yōu)化解決方案Control:控制-推行控制系統(tǒng)10、軟件質(zhì)量模型：功能性：當(dāng)軟件在指定條件下使用時(shí)，軟件產(chǎn)品提供滿足明確和隱含需求的功能的能力。包括：適合性；準(zhǔn)確性；互操作性；保密安全性；功能性的依從性?？煽啃裕涸谥付l件下使用時(shí)，軟件產(chǎn)品維持規(guī)定的性能級別的能力。包括：成熟

9、性；容錯(cuò)性；易恢復(fù)性；可靠性的依從性。易用性：在指定條件下使用時(shí)，軟件產(chǎn)品被理解、學(xué)習(xí)、使用和吸引用戶的能力。包括：易理解性；易學(xué)性；易操作性；吸引性；易用性的依從性。效率：在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品可提供適當(dāng)性能的能力。包括：時(shí)間特性；資源利用性；效率依從性。維護(hù)性：軟件產(chǎn)品可被修改的能力。修改可能包括修正、改進(jìn)或軟件對環(huán)境、需求和功能規(guī)格說明變化的適應(yīng)。包括：易分析性；易改變性；穩(wěn)定性；易測試性；維護(hù)性的依從性?？梢浦残裕很浖a(chǎn)品從一種環(huán)境遷移到另外一種環(huán)境的能力。包括：適應(yīng)性；易安裝性；共存性；易替換性；可移植性的依從性。11、SQA與測試的關(guān)系：測試從技術(shù)的角度來保證

10、軟件質(zhì)量SQA從流程的角度保障軟件質(zhì)量組織用來保障SQAO測試的活動12、SQA的主要工作范圍：指導(dǎo)并監(jiān)督項(xiàng)目按照過程實(shí)施；-對項(xiàng)目進(jìn)行度量、分析，增加項(xiàng)目的可視性；-審核工作產(chǎn)品，評價(jià)工作產(chǎn)品和過程質(zhì)量目標(biāo)的復(fù)合度；-進(jìn)行缺陷分析，缺陷預(yù)防活動，發(fā)現(xiàn)過程的缺陷，提供決策參考，促進(jìn)過程改進(jìn)。13、度量：對事物屬性的量化表示；軟件度量：是指計(jì)算機(jī)軟件中范圍廣泛的測度，包括對軟件系統(tǒng)、構(gòu)建或生命周期過程具有的某個(gè)給定屬性的度的一個(gè)定量測量。目的：提高軟件生產(chǎn)率，縮短產(chǎn)品研發(fā)周期，降低研發(fā)成本、維護(hù)成本；-提高軟件產(chǎn)品質(zhì)量，提高用戶滿意度；-為組織持續(xù)改進(jìn)提供量化的指標(biāo)和反饋。14、軟件度量的作用：

11、1）理解；預(yù)測；評估；改進(jìn)。2）分類：規(guī)模；工作量；進(jìn)度；質(zhì)量15、如何將度量的知識應(yīng)用于實(shí)際工作中：建立測試工作的度量數(shù)據(jù)，目的是作為預(yù)測和改進(jìn)的基礎(chǔ)a. 熟悉需求：進(jìn)度、工作量、規(guī)模；b. 設(shè)計(jì)用例：工作效率、覆蓋率；c. 執(zhí)行用例：工作效率、缺陷密度；）第三章測試方法1、什么是白盒測試：-白盒測試是依據(jù)被測軟件，分析程序內(nèi)部構(gòu)造，并根據(jù)內(nèi)部構(gòu)造設(shè)計(jì)用例，來對內(nèi)部控制流程進(jìn)行測試，可完全不顧程序的整體功能實(shí)現(xiàn)情況；-白盒測試是基于程序結(jié)構(gòu)的邏輯驅(qū)動測試；-白盒測試又可以被稱為玻璃盒測試、透明盒測試、開放盒測試、結(jié)構(gòu)化測試、邏輯驅(qū)動測試。2、為什么進(jìn)行白盒測試：-一般在測試前期進(jìn)行，通過達(dá)到

12、一定的邏輯覆蓋率指標(biāo)，使得軟件內(nèi)部邏輯控制結(jié)構(gòu)上的問、難題能基本得到消除；-能保證內(nèi)部邏輯結(jié)構(gòu)達(dá)到一定的覆蓋程度，能夠給予軟件代碼質(zhì)量更大的保證；-發(fā)現(xiàn)問題后解決問題的成本較低。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）從程序入口進(jìn)入后無法達(dá)到的語句；4）不能達(dá)到停機(jī)語句的語句。6、數(shù)據(jù)流相關(guān)概念：數(shù)據(jù)的定義；數(shù)據(jù)的引用。（步驟：3）7、數(shù)據(jù)流分析的

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

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

15、進(jìn)行測試，很容易被大家理解和接受；-有助于暴露任何規(guī)格不一致或有歧義的問題。黑盒測試的缺點(diǎn)：-沒有清晰的和簡明的規(guī)格，測試用例很難設(shè)計(jì)；-不能控制內(nèi)部執(zhí)行路徑，會有很多內(nèi)部程序路徑?jīng)]有被測試到；-不能直接針對特定的程序段，這些程序可能非常復(fù)雜（因此可能隱藏更多的問題）。動態(tài)和靜態(tài)測試的分類依據(jù)在于：被測對象是否運(yùn)行起來。手工靜態(tài)分析一一同行評審：正規(guī)檢視；技術(shù)評審；走查。評審對象：計(jì)劃、需求文檔、設(shè)計(jì)圖、代碼等。自動化靜態(tài)分析：靜態(tài)驗(yàn)證；語法分析器；符號執(zhí)行器。自動化測試應(yīng)該考慮的因素：1）測試進(jìn)度要求2）人力資源要求3）版本穩(wěn)定度4）版本應(yīng)用情況5）可自動化率6）版本規(guī)模自動化測試的誤區(qū)：1

16、）自動化不能取代手工測試。2）手工測試都做不好，或者經(jīng)驗(yàn)積累不夠，就嘗試自動化，很難成功。3）自動化只能保證測試執(zhí)行效率，確保已有的問題不會再發(fā)生，自動化測試不能發(fā)現(xiàn)大量新缺陷。4）進(jìn)行了自動化測試的軟件不一定就是安全的，質(zhì)量有保證的。所以手工測試是自動化測試的一個(gè)基礎(chǔ)22、自動化五大等級：1）錄制和回放2）腳本3）自動化框架腳本4）數(shù)據(jù)驅(qū)動5）關(guān)鍵字驅(qū)動?自動化測試的限制（板書）：-自動化測試不具備想象力，不能夠檢查腳本中給定的觀察點(diǎn)之外的錯(cuò)誤；-自動化測試只能提高測試效率，不能提高測試效果，不能發(fā)現(xiàn)比人工測試更多的問題；如被測對象不穩(wěn)定，存在變動性的話不適合開展自動化測試，否則腳本的編寫和

17、維護(hù)所耗費(fèi)的時(shí)間可能遠(yuǎn)大于人工測試；-只有手工測試積累到一定程度（提供更多的觀察點(diǎn)），才能做好自動化測試。第四章測試過程1、各階段測試的目的：1）單元測試：檢測軟件模塊對詳細(xì)設(shè)計(jì)說明書的符合程度2）集成測試：檢測軟件模塊對概要設(shè)計(jì)說明書的符合程度3）系統(tǒng)測試：通過與需要規(guī)格說明書作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符或與之矛盾的地方。2、單元、集成、系統(tǒng)測試的比較:測試類型目的考察范圍評估基準(zhǔn)測試方法單元測試消除局部模塊的邏輯和功能上的錯(cuò)誤和缺陷（消除單元、模塊內(nèi)部的邏輯和功能上的錯(cuò)誤與缺陷）單元內(nèi)部的數(shù)據(jù)結(jié)構(gòu)、邏輯控制、異常處理等邏輯覆蓋率大量米用白盒測試力法集成測試找出與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)，模

18、塊調(diào)用關(guān)系，模塊間接口方面的問題（找出與軟件架構(gòu)設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)，單元/子模塊間的調(diào)用關(guān)系，單元/子模塊問接口方米那的問題）接口和接口數(shù)據(jù)傳遞關(guān)系、模塊組合后的整體功能接口覆蓋率結(jié)合使用白盒與黑盒測試方法，較多采用黑盒方法構(gòu)造測試用例（也有說法叫灰盒測試方法）系統(tǒng)測試對整個(gè)系統(tǒng)進(jìn)行一系列的整體、有效性測試（對系統(tǒng)規(guī)格中的功能與性能進(jìn)行一系列的有效性測試）整個(gè)系統(tǒng)對需求的符合度測試用例對需求規(guī)格的覆蓋率黑盒測試3、回歸測試策略：完全重復(fù)測試；選擇性重復(fù)測試（覆蓋修改法；周邊影響法；指標(biāo)達(dá)成方法；選擇重要級別高的測試用例）4、回歸測試流程：1）在測試策略制定階段，制定回歸測試策略2）確定需要回歸

19、測試的版本3）回歸測試版本發(fā)布，按照回歸測試策略執(zhí)行回歸測試4）回歸測試通過，關(guān)閉缺陷跟蹤單（問題單）5）回歸測試不通過，缺陷跟蹤單返回開發(fā)人員，開發(fā)人員重新修改問題，再次提交測試人員回歸測試5、有用戶參與的其他一些測試：驗(yàn)收測試、a測試、6測試6、a測試與6測試的比較：Alpha測試Beta測試比較測試環(huán)境開發(fā)環(huán)境或者模擬實(shí)際操作的環(huán)境卜實(shí)際使用環(huán)境測試人員可以是終端用戶也可以是企業(yè)內(nèi)部的用戶終端用戶（包括潛在用戶）開發(fā)人員是否在場有開發(fā)人員在場，實(shí)際上是一種受控的測試。開發(fā)人員通常不在測試現(xiàn)場，測試情況通常不受控。關(guān)注點(diǎn)Alpha測試關(guān)注軟件產(chǎn)品的FLURPS即功能、局域化、可使用性、可靠

20、性、性能和支持），尤其注重產(chǎn)品的界面和特色。Beta測試著重關(guān)注產(chǎn)品的支持性，包括文檔、客戶培訓(xùn)和支持產(chǎn)品的生產(chǎn)能力。共同點(diǎn)1. 都希望從實(shí)際終端用戶的使用角度來對軟件的功能和性能進(jìn)行測試，以發(fā)現(xiàn)可能只有終端用戶才能發(fā)現(xiàn)的錯(cuò)誤；2. 都不能由測試人員和程序員完成；7、主要的測試文檔：測試計(jì)劃；測試方案；測試用例；測試規(guī)程；測試報(bào)告；測試日報(bào)8、驗(yàn)證與確認(rèn)V&V:驗(yàn)證（VERIFICATION強(qiáng)調(diào)過程；確認(rèn)（VALIDATION強(qiáng)調(diào)結(jié)果。9、V&V模型優(yōu)點(diǎn)：實(shí)現(xiàn)了測試設(shè)計(jì)和測試執(zhí)行相分離；-揭示了軟件測試活動分層和分階段的本質(zhì)特性：測試執(zhí)行的順序與開發(fā)活動相反10、V&V

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

22、段1. 概要設(shè)計(jì)說明書2. 集成測試計(jì)劃集成測試方案實(shí)現(xiàn)階段1. 概要設(shè)計(jì)說明書2. 集成測試計(jì)劃3. 集成測試方案1. 集成測試用例2. 集成測試規(guī)程執(zhí)行階段1. 集成測試計(jì)劃2. 集成測試方案3. 集成測試用例4. 集成測試規(guī)程1. 集成測試報(bào)告2. 缺陷報(bào)告單元測試計(jì)劃階段1. 軟件測試計(jì)劃2. 詳細(xì)設(shè)計(jì)說明書單元測試計(jì)劃設(shè)計(jì)階段1. 詳細(xì)設(shè)計(jì)說明書2. 單元測試計(jì)劃單元測試方案實(shí)現(xiàn)階段1. 詳細(xì)設(shè)計(jì)說明書2. 單元測試計(jì)劃3. 單元測試方案1. 單元測試用例2. 單元測試規(guī)程執(zhí)行階段1. 單元測試計(jì)劃2. 單元測試方案3. 單元測試用例4. 單元測試規(guī)程1. 單元測試報(bào)告2. 缺陷報(bào)告

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

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

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

26、執(zhí)行單元測試用例，修改發(fā)現(xiàn)的問題并進(jìn)行回歸測試，提交單元測試報(bào)告。單元測試：樁&驅(qū)動舉例：無論是單元測試還是集成測試都涉及到以下三個(gè)函數(shù)：主控函數(shù):intctrl(intx,inty)加法函數(shù):intadd(intx,inty)減法函數(shù)：intsub(intx,inty)注意：進(jìn)行單元測試時(shí)，設(shè)計(jì)用例時(shí)依據(jù)的是LLD;進(jìn)行集成測試時(shí)，設(shè)計(jì)測試用例依據(jù)的是HLD下面給出來的是需要測試的實(shí)際的代碼。intctrl(intx,inty)inttemp=0;if(x>=y)temp=add(x,y);elsetemp=sub(x,y);returntemp;intadd(intx,int

27、y)return(x+y);intsub(intx,inty)return(x-y);自頂向下單元測試策略不同測試步驟中的驅(qū)動可以寫到一起，也可以分開寫，這里是寫到一起了。?測試ctrl函數(shù)需要寫一個(gè)驅(qū)動和兩個(gè)樁。?驅(qū)動函數(shù)voiddriver()intret=0;ret=ctrl(2,1);/x>yif(ret=3)printf("testcaseJISUAN_UT_CTRL_001pass”);elseprintf("testcaseJISUAN_UT_CTRL_001fail”);ret=ctrl(1,1);/x=yif(ret=2)printf("t

28、estcaseJISUAN_UT_CTRL_002pass”);elseprintf("testcaseJISUAN_UT_CTRL_002fail”);ret=ctrl(1,2);/x<yif(ret=-1)printf("testcaseJISUAN_UT_CTRL_003pass”);elseprintf("testcaseJISUAN_UT_CTRL_003fail”);?樁函數(shù)intstub_add(intx,inty)if(x=2&&y=1)return3;if(x=1&&y=1)return2;return999

29、999;?修改代碼為了讓樁能體現(xiàn)在測試過程中，需要修改intctrl(intx,inty)inttemp=0;if(x>=y)temp=stub_add(x,y);elsetemp=stub_sub(x,y);returntemp;?測試add函數(shù)intstub_sub(intx,inty)if(x=1&&y=2)return-1;return999999;ctrl函數(shù)：同測試ctrl函數(shù)時(shí)的驅(qū)動?驅(qū)動函數(shù)樁函數(shù)同測試ctrl函數(shù)時(shí)sub函數(shù)對應(yīng)的樁?修改代碼intctrl(intx,inty)(inttemp=0;if(x>=y)(temp=add(x,y);if

30、(x=2&&y=1&&temp=3)printf("testcaseJISUAN_UT_ADD_001pass”);elseprintf("testcaseJISUAN_UT_ADD_001fail”);if(x=1&&y=1&&temp=2)printf("testcaseJISUAN_UT_ADD_002pass”);elseprintf("testcaseJISUAN_UT_ADD_002fail”);elsetemp=stub_sub(x,y);returntemp;測試sub函數(shù)?

31、驅(qū)動函數(shù)同測試ctrl函數(shù)時(shí)的驅(qū)動?樁函數(shù)無?修改代碼intctrl（intx,inty）（inttemp=0;if（x>=y）temp=add（x,y）;else（temp=sub（x,y）;if（x=1&&y=2&&temp=-1）printf（"testcaseJISUAN_UT_SUB_001pass”）;elseprintf（"testcaseJISUAN_UT_SUB_001fail”）;returntemp;第六章集成測試集成測試的目的：確保各組件組合在一起后能夠按照既定意圖寫作運(yùn)行，并確保增量的行為正確（屬于灰盒測試）1

32、）驗(yàn)證接口是否與設(shè)計(jì)相符2）發(fā)現(xiàn)設(shè)計(jì)和需求中存在的錯(cuò)誤1. 集成測試關(guān)注的重點(diǎn)：單元間的接口、集成后的功能2. 集成測試的層次：模塊內(nèi)集成、子系統(tǒng)內(nèi)集成、子系統(tǒng)間集成3. 集成測試策略：1）大爆炸集成2）自頂向下集成3）自底向上集成4）三明治（混合式）集成5）基干集成6）分層集成7）基于功能的集成8）基于消息的集成9）基于進(jìn)度的集成10）基于風(fēng)險(xiǎn)的集成5.各種集成測試策略的優(yōu)缺點(diǎn):優(yōu)點(diǎn)缺點(diǎn)適用范圍大爆炸集成1. 只要極少數(shù)的驅(qū)動和樁2. 可并行工作，人力、物力資源利用率較高1. 一次運(yùn)行成功的可能性不大2. 定位和修改錯(cuò)誤比較困難3. 會有很多接口錯(cuò)誤進(jìn)入到系統(tǒng)測試1. 維護(hù)型項(xiàng)目（增強(qiáng)型）2

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

34、行進(jìn)行集成3. 減少了樁的工作量4. 支持故障隔離1. 驅(qū)動的開發(fā)和維護(hù)成本高2. 對高層的驗(yàn)證被推退到了最后，設(shè)計(jì)上的錯(cuò)誤不能被及時(shí)發(fā)現(xiàn)1. 底層接口比較穩(wěn)定、變動較少的產(chǎn)品2. 高層接口變化較頻繁的產(chǎn)品3. 底層組件較早被完成的產(chǎn)品三明治集成集合了自頂向下和自底向上策略的優(yōu)點(diǎn)中間層在被集成前測試不充分大部分軟件開發(fā)項(xiàng)目基干集成具有二明治集成的優(yōu)點(diǎn)1. 必須對系統(tǒng)的結(jié)構(gòu)和相互依存性進(jìn)行仔細(xì)分析2. 必須開發(fā)驅(qū)動和樁3. 有些接口可能測試不充分大型復(fù)雜項(xiàng)目基于功能集成/基于消息集成1. 可盡快看到關(guān)鍵功能的實(shí)現(xiàn)，并驗(yàn)證正確性2. 進(jìn)度上要短3. 可減少驅(qū)動的開發(fā)1. 對有些接口測試不充分，會丟

35、失許多接口錯(cuò)誤2. 可能會有較大的冗余測試基于進(jìn)度集成1. 具有比較局的并行度2. 能有效縮短項(xiàng)目開發(fā)的進(jìn)度1. 許多接口要到后期才能驗(yàn)證，無法發(fā)現(xiàn)有效的接口問題2. 樁和驅(qū)動開發(fā)工作量大3. 由于進(jìn)度，組件很不穩(wěn)定且會不斷變動，導(dǎo)致測試的重復(fù)和浪費(fèi)進(jìn)度優(yōu)先級局于質(zhì)里的項(xiàng)目基于風(fēng)險(xiǎn)集成最具有風(fēng)險(xiǎn)的組件最早進(jìn)行驗(yàn)證，有助于系統(tǒng)的快速穩(wěn)定需要對各組件的風(fēng)險(xiǎn)有一個(gè)清晰的分析1. 第七章系統(tǒng)測試系統(tǒng)測試目的：1）通過與需求做比較，發(fā)現(xiàn)與系統(tǒng)定義不符合或與之矛盾的地方2. 2）系統(tǒng)測試的用例應(yīng)根據(jù)需求分析說明書來設(shè)計(jì)，并在實(shí)際使用環(huán)境下運(yùn)行系統(tǒng)測試對象1）軟硬件集合在一起的系統(tǒng)3. 2）驗(yàn)證時(shí)應(yīng)盡可能模

36、擬實(shí)際的運(yùn)行環(huán)境與條件系統(tǒng)測試常用類型：功能、性能、壓力、容量、安全性、GUI、可用性、安裝、配置、4. 異常（恢復(fù)性）、備份、健壯性、文檔、在線幫助、網(wǎng)絡(luò)、穩(wěn)定性測試功能測試：1）概念：根據(jù)產(chǎn)品的SRS和測試需求列表，驗(yàn)證產(chǎn)品的功能實(shí)現(xiàn)是否符合產(chǎn)品的需求規(guī)格2）目標(biāo)：為了發(fā)現(xiàn)以下幾類錯(cuò)誤a）是否有不正確或遺漏了的功能b）功能實(shí)現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計(jì)的隱藏需求c）輸入能否正確接受？能否正確輸出結(jié)果？5. 性能測試：1）概念：用來測試軟件在集成系統(tǒng)中的運(yùn)行性能2）目標(biāo)：度量系統(tǒng)相對于預(yù)定義目標(biāo)的差距3）工具：LoadRunner、WebLoadSilkPerformer6. 4）重要性：a

37、）性能是質(zhì)量的重要組成部分b）給用戶樹立良好形象c）節(jié)省成本的重要手段性能測試的關(guān)鍵：有效的協(xié)調(diào)、正確的模型、瓶頸的定位、合理的建議性能需求五大特性：需求行、代表性、完整性、可測試性、可用性壓力測試：關(guān)注穩(wěn)定性和破壞性1）目的：調(diào)查系統(tǒng)在其資源超負(fù)荷的情況下的表現(xiàn)2）目標(biāo)：通過極限測試方法，發(fā)現(xiàn)系統(tǒng)在極限或惡劣環(huán)境中自我保護(hù)能力，主要驗(yàn)證系統(tǒng)的可靠性。7. 容量測試：1）目的：使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理8. 2）關(guān)注點(diǎn)：a）整體的業(yè)務(wù)流量（一般關(guān)注靜態(tài)容量）b）數(shù)據(jù)庫的容量c）最大文件數(shù)目d）最大事務(wù)數(shù)安全性測試：口令認(rèn)證、加解密技術(shù)、權(quán)限管理、安全日志9. GUI測試：

38、1）關(guān)注點(diǎn)：界面實(shí)現(xiàn)與界面設(shè)計(jì)的吻合情況、確認(rèn)界面處理的正確性2）對象：簡單界面元素、組合類界面元素、完整界面（窗口）10. 3）內(nèi)容：外觀、界面元素行為、布局、友好功能可用性測試：關(guān)注點(diǎn)：1）過分復(fù)雜的功能或指令2）困難的安裝過程3）錯(cuò)誤信息過于簡單4）用戶被迫去記住太多的信息11. 5）語法、格式和定義不一致配置測試：概念：測試系統(tǒng)在各種軟硬件配置、不同的參數(shù)配置下系統(tǒng)具有的功能和性能12. 目標(biāo)：驗(yàn)證全部配置的可操作性和有效性，特別需要對最大配置、最小配置或特殊配置進(jìn)行測試異常測試：概念：又叫系統(tǒng)容錯(cuò)和可恢復(fù)性測試，通過人工干預(yù)手段使系統(tǒng)產(chǎn)生軟、硬件異常，通過驗(yàn)證系統(tǒng)異常前后的功能和運(yùn)行

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

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

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

42、）3. -BranchConditionCoverageDecisionConditionCoverage）,它的含義是，在測試時(shí)運(yùn)行被測程序后，所有判斷語句中每個(gè)條件的所有可能值（為真為假）和每個(gè)判斷本身的判定結(jié)果（為真為假）出現(xiàn)4. 的比率；分支條件覆蓋率=（條件操作樹枝或判定結(jié)果至少被評價(jià)一次的數(shù)量）/（條件操作數(shù)值總數(shù)+判定結(jié)果總數(shù)）路徑覆蓋率：（PathCoverage）的含義是，在測試時(shí)運(yùn)行被測程序后，程序中所有可能的路徑被執(zhí)行過的比率；路徑覆蓋率=（至少被執(zhí)行到一次的路徑數(shù)）/（總的路徑數(shù)）其他覆蓋率：功能覆蓋率；面向?qū)ο蟮母采w率；函數(shù)覆蓋；指令塊覆蓋；判定路徑覆蓋。第九章測試用

43、例舉例測試用例編號BOSS_ST_MARKETING_NEW_01P重要級別P局（還有“較局、中、較低、低”幾個(gè)等級）測試項(xiàng)目新增營銷記錄測試標(biāo)題新增10元的營銷記錄用例類型P基本事件（對應(yīng)還有“備選事件”、“異常事件”）用例設(shè)計(jì)者songfun設(shè)計(jì)日期2005-04-25對應(yīng)需求編號REQ_MARKETING_NEW_01對應(yīng)UIMarketing.htm對應(yīng)UCUC_MARKETING_NEW_01版本號Buildv0.1對應(yīng)開發(fā)人員Frank預(yù)置條件操作員登錄營銷管理系統(tǒng)測試方法等價(jià)類劃分（對應(yīng)還有“錯(cuò)誤猜測法”、“邊界值分析”等）輸入用戶名：51testing性別：男金額：10元描述：

44、aaaaaaa操作步驟 .進(jìn)入【營銷下發(fā)】頁面； .點(diǎn)擊增加按鈕； .輸入相應(yīng)數(shù)據(jù)； .點(diǎn)擊確定按鈕； .在后臺數(shù)據(jù)庫（test/testtestDB）輸入查詢語句驗(yàn)證：select*fromMarketingTabwhereID='1001'預(yù)期輸出1. 執(zhí)行步驟后，貝面彈出添加成功提示信息框；2. 執(zhí)行步驟后查詢數(shù)據(jù)庫，記錄確實(shí)添加成功且數(shù)據(jù)無誤1. 第十章測試經(jīng)驗(yàn)和誤區(qū)軟件測試的誤區(qū)：1）測試和調(diào)試是一樣的2）測試組應(yīng)當(dāng)為保證質(zhì)量負(fù)責(zé)3）過分依賴BETAI試4）把測試作為新員工的一個(gè)過渡工作5）把不合格的開發(fā)人員安排做測試6）關(guān)注于測試的執(zhí)行而忽略測試的設(shè)計(jì)7）自動化測試

45、是萬能的8）測試是可以窮盡的9）測試是為了證明軟件的正確性2. 10）測試是枯燥乏味，缺乏創(chuàng)造力的工作軟件測試的10大原則：1）測試是一個(gè)持續(xù)改進(jìn)的過程，而不是一個(gè)階段2）測試必須被計(jì)劃、被控制、并且被提供時(shí)間和資源3）測試應(yīng)當(dāng)分級別4）測試應(yīng)當(dāng)有重點(diǎn)5）測試不是為了證明程序的正確性，而是為了證明程序不能工作6）測試是不可能窮盡的，當(dāng)測試出口條件滿足時(shí)就可以停止測試7）測試是開發(fā)的朋友，不是敵人8）測試人員應(yīng)當(dāng)站在公正的立場上進(jìn)行測試，如實(shí)的記錄和報(bào)告缺陷9）自動化測試能解決一部分問題，但不是全部3. 10）測試不能僅僅包括功能性的驗(yàn)證，還應(yīng)當(dāng)包含性能、可靠性、可維護(hù)型、安全性等方面的驗(yàn)證軟件

46、測試的10個(gè)最佳實(shí)踐：1）盡早的、頻繁的進(jìn)行測試-降低成本、提高質(zhì)量2）盡早的產(chǎn)生一個(gè)綜合的主測試計(jì)劃3）對質(zhì)量要求較高的產(chǎn)品或大型復(fù)雜的產(chǎn)品成立獨(dú)立的測試組4）在每個(gè)開發(fā)階段，使用測試和評價(jià)的結(jié)果作為是否可以通過的標(biāo)準(zhǔn)5）開發(fā)和維護(hù)一個(gè)測試需求和目標(biāo)的風(fēng)險(xiǎn)優(yōu)先級列表6）把測試作為產(chǎn)品的一部分等同起來，使用相同的評價(jià)標(biāo)準(zhǔn)和過程7）提供集成化的測試工具和測試技術(shù)支持8）加強(qiáng)測試度量工作和缺陷分析工作，不斷地改進(jìn)測試9）加強(qiáng)測試的培訓(xùn)并且為測試人員提供技能發(fā)展的通道10）加強(qiáng)溝通和交流，讓項(xiàng)目組內(nèi)所有人員都了解測試的重要性和測試的工作1. a)同行評審?fù)性u審：(PeerReview)是一種通過作

47、者的同行來確認(rèn)缺陷和需要變更區(qū)域的檢查方法。需要進(jìn)行同行評審的特定產(chǎn)品在定義項(xiàng)目軟件過程的時(shí)候被確定并且作為軟件開發(fā)計(jì)劃的一部分被安排了進(jìn)度。2. -需要前期準(zhǔn)備、計(jì)劃和時(shí)間進(jìn)度表-越早越好同行評審的作用：早期發(fā)現(xiàn)缺陷；去除缺陷；降低成本；提高質(zhì)量。3. 同行評審的類型：正規(guī)檢視：(Inspection)最嚴(yán)格，要求有規(guī)范的流程，參加者經(jīng)過正式培訓(xùn)；-技術(shù)評審：(TechniqueReview)以技術(shù)方案的比較、裁決為目的，嚴(yán)格程度介于正規(guī)檢視和走讀之間；走讀：(WalkThrough)最(自由)松散的形式，無流程要求，有評審團(tuán)隊(duì)，評審流程無要求。4. 通用評審流程步驟(正規(guī)檢視流程)：計(jì)劃階

48、段：-項(xiàng)目負(fù)責(zé)人指定組織者；作者自檢工作產(chǎn)品；組織者規(guī)劃本次評審；-檢查入口準(zhǔn)則：是否符合文檔標(biāo)準(zhǔn)？是否已用工具檢查？代碼<=500行；文檔<=40頁；-準(zhǔn)備評審包：工作產(chǎn)品(HL。；參考資料(SRS檢查一致性)；評審表(ReviewForm);查檢表(Checklist)。-指定評審專家(3-6人)；-組織者將評審包、評審?fù)ㄖ獑伟l(fā)給相關(guān)人員。介紹會議：-被評審對象采用新技術(shù)、新方法；被評審對象第一次被評審(作者介紹被審對象以及相關(guān)技術(shù))-評審專家第一次參加評審(評審者介紹評審流程)-介紹會議的召開距接到評審?fù)ㄖ臅r(shí)間大于5小時(shí)；-介紹會議的時(shí)間不超過1小時(shí)，30-60間為宜，關(guān)注

49、講解。3. 準(zhǔn)備階段：（最重要、發(fā)現(xiàn)缺陷最多）,評審專家個(gè)人獨(dú)立完成工作廣品的審視，提出缺陷；-準(zhǔn)備時(shí)間大于會議時(shí)間，且應(yīng)于會議前2天開始；4. -評審者：收到組織者發(fā)來的評審包；審核工作產(chǎn)品、發(fā)現(xiàn)缺陷；填寫評審表單；反饋評審表單給組織者；組織者：檢查評審表單；裁決是否需要增加評審評審?fù)度耄ㄔ黾訙?zhǔn)備時(shí)間；增加評審專家人數(shù)；更換評審專家）會議階段（2小時(shí)內(nèi)；只提出問題，不關(guān)注解決）：-組織者召開評審會議；-講解員講解工作產(chǎn)品；（盡量不要由作者兼任）-大家共同確認(rèn)問題（評審表單中記錄的問題；會上發(fā)現(xiàn)的問題；當(dāng)爭執(zhí)不下時(shí)組織者應(yīng)做出裁決）-對已確認(rèn)的問題進(jìn)行分類；-作者決定是否召開第三小時(shí)會議；-記

50、錄員記錄所有的問題及分類，并發(fā)給組織者；（記錄員盡量不要由作者和組織者擔(dān)任）-組織者更新評審表單。第三小時(shí)會議-有爭議的問題繼續(xù)討論，給出決議；-討論解決問題方案；-組織者更新評審表單。5. 返工：發(fā)回作者修改；跟蹤：-匯總所有需要的數(shù)據(jù)到評審表單發(fā)給相關(guān)評審專家；（2組織者）-組織評審專家確認(rèn)各缺陷得到了修改，并且沒有引入新的缺陷；-協(xié)助組織者確認(rèn)相關(guān)問題得到了正確修改并且沒有引入新的缺陷；-確認(rèn)評審表單中各相關(guān)度量數(shù)據(jù)正確（發(fā)現(xiàn)缺陷數(shù)；評審?fù)度霑r(shí)間；評審專家人數(shù)等）（評審專家2）a）配置&需求管理1、配置管理的目的和意義:目的：a.可視性：用戶/買方/賣方詳細(xì)知道工作內(nèi)容；管理層能

51、夠知道產(chǎn)品特性；所有的項(xiàng)目參與者在同一平臺下交流；了解現(xiàn)在和計(jì)劃的配置；管理層可看到變更的影響；管理層可選擇參與的節(jié)點(diǎn)；目標(biāo)：項(xiàng)目：減少返工，減少工作量；意義：L公司：節(jié)約成本，積累項(xiàng)目財(cái)富;可視性提高；項(xiàng)目可跟蹤性高;2、配置、基線、版本各自定義及關(guān)系：配置：是軟件生命周期個(gè)階段產(chǎn)生的程序、數(shù)據(jù)、文件、環(huán)境的集合；配置項(xiàng)：是軟件生命周期個(gè)階段產(chǎn)生的程序、數(shù)據(jù)、文件、環(huán)境基線：配置項(xiàng)在其生命周期的不同時(shí)間點(diǎn)上通過評審而進(jìn)入正式受控的一種狀態(tài)，而這個(gè)過程被稱為“基線化”；版本：是表示一個(gè)配置項(xiàng)具有一組定義的功能的一種標(biāo)識；3、變更控制的流程（各種角色、職責(zé)輸出）：-項(xiàng)目成員、客戶代表、市場人員提

52、交CR-CMO將CR狀態(tài)表示為已提交，并將CR艮據(jù)條件進(jìn)行判斷，把不需要CCBS行審核的、決定采納的CR直接進(jìn)行簽發(fā)；把不需要CCB進(jìn)行審核的、不決定采納的CR直接關(guān)閉（4CMO將CR狀態(tài)標(biāo)識為已拒絕）；將需要CC階審的CR提交給CCB進(jìn)行評估；-CCB召開會議對CR進(jìn)行評估-CMO#CR狀態(tài)標(biāo)識為已接受，將CR于要修改的配置項(xiàng)發(fā)給項(xiàng)目組成員并開放CI的配置庫權(quán)限-項(xiàng)目組成員執(zhí)行更改并進(jìn)行驗(yàn)證-CCB召開會議對修改進(jìn)行審核，如果通過將CR狀態(tài)表示為已驗(yàn)證，發(fā)給CMO否則直接關(guān)閉，并給出提交人反饋信息4、配置管理中測試工程師的職責(zé)：-測試工程師將自己創(chuàng)建的與測試相關(guān)配置項(xiàng)（比如軟件測試計(jì)劃、軟件

53、測試方案、軟件測試用例、軟件測試日報(bào)、軟件測試報(bào)告等）加入配置庫中；-測試工程師根據(jù)變更請求，對已經(jīng)基線化的配置項(xiàng)進(jìn)行Check-Out、修改、Check-In操作。比如，在測試執(zhí)行之前，需要更新測試用例，此時(shí)需要經(jīng)過CMO勺授權(quán)，然后由測試人員對相應(yīng)的配置項(xiàng)（測試用例文件）Check-Out、修改、Check-In5、需求跟蹤涉及到的配置項(xiàng)TaskOutput6、配置項(xiàng)的跟蹤矩陣Input缺陷管理1、缺陷管理的目的：保證信息的一致性；保證缺陷得到有效跟蹤，解決;-獲取正確的Bug信息，用作缺陷分析和產(chǎn)品度量。2、缺陷的相關(guān)屬性：缺陷發(fā)現(xiàn)人(DefectReporter);-缺陷發(fā)現(xiàn)時(shí)間(De

54、fectedonDate);-缺陷狀態(tài)(Status);-缺陷嚴(yán)重程度(Sewrity);-缺陷所屬版本(DefectedinVersion);-優(yōu)先級(Priority)-缺陷修改日期(FixedonDate);-再現(xiàn)性(Reproducible);-回歸測試(Regression)；3、缺陷管理流程：(參考缺陷管理作業(yè))4、缺陷跟蹤單寫作準(zhǔn)則(5C)-Correct(準(zhǔn)確)，每個(gè)組成部分的描述準(zhǔn)確，不會引起誤會；-Clear(清晰)，每個(gè)組成部分的描述清晰，易于理解；-Concise(簡潔)，只包含必不可少的信息，不包括任何多余的內(nèi)容;-Complete(完整)，包含復(fù)現(xiàn)該缺陷的完整步驟和

55、其他本質(zhì)信息；-Consistent（一致），按照一致的格式書寫全部缺陷報(bào)告。5、缺陷跟蹤單基本內(nèi)容：（其他相關(guān)屬性）；簡單描述；詳細(xì)描述；相關(guān)附件。i. 6、QC中缺陷管理流程：（實(shí)際流程應(yīng)參考各公司內(nèi)部流程或者書本）Qatester提交一個(gè)狀態(tài)為new的新缺陷后assignedtoPMPM魘看該缺陷，并判斷是否為缺陷需要修改：ii. n在comments中記錄否決意見后closed;y在comments中記錄相關(guān)意見后將該缺陷指派給相關(guān)開發(fā)人員，并將status置為open/reopenDeveloper打開缺陷模塊，看到指派給自己的缺陷后確定是否修改：n在comments中記錄意見后re

56、jectedtoPM2y修改該缺陷，并將status置為fixed指給PMPM務(wù)該缺陷指派給Qatester進(jìn)行回歸測試Qatester看到指派給自己的fixed的缺陷后，進(jìn)行回歸測試，通過？yclosed;nrejected給PM2SQLSERVER?數(shù)據(jù)定義語言(DDL?Createtable創(chuàng)建數(shù)據(jù)庫的表?Createindex創(chuàng)建數(shù)據(jù)庫表的索引?Droptable刪除數(shù)據(jù)庫表?Dropindex刪除數(shù)據(jù)庫表的索引?Truncatetable刪除表的所有行?Altertable修改表：增加表列、重定義表列、更改存儲分配等?Altertableaddconstraint在已有的表上增加約束?數(shù)據(jù)操作語言DML?Insert增加數(shù)據(jù)