測試執(zhí)行課件

測試執(zhí)行點(diǎn)時(shí)創(chuàng)新目錄測試執(zhí)行軟件缺陷測試報(bào)告

測試需求分析過程123測試執(zhí)行測試執(zhí)行測試執(zhí)行基本概念測試執(zhí)行過程注意事項(xiàng)測試執(zhí)行–基本概念當(dāng)測試用例編寫完成，并通過審核后，就進(jìn)入到軟件測試最主要的測試執(zhí)行階段（也就是執(zhí)行測試用例、提交問題單、測試評(píng)估等活動(dòng)），進(jìn)行軟件測試。執(zhí)行測試用例，就是根據(jù)已有的測試用例，按照里面的操作步驟一步一步的執(zhí)行，并查看預(yù)期結(jié)果與實(shí)際結(jié)果是否一致。執(zhí)行測試用例不等于是測試執(zhí)行。測試執(zhí)行–過程注意事項(xiàng)搭建測試環(huán)境事項(xiàng)注意前提條件和特殊說明測試用例要全部執(zhí)行不要忽視任何偶然現(xiàn)象加強(qiáng)測試過程記錄詳細(xì)預(yù)期與實(shí)際的不一致提交缺陷時(shí)與開發(fā)的關(guān)系處理提交一份優(yōu)秀的問題報(bào)告單及時(shí)更新維護(hù)測試用例測試執(zhí)行–過程注意事項(xiàng)搭建測試環(huán)境事項(xiàng)常見軟件基礎(chǔ)運(yùn)行環(huán)境： Linux+Tomcat+MySQL+JAVALinux+

Apache+MySQL+PHP

Windows+IIS+MySQL+ASP/.NET環(huán)境搭建注意事項(xiàng)：

測試用例執(zhí)行之前，成功搭建測試環(huán)境是第一步。一般來說，軟件產(chǎn)品提交測試后，開發(fā)人員應(yīng)該提交一份被測試軟件產(chǎn)品的詳細(xì)安裝指導(dǎo)書。如果開發(fā)人員未提供相關(guān)的安裝指導(dǎo)書，搭建過程中如遇到問題，測試人員可以要求開發(fā)人員協(xié)助，這時(shí)候，一定要把開發(fā)人員解決問題的方法記錄下來，避免同樣的問題再次請(qǐng)教開發(fā)人員，這樣會(huì)招致開發(fā)人員的反感，也降低了開發(fā)人員對(duì)測試人員的認(rèn)可程度。測試執(zhí)行–過程注意事項(xiàng)注意測試用例中的前提條件和特殊規(guī)程說明有些測試軟件是有順序性的，那么它的測試用例就會(huì)有一些執(zhí)行前提或特殊說明。比如要測試某個(gè)軟件的登陸功能，那么測試前必須創(chuàng)建用戶，并為用戶分配一定的權(quán)限等。如果前提條件和特殊說明沒有注意，會(huì)導(dǎo)致測試用例的無法執(zhí)行。測試執(zhí)行–過程注意事項(xiàng)測試用例要執(zhí)行全部執(zhí)行，每條用例至少要執(zhí)行一遍因?yàn)榫帉憸y試用例時(shí)，它考慮了測試覆蓋率的問題，每條測試用例都對(duì)應(yīng)一個(gè)功能點(diǎn)，如果少執(zhí)行一條，就會(huì)有一個(gè)功能點(diǎn)沒有測試到。我們執(zhí)行測試前要認(rèn)為待測試軟件的每條功能點(diǎn)都是未實(shí)現(xiàn)的，每個(gè)功能點(diǎn)我們都要測試一遍，才能保證待測試軟件能正確滿足用戶需求。測試執(zhí)行–過程注意事項(xiàng)不要忽視任何偶然現(xiàn)象我們?cè)趫?zhí)行某條用例時(shí)，軟件會(huì)出錯(cuò)，但是當(dāng)再次執(zhí)行時(shí)這個(gè)錯(cuò)誤就不再重現(xiàn)。這種情況，一般大家就會(huì)認(rèn)為是偶然現(xiàn)象，就會(huì)忽略過去。其實(shí)，這種錯(cuò)誤才是隱藏最深的，最難發(fā)現(xiàn)的錯(cuò)誤。遇到這種情況時(shí)，要仔細(xì)分析這種情況，不要忽視任何小的細(xì)節(jié)，多測試幾次，盡可能準(zhǔn)確的找出問題的原因。測試執(zhí)行–過程注意事項(xiàng)加強(qiáng)測試過程記錄測試執(zhí)行過程中，一定要加強(qiáng)測試過程記錄。執(zhí)行過的用例做好對(duì)應(yīng)標(biāo)記，發(fā)現(xiàn)了缺陷應(yīng)及時(shí)提交確認(rèn)。一般軟件產(chǎn)品提供了日志功能，比如有軟件運(yùn)行日志、用戶操作日志。如果發(fā)現(xiàn)比較復(fù)雜難定位的問題，一定要在測試用例執(zhí)行后記錄相關(guān)的日志文件，作為測試過程記錄，這樣開發(fā)人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環(huán)境，為開發(fā)人員重現(xiàn)問題。測試執(zhí)行–過程注意事項(xiàng)詳細(xì)記錄預(yù)期與實(shí)際的不一致如果不一致，要從多個(gè)角度多測試幾次，盡量詳細(xì)的定位軟件出錯(cuò)的位置和原因，并測試出因?yàn)檫@個(gè)錯(cuò)誤會(huì)不會(huì)導(dǎo)致更嚴(yán)重的錯(cuò)誤出現(xiàn)，最后把詳細(xì)的輸入和實(shí)際的輸出，以及對(duì)問題的描述寫到測試報(bào)告中。因?yàn)樵谝粋€(gè)項(xiàng)目組中，項(xiàng)目的開發(fā)時(shí)間是有限的，如果我們測試時(shí)能把問題描述的詳細(xì)一些，那么開發(fā)人員就會(huì)很容易的重現(xiàn)這個(gè)問題，也就能更快的解決問題，節(jié)省項(xiàng)目時(shí)間。

測試執(zhí)行–過程注意事項(xiàng)提交缺陷時(shí)與開發(fā)的關(guān)系處理測試執(zhí)行過程中，當(dāng)你提交了問題報(bào)告單，可能被開發(fā)人員無情駁回，拒絕修改。這時(shí)候，只能對(duì)開發(fā)人員曉之以理，做到有理、有據(jù)，有說服力。測試執(zhí)行–過程注意事項(xiàng)提交一份優(yōu)秀的問題報(bào)告單測試提交的問題報(bào)告單和測試日?qǐng)?bào)一樣，都是測試人員的工作輸出，及績效的集中體現(xiàn)。因此，提交一份優(yōu)秀的問題報(bào)告單是很重要的。測試執(zhí)行–過程注意事項(xiàng)及時(shí)更新維護(hù)測試用例

測試執(zhí)行過程中，應(yīng)該注意及時(shí)更新維護(hù)測試用例：往往在測試執(zhí)行過程中，才發(fā)現(xiàn)遺漏了一些測試用例，這時(shí)候應(yīng)該及時(shí)的補(bǔ)充；有些測試用例在具體的執(zhí)行過程中根本無法操作，這時(shí)候應(yīng)該刪除這部分用例；若干個(gè)冗余的測試用例完全可以由某一個(gè)測試用例替代，那么刪除冗余的測試用例?？傊?，測試執(zhí)行的過程中及時(shí)地更新測試用例是很好的習(xí)慣。不要打算在測試執(zhí)行結(jié)束后，統(tǒng)一更新測試用例，如果這樣，往往會(huì)遺漏很多本應(yīng)該更新的測試用例。軟件缺陷

缺陷基礎(chǔ)理論

缺陷的生命周期

缺陷的流程

缺陷的狀態(tài)

缺陷的等級(jí)缺陷實(shí)例與練習(xí)軟件缺陷–基礎(chǔ)理論

缺陷的概念

缺陷的原因

缺陷的修復(fù)成本缺陷的分布特征

缺陷的抗藥性

并非所有缺陷都要修改缺陷基礎(chǔ)理論–概念軟件缺陷：計(jì)算機(jī)系統(tǒng)或者程序中存在的任何一種破壞正常運(yùn)行能力的問題、錯(cuò)誤，或者隱藏的功能缺陷、瑕疵。缺陷又名為BUG（臭蟲）缺陷的主要類型：功能、特性沒有實(shí)現(xiàn)或部分實(shí)現(xiàn)；設(shè)計(jì)不合理，存在缺陷；實(shí)際結(jié)果和預(yù)期結(jié)果不一致；運(yùn)行出錯(cuò)，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂；數(shù)據(jù)結(jié)果不正確、精度不夠；用戶不能接受的其他問題，如存取時(shí)間過長、界面不美觀。

缺陷基礎(chǔ)理論–原因缺陷基礎(chǔ)理論–修復(fù)成本缺陷基礎(chǔ)理論–分布特征集結(jié)（二八定理）缺陷往往喜歡扎堆，一個(gè)模塊已經(jīng)發(fā)現(xiàn)的缺陷比別的模塊多，通常不是代表這個(gè)模塊已經(jīng)把缺陷暴露完了，而是意味著這個(gè)模塊還存在有同樣多的缺陷尚未被發(fā)現(xiàn)。這就是著名的二八定理：80%的缺陷出現(xiàn)在20%的模塊。另外，在系統(tǒng)分析、系統(tǒng)設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)階段的復(fù)審，測試工作中能夠發(fā)現(xiàn)和避免80%的軟件缺陷，此后的系統(tǒng)測試能夠幫助我們找出剩余缺陷中的80%，最后的5%的軟件缺陷可能只有在系統(tǒng)交付使用后用戶經(jīng)過大范圍、長時(shí)間使用后才會(huì)曝露出來。因?yàn)檐浖y試只能夠保證盡可能多地發(fā)現(xiàn)軟件缺陷，卻無法保證能夠發(fā)現(xiàn)所有的軟件缺陷。缺陷基礎(chǔ)理論–抗藥性測試進(jìn)行得越多，新缺陷就越難被發(fā)現(xiàn)因?yàn)橹耙恢笔褂猛瑯拥臏y試思路，同樣的一套測試用例，沒有新的突破。某些缺陷天然地只有在很特殊或者很極端的情況下才會(huì)被觸發(fā)。并非所以缺陷都需要修改有一些原因，使得有些缺陷我們不修復(fù)：沒有足夠的時(shí)間不算真正的軟件缺陷修復(fù)的風(fēng)險(xiǎn)太大不值得修復(fù)軟件缺陷生命周期當(dāng)一個(gè)缺陷被發(fā)現(xiàn)了之后：測試工程師填寫《缺陷跟蹤單》，提交測試經(jīng)理審核測試經(jīng)理作出初步判斷，將問題單轉(zhuǎn)項(xiàng)目經(jīng)理審核項(xiàng)目經(jīng)理確認(rèn)問題單,轉(zhuǎn)給開發(fā)人員定位問題開發(fā)人員定位錯(cuò)誤后修復(fù)缺陷轉(zhuǎn)給項(xiàng)目經(jīng)理確認(rèn)項(xiàng)目經(jīng)理確認(rèn)完轉(zhuǎn)給轉(zhuǎn)給測試經(jīng)理確認(rèn)并組織測試測試人員對(duì)該修復(fù)進(jìn)行驗(yàn)證，確認(rèn)是否正確修復(fù)，確認(rèn)是否有引發(fā)新問題，是否影響了原有正常的功能

軟件缺陷流程軟件缺陷狀態(tài)缺陷狀態(tài)描述New（新建）測試中新報(bào)告的軟件缺陷，等待分派Open（打開）已確認(rèn)的缺陷，等待開發(fā)人員修改Fixed（已修復(fù)）已經(jīng)被開發(fā)人員修改的缺陷，等待測試人員校驗(yàn)Rejected（被拒絕）不是缺陷或不需要修復(fù)Reopen（重新打開）沒有修復(fù)，重新打開返回開發(fā)人員Postponed（掛起）因某種原因（如需求取消等）導(dǎo)致該問題不需要在當(dāng)前版本修改Closed（已關(guān)閉）已經(jīng)被測試人員確認(rèn)得到正確修復(fù)，可以關(guān)閉軟件缺陷等級(jí)缺陷嚴(yán)重程度描述1--致命軟件無法運(yùn)行，或者軟件的主要功能喪失，或者很大可能性會(huì)造成嚴(yán)重不良后果

2--嚴(yán)重?軟件的次要功能喪失，或者主要功能在一些特定情況下會(huì)出錯(cuò)

，比如金額計(jì)算等3--一般?軟件在某些情況下會(huì)出錯(cuò)，但是造成的后果影響不大4—提示提示文字出錯(cuò)，或缺少錯(cuò)誤提示4—建議不包含在需求內(nèi)，是希望可以實(shí)現(xiàn)或優(yōu)化的功能附帶上所有有價(jià)值的信息一個(gè)好的缺陷單，是你提交之后就再也沒人聯(lián)系你，然后過了一段時(shí)間已經(jīng)被完美地修復(fù)，轉(zhuǎn)回到你手上進(jìn)行驗(yàn)證測試這樣的一個(gè)單子要做到這樣，你應(yīng)該提供足夠的信息，使得開發(fā)人員既能夠明確如何重現(xiàn)故障現(xiàn)象，又有足夠的信息定位到問題的根源除了書寫良好的重現(xiàn)步驟，你還可以考慮附上打印日志，截圖，網(wǎng)絡(luò)抓包，錄屏。合理地利用各種手段強(qiáng)調(diào)關(guān)鍵信息假如你的缺陷跟蹤單支持字體顏色關(guān)鍵詞強(qiáng)調(diào)特殊標(biāo)記例子–Excel例子–Bugfree缺陷寫作練習(xí)1.當(dāng)運(yùn)行WORD程序時(shí)，如果輸入字符SHUTDOWN，會(huì)導(dǎo)致程序自動(dòng)