第1章軟件測(cè)試基礎(chǔ)PPT課件

1、 第第1章章 軟件測(cè)試基礎(chǔ)軟件測(cè)試基礎(chǔ) 軟件測(cè)試模型 軟件測(cè)試原則 軟件測(cè)試基本流程 軟件概述 軟件缺陷管理 軟件測(cè)試概述 本章學(xué)習(xí)目標(biāo) 軟件 1.1.1 軟件生命周期軟件生命周期可分為6個(gè)階段：?jiǎn)栴}問題定義定義需求需求分析分析軟件軟件設(shè)計(jì)設(shè)計(jì)軟件軟件開發(fā)開發(fā)軟件軟件測(cè)試測(cè)試軟件軟件維護(hù)維護(hù)淘汰淘汰 1.1.2 軟件開發(fā)模型1、瀑布模型計(jì)劃計(jì)劃需求分析需求分析軟件設(shè)計(jì)軟件設(shè)計(jì)編碼編碼測(cè)試測(cè)試運(yùn)行維護(hù)運(yùn)行維護(hù)軟件設(shè)計(jì)階段軟件設(shè)計(jì)階段軟件開發(fā)階段軟件開發(fā)階段軟件維護(hù)階段軟件維護(hù)階段 1.1.2 軟件開發(fā)模型1、瀑布模型優(yōu)點(diǎn)：檢查點(diǎn)清晰，分工明確，有利于大型軟件軟件開發(fā)人員的組織管理及工具的使用與研

2、究，可以提高開發(fā)的效率。缺點(diǎn)：嚴(yán)格按照線性執(zhí)行，增加了開發(fā)風(fēng)險(xiǎn)；要求必須有產(chǎn)出結(jié)果，增加了開發(fā)工作量。對(duì)于現(xiàn)代軟件，各階段之間的關(guān)系很少是線性，瀑布模型已經(jīng)不適合現(xiàn)代軟件開發(fā)。 1.1.2 軟件開發(fā)模型2、快速原型模型需求分析需求分析構(gòu)建原型構(gòu)建原型原型評(píng)價(jià)原型評(píng)價(jià)確定最終確定最終需求需求軟件開發(fā)軟件開發(fā)細(xì)化需求細(xì)化需求 1.1.2 軟件開發(fā)模型2、快速原型模型優(yōu)點(diǎn)：克服了需求不明確帶來的風(fēng)險(xiǎn)，適用于不能預(yù)先確定需求的軟件項(xiàng)目。缺點(diǎn)：原型設(shè)計(jì)較難；不利于開發(fā)人員對(duì)產(chǎn)品的擴(kuò)展。 1.1.2 軟件開發(fā)模型3、迭代模型需求分析需求分析軟件設(shè)計(jì)軟件設(shè)計(jì)編碼編碼測(cè)試測(cè)試迭代1組件1需求分析需求分析軟件設(shè)

3、計(jì)軟件設(shè)計(jì)編碼編碼測(cè)試測(cè)試迭代2組件2 需求分析需求分析軟件設(shè)計(jì)軟件設(shè)計(jì)編碼編碼測(cè)試測(cè)試迭代n組件n 1.1.2 軟件開發(fā)模型3、迭代模型優(yōu)點(diǎn)：適應(yīng)客戶需求變更；降低了開發(fā)成本和風(fēng)險(xiǎn)。缺點(diǎn)：增加了集成失敗風(fēng)險(xiǎn)；容易退化為“邊做邊改”模式，失去對(duì)整個(gè)項(xiàng)目的控制。 1.1.2 軟件開發(fā)模型4、螺旋模型 1.1.2 軟件開發(fā)模型4、螺旋模型螺旋模型包含四個(gè)象限： 制定計(jì)劃：確定軟件目標(biāo)，制定實(shí)施方案，列出項(xiàng)目開發(fā)的限制條件。 風(fēng)險(xiǎn)分析：評(píng)價(jià)所制定的實(shí)施方案，識(shí)別風(fēng)險(xiǎn)并消除風(fēng)險(xiǎn)。 實(shí)施工程：開發(fā)產(chǎn)品并進(jìn)行驗(yàn)證。 客戶評(píng)估：客戶對(duì)產(chǎn)品進(jìn)行審核評(píng)估，提出修正建議，制定下一步計(jì)劃。 1.1.2 軟件開發(fā)模型

4、4、螺旋模型優(yōu)點(diǎn)：強(qiáng)調(diào)了風(fēng)險(xiǎn)分析，有助于將軟件質(zhì)量融入開發(fā)中；小分段構(gòu)建大型軟件，易于計(jì)算成本；客戶參與，保證項(xiàng)目可控性。缺點(diǎn)：構(gòu)建過程太過繁瑣，不適合小型項(xiàng)目。 1.1.2 軟件開發(fā)模型5、敏捷模型敏捷模型以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)。 1.1.2 軟件開發(fā)模型5、敏捷模型敏捷模型的特點(diǎn)如下： 項(xiàng)目被拆分成多個(gè)子項(xiàng)目，迭代完成，每個(gè)迭代都要經(jīng)過測(cè)試。 快速響應(yīng)需求變更，在修改過程中，軟件一直處于可用狀態(tài)。 不斷對(duì)產(chǎn)品進(jìn)行細(xì)微、漸進(jìn)式地改進(jìn)，每次改進(jìn)一小部分，如果可行再逐步擴(kuò)大改進(jìn)范圍。 開發(fā)未動(dòng)，測(cè)試先行。 注重“人”的作用。 1.1.2 軟件開發(fā)模型5、敏捷

5、模型優(yōu)點(diǎn)：及時(shí)響應(yīng)客戶需求變更，不斷適應(yīng)新的趨勢(shì)。缺點(diǎn)：管理相對(duì)混亂，不適合大型項(xiàng)目。 多學(xué)一招：多學(xué)一招：敏捷模型開發(fā)方式敏捷模型開發(fā)方式1、ScrumScrum Master（產(chǎn)品負(fù)責(zé)人）全面負(fù)責(zé)產(chǎn)品的開發(fā)過程。Scrum Master把團(tuán)隊(duì)劃分成不同的小組，把整個(gè)項(xiàng)目劃分成細(xì)小的可交付成果的子項(xiàng)目，分別由不同的小組完成，并對(duì)各小組的工作劃分優(yōu)先級(jí)，估算每個(gè)小組的工作量。 多學(xué)一招：多學(xué)一招：敏捷模型開發(fā)方式敏捷模型開發(fā)方式2、Kanban利用可視化軟件將開發(fā)的軟件項(xiàng)目細(xì)分成小任務(wù)，并分配給團(tuán)隊(duì)成員，每個(gè)成員都可以在“看板”上了解自己的工作任務(wù)及整個(gè)團(tuán)隊(duì)的工作進(jìn)度。項(xiàng)目開始之后，從目前執(zhí)行

6、的任務(wù)和過程開始，團(tuán)隊(duì)會(huì)針對(duì)每個(gè)成員的工作作出持續(xù)性、增量、漸進(jìn)式的改變。 1.1.3 軟件質(zhì)量概述軟件質(zhì)量是指軟件產(chǎn)品滿足基本需求及隱式需求的程度。軟件產(chǎn)品滿足基本需求是指其能滿足軟件開發(fā)時(shí)所規(guī)定需求的特性，其次是軟件產(chǎn)品滿足隱式需求的程度。 1.1.3 軟件質(zhì)量概述從軟件質(zhì)量的定義，可將軟件質(zhì)量分為三個(gè)層次： 滿足需求規(guī)定：軟件產(chǎn)品符合開發(fā)者明確定義的目標(biāo)，并且能可靠運(yùn)行。 滿足用戶需求：軟件產(chǎn)品的需求是由用戶產(chǎn)生的，軟件最終的目的就是滿足用戶需求，解決用戶的實(shí)際問題。 滿足用戶隱式需求：軟件如果滿足用戶隱式需求，即潛在的可能需要在將來開發(fā)的功能。將會(huì)極大的提升用戶滿意度，這就意味著軟件質(zhì)

7、量更高。 1.1.3 軟件質(zhì)量概述軟件質(zhì)量模型 多學(xué)一招：多學(xué)一招：紙杯測(cè)試紙杯測(cè)試 測(cè)試項(xiàng)目：紙杯。 需求測(cè)試：查看紙杯說明書是否完整。 界面測(cè)試：觀察紙杯外觀，表面是否光滑、手感是否舒適。 功能測(cè)試：用紙杯裝水，觀察是否漏水。 安全測(cè)試：紙杯是否有毒或細(xì)菌。 多學(xué)一招：多學(xué)一招：紙杯測(cè)試紙杯測(cè)試 易用性測(cè)試：用紙杯盛放開水是否燙手、紙杯是否易滑、是否方便飲用。 兼容性測(cè)試：用紙杯分別盛放水、酒精、飲料、汽油等，觀察是否有滲漏現(xiàn)象。 可靠性測(cè)試：從不同高度摔下來，觀察紙杯的損壞程度。 可移植性測(cè)試：將紙杯放在溫度、濕度等不同的環(huán)境中，查看紙杯是否還能正常使用。 多學(xué)一招：多學(xué)一招：紙杯測(cè)試紙

8、杯測(cè)試 可維護(hù)性：將紙杯揉捏變形，看其是否能恢復(fù)。 壓力測(cè)試：用一根針扎在紙杯上不斷增加力量，記錄多大壓強(qiáng)時(shí)能穿透紙杯。 疲勞測(cè)試：用紙杯分別盛放水、汽油放置24小時(shí)，觀察其滲漏情況（時(shí)間和程度）。 跌落測(cè)試：紙杯（加包裝）從高處落下，查看達(dá)到破損的高度。 多學(xué)一招：多學(xué)一招：紙杯測(cè)試紙杯測(cè)試 震動(dòng)測(cè)試：紙杯（加包裝）六面震動(dòng)，評(píng)估它是否能應(yīng)對(duì)惡劣的公路/鐵路/航空運(yùn)輸?shù)取?測(cè)試數(shù)據(jù)：編寫具體測(cè)試數(shù)據(jù)（略），其中可能會(huì)用到場(chǎng)景法、等價(jià)類劃分法、邊界值分析法等測(cè)試方法。 期望輸出：期望輸出需要查閱國(guó)際標(biāo)準(zhǔn)及用戶的使用需求。 多學(xué)一招：多學(xué)一招：紙杯測(cè)試紙杯測(cè)試 用戶文檔：使用手冊(cè)是否對(duì)紙杯的用法

9、、使用條件、限制條件等有詳細(xì)描述。 說明書測(cè)試：查看紙杯說明書的正確性、準(zhǔn)確性及完整性。 1.1.3 軟件質(zhì)量概述影響軟件質(zhì)量的因素： 需求模糊 軟件開發(fā)缺乏規(guī)范性文件指導(dǎo) 軟件開發(fā)人員問題 缺乏軟件質(zhì)量控制管理 1.2.1 軟件缺陷產(chǎn)生的原因 1.2.2 軟件缺陷的分類劃分標(biāo)準(zhǔn)劃分標(biāo)準(zhǔn)缺陷類型缺陷類型測(cè)試種類測(cè)試種類界面類功能類性能類安全性類兼容性類嚴(yán)重程度嚴(yán)重程度嚴(yán)重一般次要建議優(yōu)先級(jí)優(yōu)先級(jí)立即解決高優(yōu)先級(jí)正常排隊(duì)低優(yōu)先級(jí)發(fā)生階段發(fā)生階段需求階段構(gòu)架階段設(shè)計(jì)階段編碼階段測(cè)試階段 1.2.3 軟件缺陷的處理流程每個(gè)公司的軟件缺陷處理流程不盡相同，但是它們遵循的最基本流程是一樣的，都要經(jīng)過提交

10、、分配、確認(rèn)、處理、復(fù)測(cè)、關(guān)閉等環(huán)節(jié)。 1.2.3 軟件缺陷的處理流程 提交：測(cè)試人員發(fā)現(xiàn)缺陷之后，將缺陷提交給測(cè)試組長(zhǎng)。 分配：測(cè)試組長(zhǎng)接收到測(cè)試組員提交的缺陷之后，將其移交給開發(fā)人員。 確認(rèn)：開發(fā)人員接收到移交的缺陷之后，會(huì)與團(tuán)隊(duì)甚至測(cè)試人員一起商議，確定該缺陷是否是一個(gè)缺陷。 拒絕：如果經(jīng)過商議之后，缺陷不是一個(gè)真正的缺陷則拒絕處理，關(guān)閉缺陷。如果經(jīng)過商議之后，確定其是一個(gè)真正的缺陷，則可以根據(jù)缺陷的嚴(yán)重程度或優(yōu)先級(jí)等立即處理或延期處理。 1.2.3 軟件缺陷的處理流程 復(fù)測(cè)：開發(fā)人員修改好缺陷之后，測(cè)試人員重新進(jìn)行測(cè)試（復(fù)測(cè)），檢測(cè)缺陷是否確實(shí)已經(jīng)修改。如果未被正確修改，則重新提交缺陷

11、。 關(guān)閉：測(cè)試人員重新測(cè)試之后，如果缺陷已經(jīng)被正確修改，則將缺陷關(guān)閉，整個(gè)缺陷處理完成。 多學(xué)一招：多學(xué)一招：缺陷報(bào)告缺陷報(bào)告測(cè)試人員在提交軟件測(cè)試時(shí)都會(huì)按照公司規(guī)定的模板（Word、Excel、缺陷管理軟件等）將缺陷的詳細(xì)情況記錄下來生成缺陷報(bào)告，每個(gè)公司的缺陷報(bào)告模板并不相同，但一般都會(huì)包括缺陷的編號(hào)、類型、嚴(yán)重程度、優(yōu)先級(jí)、測(cè)試環(huán)境等，有時(shí)還會(huì)有測(cè)試人員的建議。 注 意多學(xué)一招：多學(xué)一招：缺陷報(bào)告缺陷報(bào)告編寫缺陷報(bào)告要注意以下事項(xiàng)： 每個(gè)缺陷都有一個(gè)唯一的編號(hào)。 缺陷要有重現(xiàn)步驟。 一個(gè)缺陷生成一份報(bào)告。 缺陷報(bào)告要整潔、完整。 1.2.4 常見的軟件缺陷管理工具1、BugzillaBu

12、gzilla是Mozilla公司提供的一款免費(fèi)的軟件缺陷管理工具。Bugzilla能夠建立一個(gè)完整的缺陷跟蹤體系，包括缺陷跟蹤、記錄、缺陷報(bào)告、處理解決情況等。使用Bugzilla管理軟件缺陷時(shí)，測(cè)試人員可以在Bugzilla上提交缺陷報(bào)告，Bugzilla會(huì)將缺陷轉(zhuǎn)給相應(yīng)的開發(fā)者，開發(fā)者可以使用Bugzilla做一個(gè)工作表，標(biāo)明要做的事情的優(yōu)先級(jí)、時(shí)間安排和跟蹤記錄。 1.2.4 常見的軟件缺陷管理工具2、禪道禪道是一款優(yōu)秀的國(guó)產(chǎn)項(xiàng)目管理軟件，它集產(chǎn)品管理、項(xiàng)目管理、質(zhì)量管理、缺陷管理、文檔管理、組織管理和事務(wù)管理于一體，是一款功能完備的項(xiàng)目管理軟件，完美地覆蓋了項(xiàng)目管理的核心流程。禪道分為

13、專業(yè)和開源兩個(gè)版本，專業(yè)版是收費(fèi)軟件，開源版是免費(fèi)軟件，對(duì)于日常的項(xiàng)目管理，開源版本已經(jīng)足夠使用。 1.2.4 常見的軟件缺陷管理工具3、JIRAJIRA是Atlassian公司開發(fā)的項(xiàng)目與實(shí)務(wù)跟蹤工具，被廣泛用于缺陷跟蹤、客戶實(shí)務(wù)、需求收集、流程審批、任務(wù)跟蹤、項(xiàng)目跟蹤和敏捷管理等工作領(lǐng)域。JIRA配置靈活、功能全面、部署簡(jiǎn)單、擴(kuò)展豐富、易用性好，是目前比較流行的基于Java架構(gòu)的管理工具。 JIRA軟件有兩個(gè)認(rèn)可度很高的特色：第一個(gè)是Atlassian公司對(duì)該開源項(xiàng)目實(shí)行免費(fèi)提供缺陷跟蹤服務(wù)；第二個(gè)是用戶在購(gòu)買JIRA軟件同時(shí)將源代碼也購(gòu)置進(jìn)來，方便做二次開發(fā)。 1.3.1 軟件測(cè)試簡(jiǎn)介軟

14、件測(cè)試的發(fā)展也經(jīng)歷了一個(gè)漫長(zhǎng)的過程，其發(fā)展過程可用下圖表示： 1.3.2 軟件測(cè)試的目的 對(duì)于軟件開發(fā)來說，軟件測(cè)試通過找到的問題缺陷幫助開發(fā)人員找到開發(fā)過程中存在的問題，包括軟件開發(fā)的模式、工具、技術(shù)等方面存在的問題與不足，預(yù)防下次缺陷的產(chǎn)生。 對(duì)于軟件測(cè)試來說，使用最少的人力、物力、時(shí)間等找到軟件中隱藏的缺陷，保證軟件的質(zhì)量，也為以后軟件測(cè)試積累豐富的經(jīng)驗(yàn)。 對(duì)于客戶需求來說，軟件測(cè)試能夠檢驗(yàn)軟件是否符合客戶需求，對(duì)軟件質(zhì)量進(jìn)行評(píng)估和度量，為客戶評(píng)審軟件提供有力的依據(jù)。 1.3.3 軟件測(cè)試的分類1、按照測(cè)試階段分類 單元測(cè)試：驗(yàn)證軟件單元是否符合軟件需求與設(shè)計(jì)，開發(fā)人員自測(cè)。 冒煙測(cè)試：

15、軟件構(gòu)建版本建立后，對(duì)系統(tǒng)的基本功能進(jìn)行簡(jiǎn)單的測(cè)試，這種測(cè)試重點(diǎn)驗(yàn)證的是程序的主要功能，而不會(huì)對(duì)具體功能進(jìn)行深入測(cè)試。 集成測(cè)試：冒煙測(cè)試之后，將已經(jīng)測(cè)試過的軟件單元組合在一起測(cè)試它們之間的接口，用于驗(yàn)證軟件是否滿足設(shè)計(jì)需求。 1.3.3 軟件測(cè)試的分類1、按照測(cè)試階段分類 系統(tǒng)測(cè)試：將經(jīng)過測(cè)試的軟件在實(shí)際環(huán)境中運(yùn)行，并與其他系統(tǒng)的成分（如數(shù)據(jù)庫(kù)、硬件和操作人員等）組合在一起進(jìn)行測(cè)試。 驗(yàn)收測(cè)試：主要是對(duì)軟件產(chǎn)品說明進(jìn)行驗(yàn)證，逐行逐字的按照說明書的描述對(duì)軟件產(chǎn)品進(jìn)行測(cè)試，確保其符合客戶的各項(xiàng)要求。 1.3.3 軟件測(cè)試的分類2、按照測(cè)試技術(shù)分類 黑盒測(cè)試：把軟件（程序）當(dāng)作一個(gè)有輸入與輸出的黑

16、匣子，它把程序當(dāng)作一個(gè)輸入域到輸出域的映射，只要輸入的數(shù)據(jù)能輸出預(yù)期的結(jié)果即可，不必關(guān)心程序內(nèi)部是怎么樣實(shí)現(xiàn)的。 1.3.3 軟件測(cè)試的分類2、按照測(cè)試技術(shù)分類白盒測(cè)試：測(cè)試人員了解軟件程序的邏輯結(jié)構(gòu)、路徑與運(yùn)行過程，在測(cè)試時(shí)，按照程序的執(zhí)行路徑得出結(jié)果。白盒測(cè)試就是把軟件（程序）當(dāng)作一個(gè)透明的盒子，測(cè)試人員清楚的知道從輸入到輸出的每一步過程。 1.3.3 軟件測(cè)試的分類2、按照測(cè)試技術(shù)分類總結(jié)：相對(duì)于黑盒測(cè)試來說，白盒測(cè)試對(duì)測(cè)試人員的要求會(huì)更高一點(diǎn)，它要求測(cè)試人員具有一定的編程能力，而且要熟悉各種腳本語言。但是在軟件公司里，黑盒測(cè)試與白盒測(cè)試并不是界限分明的，在測(cè)試一款軟件時(shí)往往是黑盒測(cè)試與

17、白盒測(cè)試相結(jié)合對(duì)軟件進(jìn)行完整全面的測(cè)試。 1.3.3 軟件測(cè)試的分類3、按照軟件質(zhì)量特性分類 功能測(cè)試：測(cè)試軟件的功能是否滿足客戶的需求，包括準(zhǔn)確性、易用性、適合性、互操作性等。 性能測(cè)試：測(cè)試軟件的性能是否滿足客戶的需求，性能測(cè)試包括負(fù)載測(cè)試、壓力測(cè)試、兼容性測(cè)試、可移植性測(cè)試和健壯性測(cè)試等。 1.3.3 軟件測(cè)試的分類4、按照自動(dòng)化程度分類 手工測(cè)試：測(cè)試人員一條一條的執(zhí)行代碼完成測(cè)試工作。費(fèi)時(shí)費(fèi)力且很驗(yàn)證保證測(cè)試效果。 自動(dòng)化測(cè)試：借助腳本、自動(dòng)化測(cè)試工具等完成相應(yīng)的測(cè)試工作，它也需要人工的參與，但是它可以將要執(zhí)行的測(cè)試代碼或流程寫成腳本，執(zhí)行腳本完成整個(gè)測(cè)試工作。 1.3.3 軟件測(cè)試

18、的分類5、按照測(cè)試項(xiàng)目分類 界面類測(cè)試：驗(yàn)證軟件界面是否符合客戶需求。 安全性測(cè)試：試軟件在沒有授權(quán)的內(nèi)部或外部用戶的攻擊或惡意破壞時(shí)如何進(jìn)行處理，是否能保證軟件與數(shù)據(jù)的安全。 文檔測(cè)試：以需求分析、軟件設(shè)計(jì)、用戶手冊(cè)、安裝手冊(cè)為主，主要驗(yàn)證文檔說明與實(shí)際軟件之間是否存在差異。 1.3.3 軟件測(cè)試的分類6、其他分類 測(cè)試：軟件上線之前進(jìn)行的版本測(cè)試。由開發(fā)人員和測(cè)試人員或者用戶協(xié)助進(jìn)行測(cè)試。測(cè)試人員記錄使用過程中出現(xiàn)的錯(cuò)誤與問題，整個(gè)測(cè)試過程是可控的。 測(cè)試：軟件上線之后進(jìn)行的版本測(cè)試。由用戶在使用過程中發(fā)現(xiàn)錯(cuò)誤與問題并進(jìn)行記錄，然后反饋給開發(fā)人員進(jìn)行修復(fù)。 1.3.3 軟件測(cè)試的分類6、其

19、他分類 回歸測(cè)試：對(duì)修改后的程序重新進(jìn)行測(cè)試確認(rèn)原有的缺陷已經(jīng)消除并且沒有引入新的缺陷，這個(gè)重新測(cè)試的過程就叫作回歸測(cè)試。 隨機(jī)測(cè)試：沒有測(cè)試用例、檢查列表、腳本或指令的測(cè)試，它主要是根據(jù)測(cè)試人員的經(jīng)驗(yàn)對(duì)軟件進(jìn)行功能和性能抽查。 1.4.1 軟件測(cè)試與軟件開發(fā)的關(guān)系軟件測(cè)試在項(xiàng)目各個(gè)階段的作用如下： 項(xiàng)目規(guī)劃階段：負(fù)責(zé)從單元測(cè)試到系統(tǒng)測(cè)試的整個(gè)測(cè)試階段的監(jiān)控。 需求分析階段：確定測(cè)試需求分析，即確定在項(xiàng)目中需要測(cè)試什么，同時(shí)制定系統(tǒng)測(cè)試計(jì)劃。 概要設(shè)計(jì)與詳細(xì)設(shè)計(jì)階段：制定單元測(cè)試計(jì)劃和集成測(cè)試計(jì)劃。 編碼階段：開發(fā)相應(yīng)的測(cè)試代碼和測(cè)試腳本。 測(cè)試階段：實(shí)施測(cè)試并提交相應(yīng)的測(cè)試報(bào)告。 1.4.1

20、 軟件測(cè)試與軟件開發(fā)的關(guān)系軟件測(cè)試與軟件開發(fā)的關(guān)系如右圖。 1.4.2 常見的軟件測(cè)試模型1、V模型 1.4.2 常見的軟件測(cè)試模型1、V模型優(yōu)點(diǎn)：將復(fù)雜的測(cè)試工作分成了目標(biāo)明確的小階段完成，具有階段性、順序性和依賴性，它既包含了對(duì)于源代碼的底層測(cè)試也包含了對(duì)于軟件需求的高層測(cè)試。缺點(diǎn)：只能在編碼之后才能開始測(cè)試，早期的需求分析等前期工作沒有涵蓋其中，因此它不能發(fā)現(xiàn)需求分析等早期的錯(cuò)誤，這為后期的系統(tǒng)測(cè)試、驗(yàn)收測(cè)試埋下了隱患。 1.4.2 常見的軟件測(cè)試模型2、W模型 1.4.2 常見的軟件測(cè)試模型2、W模型優(yōu)點(diǎn)：測(cè)試范圍不僅包括程序，還包括需求分析、軟件設(shè)計(jì)等前期工作，這樣有利于盡早全面的發(fā)

21、現(xiàn)問題。缺點(diǎn)：它將軟件開發(fā)過程分成需求、設(shè)計(jì)、編碼、集成等一系列的串行活動(dòng)，無法支持迭代、自發(fā)性等需要變更調(diào)整的項(xiàng)目。 1.4.2 常見的軟件測(cè)試模型3、H模型H模型將測(cè)試活動(dòng)完全獨(dú)立了出來，形成一個(gè)完全獨(dú)立的流程，這個(gè)流程將測(cè)試準(zhǔn)備活動(dòng)和測(cè)試執(zhí)行活動(dòng)清晰的體現(xiàn)出來。測(cè)試流程和其他工作流程是并發(fā)執(zhí)行的，只要某一個(gè)工作流程的條件成熟就可以開始進(jìn)行測(cè)試。 1.4.2 常見的軟件測(cè)試模型4、X模型X模型的設(shè)計(jì)原理是將程序分成多個(gè)片段反復(fù)迭代測(cè)試，然后將多個(gè)片段集成再進(jìn)行迭代測(cè)試。 1.4.2 常見的軟件測(cè)試模型4、X模型優(yōu)點(diǎn)：對(duì)單獨(dú)程序片段進(jìn)行的相互分離的編碼和測(cè)試，保證了測(cè)試效果。增加了探索測(cè)試，

22、可以幫助測(cè)試人員發(fā)現(xiàn)計(jì)劃之外的軟件錯(cuò)誤。缺點(diǎn)：頻繁的集成會(huì)增加測(cè)試成本；探索測(cè)試對(duì)測(cè)試人員要求更高。 1.5 軟件測(cè)試原則 測(cè)試應(yīng)基于客戶需求。 測(cè)試要盡早進(jìn)行。 窮盡測(cè)試是不可能的。 遵循GoodEnough原則。 測(cè)試缺陷要符合“二八”定理。 避免缺陷免疫。 測(cè)試應(yīng)基于客戶需求所有的測(cè)試工作都應(yīng)該建立在滿足客戶需求的基礎(chǔ)上，從客戶角度來看，最嚴(yán)重的錯(cuò)誤就是軟件無法滿足要求。有時(shí)候，軟件產(chǎn)品的測(cè)試結(jié)果非常完美，但卻不是客戶最終想要的產(chǎn)品，那么軟件產(chǎn)品的開發(fā)就是失敗的，而測(cè)試工作也是沒有任何意義的。因此測(cè)試應(yīng)依照客戶的需求配置環(huán)境并且按照客戶的使用習(xí)慣進(jìn)行測(cè)試并評(píng)價(jià)結(jié)果。1.5 軟件測(cè)試原則

23、測(cè)試要盡早進(jìn)行軟件的錯(cuò)誤存在于軟件生命周期的各個(gè)階段，因此應(yīng)該盡早開展測(cè)試工作，把軟件測(cè)試貫穿到軟件生命周期的各個(gè)階段中，這樣測(cè)試人員能夠盡早地發(fā)現(xiàn)和預(yù)防錯(cuò)誤，降低錯(cuò)誤修復(fù)的成本。盡早的開展測(cè)試工作有利于幫助測(cè)試人員了解軟件產(chǎn)品的需求和設(shè)計(jì)，從而預(yù)測(cè)測(cè)試的難度和風(fēng)險(xiǎn)，制定出完善的計(jì)劃和方案，提高測(cè)試的效率。1.5 軟件測(cè)試原則 窮盡測(cè)試是不可能的由于時(shí)間和資源的限制，進(jìn)行完全（各種輸入和輸出的全部組合）的測(cè)試是不可能的，測(cè)試人員可以根據(jù)測(cè)試的風(fēng)險(xiǎn)和優(yōu)先級(jí)等確定測(cè)試的關(guān)注點(diǎn)，從而控制測(cè)試的工作量，在測(cè)試成本、風(fēng)險(xiǎn)和收益之間求得平衡。1.5 軟件測(cè)試原則 遵循GoodEnough原則GoodEno

24、ugh原則是指測(cè)試的投入與產(chǎn)出要適當(dāng)權(quán)衡，形成充分的質(zhì)量評(píng)估過程，這個(gè)過程建立在測(cè)試花費(fèi)的代價(jià)之上。測(cè)試不充分無法保證軟件產(chǎn)品的質(zhì)量，但測(cè)試投入過多會(huì)造成資源的浪費(fèi)。隨著測(cè)試資源投入的增加，測(cè)試的產(chǎn)出也是增加的，但當(dāng)投入達(dá)到一定的比例后，測(cè)試的效果就不會(huì)明顯增強(qiáng)了。因此在測(cè)試時(shí)要根據(jù)實(shí)際要求和產(chǎn)品質(zhì)量考慮測(cè)試的投入，最好使測(cè)試投入與產(chǎn)出達(dá)到一個(gè)GoodEnough狀態(tài)。1.5 軟件測(cè)試原則 測(cè)試缺陷要符合“二八”定理一般情況下，軟件80%的缺陷會(huì)集中在20%的模塊中，缺陷并不是平均分布的。因此在測(cè)試時(shí)，要抓住主要矛盾，如果發(fā)現(xiàn)某些模塊比其他模塊具有更多的缺陷，則要投入更多的人力、精力重點(diǎn)測(cè)試這

25、些模塊以提高測(cè)試效率。1.5 軟件測(cè)試原則 避免缺陷免疫測(cè)試用例被反復(fù)使用，發(fā)現(xiàn)缺陷的能力就會(huì)越來越差；測(cè)試人員對(duì)軟件越熟悉越會(huì)忽略一些看起來比較小的問題，發(fā)現(xiàn)缺陷的能力也越差，這種現(xiàn)象被稱為軟件測(cè)試的“殺蟲劑”現(xiàn)象。它主要是由于測(cè)試人員沒有及時(shí)更新測(cè)試用例或者是對(duì)測(cè)試用例和測(cè)試對(duì)象過于熟悉，形成了思維定勢(shì)。1.5 軟件測(cè)試原則 1.6.1 軟件測(cè)試流程不同類型的軟件產(chǎn)品測(cè)試的方式和重點(diǎn)不一樣，測(cè)試流程也會(huì)不一樣。同樣類型的軟件產(chǎn)品，不同的公司所制定的測(cè)試流程也會(huì)不一樣。雖然不同軟件的詳細(xì)測(cè)試步驟不同，但它們所遵循的最基本的測(cè)試流程是一樣的分析測(cè)試分析測(cè)試需求需求制定測(cè)試制定測(cè)試計(jì)劃計(jì)劃設(shè)計(jì)測(cè)

26、試設(shè)計(jì)測(cè)試用例用例執(zhí)行測(cè)試執(zhí)行測(cè)試編寫測(cè)試編寫測(cè)試報(bào)告報(bào)告 1.6.1 軟件測(cè)試流程（1）分析測(cè)試需求測(cè)試人員在制定測(cè)試計(jì)劃之前需要先對(duì)軟件需求進(jìn)行分析，以便對(duì)要開發(fā)的軟件產(chǎn)品有一個(gè)清晰的認(rèn)識(shí)，從而明確測(cè)試對(duì)象及測(cè)試工作的范圍和測(cè)試重點(diǎn)。在分析需求時(shí)還可以獲取一些測(cè)試數(shù)據(jù)，作為測(cè)試計(jì)劃的基本依據(jù)，為后續(xù)的測(cè)試打好基礎(chǔ)。此外，分析測(cè)試需求也是對(duì)軟件需求進(jìn)行測(cè)試，以發(fā)現(xiàn)軟件需求中不合理的地方。 1.6.1 軟件測(cè)試流程序號(hào)序號(hào)檢查項(xiàng)檢查項(xiàng)檢查結(jié)果檢查結(jié)果說明說明1 1是否覆蓋了客戶提出的所有需求項(xiàng)是【】否【】NA【】 2 2用詞是否清晰、語義是否存在歧義是【】否【】NA【】 3 3是否清楚地描述了

27、軟件需要做什么以及不做什么是【】否【】NA【】 4 4是否描述了軟件的目標(biāo)環(huán)境，包括軟硬件環(huán)境是【】否【】NA【】 5 5是否對(duì)需求項(xiàng)進(jìn)行了合理的編號(hào)是【】否【】NA【】 6 6需求項(xiàng)是否前后一致、彼此不沖突是【】否【】NA【】 7 7是否清楚地說明了軟件的每個(gè)輸入、輸出格式，以及輸入與輸出之間的對(duì)應(yīng)關(guān)系是【】否【】NA【】 8 8是否清晰地描述了軟件系統(tǒng)的性能要求是【】否【】NA【】 9 9需求的優(yōu)先級(jí)是否合理分配是【】否【】NA【】 1010是否描述了各種約束條件是【】否【】NA【】 1.6.1 軟件測(cè)試流程被確定的測(cè)試需求必須是可核實(shí)的，測(cè)試需求必須有一個(gè)可觀察、可評(píng)測(cè)的結(jié)果。無法核實(shí)的

28、需求就不是測(cè)試需求。測(cè)試需求分析還要與客戶進(jìn)行交流，以澄清某些混淆，確保測(cè)試人員與客戶盡早地對(duì)項(xiàng)目達(dá)成共識(shí)。注 意 1.6.1 軟件測(cè)試流程（2）制定測(cè)試計(jì)劃測(cè)試計(jì)劃一般要做好以下工作安排。 確定測(cè)試范圍：明確哪些對(duì)象是需要測(cè)試的，哪些對(duì)象不是需要測(cè)試的。 制定測(cè)試策略：測(cè)試策略是測(cè)試計(jì)劃中最重要的部分，它將要測(cè)試的內(nèi)容劃分出不同的優(yōu)先級(jí)，并確定測(cè)試重點(diǎn)。根據(jù)測(cè)試模塊的特點(diǎn)和測(cè)試類型（如功能測(cè)試、性能測(cè)試）選定測(cè)試環(huán)境和測(cè)試方法（如人工測(cè)試、自動(dòng)化測(cè)試）。 1.6.1 軟件測(cè)試流程 安排測(cè)試資源：通過對(duì)測(cè)試難度、時(shí)間、工作量等因素對(duì)測(cè)試資源合理安排，包括人員分配、工具配置等。 安排測(cè)試進(jìn)度：根

29、據(jù)軟件開發(fā)計(jì)劃、產(chǎn)品的整體計(jì)劃來安排測(cè)試工作的進(jìn)度，同時(shí)還要考慮各部分工作的變化。在安排工作進(jìn)度時(shí)，最好在各項(xiàng)測(cè)試工作之間預(yù)留一個(gè)緩沖時(shí)間以應(yīng)對(duì)計(jì)劃變更。 預(yù)估測(cè)試風(fēng)險(xiǎn)：羅列出測(cè)試工作過程中可能會(huì)出現(xiàn)的不確定因素，并制定應(yīng)對(duì)策略。 1.6.1 軟件測(cè)試流程（3）設(shè)計(jì)測(cè)試用例測(cè)試用例（Test Case）指的是一套詳細(xì)的測(cè)試方案，包括測(cè)試環(huán)境、測(cè)試步驟、測(cè)試數(shù)據(jù)和預(yù)期結(jié)果。不同的公司會(huì)有不同的測(cè)試用例模板，雖然它們?cè)陲L(fēng)格和樣式上有所不同，但本質(zhì)上是一樣的，都包括了測(cè)試用例的基本要素。測(cè)試用例編寫的原則是盡量以最少的測(cè)試用例達(dá)到最大測(cè)試覆蓋率。 1.6.1 軟件測(cè)試流程（4）執(zhí)行測(cè)試測(cè)試執(zhí)行就是按

30、照測(cè)試用例執(zhí)行測(cè)試的過程，這是測(cè)試人員最主要的活動(dòng)階段。在執(zhí)行測(cè)試時(shí)要根據(jù)測(cè)試用例的優(yōu)先級(jí)進(jìn)行。在執(zhí)行測(cè)試過程中，測(cè)試人員要密切跟蹤測(cè)試過程，記錄缺陷、形成報(bào)告等，這一階段是測(cè)試人員最重要的工作階段。 1.6.1 軟件測(cè)試流程（5）編寫測(cè)試報(bào)告一份完整的測(cè)試報(bào)告必須要包含以下幾個(gè)要點(diǎn)。 引言：測(cè)試報(bào)告編寫目的、報(bào)告中出現(xiàn)的專業(yè)術(shù)語解釋及參考資料等。 測(cè)試概要：介紹項(xiàng)目背景、測(cè)試時(shí)間、測(cè)試地點(diǎn)及測(cè)試人員等信息。 測(cè)試內(nèi)容及執(zhí)行情況：描述本次測(cè)試模塊的版本、測(cè)試類型，使用的測(cè)試用例設(shè)計(jì)方法及測(cè)試通過覆蓋率，依據(jù)測(cè)試的通過情況提供對(duì)測(cè)試執(zhí)行過程的評(píng)估結(jié)論，并給出測(cè)試執(zhí)行活動(dòng)的改進(jìn)建議，以供后續(xù)測(cè)試執(zhí)

31、行活動(dòng)借鑒參考。 1.6.1 軟件測(cè)試流程（5）編寫測(cè)試報(bào)告 缺陷統(tǒng)計(jì)與分析：統(tǒng)計(jì)本次測(cè)試所發(fā)現(xiàn)的缺陷數(shù)目、類型等，分析缺陷產(chǎn)生的原因給出規(guī)避措施等建議，同時(shí)還要記錄殘留缺陷與未解決問題。 測(cè)試結(jié)論與建議：從需求符合度、功能正確性、性能指標(biāo)等多個(gè)維度對(duì)版本質(zhì)量進(jìn)行總體評(píng)價(jià)，給出具體明確的結(jié)論。測(cè)試報(bào)告的數(shù)據(jù)是真實(shí)的，每一條結(jié)論的得出都要有評(píng)價(jià)依據(jù)，不能是主觀臆斷的。 多學(xué)一招：多學(xué)一招：測(cè)試的準(zhǔn)入準(zhǔn)出測(cè)試的準(zhǔn)入準(zhǔn)出測(cè)試準(zhǔn)入標(biāo)準(zhǔn)如下： 開發(fā)編碼結(jié)束，開發(fā)人員在開發(fā)環(huán)境已經(jīng)進(jìn)行了單元測(cè)試，即開發(fā)人員完成自測(cè)。 軟件需求上規(guī)定的功能都已經(jīng)實(shí)現(xiàn)。如果沒有完全實(shí)現(xiàn)，開發(fā)人員提供測(cè)試范圍。 測(cè)試項(xiàng)目通過基

32、本的冒煙測(cè)試，界面上的功能均已經(jīng)實(shí)現(xiàn)，符合設(shè)計(jì)規(guī)定的功能。 被測(cè)試項(xiàng)目的代碼符合軟件編碼規(guī)范并已通過評(píng)審。 開發(fā)人員提交了測(cè)試申請(qǐng)并提供了相應(yīng)的文檔資料。 多學(xué)一招：多學(xué)一招：測(cè)試的準(zhǔn)入準(zhǔn)出測(cè)試的準(zhǔn)入準(zhǔn)出 測(cè)試項(xiàng)目滿足客戶需求。 所有測(cè)試用例都已經(jīng)通過評(píng)審并成功執(zhí)行。 測(cè)試覆蓋率已經(jīng)達(dá)到要求。 所有發(fā)現(xiàn)的缺陷都記錄在缺陷管理系統(tǒng)。 一二級(jí)錯(cuò)誤修復(fù)率達(dá)到100%。 三四級(jí)錯(cuò)誤修復(fù)率達(dá)到了95%。 所有遺留問題都已經(jīng)有解決方案。 測(cè)試項(xiàng)目的功能、性能、安全性等都滿足要求。 完成系統(tǒng)測(cè)試總結(jié)報(bào)告。測(cè)試準(zhǔn)出標(biāo)準(zhǔn)如下： 多學(xué)一招：多學(xué)一招：測(cè)試的準(zhǔn)入準(zhǔn)出測(cè)試的準(zhǔn)入準(zhǔn)出測(cè)試中需要暫停的情況包括以下幾種。

33、測(cè)試人員進(jìn)行冒煙測(cè)試時(shí)發(fā)現(xiàn)重大缺陷，導(dǎo)致測(cè)試無法正常進(jìn)行，需要暫停并返回開發(fā)。 測(cè)試人員進(jìn)行冒煙測(cè)試時(shí)發(fā)現(xiàn)bug過多可以申請(qǐng)暫停測(cè)試，返回開發(fā)。 測(cè)試項(xiàng)目需要更新調(diào)整而暫停，測(cè)試工作也要相應(yīng)暫停。 如果測(cè)試人員有其他優(yōu)先級(jí)更高的任務(wù)時(shí)，可以申請(qǐng)暫停測(cè)試。 1.6.2 摩拜單車App開鎖用車功能測(cè)試流程摩拜單車業(yè)務(wù)流程圖： 1.6.2 摩拜單車App開鎖用車功能測(cè)試流程（1）分析測(cè)試需求摩拜單車的用車功能需要測(cè)試三個(gè)內(nèi)容： 掃描二維碼開鎖。 輸入車輛編號(hào)開鎖。 調(diào)取手機(jī)手電筒。 1.6.2 摩拜單車App開鎖用車功能測(cè)試流程（2）制定測(cè)試計(jì)劃軟件版本軟件版本摩拜單車摩拜單車App 8.10.0A

34、pp 8.10.0版本版本模塊模塊開鎖用車負(fù)責(zé)人負(fù)責(zé)人測(cè)試組長(zhǎng)測(cè)試人員測(cè)試人員測(cè)試員1、測(cè)試員2測(cè)試時(shí)間測(cè)試時(shí)間2019.3.12019.3.3測(cè)試用例測(cè)試用例001012回歸測(cè)試回歸測(cè)試2019.4.102019.4.13 1.6.2 摩拜單車App開鎖用車功能測(cè)試流程（2）設(shè)計(jì)測(cè)試用例 白天：掃碼開鎖。 白天：手動(dòng)輸入車輛編號(hào)開鎖。 晚上：掃碼+手電筒開鎖。 晚上：手動(dòng)輸入車輛編號(hào)開鎖。 1.6.2 摩拜單車App開鎖用車功能測(cè)試流程注 意開鎖用車模塊與其他模塊的關(guān)聯(lián)，在開鎖時(shí)，如果有正在運(yùn)行的訂單或者有未支付的訂單，則無法開鎖。 1.6.2 摩拜單車App開鎖用車功能測(cè)試流程序號(hào)序號(hào)用例

35、說明用例說明前置操作前置操作操作操作預(yù)期結(jié)果預(yù)期結(jié)果備注備注001001開鎖沒有正在運(yùn)行的訂單，也沒有未支付的訂單白天掃碼進(jìn)入數(shù)碼解鎖頁面 002002開鎖有正在運(yùn)行的訂單 白天掃碼無法開鎖，提示正在騎行，需結(jié)束騎行并支付才能解鎖 003003開鎖有未支付的訂單白天掃碼無法開鎖，提示支付未支付訂單才能解鎖 004004開鎖沒有正在運(yùn)行的訂單，也沒有未支付的訂單白天手動(dòng)輸入車輛編號(hào)進(jìn)入數(shù)碼解鎖頁面 1.6.2 摩拜單車App開鎖用車功能測(cè)試流程序號(hào)序號(hào) 用例說明用例說明前置操作前置操作操作操作預(yù)期結(jié)果預(yù)期結(jié)果備注備注005005開鎖有正在運(yùn)行的訂單白天手動(dòng)輸入車輛編號(hào)無法開鎖，提示正在騎行，需結(jié)束騎行并支付才能解鎖 006006開鎖有未支付的訂單白天手動(dòng)輸入車輛編號(hào)無法開鎖，提示支付未支付訂單才能解鎖