什么是軟件測(cè)試

在規(guī)定的條件下對(duì)程序進(jìn)行操作，以發(fā)現(xiàn)程序錯(cuò)誤，衡量軟件質(zhì)量，并對(duì)其是否能滿足設(shè)計(jì)要求進(jìn)行評(píng)估的過程。

軟件測(cè)試的目的

Grenford J.Myers提出的觀點(diǎn)

（1）軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。

（2）測(cè)試是為了證明程序有錯(cuò)，而不是證明程序無錯(cuò)。

（3）一個(gè)好的測(cè)試用例在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤。

（4）一個(gè)成功的測(cè)試在于它發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤。

測(cè)試的目的是以最少人力、物力和時(shí)間找出軟件中潛在各種錯(cuò)誤和缺陷，通過修正這種錯(cuò)誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯(cuò)誤造成的隱患和商業(yè)風(fēng)險(xiǎn)。當(dāng)然測(cè)試是不可能找出全部的錯(cuò)誤的。

軟件開發(fā)與軟件測(cè)試的關(guān)系

軟件開發(fā)經(jīng)過制定計(jì)劃、需求分析、設(shè)計(jì)階段后，才能進(jìn)入編碼階段。軟件故障可能出現(xiàn)在軟件開發(fā)的各個(gè)階段。因此，軟件測(cè)試應(yīng)貫穿于軟件定義與開發(fā)的整個(gè)期間。

測(cè)試在開發(fā)的各個(gè)階段如下：

（1）項(xiàng)目規(guī)劃階段：負(fù)責(zé)整個(gè)測(cè)試階段的監(jiān)控。

（2）需求分析階段：確定測(cè)試需求分析、制定系統(tǒng)測(cè)試計(jì)劃。測(cè)試需求分析是指分析產(chǎn)品生存周期中測(cè)試所需的資源、配置、各階段評(píng)審?fù)ㄟ^的標(biāo)準(zhǔn)等。

（3）概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)階段：制定集成測(cè)試計(jì)劃和單元測(cè)試計(jì)劃。

（4）程序編寫階段：開發(fā)相應(yīng)的測(cè)試代碼或測(cè)試腳本。

（5）測(cè)試階段：實(shí)施測(cè)試，并提交相應(yīng)的測(cè)試報(bào)告。

軟件測(cè)試的原則

（1）測(cè)試應(yīng)基于用戶需求

（2）做好軟件測(cè)試計(jì)劃是做好軟件測(cè)試工作的關(guān)鍵

（3）應(yīng)盡早的開始軟件測(cè)試并不斷的進(jìn)行軟件測(cè)試測(cè)試盡早介入

（4）測(cè)試前必須明確定義好產(chǎn)品的質(zhì)量標(biāo)準(zhǔn)

（5）避免測(cè)試自己的軟件

（6）應(yīng)充分注意測(cè)試中的集群現(xiàn)象

（7）必須檢查每個(gè)實(shí)際輸出結(jié)果

（8）窮舉測(cè)試是不可能的

（9）測(cè)試設(shè)計(jì)決定了測(cè)試的有效性和效率

（10）注意保留測(cè)試設(shè)計(jì)和說明文檔，并注意測(cè)試設(shè)計(jì)的可重用性

軟件測(cè)試需要考慮的測(cè)試方面

功能測(cè)試（滿足需求）

安裝/卸載/升級(jí)

異常處理（接聽電話、短信、斷電、切換網(wǎng)絡(luò)、前后臺(tái)切換等操作）

兼容性測(cè)試（不同機(jī)型、不同版本、不同尺寸、不同分辨率）

性能測(cè)試（安裝卸載響應(yīng)時(shí)間、打開app速度、各類功能性操作響應(yīng)時(shí)間、反復(fù)長(zhǎng)時(shí)操作）

安全測(cè)試（權(quán)限測(cè)試、安裝卸載安全性、數(shù)據(jù)安全性-密碼不會(huì)被存儲(chǔ)到設(shè)備中）

用戶體驗(yàn)測(cè)試

UI界面測(cè)試

典型的軟件開發(fā)模型

（1）邊做邊改模型（build-and-fix model）

（2）瀑布模型（waterfall model）

（3）快速原型模型（rapid prototype model）

（4）增量模型（incremental model）

（5）螺旋模型（spiral model）

（6）演化模型（evolutionary model）

（7）噴泉模型（fountain model）

（8）智能模型（Intelligent model）

（9）混合模型（hybrid model）

軟件測(cè)試模型

V模型：強(qiáng)調(diào)了整個(gè)軟件項(xiàng)目開發(fā)中需要經(jīng)歷的若干個(gè)測(cè)試級(jí)別，每個(gè)級(jí)別都與一個(gè)開發(fā)階段相對(duì)應(yīng)，但它沒有明確指出應(yīng)該對(duì)需求、設(shè)計(jì)進(jìn)行測(cè)試。

W模型：對(duì)V模型進(jìn)行了補(bǔ)充。強(qiáng)調(diào)了測(cè)試計(jì)劃等工作的先行和對(duì)系統(tǒng)需求和系統(tǒng)設(shè)計(jì)的測(cè)試，但和V模型一樣，沒有專門針對(duì)軟件測(cè)試的流程予以說明。

H模型：表現(xiàn)了測(cè)試是獨(dú)立的。就每一個(gè)軟件的的測(cè)試細(xì)節(jié)來說，都有一個(gè)獨(dú)立的操作流程，只要測(cè)試前提具備了，就可以開始進(jìn)行測(cè)試。

軟件測(cè)試的分類

（1）按測(cè)試階段劃分：?jiǎn)卧獪y(cè)試、集成測(cè)試、確認(rèn)測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試，在測(cè)試中如果有需要還會(huì)進(jìn)行回歸測(cè)試。

（2）按執(zhí)行主體劃分：Alpha測(cè)試（驗(yàn)收測(cè)試或開發(fā)方測(cè)試）、Beta測(cè)試（用戶測(cè)試）、第三方測(cè)試

（3）按執(zhí)行狀態(tài)劃分：靜態(tài)測(cè)試、動(dòng)態(tài)測(cè)試

（4）按測(cè)試技術(shù)劃分：黑盒測(cè)試、白盒測(cè)試、灰盒測(cè)試

（5）其他測(cè)試：回歸測(cè)試、隨機(jī)測(cè)試

單元測(cè)試的測(cè)試對(duì)象、測(cè)試目的、測(cè)試依據(jù)、測(cè)試方法

單元測(cè)試的測(cè)試對(duì)象是模塊內(nèi)部的程序錯(cuò)誤；測(cè)試目的是消除局部模塊邏輯和功能上的錯(cuò)誤和缺陷；測(cè)試依據(jù)是模塊的詳細(xì)設(shè)計(jì)；測(cè)試方法采用白盒測(cè)試。

集成測(cè)試的測(cè)試對(duì)象、測(cè)試目的、測(cè)試依據(jù)、測(cè)試方法

集成測(cè)試的測(cè)試對(duì)象是模塊間的組裝和調(diào)用關(guān)系；測(cè)試目的是找出與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)模塊調(diào)用關(guān)系，模塊間接口方面的問題；測(cè)試依據(jù)是概要設(shè)計(jì)；測(cè)試方法采用灰盒測(cè)試。

系統(tǒng)測(cè)試的測(cè)試對(duì)象、測(cè)試目的、測(cè)試依據(jù)、測(cè)試方法

系統(tǒng)測(cè)試的測(cè)試對(duì)象是整個(gè)系統(tǒng)；測(cè)試目的是對(duì)整個(gè)系統(tǒng)進(jìn)行測(cè)試；測(cè)試依據(jù)是需求規(guī)格說明書；測(cè)試方法采用的是黑盒測(cè)試。

單元測(cè)試----白盒測(cè)試、自動(dòng)化測(cè)試、靜態(tài)測(cè)試

1、單元測(cè)試概念？

單元測(cè)試是完成最小的軟件設(shè)計(jì)單元（模塊）的驗(yàn)證工作，目標(biāo)是確保模塊被正確的編碼，使用過程設(shè)計(jì)描述作為指南，對(duì)重要的控制路徑進(jìn)行測(cè)試以發(fā)現(xiàn)模塊內(nèi)的錯(cuò)誤，通常情況下是白盒的，對(duì)代碼風(fēng)格和規(guī)則、程序設(shè)計(jì)和結(jié)構(gòu)、業(yè)務(wù)邏輯等進(jìn)行靜態(tài)測(cè)試，及早的發(fā)現(xiàn)和解決不易顯現(xiàn)的錯(cuò)誤。

2、單元測(cè)試的內(nèi)容？

接口測(cè)試：保證進(jìn)出單元模塊的數(shù)據(jù)流是正確的

內(nèi)部數(shù)據(jù)結(jié)構(gòu)：保證臨時(shí)存儲(chǔ)的數(shù)據(jù)在算法執(zhí)行過程中的完整性

全局?jǐn)?shù)據(jù)結(jié)構(gòu)：全局?jǐn)?shù)據(jù)結(jié)構(gòu)對(duì)單元模塊的影響應(yīng)當(dāng)審查

邊界：才用邊界值分析技術(shù)，保證模塊在邊界條件和極限情況下正常執(zhí)行

語句覆蓋：保證每個(gè)語句執(zhí)行一次

錯(cuò)誤路徑：對(duì)所有處理錯(cuò)誤的路徑進(jìn)行測(cè)試

集成測(cè)試----白盒測(cè)試、黑盒測(cè)試、自動(dòng)化測(cè)試、靜態(tài)測(cè)試

1、集成測(cè)試概念？

通過測(cè)試發(fā)現(xiàn)與模塊接口有關(guān)的問題。目標(biāo)是把通過了單元測(cè)試的模塊拿來，構(gòu)造一個(gè)在設(shè)計(jì)中所描述的程序結(jié)構(gòu)，應(yīng)當(dāng)避免一次性的集成（除非軟件規(guī)模很?。?，而采用增量集成。

自頂向下集成：模塊集成的順序是首先集成主模塊，然后按照控制層次結(jié)構(gòu)向下進(jìn)行集成，隸屬于主模塊的模塊按照深度優(yōu)先或廣度優(yōu)先的方式集成到整個(gè)結(jié)構(gòu)中去。

自底向上集成：從原子模塊開始來進(jìn)行構(gòu)造和測(cè)試，因?yàn)槟K是自底向上集成的，進(jìn)行時(shí)要求所有隸屬于某個(gè)給頂層次的模塊總是存在的，也不再有使用穩(wěn)定測(cè)試樁的必要。

2、集成測(cè)試的過程？

a.明確測(cè)試的目標(biāo)和完成準(zhǔn)則，并確定關(guān)鍵部分

b.確定階段和進(jìn)度安排

c.測(cè)試和修正協(xié)調(diào)的計(jì)劃

d.清理系統(tǒng)結(jié)構(gòu)

e.確定集成測(cè)試方法的組合策略

f.描述集成順序

g.針對(duì)每次集成編制測(cè)試用例，從而形成測(cè)試方案

h.進(jìn)行附加軟件（測(cè)試樁）的開發(fā)

i.測(cè)試軟件和測(cè)試準(zhǔn)備準(zhǔn)備

j.依據(jù)測(cè)試方案進(jìn)行測(cè)試

k.根據(jù)測(cè)試結(jié)果提交測(cè)試報(bào)告

l.測(cè)試報(bào)告的分析

m.缺陷的管理

n.修正和測(cè)試工作

o.完成測(cè)試軟件提交

系統(tǒng)測(cè)試----黑盒測(cè)試、自動(dòng)化測(cè)試、手工測(cè)試

1、系統(tǒng)測(cè)試概念？

根據(jù)軟件需求規(guī)范的要求進(jìn)行系統(tǒng)測(cè)試，確認(rèn)系統(tǒng)滿足需求的要求，系統(tǒng)測(cè)試人員相當(dāng)于用戶代言人，在需求分析階段要確定軟件的可測(cè)性，保證有效完成系統(tǒng)測(cè)試工作

2、系統(tǒng)測(cè)試主要內(nèi)容？

a.所有功能需求得到滿足

b.所有性能需求得到滿足

c.其他需求（如安全性、容錯(cuò)性、兼容性等）得到滿足

回歸測(cè)試----黑盒測(cè)試、自動(dòng)化測(cè)試、手工測(cè)試

1、回歸測(cè)試概念？

當(dāng)發(fā)現(xiàn)并修改缺陷后，或在軟件中添加新的功能后，重新測(cè)試。用來檢查被發(fā)現(xiàn)的缺陷是否被改正，并且所做的修改沒有引發(fā)新的問題。回歸測(cè)試可以通過人工重新執(zhí)行測(cè)試用例，也可以使用自動(dòng)化的工具來進(jìn)行。

2、回歸測(cè)試方式？

a.覆蓋全部測(cè)試用例。選擇基線測(cè)試用例庫中的全部測(cè)試用例組成回歸測(cè)試包，測(cè)試成本最高

b.基于風(fēng)險(xiǎn)選擇測(cè)試?？梢曰谝欢ǖ娘L(fēng)險(xiǎn)標(biāo)準(zhǔn)來從基線測(cè)試用例庫中選擇回歸測(cè)試包，首先運(yùn)行最重要的、最關(guān)鍵的和最可疑的測(cè)試用例，測(cè)試從主要特征到次要特征

c.基于操作剖面選擇測(cè)試。測(cè)試所使用的測(cè)試用例個(gè)數(shù)可以由測(cè)試預(yù)算確定，回歸測(cè)試可以優(yōu)先選擇那些最重要或最頻繁使用的功能的測(cè)試用例

d.重新測(cè)試修改的部分。當(dāng)測(cè)試者對(duì)修改的局部化有足夠信心時(shí)，可以通過相依性分析識(shí)別軟件的修改情況并分析修改的影響，將回歸測(cè)試局限于被改變的模塊和他的接口上

用戶驗(yàn)收測(cè)試----黑盒測(cè)試、自動(dòng)化測(cè)試、手工測(cè)試

1、用戶驗(yàn)收測(cè)試內(nèi)容？

a.配置審查。確保已開發(fā)軟件的所有文件資料均已編寫齊全，并分類編目

b.Alpha測(cè)試。是由用戶在開發(fā)者的場(chǎng)所來進(jìn)行的，在一個(gè)受控的環(huán)境中進(jìn)行。

c.Beta測(cè)試。由軟件的最終用戶在一個(gè)或多個(gè)用戶場(chǎng)所來進(jìn)行的，開發(fā)者通常不在現(xiàn)場(chǎng)，用戶記錄測(cè)試中遇到的問題并報(bào)告給開發(fā)者，開發(fā)者對(duì)系統(tǒng)進(jìn)行最后的修改，并開始準(zhǔn)備發(fā)布最終的軟件

白盒測(cè)試常用的技術(shù)

（1）邏輯覆蓋法：語句覆蓋、判定覆蓋、條件覆蓋、判斷/條件覆蓋、條件組合覆蓋、路徑覆蓋

（2）程序插裝技術(shù)

（3）基本路徑法

（4）符號(hào)測(cè)試

黑盒測(cè)試的方法

（1）等價(jià)類劃分法

（2）邊界值分析法

（3）因果圖法

（4）決策表法

（5）錯(cuò)誤推測(cè)法

（6）場(chǎng)景法

非功能測(cè)試的測(cè)試方法：

（1）性能測(cè)試

（2）壓力測(cè)試

（3）容量測(cè)試

（4）健壯性測(cè)試

（5）安全性測(cè)試

（6）可靠性測(cè)試

（7）恢復(fù)性測(cè)試與備份測(cè)試

（8）協(xié)議一致性測(cè)試

（9）兼容性測(cè)試

（10）安裝測(cè)試

（11）可用性測(cè)試

（12）配置測(cè)試

（13）文檔測(cè)試

（14）GUI測(cè)試

性能測(cè)試分類：

1.負(fù)載測(cè)試

2.壓力測(cè)試

3.可靠性測(cè)試

4.數(shù)據(jù)庫測(cè)試

5.安全性測(cè)試

6.文檔測(cè)試

負(fù)載測(cè)試可以和壓力測(cè)試結(jié)合進(jìn)行

請(qǐng)?jiān)囍容^一下黑盒測(cè)試、白盒測(cè)試、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試的區(qū)別與聯(lián)系。

黑盒測(cè)試：把測(cè)試對(duì)象當(dāng)成一個(gè)黑盒子，測(cè)試人員完全不考慮邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程式的需求說明書來檢查程式的功能是否滿足它的功能說明。

白盒測(cè)試：把測(cè)試對(duì)象當(dāng)成一個(gè)透明的盒子，允許測(cè)試人員利用程序內(nèi)部邏輯結(jié)構(gòu)及相關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程式所有邏輯路徑進(jìn)行測(cè)試。

單元測(cè)試：白盒測(cè)試的一種，對(duì)軟件設(shè)計(jì)中的單元模塊進(jìn)行測(cè)試。

集成測(cè)試：在單元測(cè)試的基礎(chǔ)上，對(duì)單元模塊之間的連接和組裝進(jìn)行測(cè)試。

系統(tǒng)測(cè)試：在所有都考慮的情況下，對(duì)系統(tǒng)進(jìn)行測(cè)試。

驗(yàn)收測(cè)試：第三方進(jìn)行的確認(rèn)軟件滿足需求的測(cè)試。

軟件測(cè)試與軟件質(zhì)量的區(qū)別？

質(zhì)量保證（QA）：主要工作是通過預(yù)防，檢查與改進(jìn)來保證軟件質(zhì)量。它所關(guān)心的是軟件質(zhì)量的檢查與測(cè)量。著眼軟件開發(fā)活動(dòng)中的過程、步驟及產(chǎn)物，而不是對(duì)軟件進(jìn)行剖析進(jìn)而找出問題。

軟件測(cè)試：測(cè)試關(guān)心的不是過程的活動(dòng)，而是對(duì)過程的產(chǎn)物以及開發(fā)出的軟件進(jìn)行剖析。測(cè)試人員要“執(zhí)行”軟件，對(duì)過程中的產(chǎn)物—開發(fā)文檔和源代碼進(jìn)行走查、運(yùn)行，以找出問題，報(bào)告質(zhì)量。測(cè)試人員也必須假設(shè)軟件存在問題，所以所做的操作都是為了找出更多的問題，而不是僅僅驗(yàn)證每一件事兒是正確的。

軟件缺陷概述：

軟件缺陷，通常又被叫做Defect或者Bug，即為軟件或程序中存在的某種破壞正常運(yùn)行能力的問題、錯(cuò)誤，其存在會(huì)導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。

從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中存在的問題、錯(cuò)誤。

從產(chǎn)品外部看，缺項(xiàng)是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。

確定缺陷的幾個(gè)標(biāo)準(zhǔn)（P5）

（1）軟件未達(dá)到產(chǎn)品說明書中已經(jīng)標(biāo)明的功能，即沒有完全實(shí)現(xiàn)功能。

（2）軟件未達(dá)到產(chǎn)品說明書中雖未明顯指出但應(yīng)達(dá)到的目標(biāo)。

（3）軟件出現(xiàn)了產(chǎn)品說明書中指明不會(huì)出現(xiàn)的錯(cuò)誤，即基本實(shí)現(xiàn)用戶需求，但運(yùn)行時(shí)會(huì)出現(xiàn)一些功能和性能上的問題。

（4）軟件功能超出了軟件產(chǎn)品說明書中指明的范圍，即實(shí)現(xiàn)了多余的功能。

（5）軟件難以理解，不易使用，運(yùn)行緩慢或最后用戶會(huì)認(rèn)為不好。

缺陷的特點(diǎn)

（1）雪崩效應(yīng)

缺陷的雪崩效應(yīng)是指缺陷數(shù)目會(huì)隨著軟件開發(fā)過程的深入而不斷地增加，類似于滾雪球的效應(yīng)。

產(chǎn)生的原因：

a.開發(fā)過程中前一階段出現(xiàn)缺陷的地方，在后一階段同樣會(huì)出現(xiàn)，并且通常來說前一階段的缺陷數(shù)目比前一階段更多

b.即使前一階段是正確的軟件工作產(chǎn)品，由于人容易犯錯(cuò)誤，在后繼的階段也可能引入新的缺陷，從而導(dǎo)致缺陷數(shù)目的增加

（2）成本放大效應(yīng)

不同階段發(fā)現(xiàn)和修復(fù)缺陷的成本是不一樣的；到軟件開發(fā)生命周期的后期發(fā)現(xiàn)缺陷，其修復(fù)成本是急劇增加的，而不是線性增加。

測(cè)試人員應(yīng)盡早參與靜態(tài)測(cè)試，例如：盡早參與軟件文檔的評(píng)審，可以有效地發(fā)現(xiàn)其中的缺陷并盡早修復(fù)，因此可以有效地減緩缺陷的雪崩效應(yīng)，并降低修復(fù)缺陷的成本。

（3）集群效應(yīng)

測(cè)試過程中發(fā)現(xiàn)的缺陷分布在測(cè)試對(duì)象的不同功能模塊，同樣也滿足20/80原則：測(cè)試對(duì)象20%模塊中可以發(fā)現(xiàn)80%的缺陷，即缺陷的集群效應(yīng)。

測(cè)試人員根據(jù)該原則，可以在后繼的測(cè)試中重點(diǎn)關(guān)注該20%模塊。同時(shí)分析在該20%模塊中集中引入缺陷的原因，以發(fā)現(xiàn)開發(fā)和測(cè)試過程中存在的問題，從而幫助后續(xù)項(xiàng)目的過程改進(jìn)。

缺陷的狀態(tài)一般有如下幾種

（1）新建（打開）：當(dāng)QA人員匯報(bào)新的缺陷時(shí)。

（2）延后處理：如果這個(gè)缺陷和當(dāng)前發(fā)布的這個(gè)版本沒有直接關(guān)系，或當(dāng)前版本無法修復(fù)，或這個(gè)缺陷不是很嚴(yán)重，不需要立即修復(fù)，那么項(xiàng)目經(jīng)理可以把狀態(tài)設(shè)為“延后處理”。

（3）已指派：“指派給”這個(gè)值是由項(xiàng)目組長(zhǎng)或項(xiàng)目經(jīng)理來填，指定給具體的某個(gè)開發(fā)人員。

（4）已解決/已修復(fù)：當(dāng)開發(fā)人員做了某些必要的代碼改動(dòng)，并確認(rèn)修改后，他就可以把狀態(tài)改為“已修復(fù)”，然后交給測(cè)試組進(jìn)行回歸測(cè)試。

（5）無法重現(xiàn)：如果開發(fā)人員根據(jù)QA人員在缺陷報(bào)告里描述的步驟，都無法重現(xiàn)這個(gè)缺陷的時(shí)候，那么開發(fā)人員可以把這個(gè)缺陷標(biāo)為“無法重現(xiàn)”，QA人員需要檢查這個(gè)缺陷是否可以重現(xiàn)，并把更為詳細(xì)的重現(xiàn)步驟提供給開發(fā)人員。

（6）需要更多信息：如果開發(fā)人員認(rèn)為QA人員提供的缺陷重現(xiàn)步驟不夠清晰，因而無法重現(xiàn)缺陷的時(shí)候，那么他可以把這個(gè)狀態(tài)改為“需要更多信息”，在這種情況下，QA人員需要提供更為詳細(xì)的重現(xiàn)步驟，并把缺陷返回給開發(fā)小組。

（7）重新打開：如果QA人員不滿意這個(gè)修復(fù)結(jié)果，或者說即使在修復(fù)之后，依然出現(xiàn)同樣的問題，那么QA人員可以把這個(gè)狀態(tài)標(biāo)記為“重新打開”，這樣的話，開發(fā)人員就可以采取相應(yīng)的行動(dòng)了。

（8）關(guān)閉：如果QA小組已經(jīng)驗(yàn)證過這個(gè)缺陷的修復(fù)結(jié)果，并且這個(gè)問題已經(jīng)得到了解決，那么QA人員就可以把狀態(tài)改為“關(guān)閉”。

（9）駁回/無效：如果這個(gè)系統(tǒng)的確是按照規(guī)格說明運(yùn)行的，而缺陷的產(chǎn)生只是由誤解引起的，那么開發(fā)人員或者小組長(zhǎng)可以把這些缺陷標(biāo)記為“駁回”或者“無效”。

缺陷的嚴(yán)重程度

A類-嚴(yán)重錯(cuò)誤

1.由于程序引起的死機(jī)，非法退出。

2.死循環(huán)。

3.數(shù)據(jù)庫發(fā)生死鎖。

4.數(shù)據(jù)通信錯(cuò)誤。

5.嚴(yán)重的數(shù)值計(jì)算錯(cuò)誤。

6.與數(shù)據(jù)庫連接錯(cuò)誤。

7.因錯(cuò)誤操作導(dǎo)致的程序中斷。

B類-較嚴(yán)重錯(cuò)誤

1.功能不符。

2.數(shù)據(jù)流錯(cuò)誤。

3.程序接口錯(cuò)誤。

4.輕微數(shù)值計(jì)算錯(cuò)誤。

C類-一般性錯(cuò)誤

1.界面錯(cuò)誤（詳細(xì)文檔）。

2.打印內(nèi)容，格式錯(cuò)誤。

3.簡(jiǎn)單的輸入限制未放到前臺(tái)進(jìn)行控制。

4.刪除操作未給出提示。

D類-較小錯(cuò)誤

1.輔助說明描述不清楚。

2.顯示格式不規(guī)范。

3.長(zhǎng)時(shí)間操作未給用戶進(jìn)度提示。

4.提示窗口文字未使用行業(yè)術(shù)語。

5.可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志。

6.系統(tǒng)處理未優(yōu)化。

E類-其他錯(cuò)誤

1.光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯(cuò)誤。

2.一些建議性問題。

缺陷的優(yōu)先級(jí)

立即解決P1—缺陷導(dǎo)致系統(tǒng)幾乎不能使用或測(cè)試不能繼續(xù)，需要立即修復(fù)。

高優(yōu)先級(jí)P2—缺陷嚴(yán)重影響測(cè)試，需要優(yōu)先考慮。

正常排隊(duì)P3—缺陷需要正常排隊(duì)等待修復(fù)。

低優(yōu)先級(jí)P4—缺陷可以在開發(fā)人員有時(shí)間的時(shí)候再被糾正。

缺陷的類型

（1）功能：影響了各種系統(tǒng)功能、邏輯的缺陷。

（2）用戶界面：影響了用戶界面、人機(jī)交互特性，包括屏幕格式、用戶輸入靈活性、結(jié)果輸出格式等方面的缺陷。

（3）文檔：影響發(fā)布和維護(hù)，包括注釋、用戶手冊(cè)、設(shè)計(jì)文檔。

（4）軟件包：由于軟件配置庫、變更管理或版本控制引起的錯(cuò)誤。

（5）性能：不滿足系統(tǒng)可測(cè)量的屬性值，如執(zhí)行時(shí)間、事務(wù)處理速率等。

（6）系統(tǒng)/模塊接口：與其他組件、模塊或設(shè)備驅(qū)動(dòng)程序、調(diào)用參數(shù)、控制塊或參數(shù)列表等不匹配、沖突

缺陷來源

（1）需求說明書：需求說明書錯(cuò)誤或不清楚引起的問題。

（2）設(shè)計(jì)文檔：設(shè)計(jì)文檔描述不準(zhǔn)確和需求說明書不一致的問題。

（3）系統(tǒng)集成接口：系統(tǒng)各模塊參數(shù)不匹配、開發(fā)組之間缺乏協(xié)調(diào)引起的缺陷。

（4）數(shù)據(jù)流（庫）：由于數(shù)據(jù)字典、數(shù)據(jù)庫中的錯(cuò)誤引起的缺陷。

（5）程序代碼：純粹在編碼中的問題所引起缺陷。

缺陷的根源

a)測(cè)試策略：錯(cuò)誤的測(cè)試范圍，誤解測(cè)試目標(biāo)，超越測(cè)試能力等；

b)過程、工具和方法：無效的需求收集過程，過失的風(fēng)險(xiǎn)管理過程，不適用的項(xiàng)目管理方法，無效的變更控制過程等；

c)團(tuán)隊(duì)/人：項(xiàng)目團(tuán)隊(duì)職責(zé)較差，缺乏培訓(xùn)，沒有經(jīng)驗(yàn)的項(xiàng)目團(tuán)隊(duì)，缺乏士氣等；

d)缺乏組織和溝通：缺乏用戶參與，職責(zé)不明確、管理失敗等；

e)硬件：硬件配置不對(duì)、缺乏等；

f)軟件：軟件配置不對(duì)、缺乏，或操作系統(tǒng)錯(cuò)誤導(dǎo)致無法釋放資源，工具軟件錯(cuò)誤，編譯器錯(cuò)誤等；

g)工作環(huán)境：組織機(jī)構(gòu)調(diào)整，預(yù)算改變，工作環(huán)境惡劣等。

Bug報(bào)告包括哪些內(nèi)容？

Bug出現(xiàn)的位置、可重現(xiàn)的步驟、所使用的數(shù)據(jù)、bug的截圖、發(fā)現(xiàn)人以及日期

如果一個(gè)bug只出現(xiàn)一次，該怎么處理？

1.bug出現(xiàn)的同時(shí)立即截圖留下異常的畫面；

2.使用相同的環(huán)境、設(shè)備、測(cè)試步驟、方法，使用相同的輸入數(shù)據(jù)看能否重現(xiàn)；

3.不能重現(xiàn)，則告訴項(xiàng)目經(jīng)理發(fā)現(xiàn)的過程，分析優(yōu)先級(jí)，討論解決方案。

缺陷的生命周期

缺陷的生命周期就是從缺陷開始（即被發(fā)現(xiàn)）到結(jié)束（即該缺陷被確保不會(huì)再出現(xiàn)）的周期。

一個(gè)缺陷的生命周期通常有以下幾個(gè)階段（各個(gè)公司通常都會(huì)有自己對(duì)缺陷階段的定義，下面只是一個(gè)范例）

1.New :缺陷被測(cè)試人員發(fā)現(xiàn)，但是沒有提交給任何開發(fā)。

2.Open:缺陷被測(cè)試人員提交給開發(fā)，由測(cè)試人員更改為Open。之后開發(fā)可能會(huì)Rejected(拒絕修復(fù))，或者改為duplicate（該bug被重復(fù)提交，也或者是改為deferred（延期解決）

3.Update：開發(fā)修復(fù)了但是還沒有提交給測(cè)試人員，由開發(fā)將狀態(tài)更改為Update。

4.Fix :開發(fā)修復(fù)之后并自測(cè)通過并提交給測(cè)試人員，由開發(fā)將狀態(tài)更改為fixed.

5.Close :由測(cè)試驗(yàn)證確實(shí)修改正確后，將狀態(tài)改為Close.

6.Reopen：由測(cè)試驗(yàn)證仍然沒有修復(fù)，則將狀態(tài)更改為Reopen，再次提交給開發(fā)，讓其修復(fù)。

缺陷周期一般分為3段和1個(gè)特殊階段

1、發(fā)現(xiàn)缺陷：測(cè)試執(zhí)行過程中，發(fā)現(xiàn)bug，并記錄相關(guān)bug情況

2、跟蹤修復(fù)缺陷：測(cè)試人員追蹤bug修復(fù)情況，開發(fā)人員及時(shí)獲得bug情況進(jìn)行修復(fù)。

3、修復(fù)確認(rèn)缺陷：驗(yàn)證bug，確認(rèn)bug已經(jīng)被修復(fù)（當(dāng)?shù)谌绞〉脑?，將重新回歸至第2步）

4、掛起階段：當(dāng)bug所需要修復(fù)的成本過于龐大或特殊原因，造成bug無法修復(fù)的話，會(huì)進(jìn)入bug的掛起階段

軟件的生命周期

軟件的生命周期，亦稱軟件的生存周期。它是按開發(fā)軟件的規(guī)模和復(fù)雜程度，從時(shí)間上把軟件開發(fā)的整個(gè)過程（從計(jì)劃開發(fā)開始到軟件報(bào)廢為止的整個(gè)歷史階段）進(jìn)行分解，形成相對(duì)獨(dú)立的幾個(gè)階段，每個(gè)階段又分解成幾個(gè)具體的任務(wù)，然后按規(guī)定順序依次完成各階段的任務(wù)并規(guī)定一套標(biāo)準(zhǔn)的文檔作為各個(gè)階段的開發(fā)成果，最后生產(chǎn)出高質(zhì)量的軟件。

1、問題的定義及規(guī)劃

此階段是軟件開發(fā)方與需求方共同討論，主要確定軟件的開發(fā)目標(biāo)及其可行性。

2、需求分析

在確定軟件開發(fā)可行的情況下，對(duì)軟件需要實(shí)現(xiàn)的各個(gè)功能進(jìn)行詳細(xì)分析。需求分析階段是一個(gè)很重要的階段，這一階段做得好，將為整個(gè)軟件開發(fā)項(xiàng)目的成功打下良好的基礎(chǔ)。"唯一不變的是變化本身。"，同樣需求也是在整個(gè)軟件開發(fā)過程中不斷變化和深入的，因此我們必須制定需求變更計(jì)劃來應(yīng)付這種變化，以保護(hù)整個(gè)項(xiàng)目的順利進(jìn)行。

3、軟件設(shè)計(jì)

此階段主要根據(jù)需求分析的結(jié)果，對(duì)整個(gè)軟件系統(tǒng)進(jìn)行設(shè)計(jì)，如系統(tǒng)框架設(shè)計(jì)，數(shù)據(jù)庫設(shè)計(jì)等等。軟件設(shè)計(jì)一般分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)。好的軟件設(shè)計(jì)將為軟件程序編寫打下良好的基礎(chǔ)。

4、程序編碼

此階段是將軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。在程序編碼中必須要制定統(tǒng)一，符合標(biāo)準(zhǔn)的編寫規(guī)范。以保證程序的可讀性，易維護(hù)性，提高程序的運(yùn)行效率。

5、軟件測(cè)試

在軟件設(shè)計(jì)完成后要經(jīng)過嚴(yán)密的測(cè)試，以發(fā)現(xiàn)軟件在整個(gè)設(shè)計(jì)過程中存在的問題并加以糾正。整個(gè)測(cè)試過程分單元測(cè)試、組裝測(cè)試以及系統(tǒng)測(cè)試三個(gè)階段進(jìn)行。測(cè)試的方法主要有白盒測(cè)試和黑盒測(cè)試兩種。在測(cè)試過程中需要建立詳細(xì)的測(cè)試計(jì)劃并嚴(yán)格按照測(cè)試計(jì)劃進(jìn)行測(cè)試，以減少測(cè)試的隨意性。

6、運(yùn)行維護(hù)

軟件維護(hù)是軟件生命周期中持續(xù)時(shí)間最長(zhǎng)的階段。在軟件開發(fā)完成并投入使用后，由于多方面的原因，軟件不能繼續(xù)適應(yīng)用戶的要求。要延續(xù)軟件的使用壽命，就必須對(duì)軟件進(jìn)行維護(hù)。軟件的維護(hù)包括糾錯(cuò)性維護(hù)和改進(jìn)性維護(hù)兩個(gè)方面。

軟件測(cè)試的流程

1.需求：閱讀需求，理解需求，與客戶、開發(fā)、架構(gòu)多方交流，深入了解需求。--testing team

2.測(cè)試計(jì)劃:根據(jù)需求估算測(cè)試所需資源（人力、設(shè)備等）、所需時(shí)間、功能點(diǎn)劃分、如何合理分配安排資源等。---testing leader or testing manager

3.用例設(shè)計(jì)：根據(jù)測(cè)試計(jì)劃、任務(wù)分配、功能點(diǎn)劃分，設(shè)計(jì)合理的測(cè)試用例。---testing leader, senior tester

4.執(zhí)行測(cè)試：根據(jù)測(cè)試用例的詳細(xì)步驟，執(zhí)行測(cè)試用例。--every tester(主要是初級(jí)測(cè)試人員)

5.執(zhí)行結(jié)果記錄和bug記錄：對(duì)每個(gè)case記錄測(cè)試的結(jié)果，有bug的在測(cè)試管理工具中編寫bug記錄。--every tester(主要是初級(jí)測(cè)試人員)

6.defect tracking：追蹤leader分配給你追蹤的bug.直到bug fixed。--everytester

7.測(cè)試報(bào)告：通過不斷測(cè)試、追蹤，直到被測(cè)軟件達(dá)到測(cè)試需求要求，并沒有重大bug.

8.編寫安裝文檔或者使用手冊(cè)

9.結(jié)束

軟件測(cè)試結(jié)束的標(biāo)準(zhǔn)

1．模塊測(cè)試用例執(zhí)行完畢，覆蓋了全部軟件需求；

2．缺陷收斂趨勢(shì)符合質(zhì)量要求；

3．缺陷修復(fù)率達(dá)到產(chǎn)品設(shè)計(jì)人員的需求；

4．達(dá)到預(yù)先的缺陷度量原則（缺陷密度值達(dá)到客戶的需求）。

對(duì)C/S和B/S結(jié)構(gòu)的軟件進(jìn)行測(cè)試時(shí)有何不同？

C/S又稱Client/Server或客戶/服務(wù)器模式。服務(wù)器通常采用高性能的PC、工作站或小型機(jī)，并采用大型數(shù)據(jù)庫。客戶端需要安裝專用的客戶端軟件。

B/S又稱Brower/Server，客戶機(jī)上只需要安裝一個(gè)瀏覽器。瀏覽器通過web server同數(shù)據(jù)庫數(shù)據(jù)進(jìn)行交互。