軟件測試相關(guān)知識

軟件測試相關(guān)知識大綱1、什么是軟件測試2、軟件測試工作內(nèi)容和流程3、測試方法案例千年蟲問題20世紀70年代，人們所使用的計算機存儲空間很小，程序員為了節(jié)省存儲空間，將存儲日期只存儲2位，如1974存儲為74。工資系統(tǒng)經(jīng)常依賴于日期的處理，因此他們節(jié)省了大量的空間，他們知道在2000年到來時會出現(xiàn)問題，比如銀行在計算利息時，用當前的日期（如“2000年1月1日”）減去客戶的存款日期（如“1974年1月1日”），如果年利息為3%，那么，每一百元銀行應(yīng)付給客戶78的利息。如果與年份存儲問題沒有得到糾正，其存款年數(shù)就變?yōu)?74年，客戶反而應(yīng)該付給銀行利息了，這顯然是不合理的。但他們認為在20多年內(nèi)程序肯定會更新或升級，而且眼前的任務(wù)比計劃遙不可及的未來更加重要。為此，全世界付出了數(shù)千萬美元的代價來更換或升級類似程序以解決千年蟲的問題，特別是金融、保險、軍事、科學、商務(wù)等領(lǐng)域，花費了大量的人力，物力對已有的各種各樣的程序進行檢查，修改和更新。Intel奔騰處理器芯片缺陷在pc機的“計算器”中輸入以下模式：（4195835/3145727）X3145727—4195835如果答案不為0，就說明計算機使用的是帶有浮點除法軟件缺陷的老式Intel奔騰處理器。1994年，美國佛吉利亞州Lynchburg學院的以為博士在用奔騰PC機解決一個除法問題時，發(fā)現(xiàn)了這個問題。他將發(fā)現(xiàn)的問題放在internet上，引發(fā)了一場風暴，成千上萬的人發(fā)現(xiàn)了同樣的問題，以及其他的出錯誤結(jié)果的情形。萬幸的是，這種情況很少出現(xiàn)，僅在精度要求很高的數(shù)學，科學和工程計算中才會出現(xiàn)。這個事件引起人們關(guān)注的原因并不是這個軟件缺陷，而是Intel公司解決問題態(tài)度。Intel公司的測試工程師在芯片發(fā)布之前已經(jīng)發(fā)現(xiàn)了這個問題，但管理層認為還沒有嚴重到一定要修正，甚至公開的程度。當這個軟件缺陷被發(fā)現(xiàn)時，Intel公司通過新聞發(fā)布和公開聲明試圖弱化問題的嚴重性。當壓力增大時，Intel承諾可以更換有問題的芯片，單要求用戶必須證明自己受到缺陷的影響。結(jié)果輿論嘩然，internetshang

充斥著憤怒的客戶要求Intel公司解決問題呼聲，新聞報道將Intel公司描繪成不誠信者。最后，Intel公司為自己處理軟件缺陷的行為道歉并拿出4億多美元來支付更換芯片的費用。由此可見，一個小小的軟件缺陷造成的損失可能有多大。軟件測試背景早期：軟件開發(fā)過程中，將測試等同于“調(diào)試”。目的是糾正軟件中已經(jīng)知道的故障，通常由開發(fā)人員自己完成這部分的工作。常常是等到形成代碼，產(chǎn)品已經(jīng)基本完成時，才進行測試。直到1957年，軟件測試區(qū)別于調(diào)試，成為一種發(fā)現(xiàn)軟件缺陷的活動。1972年在北卡羅來納大學舉行了首屆軟件測試正式會議。1975年在IEEE上發(fā)表了“測試數(shù)據(jù)選擇的原理”的文章，軟件測試才被確定為一種研究方向。1979年GlenfordMyers的《軟件測試藝術(shù)》中，定義“測試是為發(fā)現(xiàn)錯誤而執(zhí)行的一個程序或者系統(tǒng)的過程”————測試過程發(fā)展的里程碑軟件測試背景，國外軟件測試人員與開發(fā)人員的比例微軟的開發(fā)工程師與測試工程師的比例1∶2，國內(nèi)一般公司是6∶1；軟件測試概念軟件測試就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。軟件測試階段需求測試單元測試集成測試確認測試系統(tǒng)測試回歸測試驗收測試需求測試：需求規(guī)格說明說，概要設(shè)計文檔，詳細設(shè)計文檔，是否描述不準確，需求定義模糊等問題；單元測試：又叫“模塊測試”檢測程序模塊中有無故障存在集成測試：發(fā)生在模塊與模塊、接口確認測試：按需求說明書的功能要求系統(tǒng)測試：在軟、硬件、網(wǎng)絡(luò)環(huán)境下回歸測試：重復執(zhí)行集成和系統(tǒng)測試的測試用例驗收測試：按照項目任務(wù)書或合同、供需雙方約定的驗收依據(jù)文檔進行的對整個系統(tǒng)的測試與評審，決定是否接收或拒收系統(tǒng)?！皹渖嫌惺圾B，開槍打死一只，還剩幾只？”需求測試單元測試回歸測試驗收測試集成測試系統(tǒng)測試軟件測試流程：V模型和W模型軟件測試模型V模型：強調(diào)軟件開發(fā)的協(xié)作和速度，反映測試活動與分析設(shè)計關(guān)系，清楚描述了測試階段和研發(fā)過程間各階段對應(yīng)關(guān)系局限性：忽視測試活動對需求分析，系統(tǒng)設(shè)計等活動的驗證和確認功能W模型：雙V模型組成，分別代表測試和開發(fā)過程強調(diào)測試伴隨整個軟件開發(fā)周期，測試開發(fā)同步進行，有利于盡早發(fā)現(xiàn)問題，測試不僅是程序，包括需求和設(shè)計優(yōu)點：有利于及時了解項目難度和測試風險，及早制定應(yīng)對措施，顯著減少總體測試實踐，加快項目進度V模型軟件測試

W模型軟件測試軟件測試模型V模型：強調(diào)軟件開發(fā)的協(xié)作和速度，反映測試活動與分析設(shè)計關(guān)系，清楚描述了測試階段和研發(fā)過程間各階段對應(yīng)關(guān)系局限性：忽視測試活動對需求分析，系統(tǒng)設(shè)計等活動的驗證和確認功能W模型：雙V模型組成，分別代表測試和開發(fā)過程強調(diào)測試伴隨整個軟件開發(fā)周期，測試開發(fā)同步進行，有利于盡早發(fā)現(xiàn)問題，測試不僅是程序，包括需求和設(shè)計優(yōu)點：有利于及時了解項目難度和測試風險，及早制定應(yīng)對措施，顯著減少總體測試實踐，加快項目進度軟件測試范圍功能測試易用性測試兼容性測試負載壓力測試安裝卸載測試安全性測試接口測試數(shù)據(jù)庫測試軟件測試方法靜態(tài)測試動態(tài)測試黑盒測試白盒測試靜態(tài)測試：主要是查看的方法，包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等；如：單元測試。動態(tài)測試：主要是當軟件系統(tǒng)在模擬的或真實的環(huán)境中執(zhí)行之前、之中和之后，對軟件系統(tǒng)行為的分析：如：人工進行的系統(tǒng)測試，自動化測試黑盒、白盒測試黑盒測試：檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用，程序是否能接收輸入數(shù)據(jù)而產(chǎn)生正確的輸出信息，并保持數(shù)據(jù)庫或文件的完整性；在測試流程中的應(yīng)用：確認測試、系統(tǒng)測試、驗收測試；白盒測試：基于覆蓋全部代碼、分支、路徑、條件，使用程序設(shè)計的控制結(jié)構(gòu)導出測試用例測試流程中應(yīng)用：單元測試，集成測試白盒測試幫助測試人員增大代碼覆蓋率，提高代碼質(zhì)量黑盒測試發(fā)現(xiàn)錯誤類型功能不對或遺漏界面錯誤數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤性能問題初始化和終止錯誤黑盒測試方法等價類劃分法：（做計算器程序）時，在兩數(shù)相加中，1+1，1+2，1+9，1+999邊界值分析法：如果軟件接受用戶輸入1-1000的數(shù)字，該如何輸入？

錯誤推測法：列舉出程序中所有可能的錯誤和容易發(fā)生錯誤的特殊情況。例子：設(shè)計一些非法、錯誤、不正確和垃圾數(shù)據(jù)進行輸入測試是很有意義的。因果圖法：投幣機的例子：有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟件。若投入，若投入1元5角錢硬幣，按下“可樂”或“雪碧”，相應(yīng)的飲料酒送出來。若投入的是2元硬幣，在送出飲料的同時退還5角硬幣。原因：（1）投入1元5角硬幣；（2）投入2元硬幣（3）按“可樂”按鈕；（4）按“雪碧”按鈕中間狀態(tài)：（1）已投幣；（2）已按鈕結(jié)果：（1）退還5角硬幣；（2）送出“可樂”飲料（3）送出“雪碧”飲料。場景法進入審計系統(tǒng)，某用戶設(shè)定策略，有觸發(fā)策略的記錄，產(chǎn)生報警功能的用例?；玖鳎罕居美拈_始，GNPSJ軟件處于準備就緒狀態(tài)。驗證用戶：輸入用戶名、密碼，驗證碼添加策略窗口在添加策略的必填項，都輸入正確且完畢執(zhí)行策略生效觸發(fā)策略，查詢到報警本用例結(jié)束時，，GNPSJ軟件又回到準備就緒狀態(tài)。備選流1：不存在該用戶備選流2：用戶驗證失敗備選流3：添加策略的必填項沒有完全輸入，出現(xiàn)輸入提示備選流4：策略沒有生效備選流5：策略成功下發(fā)，未觸發(fā)策略，但無報警記錄。問題：有了黑盒測試為什么還要白盒測試？系統(tǒng)測試和驗收測試內(nèi)容幾乎是相同的，為什么還要驗收測試？白盒測試發(fā)現(xiàn)錯誤類型檢查代碼和設(shè)計的一致性代碼對標準的遵循和可讀性代碼邏輯表達的正確性代碼結(jié)構(gòu)合理性程序編寫與編寫標準符合性程序中不安全、不明確和模糊部分編程風格白盒測試方法代碼檢查法邏輯覆蓋法基本路徑覆蓋法代碼檢查法代碼檢查法的方式桌面檢查：程序員對源文件代碼進行分析、檢查并補充相關(guān)文檔，發(fā)現(xiàn)程序中錯誤的過程走查：程序員和測試員組成的審查小組通過邏輯運行程序發(fā)現(xiàn)問題的過程代碼審查：程序員和測試員組成的審查小組通過閱讀、討論、分析技術(shù)對程序進行靜態(tài)分析的過程邏輯覆蓋法語句覆蓋法：選擇足夠多的測試數(shù)據(jù)，使得程序中的每個執(zhí)行語句至少執(zhí)行一次判定覆蓋法：設(shè)計足夠多的測試用例，使得程序中每個判定至少獲得一次真和假條件覆蓋