測(cè)試用例的準(zhǔn)備，都是為了執(zhí)行測(cè)試準(zhǔn)備的。

測(cè)試環(huán)境的搭建

　　（1）測(cè)試數(shù)據(jù)：有些測(cè)試需要使用大批量的數(shù)據(jù)，例如容量測(cè)試、壓力測(cè)試等。根據(jù)產(chǎn)品的具體測(cè)試要求，可能需要在數(shù)據(jù)庫表插入大量的數(shù)據(jù)，準(zhǔn)備大量的文件，生成大量的Socket包等。

　　（2）有些測(cè)試需要專門的外部硬件設(shè)備，比如打印機(jī)，條碼識(shí)別器，讀卡機(jī)，指紋儀等。

　　　　?如果是手機(jī)應(yīng)用測(cè)試，可能要把所有支持的型號(hào)的手機(jī)都準(zhǔn)備好。這些設(shè)備有些可以使用模擬器來模擬，有些則不能。模擬器比如夜神安卓模擬器。經(jīng)常遇到在手機(jī)模擬器上可以執(zhí)行的程序，在真正的手機(jī)上運(yùn)行則會(huì)出現(xiàn)問題，或者在pc上報(bào)表格式正確，但是真正打印出來則會(huì)移位，走樣。

　　（3）有些產(chǎn)品需要支持多種操作系統(tǒng)，那么在做兼容性測(cè)試之前就需要準(zhǔn)備好各種操作系統(tǒng)的計(jì)算機(jī)，或者可以考慮虛擬機(jī)來安裝，如vm ware,virtual PC等。

　　（4）有些測(cè)試需要部署到多臺(tái)機(jī)器，并且需要設(shè)置各種參數(shù)，那么就需要在測(cè)試之前準(zhǔn)備好各種安裝包。

　　（5）有些測(cè)試需要用到網(wǎng)絡(luò)，設(shè)置需要考慮網(wǎng)絡(luò)的路由設(shè)置、拓?fù)浣Y(jié)構(gòu)等，那么在測(cè)試之前就需要準(zhǔn)備好這樣的網(wǎng)絡(luò)設(shè)備和網(wǎng)絡(luò)環(huán)境配置。

BVT測(cè)試與冒煙測(cè)試

　　BVT測(cè)試（Build Verification Test)），編譯檢查測(cè)試，主要檢查源代碼是否能正確編譯成一個(gè)新的，完整可用的版本。如果BVT不通過，測(cè)試人員不能拿到新的版本進(jìn)行測(cè)試。

　　冒煙測(cè)試，該概念來源于硬件生產(chǎn)領(lǐng)域，一般通過給制造出來的電路板加電，看電板是否通電，如果設(shè)計(jì)不合理，則可能在通電的同時(shí)馬上冒出煙，電路板不可用，因此沒有必要進(jìn)行下一步的檢測(cè)。

　　那么該概念應(yīng)用于軟件測(cè)試，其實(shí)意義也一致。就是主要驗(yàn)證主功能，如果主功能都行不通，那就沒有驗(yàn)證下去的必要，直接把編譯版本退回給開發(fā)人員修改。

　　需要注意的是，冒煙測(cè)試的測(cè)試用例應(yīng)該是隨著開發(fā)的深入而不斷演進(jìn)的。

每日構(gòu)建的基本流程

　　程序模塊的集成問題是一個(gè)導(dǎo)致開發(fā)進(jìn)度受阻的常見原因。缺陷也往往在集成階段才集中出現(xiàn)的，尤其是那些接口設(shè)計(jì)不夠好的軟件。

　　那么解決集成問題的最后辦法就是盡早集成，持續(xù)地集成，小版本集成。通過每日構(gòu)建可以達(dá)到持續(xù)集成，小版本集成以及版本集成驗(yàn)證的目的。

　　每日構(gòu)建就是每天定時(shí)把所有的文件編譯，連接，組成一個(gè)可執(zhí)行的程序的過程。

　　通常把每日構(gòu)建放在晚上，利用空余時(shí)間自動(dòng)進(jìn)行，因此也叫每晚自動(dòng)構(gòu)建。簡(jiǎn)單的流程如下圖

通過每日構(gòu)建來規(guī)范代碼管理

　　每日構(gòu)建除了可以解決部分版本集成的問題外，還可以對(duì)程序員的源代碼簽入簽出行為做出規(guī)范性約束。

　　大家都知道，如果程序員沒有遵循一定的規(guī)范簽入，簽出源代碼，就很可能導(dǎo)致其他程序員的代碼模塊失效或者混亂。一個(gè)正確而謹(jǐn)慎的做法應(yīng)該是每次簽入自己修改的代碼之前，先獲取所有新版本并把所有代碼編譯通過，確保不會(huì)影響別人的代碼時(shí)才簽入，否則必須先把問題解決掉。

　　每日構(gòu)建是一個(gè)提高士氣的機(jī)制，每天項(xiàng)目組的所有人都能看到構(gòu)建出來的新版本增加了哪些新特性，看到能工作的產(chǎn)品，并且每天都比前一天多一些，增強(qiáng)一些，就像看到自己的孩子在茁壯地成長(zhǎng)著，給所有人一種信心和鼓舞。

測(cè)試的記錄和跟蹤

　　bug的質(zhì)量：所謂質(zhì)量，是指測(cè)試人員錄入bug描述的清晰度，越容易理解的bug，質(zhì)量越高。開發(fā)跟測(cè)試之間也不用花費(fèi)大量時(shí)間去理解該bug如何修改合適。

如何錄入一個(gè)合格的bug

發(fā)現(xiàn)問題的版本

　　一般來說，在不同版本發(fā)現(xiàn)同一個(gè)Bug,有可能是由于不同原因產(chǎn)生的。所以如果在版本1.1修改完該Bug后，在版本1.2又發(fā)現(xiàn)了該bug，不應(yīng)該把版本1.1的bug激活，而應(yīng)該重新錄入一個(gè)bug，版本改為1.2。因?yàn)檫@是一個(gè)新增的Bug,測(cè)試人員需要重新驗(yàn)證，統(tǒng)計(jì)。如果激活上一個(gè)bug也可能造成質(zhì)量統(tǒng)計(jì)時(shí)的漏算。

問題出現(xiàn)的環(huán)境

　　問題出現(xiàn)的環(huán)境包括操作系統(tǒng)環(huán)境、軟件配置環(huán)境，有時(shí)候還需要包括系統(tǒng)資源的情況，因?yàn)橛行╁e(cuò)誤只有在資源不足時(shí)才出現(xiàn)。

　　由于開發(fā)環(huán)境與測(cè)試環(huán)境存在差異，往往導(dǎo)致有些問題只有在測(cè)試環(huán)境下才能出現(xiàn)。例如開發(fā)環(huán)境中使用的某些第三方組件在測(cè)試環(huán)境沒有注冊(cè)。這時(shí)測(cè)試人員應(yīng)該把這些差異寫清楚，以便開發(fā)人員在重新問題和進(jìn)入調(diào)試之前把環(huán)境設(shè)置好。

問題重現(xiàn)步驟

　　描述問題出現(xiàn)的操作步驟。要盡量把操作步驟縮減到必須執(zhí)行才能重新錯(cuò)誤的幾個(gè)步驟。別浪費(fèi)步驟在無關(guān)問題上面，影響重現(xiàn)進(jìn)度。

預(yù)期行為的描述

　　需要讓開發(fā)人員知道什么才是正確的。有些描述不清的，如“編輯單據(jù)時(shí)，列表中不出現(xiàn)日期信息”，那么你是希望他出現(xiàn)日期呢，還是不出現(xiàn)日期呢？一般描述就加上XX應(yīng)該XX或者SS不應(yīng)該SS。

錯(cuò)誤行為的描述

　　描述問題的現(xiàn)象。例如“程序拋出異常信息如下。。。”，如實(shí)反映，不要夸大。

除了以上，還有嚴(yán)重程度，優(yōu)先級(jí)別，出現(xiàn)模塊，缺陷類型，發(fā)現(xiàn)日期等等，一般在缺陷管理系統(tǒng)中都會(huì)提示填寫。

BUG描述中應(yīng)該注意的幾個(gè)問題

1、不要出現(xiàn)錯(cuò)別字

　　我們是做測(cè)試的，就是要把錯(cuò)誤找出來，我們是找BUG而不是創(chuàng)建BUG。

2、不要把幾個(gè)BUG錄入到同一個(gè)ID

　　最好一個(gè)問題一個(gè)ID，比如創(chuàng)建一個(gè)客戶，沒有做非空校驗(yàn)，保存也出現(xiàn)異常。這時(shí)候需要分為2個(gè)ID錄，雖然在同個(gè)模塊同個(gè)界面，但是分開錄有利于后面可以清晰地跟蹤所有BUG的狀態(tài)，并且有利于缺陷的統(tǒng)計(jì)和質(zhì)量的衡量。

3、附加必要的截圖和文件

　　有截圖或者文件，并且在截圖上框出出錯(cuò)的位置，標(biāo)記上問題，能讓開發(fā)更快速地定位到錯(cuò)誤，高效率地修改。

4、錄入完一個(gè)BUG后自己讀一遍

　　如果一個(gè)BUG錄完之后連自己都讀不通，那么別想開發(fā)人員能修改高質(zhì)量的產(chǎn)品，所以錄完之后自己讀一遍，讀通了之后再進(jìn)行其他的測(cè)試。

如何跟蹤一個(gè)BUG的生命周期

　　創(chuàng)建-打開-修復(fù)（拒絕/延期）-關(guān)閉-激活

如何與開發(fā)人員溝通一個(gè)BUG

　　能讓開發(fā)人員解決最多的BUG的測(cè)試人員是最優(yōu)秀的測(cè)試人員，如果能正確地，高質(zhì)量地錄入一個(gè)BUG，那已經(jīng)跟開發(fā)人員溝通了一大半關(guān)于BUG的信息，但是有些BUG字面會(huì)說不清楚，所以我們就得自己找開發(fā)談，最好演示一遍給開發(fā)看。注意的是，跟開發(fā)講BUG的時(shí)候一定要語氣平和，千萬不要趾高氣揚(yáng)，指責(zé)開發(fā)等語氣，因?yàn)槊總€(gè)人都是不喜歡收拾爛攤子的，所以我們需要用技巧地跟開發(fā)溝通，比如說麻煩了，辛苦了之類的，這樣的話，開發(fā)會(huì)更樂意修改這個(gè)BUG，心情好修改當(dāng)然質(zhì)量高了。

回歸測(cè)試

　　一般如果系統(tǒng)有做其他的改動(dòng)時(shí)，可能會(huì)影響到其他功能的使用。

　　比如我創(chuàng)建一個(gè)客戶,發(fā)現(xiàn)了保存功能有異常，于是提了個(gè)BUG。開發(fā)修改完成，我們驗(yàn)證的時(shí)候，保存功能可能正常了，但是輸入功能可能因?yàn)榇舜蔚男薷亩绊懥恕?/span>

　　但是一般回歸測(cè)試不可能整個(gè)系統(tǒng)的功能都全部回歸，所以一般采用風(fēng)險(xiǎn)性的測(cè)試策略進(jìn)行。

測(cè)試總結(jié)和報(bào)告

　　如果說測(cè)試用例是測(cè)試人員的工作直接反應(yīng)方式，那么測(cè)試報(bào)告就是該項(xiàng)任務(wù)所有測(cè)試組的一個(gè)工作直接反應(yīng)。

　　閱讀測(cè)試報(bào)告的人包括產(chǎn)品部，開發(fā)部，測(cè)試部，以及各個(gè)部門的老大。

　　測(cè)試報(bào)告是可以直接提現(xiàn)測(cè)試工作的一種表現(xiàn)形式，而且簡(jiǎn)單易懂，不像缺陷列表又多又細(xì)又專業(yè)。通過測(cè)試報(bào)告，不僅可以反應(yīng)近期軟件的狀態(tài)，還有利于分析系統(tǒng)的開發(fā)趨勢(shì)。

缺陷分類報(bào)告

　　缺陷分類報(bào)告是測(cè)試報(bào)告的重要組成部分，主要分為以下幾類。

缺陷類型分類報(bào)告

　　主要描述缺陷的類型分布情況，比如界面規(guī)范性，功能缺陷，數(shù)據(jù)顯示等等。一般使用餅圖或者柱狀圖畫出。

　　

缺陷區(qū)域分布報(bào)告

　　主要描述缺陷在不同功能模塊出現(xiàn)的情況。有助于開發(fā)分析為什么缺陷集中在某個(gè)功能模塊，如果某個(gè)功能模塊存在大量的BUG，就得分析是否這個(gè)功能的某個(gè)工作流接口設(shè)計(jì)不合理。也可用柱狀圖或者餅圖表示。

　　

缺陷狀態(tài)分布報(bào)告

　　主要描述缺陷中各種狀態(tài)的比例情況，例如open,fixed,closed,reopen,rejected,delay的BUG分別占了百分之幾。這些信息有助于評(píng)估測(cè)試和產(chǎn)品的現(xiàn)狀。

• 　　如果open的BUG比例太高，則可能要考慮讓開發(fā)人員停止開發(fā)新功能，先集中精力修改BUG。
• 　　如果fixed狀態(tài)的BUG很多，則考慮讓測(cè)試人員停止測(cè)試新功能，先集中精力做一次回歸測(cè)試把修改的BUG驗(yàn)證完。
• 　　如果closed的BUG比較多，則意味著功能模塊趨于穩(wěn)定。
• 　　如果reopen的BUG比較多，則需要分析開發(fā)人員的開發(fā)狀態(tài)，是什么原因造成缺陷修改不徹底。
• 　　如果rejected的bug比例高，則要看開發(fā)人員與測(cè)試人員是否對(duì)需求存在理解上的分歧。
• 　　如果Delay的BUG比例過高，則要考慮這個(gè)版本是否滿足客戶的要求，是否缺少了太多應(yīng)該這個(gè)版本出現(xiàn)的功能特性。

　　缺陷狀態(tài)分布報(bào)告一般使用餅圖或柱形圖表示。

?

　　還有其他的缺陷分類報(bào)告可以寫在測(cè)試報(bào)告中，例如，嚴(yán)重級(jí)別分類報(bào)告、優(yōu)先級(jí)別分類報(bào)告、負(fù)責(zé)人分類報(bào)告、發(fā)現(xiàn)人分類報(bào)告、版本分類報(bào)告等。但是要注意這些分類報(bào)告是用來說明問題的，而不是用來指責(zé)別人。

缺陷趨勢(shì)報(bào)告

缺陷趨勢(shì)報(bào)告主要描述一段時(shí)間內(nèi)的缺陷情況，如果項(xiàng)目管理比較規(guī)范，缺陷管理和測(cè)試流程比較正常，從缺陷趨勢(shì)報(bào)告還可以估算出軟件可發(fā)布的日期。

典型缺陷和BUG模式

　　軟件開發(fā)有設(shè)計(jì)模式，測(cè)試其實(shí)也有模式存在，需要測(cè)試人員進(jìn)行總結(jié)和歸納。從經(jīng)常重復(fù)出現(xiàn)的BUG中學(xué)習(xí)，總結(jié)出BUG模式。

　　要成為經(jīng)典缺陷，必須滿足以下條件：

• 重復(fù)出現(xiàn)、經(jīng)常出現(xiàn)
• 能代表某種類型的錯(cuò)誤
• 能通過相對(duì)固定的測(cè)試方法或手段來發(fā)現(xiàn)這些錯(cuò)誤

總結(jié)這些典型缺陷出現(xiàn)的現(xiàn)象、出現(xiàn)的原因以及測(cè)試的方法，就成為一種BUG模式。

　　提煉BUG模式的一般步驟：

　　1、分析缺陷報(bào)告，找出經(jīng)常出現(xiàn)的BUG類型。

　　2、分析BUG的根源，找出BUG產(chǎn)生的深層次原因。

　　3、分析找到BUG的方法，總結(jié)如何才能每次都發(fā)現(xiàn)這種類型的BUG。

客觀全面的測(cè)試報(bào)告

　　測(cè)試需要以一個(gè)完美的方式結(jié)束，編寫一份出色的測(cè)試總結(jié)報(bào)告可為一個(gè)完美的測(cè)試過程劃上一個(gè)完美的句號(hào)。

　　一份測(cè)試報(bào)告應(yīng)該包括測(cè)試的資源使用情況：投入了多少測(cè)試人員，多長(zhǎng)時(shí)間，執(zhí)行了多少測(cè)試用例，覆蓋了多少功能模塊等等。

?

轉(zhuǎn)載于:https://www.cnblogs.com/xiaoqingSister/p/5471156.html

總結(jié)

以上是生活随笔為你收集整理的入门级----测试的执行、环境的搭建、每日构建、测试记录和跟踪、回归测试、测试总结和报告...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。