定義

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

測(cè)試就是發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程。

原則

保證測(cè)試的覆蓋度，但是窮舉測(cè)試是不可能的。

所有的測(cè)試都應(yīng)該追溯到用戶(hù)。

越早測(cè)越好，測(cè)試過(guò)程與開(kāi)發(fā)過(guò)程應(yīng)該是互相結(jié)合的。

測(cè)試的規(guī)模 從小到大，從單元測(cè)試到系統(tǒng)測(cè)試。

不能為了便于測(cè)試而擅自修改程序。

既應(yīng)該測(cè)試軟件能做什么，也應(yīng)該測(cè)試軟件不能做什么。

度量

測(cè)試覆蓋率

缺陷發(fā)現(xiàn)率

測(cè)試成功率（或者說(shuō)用例通過(guò)率）

測(cè)試做到什么程度并沒(méi)有一個(gè)固定答案。只要滿(mǎn)足兩個(gè)顯式條件和一個(gè)隱含條件就要一直進(jìn)行。

顯式條件：

項(xiàng)目風(fēng)險(xiǎn)

項(xiàng)目經(jīng)費(fèi)

隱含條件：

老板們從當(dāng)前的測(cè)試結(jié)果已經(jīng)獲得了足夠的信心,或者徹底摧毀了信心。只要他們還在猶豫咱就得繼續(xù)干活。

測(cè)試的原則

測(cè)試只是展示缺陷

測(cè)試只能表明缺陷存在,卻不能證明沒(méi)有缺陷。測(cè)試能降低未發(fā)現(xiàn)缺陷留存的概率,卻 不能證明軟件是絕對(duì)正確的。 正如某些數(shù)學(xué)命題,你可以窮舉 1-n,證明其正確,卻依然無(wú)法證明對(duì)于 n+1 仍然正確。

窮盡測(cè)試是不可能的

測(cè)試所有的輸入和條件組合是不可能的,除非是極其簡(jiǎn)單的情況?？梢匀《氖腔?于風(fēng)險(xiǎn)和優(yōu)先級(jí)的測(cè)試。 當(dāng)不懂裝懂的老板要求你徹底測(cè)試一個(gè)軟件的時(shí)候,這是你反駁的最好支持,當(dāng)然要說(shuō) 的委婉一點(diǎn)。

早期測(cè)試

要較早發(fā)現(xiàn)缺陷,就要在軟件周期盡可能早的時(shí)候開(kāi)始測(cè)試,而且要專(zhuān)注于已定義的測(cè) 試目標(biāo)。 盡早開(kāi)始測(cè)試!這句話(huà)估計(jì)早就把大家的耳朵磨起繭了。為什么要早?因?yàn)樵皆绨l(fā)現(xiàn)問(wèn) 題,解決的代價(jià)就越小。

缺陷簇生

要對(duì)缺陷發(fā)現(xiàn)率高的模塊投入更多的測(cè)試。少量的模塊往往隱藏了大部分的缺陷。 這不僅僅是所謂的物以類(lèi)聚。缺陷發(fā)現(xiàn)率高的模塊往往于需求不清,設(shè)計(jì)不當(dāng),編碼復(fù) 雜度高等內(nèi)在原因關(guān)聯(lián),所以從風(fēng)險(xiǎn)的角度來(lái)看必然較高,多花些時(shí)間絕對(duì)值得。

殺蟲(chóng)劑悖論

相同的測(cè)試再重復(fù)多次后就無(wú)法再找到缺陷了。要克服“殺蟲(chóng)劑悖論”,測(cè)試用例要不斷評(píng)審修改,不斷添加新的和不同的測(cè)試,就有可能找到更多缺陷。 隨著對(duì)系統(tǒng)的加深理解,必然會(huì)有更多的測(cè)試用例產(chǎn)生。另外缺陷本身也是新用例的很 好來(lái)源。

測(cè)試是上下文相關(guān)的

測(cè)試在不同上下文環(huán)境中的執(zhí)行是不同的。比方說(shuō) 安全關(guān)鍵系統(tǒng) (safety critical system)和電子商務(wù)網(wǎng)站的測(cè)試方法就有很大不同。 這個(gè)原理相對(duì)難理解。這里其實(shí)強(qiáng)調(diào)的是不能用相同的態(tài)度和手段來(lái)測(cè)試不同類(lèi)型的系 統(tǒng)。安全關(guān)鍵系統(tǒng)的概念要到高級(jí)大綱中才出現(xiàn),指的是對(duì)系統(tǒng)安全要求苛刻的系統(tǒng), 較之一般的電子商務(wù)系統(tǒng)的測(cè)試要求更為嚴(yán)苛。

無(wú)錯(cuò)謬論

假如建立的系統(tǒng)不穩(wěn)定或不能滿(mǎn)足用戶(hù)需要和期望,那么發(fā)現(xiàn)和修復(fù)缺陷就毫無(wú)幫助了。 缺陷數(shù)量往往用來(lái)評(píng)估某軟件的質(zhì)量,但要是系統(tǒng)本身背離了用戶(hù)要求,那就算缺陷再 少也沒(méi)用,因?yàn)闆](méi)有人會(huì)去用它。所以測(cè)試時(shí)要注意驗(yàn)證(verification)和確認(rèn)(validation)的區(qū)別。需求規(guī)格說(shuō)明和其他文檔只是需求的不完全載體。文字說(shuō)明必然有遺漏和偏差, 而各人的理解更有可能出錯(cuò)。要不斷通過(guò)各種途徑保證所生產(chǎn)的的確就是用戶(hù)需要的。 常用的方式就是邀請(qǐng)領(lǐng)域?qū)＜一蛴脩?hù)盡可能多地參與到開(kāi)發(fā)活動(dòng)來(lái),特別是需求評(píng)審和 演示(Demo)。

測(cè)試的標(biāo)準(zhǔn)

測(cè)試的標(biāo)準(zhǔn)是用戶(hù)的需求。

所有的軟件測(cè)試都應(yīng)該追溯用戶(hù)的需求，測(cè)試人員要始終站在用戶(hù)的角度去看問(wèn)題、去判斷的軟件缺陷的影響，系統(tǒng)最嚴(yán)重的錯(cuò)誤是那些導(dǎo)致程序無(wú)法滿(mǎn)足用戶(hù)需求的缺陷。

測(cè)試主要步驟

計(jì)劃與控制

分析與設(shè)計(jì)

實(shí)施與執(zhí)行

評(píng)估出口準(zhǔn)則和報(bào)告

測(cè)試結(jié)束活動(dòng)

測(cè)試流程

熟悉產(chǎn)品／項(xiàng)目

需求評(píng)審

測(cè)試需求

測(cè)試計(jì)劃

測(cè)試用例

預(yù)測(cè)試

第一輪測(cè)試

第二輪回歸測(cè)試

第三輪測(cè)試

測(cè)試報(bào)告

測(cè)試總結(jié)

為什么要避免測(cè)試自己的程序？

由于心理因素，人們潛意識(shí)都不希望找到自己的錯(cuò)誤。基于這種思維定勢(shì)，人們難于發(fā)現(xiàn)自己的錯(cuò)誤。

軟件測(cè)試的要素

質(zhì)量：

軟件質(zhì)量是軟件測(cè)試的目標(biāo)，也是軟件測(cè)試工作的中心，一切從質(zhì)量出發(fā)，也就是一切從客戶(hù)需求出發(fā)。任何違背質(zhì)量的東西都是問(wèn)題，測(cè)試就是要找出這些問(wèn)題。

人員：

人是決定的因素，測(cè)試人員的態(tài)度、素質(zhì)、能力決定著測(cè)試的效果，對(duì)測(cè)試產(chǎn)品的質(zhì)量也有很大的影響。測(cè)試人員因素包括測(cè)試組織結(jié)構(gòu)、角色和責(zé)任的定義。

技術(shù)：

軟件測(cè)試技術(shù)，包括方法、工具。

資源：

主要是指測(cè)試環(huán)境中所需要的硬件設(shè)備、網(wǎng)絡(luò)環(huán)境，甚至包括測(cè)試數(shù)據(jù)。另外一個(gè)重要因素就是測(cè)試時(shí)間，時(shí)間也是測(cè)試的資源，但測(cè)試人員不能看做資源，每個(gè)人的能力千差萬(wàn)別，不同的測(cè)試人員擔(dān)任不同的角色，不能相互代替。這也是軟件圖書(shū)的經(jīng)典之作——《人件》的作者反對(duì)將人作為資源對(duì)待的原因。

流程：

從測(cè)試計(jì)劃和測(cè)試用例的創(chuàng)建、評(píng)審到測(cè)試的執(zhí)行、報(bào)告，設(shè)定每個(gè)階段的進(jìn)出標(biāo)準(zhǔn)。

軟件質(zhì)量

軟件產(chǎn)品質(zhì)量評(píng)價(jià)國(guó)際標(biāo)準(zhǔn)ISO 14598 把軟件質(zhì)量定義為：軟件特性的總和，軟件滿(mǎn)足規(guī)定或潛在用戶(hù)需求的能力。上述定義反應(yīng)如下3個(gè)方面的問(wèn)題：

軟件需求是度量軟件質(zhì)量的標(biāo)準(zhǔn)；

軟件人員必須遵循軟件過(guò)程過(guò)程的規(guī)范；

如果軟件只是滿(mǎn)足規(guī)定的需求，而不能滿(mǎn)足可能存在的隱含需求，軟件質(zhì)量也不能保證。

軟件團(tuán)隊(duì)的責(zé)任

發(fā)現(xiàn)軟件程序、系統(tǒng)或產(chǎn)品中“所有”的問(wèn)題

盡早地發(fā)現(xiàn)問(wèn)題

督促和協(xié)助開(kāi)發(fā)人員盡快地解決程序中的缺陷

幫助項(xiàng)目管理人員制定合理的開(kāi)發(fā)計(jì)劃

對(duì)缺陷進(jìn)行跟蹤、分析和分類(lèi)總結(jié)，以便讓項(xiàng)目的管理人員和相關(guān)的負(fù)責(zé)人員能夠及時(shí)、清楚地了解產(chǎn)品當(dāng)前的質(zhì)量狀態(tài)

幫助改善開(kāi)發(fā)流程、調(diào)高產(chǎn)品開(kāi)發(fā)效率

促進(jìn)程序編寫(xiě)的規(guī)范性、易讀性、可維護(hù)性等

缺陷發(fā)現(xiàn)率

缺陷發(fā)現(xiàn)率DDP是另一個(gè)衡量測(cè)試工作效率的軟件質(zhì)量成本的指標(biāo)。

缺陷發(fā)現(xiàn)率

缺陷發(fā)現(xiàn)率DDP＝Bugs（tester）/ （Bugs（tester）+ Bugs（customer））

缺陷發(fā)現(xiàn)率越高，也就是測(cè)試者發(fā)現(xiàn)的錯(cuò)誤多，發(fā)布后客戶(hù)發(fā)現(xiàn)的錯(cuò)誤就越少，降低了外部故障不一致成本，達(dá)到節(jié)約總成本的目的，可獲得較高的測(cè)試投資回報(bào)率。

測(cè)試分類(lèi)

黑盒測(cè)試

又稱(chēng)功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，是針對(duì)軟件的功能需求/實(shí)現(xiàn)進(jìn)行測(cè)試，通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否符合需求，不考慮程序內(nèi)部的邏輯結(jié)構(gòu)。

方法：

功能劃分

等價(jià)類(lèi)劃分

邊界值劃分

因果圖（魚(yú)骨圖）

錯(cuò)誤推測(cè)

白盒測(cè)試

白盒測(cè)試也稱(chēng)結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，必須知道軟件內(nèi)部工作過(guò)程，通過(guò)測(cè)試來(lái)檢測(cè)軟件內(nèi)部是否按照需求、設(shè)計(jì)正常運(yùn)行。

方法：

對(duì)應(yīng)于程序的一些主要結(jié)構(gòu)：語(yǔ)句、分支、邏輯路徑、變量；

語(yǔ)句覆蓋方法

分支覆蓋方法

邏輯覆蓋方法

單元測(cè)試

定義： 又稱(chēng)模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位程序模塊進(jìn)行正確性檢查的測(cè)試工作；可以從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，多個(gè)模塊測(cè)試可以平行地獨(dú)立進(jìn)行測(cè)試；

目的：發(fā)現(xiàn)模塊內(nèi)部可能存在的差錯(cuò)；

內(nèi)容：模塊接口測(cè)試（數(shù)據(jù)流入流出）、局部數(shù)據(jù)結(jié)構(gòu)測(cè)試、路徑測(cè)試、錯(cuò)誤處理測(cè)試、邊界測(cè)試。

步驟：利用設(shè)計(jì)文檔設(shè)計(jì)測(cè)試用例；創(chuàng)建被測(cè)模塊的樁模塊或驅(qū)動(dòng)模塊；利用被測(cè)試模塊、驅(qū)動(dòng)模塊和樁模塊來(lái)建立測(cè)試環(huán)境，進(jìn)行測(cè)試。

集成測(cè)試

定義：又稱(chēng)組裝測(cè)試或聯(lián)合測(cè)試，在單元測(cè)試的基礎(chǔ)上，將所有模塊按概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)進(jìn)行組裝。

目的：發(fā)現(xiàn)模塊連接中的接口可能存在的各種差錯(cuò)

內(nèi)容：

穿越模塊之間的數(shù)據(jù)是否會(huì)丟失；

一個(gè)模塊組裝后是否會(huì)對(duì)另一模塊或其他模塊存在影響

各個(gè)子功能組裝在一起是否會(huì)達(dá)到預(yù)期的父功能

全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問(wèn)題；

單個(gè)模塊的錯(cuò)誤累積起來(lái)是否會(huì)放在。

組裝方法：包括一次性組裝方式、增殖式組裝方式兩種組裝方法

完成標(biāo)志：成功地執(zhí)行了測(cè)試計(jì)劃中規(guī)定的所有測(cè)試用例；修正了所發(fā)現(xiàn)的錯(cuò)誤；測(cè)試結(jié)果通過(guò)專(zhuān)門(mén)小組的評(píng)審

系統(tǒng)測(cè)試

目的：驗(yàn)證和確認(rèn)系統(tǒng)是否達(dá)到其原始目標(biāo)，而對(duì)集成的硬件和軟件系統(tǒng)進(jìn)行的測(cè)試

測(cè)試內(nèi)容：在真實(shí)或模擬系統(tǒng)運(yùn)行環(huán)境下，檢查完整的程序系統(tǒng)能否和系統(tǒng)（硬件設(shè)備、網(wǎng)絡(luò)、系統(tǒng)軟件）正確配置、連接，滿(mǎn)足用戶(hù)需求

驗(yàn)收測(cè)試

測(cè)試目的：在用戶(hù)環(huán)境中進(jìn)行測(cè)試，以確定系統(tǒng)和產(chǎn)品是否能夠滿(mǎn)足合同或用戶(hù)所規(guī)定的需求

測(cè)試內(nèi)容：根據(jù)任務(wù)書(shū)或合同、供需雙方約定的驗(yàn)收依據(jù)文檔進(jìn)行對(duì)整個(gè)系統(tǒng)的測(cè)試與評(píng)審，確認(rèn)是否接收或拒絕系統(tǒng)

Alpha測(cè)試

屬于驗(yàn)證測(cè)試。模擬運(yùn)行。由開(kāi)發(fā)人員與測(cè)試的測(cè)試人員。

Beta測(cè)試

屬于驗(yàn)收測(cè)試。由軟件的最終用戶(hù)在一個(gè)或多個(gè)用戶(hù)場(chǎng)所來(lái)進(jìn)行的，開(kāi)發(fā)者通常不在現(xiàn)場(chǎng)，用戶(hù)記錄測(cè)試中遇到的問(wèn)題并報(bào)告給開(kāi)發(fā)者。

靜態(tài)測(cè)試

靜態(tài)測(cè)試又稱(chēng)為靜態(tài)分析技術(shù)，不執(zhí)行被測(cè)試軟件，對(duì)需求分析說(shuō)明書(shū)、軟件設(shè)計(jì)說(shuō)明書(shū)、源程序做結(jié)構(gòu)檢測(cè)、流圖分析、符號(hào)執(zhí)行等找出軟件的錯(cuò)誤。

動(dòng)態(tài)測(cè)試

通過(guò)輸入一組預(yù)先按照一定的測(cè)試準(zhǔn)則構(gòu)造的實(shí)例數(shù)據(jù)動(dòng)態(tài)運(yùn)行程序，而達(dá)到發(fā)現(xiàn)程序錯(cuò)誤的過(guò)程。

如何進(jìn)行單元測(cè)試

完成最小的軟件設(shè)計(jì)單元——模塊驗(yàn)證工作。

確保模塊的正確編碼

使用過(guò)程設(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ò)誤。

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

接口測(cè)試

內(nèi)部數(shù)據(jù)結(jié)構(gòu)

全局?jǐn)?shù)據(jù)結(jié)構(gòu)

邊界

語(yǔ)句覆蓋，錯(cuò)誤路徑

自動(dòng)化測(cè)試

自動(dòng)化測(cè)試是把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過(guò)程。

在設(shè)計(jì)了測(cè)試用例并通過(guò)評(píng)審之后，由測(cè)試人員根據(jù)測(cè)試用例中描述的規(guī)程一步步執(zhí)行測(cè)試，得到實(shí)際結(jié)果與期望結(jié)果的比較。在此過(guò)程中，為了節(jié)省人力、時(shí)間或硬件資源，提高測(cè)試效率，便引入了自動(dòng)化測(cè)試的概念。

手工和自動(dòng)化

手工測(cè)試缺點(diǎn)在于測(cè)試工作量大，重復(fù)多，回歸測(cè)試難以實(shí)現(xiàn)

自動(dòng)測(cè)試?yán)密浖y(cè)試工具自動(dòng)實(shí)現(xiàn)全部或部分測(cè)試工作：管理、設(shè)計(jì)、執(zhí)行和報(bào)告；節(jié)省大量的測(cè)試開(kāi)銷(xiāo)，并能夠完成一些手工測(cè)試無(wú)法實(shí)現(xiàn)的測(cè)試

手工完成測(cè)試的全部過(guò)程無(wú)法保證測(cè)試的科學(xué)性與嚴(yán)密性:

修改缺陷越多，回歸測(cè)試約困難

沒(méi)有人能向決策層提供精確的數(shù)據(jù)以度量當(dāng)前的工作進(jìn)度及工作效率

反復(fù)測(cè)試帶來(lái)的倦怠情緒及其他人為因素使得測(cè)試標(biāo)準(zhǔn)前后不一

測(cè)試花費(fèi)的時(shí)間越長(zhǎng)，測(cè)試的嚴(yán)格性也就越低

自動(dòng)測(cè)試將測(cè)試人員從反復(fù)、煩雜的測(cè)試執(zhí)行中解放出來(lái)，用更多的時(shí)間進(jìn)行測(cè)試設(shè)計(jì)和結(jié)果分析

軟件測(cè)試不可能全部自動(dòng)化

不能完成所有手工測(cè)試任務(wù)

無(wú)創(chuàng)造性，且靈活性差，不能改進(jìn)測(cè)試的有效率

過(guò)程中可能會(huì)遇到很多想不到的問(wèn)題，尤其是在軟件不穩(wěn)定的情況下

測(cè)試腳本的維護(hù)高

測(cè)試用例設(shè)計(jì)原則

單個(gè)用例最小化原則

這條原則是所有這四條原則中的“老大“，也是在工程中最容易被忘記和忽略的，它或多或少的都影響到其它幾條原則。

測(cè)試用例的覆蓋邊界定義更清晰，則測(cè)試結(jié)果對(duì)產(chǎn)品問(wèn)題的指向性更強(qiáng)。

測(cè)試用例間的耦合度最低，則彼此之間的干擾也就越低。

上述這些優(yōu)點(diǎn)所能帶來(lái)直接好處是，測(cè)試用例的調(diào)試、分析和維護(hù)成本最低。每個(gè)測(cè)試用例應(yīng)該盡可能的簡(jiǎn)單，只驗(yàn)證你所要驗(yàn)證的內(nèi)容。

測(cè)試用例替代產(chǎn)品文檔功能原則

通常我們會(huì)在開(kāi)發(fā)的初期（Scrum每個(gè)Sprint的頭兩天）用Word文檔或者OneNote的記錄產(chǎn)品的需求、功能描述、以及當(dāng)前所能確定的任何細(xì)節(jié)等信息，勾勒將要實(shí)現(xiàn)功能的樣貌，便于團(tuán)隊(duì)進(jìn)行交流和細(xì)化，并在團(tuán)隊(duì)內(nèi)達(dá)成對(duì)產(chǎn)品功能共識(shí)。但隨著產(chǎn)品開(kāi)發(fā)深入，團(tuán)隊(duì)會(huì)對(duì)產(chǎn)品的功能有更新的認(rèn)識(shí)，產(chǎn)品功能也會(huì)被更具體細(xì)化，在一個(gè)迭代或者Sprint結(jié)束的時(shí)候最終實(shí)現(xiàn)的功能很可能是A+。如此往復(fù)，在不斷傾聽(tīng)和吸收用戶(hù)的反饋，多個(gè)迭代過(guò)后，原本被描述為A的功能很可能最終變?yōu)榱薢。這是時(shí)候再去看看曾經(jīng)的Word文檔和OneNote頁(yè)面，它們?nèi)匀挥涗浀氖茿。之所以會(huì)這樣 ，是因?yàn)楹苌儆腥藭?huì)去以及能夠去不斷地去更新那些文檔，以準(zhǔn)確地反映出功能當(dāng)前準(zhǔn)確的狀態(tài)。

單次投入成本和多次投入成本原則

成本永遠(yuǎn)是任何項(xiàng)目進(jìn)行決策時(shí)所要考慮的首要因素，項(xiàng)目中的測(cè)試也是如此，對(duì)成本的考慮也應(yīng)該客觀和全面的體現(xiàn)在測(cè)試的設(shè)計(jì)、執(zhí)行和維護(hù)的整個(gè)階段中。

測(cè)試中的成本按其時(shí)間跨度可以分為：?jiǎn)未瓮度氤杀竞投啻瓮度氤杀?。例如：編?xiě)測(cè)試用例可以看作是單次投入成本，因?yàn)榫帉?xiě)測(cè)試用例一般是在測(cè)試的計(jì)劃階段進(jìn)行（Scrum每個(gè)Sprint的開(kāi)始階段）的，雖然后期會(huì)有小的改動(dòng)，但絕大多數(shù)是在一開(kāi)始的設(shè)計(jì)階段就基本上成型了；

使測(cè)試結(jié)果分析和調(diào)試最簡(jiǎn)單化原則

這條原則實(shí)際上是單次投入成本和多次投入成本原則 – 針對(duì)自動(dòng)化測(cè)試用例的擴(kuò)展和延續(xù)。在編寫(xiě)自動(dòng)化測(cè)試代碼時(shí)，要重點(diǎn)考慮如何使得測(cè)試結(jié)果分析和測(cè)試調(diào)試更為簡(jiǎn)單，包括：用例日志、調(diào)試輔助信息輸出等。

測(cè)試用例方法

等價(jià)類(lèi)劃分

等價(jià)類(lèi)劃分

錯(cuò)誤推測(cè)

因果圖

判定表驅(qū)動(dòng)分析

正交實(shí)驗(yàn)設(shè)計(jì)

場(chǎng)景設(shè)計(jì)法

狀態(tài)轉(zhuǎn)換圖

測(cè)試用例內(nèi)容

測(cè)試用例主要包括用例編號(hào)、用例描述、前提條件、輸入數(shù)據(jù)、測(cè)試步驟和期望結(jié)果6項(xiàng)關(guān)鍵內(nèi)容：

用例編號(hào)

用例的組織要方便測(cè)試人員執(zhí)行測(cè)試用例，應(yīng)設(shè)計(jì)一套良好的用例編號(hào)體系。

用例描述

用例描述應(yīng)使用最精簡(jiǎn)的文字，描述出用例的全貌。讓測(cè)試人員不用看測(cè)試步驟，只看這個(gè)描述就可以知道這個(gè)用例是描述哪個(gè)場(chǎng)景、哪個(gè)功能點(diǎn)。

前提條件

一個(gè)測(cè)試用例一般是針對(duì)一個(gè)特點(diǎn)的場(chǎng)景，而需要測(cè)試的場(chǎng)景發(fā)生時(shí)通常會(huì)有一些鋪墊場(chǎng)景，即測(cè)試用例的前提，如軟硬件環(huán)境配置、權(quán)限設(shè)置，數(shù)據(jù)準(zhǔn)備。

輸入數(shù)據(jù)

一個(gè)測(cè)試用例可以有一個(gè)或多個(gè)輸入數(shù)據(jù)，也可以無(wú)輸入數(shù)據(jù)。

測(cè)試步驟

測(cè)試步驟是測(cè)試用例的主體，一個(gè)測(cè)試用例由一個(gè)或多個(gè)步驟組成，每個(gè)步驟之間有一定的前后關(guān)系。每個(gè)步驟必須表述詳細(xì)，描述清晰，用于規(guī)范、嚴(yán)謹(jǐn)而又客觀，最基本的要求是能夠使其他人理解，并能正確的執(zhí)行編寫(xiě)者希望的操作。

期望結(jié)果

期望結(jié)果是測(cè)試執(zhí)行對(duì)執(zhí)行結(jié)果進(jìn)行對(duì)比的標(biāo)尺，是測(cè)試是否通過(guò)的判斷依據(jù)。測(cè)試結(jié)果必須保證其正確性。

測(cè)試計(jì)劃

根據(jù)項(xiàng)目相關(guān)文檔，需要定義測(cè)試范圍、測(cè)試策略、人員分配、軟硬件配置、進(jìn)度表以及測(cè)試過(guò)程每個(gè)階段需要達(dá)到的目標(biāo)。

查詢(xún)遺漏問(wèn)題的方法

說(shuō)明書(shū)是基礎(chǔ)和標(biāo)準(zhǔn)

測(cè)試的執(zhí)行，通常按測(cè)試用例來(lái)進(jìn)行，但測(cè)試用例的設(shè)計(jì)編寫(xiě)是依據(jù)產(chǎn)品規(guī)格說(shuō)明書(shū)、需求規(guī)格說(shuō)明書(shū)、界面設(shè)計(jì)規(guī)范等。寫(xiě)測(cè)試用例時(shí)難免有考慮不到的地方，因此反復(fù)閱讀說(shuō)明文檔，也許會(huì)有一些新的思路和啟發(fā)。在項(xiàng)目后期，回歸測(cè)試階段，容易思維定勢(shì)、疲憊，這是可以把這些文檔拿出來(lái)，再看一下功能點(diǎn)是否覆蓋，覆蓋到的是不是和需求一致，沒(méi)有偏差。

相關(guān)變動(dòng)郵件，討論記錄

變動(dòng)是一個(gè)項(xiàng)目過(guò)程中不可少的部分，而這些變動(dòng)，通常是通過(guò)討論的方式定下來(lái)的，因此會(huì)有一些文檔記錄和郵件。反復(fù)閱讀這些郵件和文檔記錄，可以更深入的理解項(xiàng)目。

不定期閱讀別人的缺陷

每個(gè)人的思路、考慮的角度和操作習(xí)慣各不相同，因此發(fā)現(xiàn)的問(wèn)題就會(huì)不一樣。多閱讀別人的缺陷可以拓寬思路，看多了，也會(huì)不自覺(jué)把多種思路集中到一起，慢慢得應(yīng)用到測(cè)試實(shí)踐中了。

多和開(kāi)發(fā)人員溝通

功能測(cè)試對(duì)測(cè)試人員來(lái)說(shuō)大多是黑盒測(cè)試，只有開(kāi)發(fā)人員最清楚哪個(gè)函數(shù)調(diào)用哪個(gè)函數(shù)、哪塊單元測(cè)試不夠充分、哪個(gè)邏輯結(jié)構(gòu)比較復(fù)雜，多和他們溝通，可以知道哪里還需要多關(guān)注一下。

有選擇的重新驗(yàn)證以前的缺陷

特別在回歸測(cè)試、驗(yàn)收測(cè)試階段，除了驗(yàn)證前面發(fā)現(xiàn)的缺陷，還要重視那些與缺陷相關(guān)的模塊。一個(gè)底層參數(shù)的變動(dòng)，可能會(huì)引起很多相關(guān)功能的問(wèn)題，繼而造成缺陷的遺漏。

關(guān)注變化

一段代碼的改動(dòng)，需要開(kāi)發(fā)人員和測(cè)試人員去識(shí)別。開(kāi)發(fā)人員知道改動(dòng)的地方會(huì)被哪些模塊調(diào)用或者會(huì)引起哪些模塊的變化，但由于時(shí)間緊、任務(wù)重、很難做好單元測(cè)試，因此開(kāi)發(fā)人員要通知測(cè)試人員需要關(guān)注的測(cè)試點(diǎn)。

簡(jiǎn)單思維方式，一主線(xiàn)為主，減少大遺漏

一個(gè)項(xiàng)目的成功不是把缺陷全報(bào)出來(lái)，而是在有限的代價(jià)下達(dá)到預(yù)期的質(zhì)量。按計(jì)劃進(jìn)行的項(xiàng)目，主要功能的質(zhì)量在一定程度上決定了產(chǎn)品的好壞。在項(xiàng)目工期緊張時(shí)，全部走完所有測(cè)試用例是很難的，可以基本功能為主線(xiàn)，做好相關(guān)測(cè)試用例的執(zhí)行，保證不會(huì)發(fā)生大的質(zhì)量事故。

在測(cè)試后期，測(cè)試人員可能對(duì)質(zhì)量已經(jīng)很有信心，受思維和經(jīng)驗(yàn)的局限性，可能僅限于此。若此時(shí)，在產(chǎn)品發(fā)布之前，調(diào)動(dòng)其他組的員工參與限時(shí)測(cè)試并給予獎(jiǎng)勵(lì)，必然能有效減少軟件缺陷帶來(lái)的風(fēng)險(xiǎn)，提高產(chǎn)品質(zhì)量。

軟件缺陷（bug）

軟件缺陷是指系統(tǒng)或系統(tǒng)部件中那些導(dǎo)致系統(tǒng)或部件不能實(shí)現(xiàn)其應(yīng)有功能的缺陷。一般定義缺陷有以下5條原則：

軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書(shū)要求的功能。

軟件出現(xiàn)產(chǎn)品說(shuō)明書(shū)指明不應(yīng)該出現(xiàn)的錯(cuò)誤。

軟件實(shí)現(xiàn)了產(chǎn)品說(shuō)明書(shū)未說(shuō)明的功能。

軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書(shū)雖未明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)。

軟件難以理解，不易使用，運(yùn)行速度慢，或者軟件測(cè)試員認(rèn)為最終用戶(hù)會(huì)認(rèn)為不好。

提交缺陷（bug）的要求

Bug描述的基本要求是分類(lèi)準(zhǔn)確、敘述簡(jiǎn)潔、步驟清楚、實(shí)際結(jié)果描述準(zhǔn)確、復(fù)雜問(wèn)題有據(jù)可查（截圖或其他形式的附件）?；疽笕缦拢?/p>

問(wèn)題描述一般格式：模塊或功能點(diǎn)=>測(cè)試步驟=>期望結(jié)果=>實(shí)際結(jié)果=>其他信息

單一：盡量一個(gè)bug只針對(duì)一個(gè)軟件缺陷

簡(jiǎn)潔：每個(gè)步驟盡量簡(jiǎn)單明了

再現(xiàn)：?jiǎn)栴}必須能在自己機(jī)器上重現(xiàn)方可上報(bào)（個(gè)別嚴(yán)重問(wèn)題重現(xiàn)不了也可上報(bào)，但必須標(biāo)明）

復(fù)雜問(wèn)題：附截圖補(bǔ)充說(shuō)明或直接通知指定的修改人，截圖文件格式建議用JPG或GIF

報(bào)告中不允許使用抽象的詞語(yǔ)：“有錯(cuò)誤”，“有時(shí)候”之類(lèi)的不確定語(yǔ)句。

作者：西邊人

微博：@西邊青年

公眾號(hào)：testpu