1.軟件生命周期模型 從概念提出的那一刻開始,軟件產(chǎn)品就進(jìn)入了軟件生命周期。在經(jīng)歷需求、分析、設(shè)計、實現(xiàn)、部署后,軟件將被使用并進(jìn)入維護(hù)階段,直到最后由于缺少維護(hù)費用而逐漸消亡。這樣的一個過程,稱為"生命周期模型"(Life Cycle Model)。 典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。 瀑布模型的特點(文檔是主體),很多的問題在最后才會暴露出來。迭代模型比瀑布模型問題暴露的要早;快速原型法比瀑布模型直觀。 2.軟件測試概念 廣義概念:指軟件生存周期中所有的檢查、評審和確認(rèn)工作,其中包括了對分析、設(shè)計階段,以及完成開發(fā)后維護(hù)階段的各類文檔、代碼的審查和確認(rèn) 狹義概念:識別軟件缺陷的過程,即實際結(jié)果與預(yù)期結(jié)果的不一致 3.軟件測試目的 ü 測試的目的就是發(fā)現(xiàn)軟件中的各種缺陷 ü 測試只能證明軟件存在缺陷,不能證明軟件不存在缺陷 ü 測試可以使軟件中缺陷降低到一定程度,而不是徹底消滅 ü 以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷,以確保軟件的質(zhì)量 4.軟件測試原則 ü Good-enough: 一種權(quán)衡投入/產(chǎn)出比的原則 ü 保證測試的覆蓋程度,但窮舉測試是不可能的 ü 所有的測試都應(yīng)追溯到用戶需求 ü 越早測試越好,測試過程與開發(fā)過程應(yīng)是相結(jié)合的 ü 測試的規(guī)模由小而大,從單元測試到系統(tǒng)測試 ü 為了盡可能地發(fā)現(xiàn)錯誤,應(yīng)該由獨立的第三方來測試 ü 不能為了便于測試擅自修改程序 ü 既應(yīng)該測試軟件該做什么也應(yīng)該測試軟件不該做什么 5.軟件測試的的重點 ü 測試用例的設(shè)計 – 測試用例的設(shè)計是整個軟件測試工作的核心 – 測試用例反映對被測對象的質(zhì)量要求,決定對測試對象的質(zhì)量評估 ü 測試工作的管理 – 尤其是對包含多個子系統(tǒng)的大型軟件系統(tǒng),其測試工作涉及大量人力和物力,有效的測試工作管理是保證有效測試工作的必要前提 ü 測試環(huán)境的建立 – 測試環(huán)境應(yīng)該與實際測試環(huán)境一致 6.黑盒測試 ü 什么是黑盒測試 – 又稱功能測試或數(shù)據(jù)驅(qū)動測試,是針對軟件的功能需求/實現(xiàn)進(jìn)行測試,通過測試來檢測每個功能是否符合需求,不考慮程序內(nèi)部的邏輯結(jié)構(gòu) ü 黑盒測試方法 – 功能劃分 – 等價類劃分 – 邊界值分析 – 因果圖 – 錯誤推測等 7.什么是白盒測試 – 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試,必須知道軟件內(nèi)部工作過程,通過測試來檢測軟件內(nèi)部是否按照需求、設(shè)計正常運行 – 白盒測試的主要方法 – 對應(yīng)于程序的一些主要結(jié)構(gòu):語句、分支、邏輯路徑、變量;白盒測試的主要方法是: – 語句覆蓋方法 – 分支覆蓋方法 – 邏輯覆蓋方法 8. 什么是動態(tài)測試 動態(tài)測試需要在開發(fā)/測試環(huán)境或?qū)嶋H運行環(huán)境中運行軟件,并使用測試用例去查找軟件缺陷;動態(tài)測試包括功能確認(rèn)與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等 9.什么是靜態(tài)測試 靜態(tài)測試不實際運行軟件,主要是對軟件的編程格式、結(jié)構(gòu)等方面進(jìn)行評估.靜態(tài)測試包括代碼檢查、程序結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行,也可以借助軟件工具自動進(jìn)行 10.手工測試和自動測試 a.手工測試缺點在于測試工作量大,重復(fù)多,回歸測試難以實現(xiàn) b.自動測試?yán)密浖y試工具自動實現(xiàn)全部或部分測試工作:管理、設(shè)計、執(zhí)行和報告;節(jié)省大量的測試開銷,并能夠完成一些手工測試無法實現(xiàn)的測試 ü 手工完成測試的全部過程無法保證測試的科學(xué)性與嚴(yán)密性: – 修改的缺陷越多,回歸測試越困難 – 沒有人能向決策層提供精確的數(shù)據(jù)以度量當(dāng)前的工作進(jìn)度及工作效率 – 反復(fù)測試帶來的倦怠情緒及其他人為因素使得測試標(biāo)準(zhǔn)前后不一 – 測試花費的時間越長,測試的嚴(yán)格性也就越低 ü 自動測試將測試人員從反復(fù)、煩雜的測試執(zhí)行中解放出來,用更多的時間進(jìn)行測試設(shè)計和結(jié)果分析 ü 軟件測試不可能完全自動化 ü 不能完成所有手工測試任務(wù) ü 無創(chuàng)造性且靈活性差,不能改進(jìn)測試的有效性 ü 過程中可能會遇到許多意想不到的問題,特別是當(dāng)軟件不穩(wěn)定時 ü 測試腳本的維護(hù)高 11. 測試流程 ü 單元測試 ü 集成測試 ü 系統(tǒng)測試 ü 用戶驗收測試 ü 12.單元測試 ü 完成對最小的軟件設(shè)計單元—模塊的驗證工作 ü 目標(biāo)是確保模塊被正確地編碼 ü 使用過程設(shè)計描述作為指南,對重要的控制路徑進(jìn)行測試以發(fā)現(xiàn)模塊內(nèi)的錯誤 ü 通常情況下是面向白盒的 ü 對代碼風(fēng)格和規(guī)則、程序設(shè)計和結(jié)構(gòu)、業(yè)務(wù)邏輯等進(jìn)行靜態(tài)測試,及早地發(fā)現(xiàn)和解決不易顯現(xiàn)的錯誤 ü 單元測試的內(nèi)容 – 接口測試 – 內(nèi)部數(shù)據(jù)結(jié)構(gòu) – 全局?jǐn)?shù)據(jù)結(jié)構(gòu) – 邊界 – 語句覆蓋,錯誤路徑 13.集成測試 ü 通過測試發(fā)現(xiàn)與模塊接口有關(guān)的問題 ü 目標(biāo)是把通過了單元測試的模塊拿來,構(gòu)造一個在設(shè)計中所描述的程序結(jié)構(gòu) ü 應(yīng)當(dāng)避免一次性的集成(除非軟件規(guī)模很小),而采用增量集成 集成測試主要內(nèi)容 ü API ü API/參數(shù)組合 14.系統(tǒng)測試 ü 根據(jù)軟件需求規(guī)范的要求進(jìn)行系統(tǒng)測試,確認(rèn)系統(tǒng)滿足需求的要求 ü 系統(tǒng)測試人員相當(dāng)于用戶代言人 ü 在需求分析階段要確定軟件的可測性,保證有效完成系統(tǒng)測試工作 ü 系統(tǒng)測試主要內(nèi)容 ü 所有功能需求得到滿足 ü 所有性能需求得到滿足 ü 其他需求(例如安全性、容錯性、兼容性等)得到滿足 15.用戶驗收/確認(rèn)測試 ü Alpha測試 – 是由用戶在開發(fā)者的場所來進(jìn)行的,Alpha測試是在一個受控的環(huán)境中進(jìn)行的 ü Beta測試 – 由軟件的最終用戶在一個或多個用戶場所來進(jìn)行的,開發(fā)者通常不在現(xiàn)場,用戶記錄測試中遇到的問題并報告給開發(fā)者 16.壓力測試VS性能測試 性能測試是為了檢查系統(tǒng)的反映,運行速度等性能指標(biāo),他的前提是要求在一定負(fù)載下,如檢查一個網(wǎng)站在100人同時在線的情況下的性能指標(biāo),每個用戶是否都還可以正常的完成操作等。 壓力測試是為了發(fā)現(xiàn)系統(tǒng)能支持的最大負(fù)載,他的前提是要求系統(tǒng)性能處在可以接受的范圍內(nèi),比如經(jīng)常規(guī)定的葉面3秒鐘內(nèi)響應(yīng);概括就是:在性能可以接受的前提下,測試系統(tǒng)可以支持的最大負(fù)載。 舉例說明:針對一個網(wǎng)站進(jìn)行測試,模擬10到50個用戶就是在進(jìn)行常規(guī)性能測試,用戶增加到1000乃至上萬就變成了壓力/負(fù)載測試。如果同時對系統(tǒng)進(jìn)行大量的數(shù)據(jù)查詢操作,就包含了強度測試。 17. 主流測試工具的測試流程 ========winrunner |
|