軟件測試解說(術(shù)語+流程+規(guī)范

1、軟件測試說明版本標(biāo)識(shí)注 釋作 者日 期V1.0周霸王2018.10.11 目錄1.概述31.1術(shù)語與縮寫32.測試資源42.1人員結(jié)構(gòu)安排43.測試流程53.1需求分析53.2用例設(shè)計(jì)63.2.1測試用例的編寫規(guī)范63.2.2測試用例的管理辦法63.3用例執(zhí)行84.測試執(zhí)行94.1測試范圍與策劃95.缺陷管理流程115.1缺陷過程描述115.2缺陷等級(jí)定義116.測試標(biāo)準(zhǔn)121. 概述制定完整且具體的測試路線和流程，為快速、高效和高質(zhì)量的軟件測試提供基礎(chǔ)流程框架。最終目標(biāo)是實(shí)現(xiàn)軟件測試規(guī)范化，標(biāo)準(zhǔn)化1.1 術(shù)語與縮寫術(shù)語、縮寫解 釋問題、缺陷、BUG軟件工作產(chǎn)品中的一種情況，它將導(dǎo)致軟件產(chǎn)生不

2、令人滿意或非預(yù)期的結(jié)果。測試計(jì)劃定義一個(gè)測試項(xiàng)目的過程，以便能夠正確的度量和控制測試測試設(shè)計(jì)描述系統(tǒng)需要測試的特性、方法、測試環(huán)境的規(guī)劃、測試工具的設(shè)計(jì)和選用方案和測試代碼的設(shè)計(jì)方案測試實(shí)現(xiàn)根據(jù)測試方案，對(duì)測試用例、工具和代碼加以具體的實(shí)現(xiàn)測試策略描述測試工程的總體方法和目標(biāo)白盒測試又稱結(jié)構(gòu)測試、邏輯測試，是一種基于程序內(nèi)部結(jié)構(gòu)的一種測試方法黑盒測試基于規(guī)格說明書和用戶手冊(cè)的要求，是一種從用戶觀點(diǎn)出發(fā)的測試方法單元測試（Unit Testing）又稱模塊測試，著重于程序內(nèi)部的結(jié)構(gòu)，多用白盒方法進(jìn)行測試集成測試（Integration Testing）組合不同功能模塊而形成一個(gè)大的功能進(jìn)行測試確

3、認(rèn)測試（Validation Testing）又稱有效性測試，目的驗(yàn)證軟件的功能和性能以及其特性是否與用戶的要求一致系統(tǒng)測試（System Testing）將通過確認(rèn)測試的軟件作為整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素，結(jié)合硬件、外設(shè)、其它支持軟件、數(shù)據(jù)和人員待系統(tǒng)元素，在實(shí)際的運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的集成測試和確認(rèn)測試驗(yàn)收測試以用戶為主，使用生產(chǎn)實(shí)際數(shù)據(jù)作為測試數(shù)據(jù)在真實(shí)環(huán)境下進(jìn)行測試，實(shí)際上是對(duì)整個(gè)測試計(jì)劃進(jìn)行一種走查功能測試對(duì)所有可直接追蹤到用例或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的測試需求用戶界面測試通過瀏覽用戶界面測試對(duì)象是否正確反映業(yè)務(wù)的功能和需求容錯(cuò)性測試測試系統(tǒng)的錯(cuò)誤處理、錯(cuò)誤保護(hù)是否正確文檔審

4、查檢查用戶文檔的完整性、正確性、一致性、易理解性和易瀏覽性測試在軟件組織內(nèi)部驗(yàn)收前，由測試部門進(jìn)行集成測試測試在實(shí)際使用環(huán)境下進(jìn)行的測試由典型用戶從用戶的角度出發(fā)，按用戶需求進(jìn)行測試，一般在Alpha測試達(dá)到一定可靠程度下才開始進(jìn)行Ad Hot測試對(duì)系統(tǒng)進(jìn)行隨機(jī)測試Closed關(guān)閉狀態(tài)，表示BUG已經(jīng)測試確認(rèn)被解決了回歸測試檢查上一階段測試發(fā)現(xiàn)的Bug是否已被解決了。2測試資源2.1 人員結(jié)構(gòu)安排工作人員角色職責(zé)前端應(yīng)用工程師1. 分小組分模塊對(duì)其他開發(fā)人員編寫的代碼進(jìn)行代碼走查；2. 配合測試小組的測試工作，修改各自模塊的測試缺陷；后臺(tái)數(shù)據(jù)工程師1. 分小組分模塊對(duì)其他實(shí)施人員編寫的代碼和S

5、QL語句進(jìn)行復(fù)查，執(zhí)行單元測試；2. 根據(jù)需求文檔+原型編寫測試代碼，驗(yàn)證系統(tǒng)各個(gè)模塊之間的接口、與外部系統(tǒng)之間接口的正確性；3. 配合測試小組的測試工作，修改各自模塊的測試缺陷；測試工程師1. 制定測試規(guī)格說明和測試計(jì)劃文檔，定義測試需求，設(shè)計(jì)并實(shí)現(xiàn)測試用例和測試腳本，設(shè)計(jì)并實(shí)現(xiàn)測試數(shù)據(jù)集，備份并歸檔所有測試文檔和資料。2. 制定測試計(jì)劃，測試分工安排，測試進(jìn)度管理，軟件質(zhì)量評(píng)估，測試工具開發(fā)、與項(xiàng)目經(jīng)理、上層領(lǐng)導(dǎo)的溝通等。3. 定期向項(xiàng)目經(jīng)理匯報(bào)測試進(jìn)展情況和問題，并與開發(fā)組、質(zhì)量專員保持及時(shí)有效溝通。4. 編寫模塊的測試用例，執(zhí)行測試用例，觀察記錄測試結(jié)果。等等2. 測試流程3.1 需求

6、分析需求分析是介于系統(tǒng)分析和軟件設(shè)計(jì)階段之間的橋梁。一方面，需求分析以系統(tǒng)規(guī)格說明和項(xiàng)目規(guī)劃作為分析活動(dòng)的基本出發(fā)點(diǎn)，并從軟件角度對(duì)它們進(jìn)行檢查與調(diào)整；另一方面，需求規(guī)格說明又是軟件設(shè)計(jì)、實(shí)現(xiàn)、測試直至維護(hù)的主要基礎(chǔ)。良好的分析活動(dòng)有助于避免或盡早剔除早期錯(cuò)誤，從而提高軟件生產(chǎn)率，降低開發(fā)成本，改進(jìn)軟件質(zhì)量。3.2 用例設(shè)計(jì)3.2.1測試用例的編寫規(guī)范測試用例的格式：測試用例需要包括以下要素：用例ID、功能模塊、測試要點(diǎn)/檢查點(diǎn)、變更類型、前置條件、優(yōu)先級(jí)、輸入數(shù)據(jù)/步驟、預(yù)期結(jié)果、實(shí)際結(jié)果、執(zhí)行狀態(tài)、執(zhí)行人、執(zhí)行日期、備注。3.2.2測試用例的管理辦法項(xiàng)目的測試用例，用EXCEL工具進(jìn)行管理

7、。已通過審批的測試用例需要變更，分不同的等級(jí)進(jìn)行管理。等級(jí)變更范圍審批流程高需求增加，需對(duì)新需求編寫測試用例項(xiàng)目經(jīng)理和技術(shù)總監(jiān)共同審核中需求變更，修改已有的測試用例或發(fā)現(xiàn)原測試用例，不符合原有的需求，需要變更測試用例。項(xiàng)目經(jīng)理和技術(shù)總監(jiān)共同審核低修改測試用例的錯(cuò)別字不需要審核。評(píng)審組成員包括但不限于：項(xiàng)目經(jīng)理、需求分析師、技術(shù)總監(jiān)、測試工程師。 功能或流程劃分是，一定要簡單、清晰，一個(gè)測試用例只檢查一個(gè)功能點(diǎn)或者一個(gè)流程。 測試用例的步驟描述要簡單、清晰，一步就是一步。 測試用例的數(shù)據(jù)要明確，特別是輸入數(shù)據(jù)和期望結(jié)果。 測試用例需要保障唯一性，即功能用例之間不存在重疊，流程用例不存在包含關(guān)系。

8、 描述要清晰、包括特定的場合、對(duì)象和術(shù)語，沒有含糊的概念和一般性的描述 測試用例中需要有充分的異常測試數(shù)據(jù)，考慮大數(shù)據(jù)量測試時(shí)的數(shù)據(jù)準(zhǔn)備。 測試用例應(yīng)確保覆蓋詳細(xì)設(shè)計(jì)中的所有功能。 對(duì)于無輸入的操作，應(yīng)該詳細(xì)描述其具體的操作步驟的結(jié)果。 測試用例需要保障數(shù)據(jù)的正確性和操作的正確性。3.2.1 等價(jià)類劃分法等價(jià)類劃分法是把程序的輸入域劃分成若干部分，然后從每個(gè)部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。每一類的代表性數(shù)據(jù)在測試中的作用等價(jià)于這一類中的其他值。3.2.2 邊界值分析法邊界值分析法就是對(duì)輸入或輸出的邊界值進(jìn)行測試的一種黑盒測試方法。通常邊界值分析法是作為對(duì)等價(jià)類劃分法的補(bǔ)充，這種情況下，其

9、測試用例來自等價(jià)類的邊界。3.2.3 錯(cuò)誤推測法基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤, 從而有針對(duì)性的設(shè)計(jì)測試用例的方法。3.2.4 因果圖法因果圖法是一種利用圖解法分析輸入的各種組合情況，從而設(shè)計(jì)測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。3.2.5 判定表驅(qū)動(dòng)法判定表是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況的工具。3.2.6 場景法用事件觸發(fā)來控制流程的，事件觸發(fā)時(shí)的情景便形成了場景，而同一事件不同的觸發(fā)順序和處理結(jié)果就形成事件流。這種在軟件設(shè)計(jì)方面的思想也可以引入到軟件測試中，可以比較生動(dòng)地描繪出事件觸發(fā)時(shí)的情景，有利于測試設(shè)計(jì)者設(shè)計(jì)測試用例，同時(shí)使測試用例更容易

10、理解和執(zhí)行。3.3 用例執(zhí)行根據(jù)已有的測試用例，按照里面的步驟一步一步的執(zhí)行查看預(yù)期結(jié)果與實(shí)際結(jié)果是否一致。 注意前置條件和特殊說明 測試用例要全部執(zhí)行 不要忽視任何偶然現(xiàn)象 加強(qiáng)測試過程記錄 詳細(xì)記錄預(yù)期與實(shí)際的不一致 及時(shí)更新測試用例3. 測試執(zhí)行4.1 測試范圍與策劃系統(tǒng)測試包括用戶確認(rèn)測試和功能測試兩個(gè)階段。用戶確認(rèn)測試主要由用戶方來檢驗(yàn)系統(tǒng)所有模塊的功能和其它特性是否真正無誤實(shí)現(xiàn)，重點(diǎn)在于檢驗(yàn)功能、業(yè)務(wù)流程、算法等實(shí)現(xiàn)是否正確，用戶界面是否符合操作性。系統(tǒng)的基準(zhǔn)測試；核實(shí)數(shù)據(jù)的接受、處理和檢索是否正確，以及業(yè)務(wù)規(guī)則的實(shí)施是否恰當(dāng) 4.2.1 功能測試功能測試側(cè)重于所有可直接追蹤到用例

11、或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的測試需求。這種測試的目標(biāo)是核實(shí)數(shù)據(jù)的接受、處理和檢索是否正確，以及業(yè)務(wù)規(guī)則的實(shí)施是否恰當(dāng)。此類測試基于黑盒技術(shù)，該技術(shù)通過圖形用戶界面與應(yīng)用程序進(jìn)行交互，并對(duì)交互的輸出或結(jié)果進(jìn)行分析，以此來核實(shí)應(yīng)用程序及其內(nèi)部進(jìn)程。以下為各種應(yīng)用程序列出了推薦使用的測試概要。測試目標(biāo)確保測試的功能正常，如導(dǎo)航，數(shù)據(jù)輸入，處理、檢索是否正確，以及業(yè)務(wù)規(guī)則的實(shí)施是否恰當(dāng)。方法利用有效的和無效的數(shù)據(jù)來執(zhí)行各個(gè)用例，以核實(shí)以下內(nèi)容：在使用有效數(shù)據(jù)時(shí)得到預(yù)期的結(jié)果。在使用無效數(shù)據(jù)時(shí)顯示相應(yīng)的錯(cuò)誤消息或警告消息。各業(yè)務(wù)規(guī)則都得到了正確的應(yīng)用。完成標(biāo)準(zhǔn)按所準(zhǔn)備的測試用例完成全部測試測試重點(diǎn)和優(yōu)先級(jí)1.

12、 算法的準(zhǔn)確性2. 輸入數(shù)據(jù)的完整性3. 輸出數(shù)據(jù)的完整性4. 功能的完整性5. 流程的合理性4.2.2 錯(cuò)容性測試容錯(cuò)性測試是對(duì)程序的錯(cuò)誤保護(hù)是否足夠進(jìn)行的測試，要求把每個(gè)需要有錯(cuò)誤保護(hù)的點(diǎn)都進(jìn)行容錯(cuò)測試，確保系統(tǒng)對(duì)誤操作或錯(cuò)誤數(shù)據(jù)有充分的錯(cuò)誤保護(hù)。屏蔽用戶錯(cuò)誤考察對(duì)用戶常見的誤操作的提示和屏蔽情況，例如可否有效避免日期的錄入錯(cuò)誤或?qū)懭霟o效的日期。出錯(cuò)提示考察出錯(cuò)提示是否正確。當(dāng)用戶操作錯(cuò)誤或軟件發(fā)生錯(cuò)誤時(shí)，能否有準(zhǔn)確清晰的提示，使用戶知道造成錯(cuò)誤的原因。例如當(dāng)用戶未輸入完有效信息時(shí)存盤，系統(tǒng)應(yīng)當(dāng)給出關(guān)于未輸入項(xiàng)的提示。重要數(shù)據(jù)刪除提示考察是否有警告及確認(rèn)提示。輸入數(shù)據(jù)檢查當(dāng)用戶輸入的數(shù)據(jù)有

13、錯(cuò)時(shí)，考察軟件是否能判斷數(shù)據(jù)的有效性，避免無效數(shù)據(jù)的生成，或避免不合要求的數(shù)據(jù)進(jìn)入數(shù)據(jù)庫。輸入非法值考察系統(tǒng)是否能識(shí)別輸入非法值，并有相應(yīng)的錯(cuò)誤提示。4.2.3 回歸測試回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。軟件產(chǎn)生新版本，都需要進(jìn)行回歸測試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯(cuò)誤是否在新軟件版本上再次出現(xiàn)。測試目標(biāo)驗(yàn)證之前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。方法重復(fù)上輪測試發(fā)現(xiàn)缺陷時(shí)使用的測試方法；此外還需要測試因修改本缺陷可能受影響的所有功能。完成標(biāo)準(zhǔn)上輪測試出現(xiàn)BUG的功能點(diǎn)已經(jīng)修復(fù)，缺陷沒有重現(xiàn)。4. 缺陷管理流程5.1 缺陷過程描述1） 測試人員在規(guī)定日期內(nèi)提交Bug入

14、庫，狀態(tài)置為：New2） 開發(fā)組進(jìn)行判定Bug是否成立，判定Y/N（Yes or No）3） 當(dāng)開發(fā)組判定為N時(shí)，狀態(tài)置為：Rejected4） 當(dāng)開發(fā)組判定為Y時(shí)，狀態(tài)置為：Opened5） 開發(fā)工程師在規(guī)定周期內(nèi)解決問題，在測試環(huán)境中驗(yàn)證無誤后，狀態(tài)置為：Fixed6） 測試人員在Fixed版本上驗(yàn)證，驗(yàn)證BUG是否已經(jīng)修復(fù)，判定Y/N7） 驗(yàn)證BUG還沒被修復(fù)，在規(guī)定周期內(nèi)執(zhí)行Reopen操作，狀態(tài)重置為：Opened8） 驗(yàn)證BUG已經(jīng)成功被修復(fù)，在規(guī)定周期內(nèi)關(guān)閉，狀態(tài)置為：Closed5.2 缺陷等級(jí)定義等級(jí)說明描述1) Urgent嚴(yán)重錯(cuò)誤l 由于程序所引起的操作系統(tǒng)崩潰，造成數(shù)據(jù)

15、庫死鎖、數(shù)據(jù)丟失、資料破壞、內(nèi)存泄漏等；2) Very High較嚴(yán)重錯(cuò)誤l 出現(xiàn)錯(cuò)誤后，所有測試工作無法繼續(xù)執(zhí)行。3) High一般性錯(cuò)誤l 菜單或按鈕沒有實(shí)現(xiàn)其本來的作用，不能進(jìn)入所鏈接的頁面，影響其它功能的實(shí)現(xiàn)。如添加，修改按鈕不起作用。l 影響下一個(gè)流程的操作。如不能保存數(shù)據(jù)。l 按鈕實(shí)現(xiàn)了不屬于自已本身的功能。如確定按鈕實(shí)現(xiàn)了保存功能。l 遺漏了功能。l 主要功能未實(shí)現(xiàn)或與產(chǎn)品需求規(guī)格書不符。l 對(duì)數(shù)據(jù)約束的功能沒有實(shí)現(xiàn)或?qū)崿F(xiàn)不一致。l JavaScript錯(cuò)誤。4) Medium較小錯(cuò)誤l 系統(tǒng)滿足主要頁面要求，對(duì)功能有較小影響；l 輔助說明描述不清楚；l 顯示格式不規(guī)范；l 長時(shí)間操作未給用戶進(jìn)度提示；l 提示窗口文字未采用行業(yè)術(shù)語；l 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志；l