軟件測試導(dǎo)論

1、軟件測試導(dǎo)論軟件測試相關(guān)概念定義、目的、對象、分類等軟件測試的定義 軟件測試（軟件測試（Software testingSoftware testing）是軟件生存期中的一）是軟件生存期中的一個重要階段，是軟件質(zhì)量保證的關(guān)鍵步驟。通俗地講，個重要階段，是軟件質(zhì)量保證的關(guān)鍵步驟。通俗地講，軟件測試就是在軟件投入運(yùn)行前，對軟件需求分析、軟件測試就是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼進(jìn)行最終復(fù)審的活動。設(shè)計規(guī)格說明和編碼進(jìn)行最終復(fù)審的活動。19831983年年IEEEIEEE提出的軟件工程術(shù)語中給軟件測試下的定提出的軟件工程術(shù)語中給軟件測試下的定義是：義是：“使用人工或自動的手段來

2、運(yùn)行或測定某個軟使用人工或自動的手段來運(yùn)行或測定某個軟件系統(tǒng)或系統(tǒng)部件的過程，其目的在于檢驗(yàn)它是否滿件系統(tǒng)或系統(tǒng)部件的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別別”。軟件測試的意義v愛國者導(dǎo)彈防御系統(tǒng) 一個小的系統(tǒng)時鐘錯誤，導(dǎo)致在多哈襲擊戰(zhàn)中，系統(tǒng)被拖延100多個小時。 1991v美國航天局火星極地登陸 由于確定何時關(guān)閉推進(jìn)器的程序中某一個數(shù)據(jù)位被意外修改，飛船在試圖登陸火星表面失蹤。 1999軟件測試的對象12345用戶需求用戶：我要什么？理解正確性理解正確性表達(dá)正確性表達(dá)正確性需求說明書需求分析員：我可以提供什么？

3、設(shè)計說明書設(shè)計員：我要軟件做什么？源程序程序員：我要要讓計算機(jī)怎么做？運(yùn)行結(jié)果計算機(jī)：程序運(yùn)行得到的結(jié)果理解正確性理解正確性設(shè)計正確性設(shè)計正確性表達(dá)正確性表達(dá)正確性理解正確性理解正確性編碼正確性編碼正確性運(yùn)行正確性運(yùn)行正確性輸入正確性輸入正確性相符合么？相符合么？軟件測試的目的基于不同的立場，存在著兩種完全不同的測試目的。從用戶（測試人員）的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。 從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們對軟件質(zhì)量的信心。 軟件測試的原則所有的測試都應(yīng)可追溯到客

4、戶需求 窮舉測試是不可能的 嚴(yán)格執(zhí)行測試計劃，排除測試的隨意性。應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查。妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護(hù)提供方便。黑盒測試基于軟件需求，而不是基于軟件內(nèi)部設(shè)計和程序?qū)崿F(xiàn)的測試方式。白盒測試基于軟件內(nèi)部設(shè)計和程序?qū)崿F(xiàn)的測試方式。單元測試主要測試軟件模塊的源代碼。一般由開發(fā)人員而非獨(dú)立測試人員來執(zhí)行，因?yàn)闇y試者需要懂得該單元的設(shè)計與程序?qū)崿F(xiàn)，測試者可能需要編寫額外的測試驅(qū)動程序。集成測試將一些“構(gòu)件”集成一起時，測試它們能否正常運(yùn)行。這里“構(gòu)件”可以是程序模塊、客戶機(jī)服務(wù)器程序等等。功能測試測試軟件的功能是否符合功能性需求，通常采用黑盒測試方式。一

5、般由獨(dú)立測試人員執(zhí)行。系統(tǒng)測試測試軟件系統(tǒng)是否符合所有需求，包括功能性需求與非功能性需求。一般由獨(dú)立測試人員執(zhí)行，通常采用黑盒測試方式?；貧w測試指錯誤被修正后或軟件功能、環(huán)境發(fā)生變化后進(jìn)行的重新測試?；貧w測試的困難在于不好確定哪些內(nèi)容應(yīng)當(dāng)被重新測試。驗(yàn)收測試由客戶或最終用戶執(zhí)行，測試軟件系統(tǒng)是否符合需求規(guī)格說明書。軟件測試的分類軟件測試的分類負(fù)載測試測試軟件系統(tǒng)的最大負(fù)載，超出此負(fù)載軟件可能會失常。壓力測試概念上與負(fù)載測試相似，叫法不同。性能測試測試軟件在各種狀況下的性能，如在正?；蜃畲筘?fù)載下的狀況。易用性測試測試軟件是否易用，主觀性比較強(qiáng)。一般要根據(jù)很多用戶的測試反饋信息，才能評價易用性。安

6、裝與反安裝測試測試軟件在“全部、部分、升級”等狀況下的安裝/反安裝過程?；謴?fù)測試測試該系統(tǒng)從故障中恢復(fù)過來的能力。安全性測試測試該系統(tǒng)防止非法侵入的能力。兼容性測試測試該系統(tǒng)與其它軟件硬件兼容的能力。比較測試通過與同類產(chǎn)品比較，考察該系統(tǒng)的優(yōu)點(diǎn)、缺點(diǎn)。Alpha 測試一種先期的用戶測試，此時系統(tǒng)剛剛開發(fā)完成。Beta測試一種后期的用戶測試，此時系統(tǒng)已經(jīng)通過內(nèi)部測試，大部分錯誤已經(jīng)改正，即將正式發(fā)行。軟件測試方法測試用例設(shè)計、缺陷提交法則等測試人員相關(guān)素質(zhì)打破沙鍋問到底1.探索精神：軟件測試員不會害怕進(jìn)入陌生環(huán)境。2.故障排除能手：軟件測試員善于發(fā)現(xiàn)問題的癥結(jié)，喜歡猜謎。3.不懈努力：軟件測試員

7、總是不停嘗試。他們可能會碰到轉(zhuǎn)瞬即逝或者難以重建的軟件缺陷；他們不會心存僥幸，而是盡一切可能去尋找。4.創(chuàng)造性：想出富有創(chuàng)意甚至超常的手段來尋找軟件缺陷。5.追求完美：他們力求完美，但是知道某些無法企及時，不去苛求，而是盡力接近目標(biāo)。6.判斷準(zhǔn)確：軟件測試員要決定測試內(nèi)容、測試時間，以及看到的問題是否算作真正的缺陷。7.老練穩(wěn)重：軟件測試員不害怕壞消息。8.說服力：軟件測試員要善于表達(dá)觀點(diǎn)，表明軟件缺陷為何必須修復(fù)，并通過實(shí)際演示力陳訴觀點(diǎn)。測試相關(guān)文檔測試計劃：指明范圍、方法、資源，以及相應(yīng)測試活動的時間進(jìn)度安排表的文檔。測試方案：指明為完成軟件或軟件集成特性的測試而進(jìn)行的設(shè)計測試方法的細(xì)節(jié)

8、文檔。測試用例：指明為完成一個測試項(xiàng)的測試輸入、預(yù)期結(jié)果、預(yù)期執(zhí)行條件等因素的文檔。測試報告：指明執(zhí)行測試結(jié)果的文檔。什么是測試用例？所謂的測試用例就是將軟件測試的行為活動，做一個科學(xué)化的組織歸納。軟件測試是有組織性、步驟性和計劃性的，而設(shè)計軟件測試用例的目的，就是為了能將軟件測試的行為轉(zhuǎn)換為可管理的模式。軟件測試是軟件質(zhì)量管理中最實(shí)際的行動，同時也是耗時最多的一項(xiàng)?；跁r間因素的考慮，軟件測試行為必須能夠加以量化，才能進(jìn)一步讓管理階層掌握所需要的測試過程，而測試用例就是將測試行為具體量化的方法之一。測試用例要素所屬模塊：按照不同的模塊進(jìn)行測試，為測試用例分組；編號ID：測試用例的唯一性標(biāo)志；

9、用例描述：簡單的語言描述所測試的內(nèi)容，例如“設(shè)置廣播服務(wù)器網(wǎng)絡(luò)參數(shù)，并測試網(wǎng)絡(luò)連通性”；重要級別：高、中、低三級；、預(yù)置條件：就是執(zhí)行當(dāng)前測試用例的前提描述，如果不滿足這些條件，則無法進(jìn)行測試；測試輸入：測試用例執(zhí)行時，需要輸入的外部信息。例如：某一個文件，數(shù)據(jù)記錄等；操作步驟：執(zhí)行當(dāng)前測試用例所要經(jīng)過的操作步驟，需要給出每一步操作的詳細(xì)描述，測試人員根據(jù)測試用例操作步驟，完成測試用例的執(zhí)行預(yù)期結(jié)果：當(dāng)前測試用例的預(yù)期輸出結(jié)果，用來與實(shí)際結(jié)果比較，如果相同則該測試用例通過，否則該測試用例失敗。測試結(jié)果：Pass、Fail、Block測試用例設(shè)計方法等價等價類劃類劃分法分法邊界邊界值分值分析法析

10、法場景場景法法錯誤錯誤推測推測法法因果因果圖法圖法判定判定表驅(qū)表驅(qū)動法動法正交正交試驗(yàn)試驗(yàn)設(shè)計設(shè)計法法功能功能圖法圖法等價類劃分法等價類劃分法等價類劃分等價類劃分法是把程序的輸入域劃分成若干部分，法是把程序的輸入域劃分成若干部分，然后然后從每個部分從每個部分中選取少數(shù)代表性數(shù)據(jù)當(dāng)作測試用例中選取少數(shù)代表性數(shù)據(jù)當(dāng)作測試用例。每。每一類的代表性數(shù)據(jù)在測試中的一類的代表性數(shù)據(jù)在測試中的作用等價于這一類作用等價于這一類中的中的其他值，也就是說，如果某一類中的一個例子發(fā)其他值，也就是說，如果某一類中的一個例子發(fā)現(xiàn)了現(xiàn)了錯誤錯誤，這一等價類中的其他例子也能發(fā)現(xiàn)同樣的錯誤；反之，這一等價類中的其他例子也能發(fā)

11、現(xiàn)同樣的錯誤；反之，如果，如果某一類中的一個例子沒有發(fā)現(xiàn)錯誤，則這一類中的某一類中的一個例子沒有發(fā)現(xiàn)錯誤，則這一類中的其他其他例子也不會查出例子也不會查出錯誤。錯誤。 邊界值分析法邊界值分析法由由測試工作的經(jīng)驗(yàn)得知，大量的錯誤是發(fā)生在輸入測試工作的經(jīng)驗(yàn)得知，大量的錯誤是發(fā)生在輸入或輸出或輸出范范圍的邊界上，而不是在輸入范圍的內(nèi)部。因此圍的邊界上，而不是在輸入范圍的內(nèi)部。因此針對針對各種邊界情各種邊界情況設(shè)計測試用例，可以查出更多的錯誤。況設(shè)計測試用例，可以查出更多的錯誤。 邊界值分析邊界值分析是一種補(bǔ)充等價劃分的測試用例設(shè)計技術(shù)是一種補(bǔ)充等價劃分的測試用例設(shè)計技術(shù)，它，它不不是選擇等價類的任意

12、元素，而是選擇等價類邊界是選擇等價類的任意元素，而是選擇等價類邊界的測試用例的測試用例。實(shí)踐證明為檢驗(yàn)邊界附近的處理專門設(shè)計實(shí)踐證明為檢驗(yàn)邊界附近的處理專門設(shè)計測試用例測試用例，常常取得，常常取得良好的測試效果。良好的測試效果。場景法場景法 現(xiàn)在現(xiàn)在的軟件幾乎都是用事件觸發(fā)來控制流程的，事件的軟件幾乎都是用事件觸發(fā)來控制流程的，事件觸發(fā)時的情景便形成了場景，而同一事件不同的觸發(fā)順觸發(fā)時的情景便形成了場景，而同一事件不同的觸發(fā)順序和處理結(jié)果就形成事件流。這種在軟件設(shè)計方面的思序和處理結(jié)果就形成事件流。這種在軟件設(shè)計方面的思想也可引入到軟件測試中，可以比較生動地描繪出事件想也可引入到軟件測試中，可

13、以比較生動地描繪出事件觸發(fā)時的情景，有利于測試設(shè)計者設(shè)計測試用例，同時觸發(fā)時的情景，有利于測試設(shè)計者設(shè)計測試用例，同時使測試用例更容易理解和執(zhí)行。使測試用例更容易理解和執(zhí)行。用例用例場景用來描述流經(jīng)用例的路徑，從用例開始到結(jié)場景用來描述流經(jīng)用例的路徑，從用例開始到結(jié)束遍歷這條路徑上所有基本流和備選流。束遍歷這條路徑上所有基本流和備選流。軟件缺陷bug五級規(guī)范七級規(guī)范（bugzilla嚴(yán)重級別，Severity）bugzilla優(yōu)先級（Priority）問題級別描述問題嚴(yán)重等級級別定義描述1導(dǎo)致系統(tǒng)崩潰、死機(jī)；出現(xiàn)不可挽救的數(shù)據(jù)丟失或損壞、內(nèi)存泄露；blocker中斷缺陷Blocks debel

14、opment and/or testing work.妨礙開發(fā)和測試，非常嚴(yán)重。例如：程序不能運(yùn)行起來，服務(wù)不能啟動，或啟動以后立刻崩潰。P12導(dǎo)致程序模塊丟失或未實(shí)現(xiàn)；軟件錯誤導(dǎo)致數(shù)據(jù)丟失；用戶需求未實(shí)現(xiàn)；critical臨界缺陷crashes,loss of data,severe memory leak.軟件崩潰、丟失數(shù)據(jù)或嚴(yán)重的內(nèi)存泄漏等。例如：本應(yīng)7*24小時運(yùn)行的程序在運(yùn)行一天以后崩潰、錄像服務(wù)丟失錄像數(shù)據(jù)等。P23發(fā)現(xiàn)影響被測功能正確實(shí)現(xiàn)的問題；major較嚴(yán)重缺陷major loss of function.功能主體受損失。例如：原本設(shè)計的一個功能不能實(shí)現(xiàn)或?qū)崿F(xiàn)得不好，或影響實(shí)

15、際使用效果的缺陷。P3normal普通缺陷for an application crash or other issue.4一般性錯誤或者功能實(shí)現(xiàn)不完善等； minor次要缺陷minor loss of function,or other problem where easy workaround is present.功能受到較小的影響；或其他問題，可以通過簡單的方法解決；例如：較小功能按鈕的失效等。P4trivial輕微缺陷cosmetic problem like misspelled words or misaligned text .只存在于表面的問題，比如錯別字、拼寫錯誤或界面對齊

16、不好等。5一些建議性的錯誤；enhancement測試建議Request for enhancement.要求新增的功能，或者測試的建議。P5Bug描述要素bug六要素錄入要求范例摘要必選項(xiàng)。簡要、準(zhǔn)確、完整的描述錯誤實(shí)質(zhì)。需要注明出現(xiàn)問題的模塊、頁面以及按鈕名稱等，異常情況需在摘要后加上“（異常）”，建議類的問題需要在摘要后加上“（建議）”加以區(qū)分。摘要：（異常）客戶端-錄像回放，錄像下載過程中，異常停止下載。重建必選項(xiàng)。有層次的簡述出現(xiàn)bug的操作步驟。要求完整記錄與bug出現(xiàn)有關(guān)的操作，描述完畢后可根據(jù)重建的內(nèi)容自行操作一遍以確認(rèn)無誤。重建：客戶端，錄像下載，11月28日18:00以后選

17、擇70多個錄像文件開始下載，進(jìn)行老化測試。11月29日早晨發(fā)現(xiàn)，客戶端上顯示停留在一個錄像文件下載0%的進(jìn)度，是正在下載的狀態(tài)，但無下載速度，且沒有再本地生成文件。概率可選項(xiàng)。用于區(qū)分問題的出現(xiàn)概率。不寫時，出現(xiàn)概率應(yīng)為默認(rèn)的100%，如果并非每次都出現(xiàn)或者是異常問題一定要注明，可用百分比來表述，如兩次重現(xiàn)操作中有一次可以出現(xiàn)該問題，則概率為50%。概率：測試過程中在單臺客戶端出現(xiàn)三次。隔離可選項(xiàng)。用于區(qū)分問題的重要程度，并能幫助開發(fā)定位問題。無法隔離的bug和可以很容易隔離的bug對于項(xiàng)目的重要程度是不一樣的。隔離：停止不下載的文件，重新選擇一個錄像文件開始下載以后可以正常繼續(xù)。分析可選項(xiàng)。

18、記錄個人在測試中的分析過程，通過邏輯性的語言描述猜測問題可能出現(xiàn)的原因或相關(guān)聯(lián)產(chǎn)生的問題等。分析：經(jīng)抓包分析，錄像服務(wù)器沒有收到ack，可能因此導(dǎo)致此下載會話異常沒有開始且沒有斷開。附件可選項(xiàng)。盡可能的記錄圖片、dump文件（異常崩潰時必須有）、抓包文件等附件，附件可以幫助測試人員盡可能全面的向開發(fā)人員描述問題，降低溝通成本。附件：錄像異常停止下載.jpg，錄像異常停止下載.pcapBug描述的5C原則Correct： (準(zhǔn)確) 每個要素的描述準(zhǔn)確，不會引起誤解；Clear： (清晰) 每個組成部分的描述清晰，易于理解；Concise： (簡潔) 只包含必不可少的信息，不包含任何容易冗余信息，如操作過程中與bug的出現(xiàn)無關(guān)的操作步驟。Complete： (完整) 包含重現(xiàn)缺陷的完整步驟，和其他本質(zhì)信息。Consistent： (一致)按照一致的格式書寫全部的缺陷模塊。如客戶端-錄像回放-錄像下載，或服務(wù)器-會話服務(wù)器-會話?；?。性能測試性能測試通常會使用特定的測試工具，來模擬超常的數(shù)據(jù)量、負(fù)載等，監(jiān)測系統(tǒng)的各項(xiàng)性能指標(biāo)，性能測試通常會使用特定的測試工具，來模擬超常的數(shù)據(jù)量、負(fù)載等，監(jiān)測系統(tǒng)的各項(xiàng)性能指標(biāo)，如如CPUCPU和內(nèi)存的使用情況、響應(yīng)時間、反應(yīng)速