軟件測試操作指南和規(guī)范

1、軟件測試操作指南1 概述1.1 目的為確保軟件產(chǎn)品質(zhì)量，使產(chǎn)品能夠順利交付和通過驗(yàn)收，同時(shí)提升測試組的工作秩序與效率，特編寫本文檔，以作參考。1.2 對(duì)象范圍本文檔適用于測試人員在項(xiàng)目不同階段（內(nèi)網(wǎng)環(huán)境測試及正式環(huán)境測試）的功能測試。2 職責(zé)Ø 配合產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理了解需求Ø 編寫測試計(jì)劃、測試方案、搭建測試環(huán)境Ø 完成所承擔(dān)的測試任務(wù)，并按要求提交Bug、優(yōu)化建議等到Bug管理平臺(tái)（禪道）。Ø 配合開發(fā)人員修復(fù)Bug、回歸Bug。Ø 配合項(xiàng)目的順利發(fā)布。3 測試流程3.1 前期準(zhǔn)備3.1.1 需求詳細(xì)的需求是測試的重點(diǎn)依據(jù)， 因此測試人員需

2、提前介入，充分了解需求。3.1.2 原型與設(shè)計(jì)原型，是需求和功能的具象化表達(dá)，它能幫助測試人員更形象的了解各個(gè)需求與功能的實(shí)現(xiàn)。UI設(shè)計(jì)圖，是在原型的基礎(chǔ)上綜合考慮產(chǎn)品目標(biāo)、功能需求場景、用戶體驗(yàn)等因素后設(shè)計(jì)出的產(chǎn)品各版塊、界面和元素。是測試最終的參考依據(jù)。因此測試人員必須對(duì)認(rèn)真閱讀，真正弄懂系統(tǒng)需求和詳細(xì)設(shè)計(jì)。3.2 制訂測試計(jì)劃與方案在測試之前，測試人員需根據(jù)項(xiàng)目需求制定測試計(jì)劃與方案，其內(nèi)容應(yīng)包括以下內(nèi)容： Ø 測試時(shí)間安排；Ø 測試人員安排；Ø 測試環(huán)境、工具和測試軟件等；Ø 測試用例、測試數(shù)據(jù)和預(yù)期的結(jié)果。3.3 編寫測試用例測試點(diǎn)將測試模塊分

3、解成多個(gè)功能點(diǎn)，測試點(diǎn)應(yīng)涵蓋功能點(diǎn)，也涵蓋了正常測試和異常測試。輸入數(shù)據(jù) 輸入數(shù)據(jù)包括： 界面輸入數(shù)據(jù) 數(shù)據(jù)庫的初始數(shù)據(jù) 其他外部輸入數(shù)據(jù)等輸入數(shù)據(jù)盡可能全面詳細(xì)列出，并具有典型性。全面是指：數(shù)據(jù)能達(dá)到模塊所涉及的全部功能，典型是指這個(gè)數(shù)據(jù)能充分反映功能特點(diǎn)。測試描述 測試描述，即測試過程中的具體操作步驟，包括：（1） 前置條件：測試執(zhí)行時(shí)所必須的條件，即發(fā)生這個(gè)用例的前提條件；（2） 所執(zhí)行的動(dòng)作：包括鼠標(biāo)、鍵盤、加載外部數(shù)據(jù)等操作；（3） 系統(tǒng)的反應(yīng)：包括光標(biāo)定位、光標(biāo)聚焦、顯示字段值、按鈕的狀態(tài)、系統(tǒng)提示和消息等。預(yù)期輸出數(shù)據(jù) 按準(zhǔn)備的輸入數(shù)據(jù)和設(shè)計(jì)的測試過程，模塊應(yīng)輸出的數(shù)據(jù)。 輸出數(shù)

4、據(jù)包括：屏幕輸出數(shù)據(jù)、輸出到數(shù)據(jù)庫的數(shù)據(jù)、輸出到其他外部地方的數(shù)據(jù)，并指出斷點(diǎn)結(jié)果或最終結(jié)果。3.4 功能測試功能測試就是對(duì)產(chǎn)品的各功能進(jìn)行驗(yàn)證，根據(jù)功能測試用例，逐項(xiàng)測試，檢查產(chǎn)品是否達(dá)到用戶要求的功能。3.4.1 Web功能測試在Web功能測試過程中，常用的測試方法如下3.4.1.1 鏈接測試測試每一個(gè)鏈接是否都有對(duì)應(yīng)的頁面，并且頁面之間切換正確。3.4.1.2 表單測試當(dāng)用戶在web應(yīng)用系統(tǒng)上向服務(wù)器提交信息時(shí)，就需要使用表單操作，在表單測試過程中，一般關(guān)注N點(diǎn)（1） 格式規(guī)范：空格檢查、輸入法半角全角檢查、密碼檢查、字符串長度檢查、字符類型檢查、標(biāo)點(diǎn)符號(hào)檢查、特殊字符檢查、中文字符處理

5、等；（2） 提交信息完整性：比如，用戶注冊(cè)，登錄，信息變更等等；這種情況下，我們必須測試提交信息的完整性，以檢驗(yàn)提交給服務(wù)器的數(shù)據(jù)的正確性 ；（3） 考慮常理邏輯，如：出生日期、工作年限是否恰當(dāng)，填寫手機(jī)號(hào)碼的表單是否符合號(hào)碼邏輯，所在地省份城市區(qū)域間的匹配等，如果設(shè)定使用默認(rèn)值，也需要測試。3.4.1.3 導(dǎo)航測試 所謂的導(dǎo)航測試，就是在不同的頁面跳轉(zhuǎn)之間，或者按鈕，對(duì)話框，列表以及窗口等，通過考慮這些因素，去判斷一個(gè)應(yīng)用系統(tǒng)是否易于導(dǎo)航：是否直觀？系統(tǒng)的主要模塊是否可以通過主頁訪問或者到達(dá)？站點(diǎn)是否需要站內(nèi)地圖或者搜索引擎等其他幫助？web系統(tǒng)導(dǎo)航的另外一個(gè)重點(diǎn)就是頁面結(jié)構(gòu)、導(dǎo)航、菜單、風(fēng)

6、格等是否一致，確保用戶可以憑借直覺或者簡單的判斷就可以找到自己想要的內(nèi)容。3.4.1.4 圖形測試即UI界面測試，其中包括圖片、動(dòng)畫、邊框、顏色、字體、背景、按鈕等等。其中要考慮的幾個(gè)重點(diǎn)：（1） 界面是否符合系統(tǒng)現(xiàn)有邏輯，是否符合需求，（2）圖片有明確的用途、代表，如：常見的分享按鈕，是否使用準(zhǔn)確，讓用戶看圖即能知其意（3）頁面整體風(fēng)格是否和系統(tǒng)的用途一致（4）背景顏色，字體，搭配是否合理（5）整體界面測試，常說的用戶體驗(yàn)。用戶瀏覽時(shí)是否感覺舒適，整體風(fēng)格等等3.4.1.5 相關(guān)性測試（1）功能相關(guān)性：刪除/增加一項(xiàng)會(huì)不會(huì)對(duì)其他項(xiàng)產(chǎn)生影響，如果產(chǎn)生影響，這些影響是否都正確。常見的情況是，增加

7、某個(gè)數(shù)據(jù)記錄以后，如果該數(shù)據(jù)記錄某個(gè)字段內(nèi)容較長，可能會(huì)在查詢的時(shí)候讓數(shù)據(jù)列表變形；（2）數(shù)據(jù)相關(guān)性：下拉列表默認(rèn)值檢查，下拉列表值檢查，如果某個(gè)列表的數(shù)據(jù)項(xiàng)依賴于其他模塊中的數(shù)據(jù)，同樣需要檢查，比如，某個(gè)數(shù)據(jù)如果被禁用了，可能在引用該數(shù)據(jù)項(xiàng)的列表中不可見；（3）內(nèi)容相關(guān)性：主要用來檢測web系統(tǒng)提供信息的準(zhǔn)確性、相關(guān)性。比如：商品的價(jià)格，文字描述；信息的準(zhǔn)確性，是否有拼寫錯(cuò)誤等。 3.4.1.6 兼容性測試Web兼容性測試，主要指瀏覽器兼容性。需適配的瀏覽器及其優(yōu)先順序?yàn)椋篒E 8.0+ 、360瀏覽器、chrome瀏覽器、Firefox瀏覽器、搜狗瀏覽器、QQ瀏覽器3.4.2 App功能測

8、試App測試包括android測試、iOS 測試，APP測試的時(shí)候，建議讓開發(fā)打好包APK和IPA安裝包，測試人員自己安裝應(yīng)用，進(jìn)行測試。在測試過程中需要注意的測試點(diǎn)如下：安裝和卸載（1） 應(yīng)用是否可以在IOS不同系統(tǒng)版本或android不同系統(tǒng)版本上安裝（iOS 系統(tǒng)需適配iOS 8.0+ 、android需適配4.4 +）（2）軟件安裝后是否可以正常運(yùn)行，安裝過程中是否可以取消，安裝空間不足時(shí)是否有相應(yīng)提示；（3）是否可以正常卸載，若卸載過程中出現(xiàn)死機(jī)，斷電，重啟等意外的情況，待環(huán)境恢復(fù)后是否可以正確卸載，卸載是否支持取消功能，單擊取消后軟件卸載情況是否正常。運(yùn)行（1）測試APP安裝完成后

9、，是否可以正常打開軟件APP運(yùn)行時(shí)，是否有加載圖示（2）APP的速度是可以讓人接受，切換是否流暢 （3）用戶登錄狀態(tài)太久，session會(huì)過期，會(huì)出現(xiàn)“雖然是登錄狀態(tài)，系統(tǒng)會(huì)提示用戶沒有登錄。異常測試異常指非正常性用戶操作，如：手機(jī)斷網(wǎng)、中途電話接入、手機(jī)斷電等異常情況。（1）對(duì)于無網(wǎng)絡(luò)時(shí)，是否可以瀏覽本地?cái)?shù)據(jù)，不能獲取數(shù)據(jù)時(shí)，能否給出友好提示，離線獲取不到數(shù)據(jù)時(shí)，離線后又連上網(wǎng)，能否重新獲取數(shù)據(jù)。（2）退出APP再開啟APP時(shí)，是否能正常瀏覽；切換到后臺(tái)再切回APP應(yīng)用時(shí)可以正常瀏覽；鎖屏后再解鎖回到應(yīng)用前臺(tái)可以正常瀏覽；（3）正在操作App時(shí)，突然電話接入或突然離線，是否對(duì)操作有影響等。（

10、4）反復(fù)操作某個(gè)功能，不斷點(diǎn)擊，刷新時(shí)，是否會(huì)閃退數(shù)據(jù)更新（1）確認(rèn)有數(shù)據(jù)更新后，哪些地方需要手動(dòng)刷新，哪些地方需自動(dòng)刷新。（2）確認(rèn)從后臺(tái)切換回前臺(tái)時(shí)，哪些頁面需要進(jìn)行數(shù)據(jù)更新（3）根據(jù)需求和邏輯，確認(rèn)哪些數(shù)據(jù)是從服務(wù)端請(qǐng)求實(shí)時(shí)響應(yīng)，哪些是緩存到本地的數(shù)據(jù)。軟件更新當(dāng)客戶端有新版本時(shí)，有更新提示軟件更新一定要測，確保android軟件更新可以正確更新新版本，且安裝運(yùn)行正確。（iOS軟件更新必須從蘋果應(yīng)用商店App Store中更新 ) 用戶取消版本更新時(shí)，老版本可以正常使用，但是下次啟動(dòng)應(yīng)用時(shí)，仍出現(xiàn)更新提提示。當(dāng)有新版本時(shí)，不刪除客戶端的情況下，直接更新檢查是否能正常更新，且更新后客戶端的

11、功能是否最新版本（正常來講不用強(qiáng)制刪除本地客戶端可以正常更新）網(wǎng)絡(luò)環(huán)境（1）測試G、，wifi 網(wǎng)絡(luò)下應(yīng)用運(yùn)應(yīng)的速度（2）內(nèi)網(wǎng)測試時(shí)，選擇到外網(wǎng)操作是否有異常處理（3）網(wǎng)絡(luò)不好時(shí) ， 提交數(shù)據(jù)是否一直處理提交中，是否會(huì)有延遲，數(shù)據(jù)交換失敗是否會(huì)有提醒（4）有網(wǎng)到無網(wǎng)再到有網(wǎng)環(huán)境時(shí)，數(shù)據(jù)是否可以自動(dòng)恢復(fù)，正常加載3.4.1.7 其他鏈接測試、導(dǎo)航測試、圖片測試、內(nèi)容測試、UI測試等各項(xiàng)功能測試，與Web功能測試類似，此處不做詳細(xì)描述。3.5 回歸測試回歸測試是指開發(fā)人員修復(fù)bug后，重新進(jìn)行測試以確認(rèn)修改完成，以及沒有引入新的錯(cuò)誤或?qū)е缕渌K錯(cuò)誤?；貧w測試過程如下：(1) 準(zhǔn)確辨別出系統(tǒng)被修改

12、的部分；(2) 從測試用例庫中，排除所有不再適用的測試用例，如果必要，適當(dāng)增加新用例，形成新的測試用例庫。(3) 依據(jù)新的測試用例，執(zhí)行修改后的系統(tǒng)。3.6 版本發(fā)布版本發(fā)布的準(zhǔn)則系統(tǒng)經(jīng)過所有測試項(xiàng)后，必須符合以下標(biāo)準(zhǔn)n 致命錯(cuò)誤：無n 功能錯(cuò)誤：無n 功能及界面小Bug：項(xiàng)目經(jīng)理、測試負(fù)責(zé)人審核通過n 優(yōu)化及建議：項(xiàng)目經(jīng)理、測試負(fù)責(zé)人審核通過若不滿足以上要求，視為不合格。版本發(fā)布流程 3.7 測試流程圖4 Bug(Bug)管理4.1 Bug管理工具測試組目前使用的Bug管理工具是“禪道”。禪道是集產(chǎn)品管理、項(xiàng)目管理、質(zhì)量管理、文檔管理、組織管理和事務(wù)管理于一體的一款開源的研發(fā)項(xiàng)目管理。測試組

13、使用禪道提Bug、管理Bug、回歸Bug以及記錄和執(zhí)行測試用例。下圖為禪道測試界面。禪道使用網(wǎng)址：:8086/zentao 禪道的詳細(xì)使用手冊(cè)見：l4.2 Bug的定義及其基本屬性Bug是指在系統(tǒng)開發(fā)過程中的針對(duì)系統(tǒng)產(chǎn)品和開發(fā)過程中的問題，這些問題已經(jīng)影響或可能會(huì)影響軟件產(chǎn)品的質(zhì)量。Bug應(yīng)該具備以下屬性，也就是往Bug管理庫或者Bug列表中提交的Bug應(yīng)該具備以下屬性：屬性名稱描述Bug標(biāo)識(shí)(ID)標(biāo)記某個(gè)Bug的一組符號(hào)，每個(gè)Bug必須有一個(gè)唯一的標(biāo)識(shí)Bug類型根據(jù)Bug的自然屬性劃分的Bug種類Bug驗(yàn)證程度因Bug引起的故障對(duì)軟件產(chǎn)品的影響程度Bug所處的模塊或子系統(tǒng)Bug分步的模塊或

14、子系統(tǒng)Bug出現(xiàn)幾率指發(fā)現(xiàn)錯(cuò)誤的幾率Bug的重現(xiàn)步驟詳細(xì)的Bug重現(xiàn)步驟附件與Bug相關(guān)的附件（截圖、附件、用例等）備注對(duì)Bug的其他描述4.3 Bug分類根據(jù)Bug的定義，將Bug分為如下列：（1）功能錯(cuò)誤（bug）：功能上的錯(cuò)誤性bug（2）小錯(cuò)誤/細(xì)節(jié)：小錯(cuò)誤，不影響總體流程和功能（3）優(yōu)化建議：功能已滿足但待改善，屬于改良性建議（4）需求變動(dòng)：原有的需求基礎(chǔ)上的更改（5）設(shè)計(jì)Bug：UI設(shè)計(jì)Bug4.4 Bug嚴(yán)重性定義Bug的嚴(yán)重程度反映的是對(duì)Bug的發(fā)現(xiàn)對(duì)象可能造成的影響或后果來定義的。Bug等級(jí)Bug性質(zhì)描 述1致命錯(cuò)誤系統(tǒng)崩潰、系統(tǒng)死鎖以及產(chǎn)品的基本功能有致命影響的Bug等2嚴(yán)

15、重Bug嚴(yán)重錯(cuò)誤，嚴(yán)重影響系統(tǒng)的使用3一般Bug次要錯(cuò)誤、布局不合理、文字錯(cuò)誤等4微小Bug基本不影響系統(tǒng)的運(yùn)行和功能的實(shí)現(xiàn)。但是與標(biāo)準(zhǔn)、規(guī)范和定義不一致建議優(yōu)化不在定義、標(biāo)準(zhǔn)、范圍的定義和約束之內(nèi)，但是從提出者來看是需要完善的建議4.5 Bug優(yōu)先級(jí)定義Bug優(yōu)先級(jí)描 述1需要立刻進(jìn)行修改2一天到兩天之內(nèi)必須修改3Bug需要正常排隊(duì)等待修復(fù)或列入軟件發(fā)布清單4留到組后解決，如果項(xiàng)目的進(jìn)度跟緊張可以在產(chǎn)品發(fā)布以前不解決4.6 Bug狀態(tài)定義Bug狀態(tài)描 述激活測試人員提交一個(gè)新的Bug，等待開發(fā)人員修改打回開發(fā)人員并未重新問題，或要求Bug的報(bào)告者再次對(duì)Bug進(jìn)行說明已分派指Bug已經(jīng)分派給相

16、關(guān)開發(fā)人員，等待修改已確認(rèn)指Bug已被相關(guān)開發(fā)人員卻，等待排期修改已解決指Bug已被修改，等待測試人員回歸驗(yàn)證。關(guān) 閉測試人員回歸驗(yàn)證Bug，并已經(jīng)修復(fù)重新激活測試人員回歸驗(yàn)證，但Bug并沒有修改正確4.7 Bug管理流程5 處理機(jī)制5.1 退回機(jī)制若在測試過程中發(fā)生如下情況，可將系統(tǒng)退回到相關(guān)開發(fā)負(fù)責(zé)人員：（1）經(jīng)過測試后，發(fā)現(xiàn)與需求不符，或功能項(xiàng)存在較大的差異（2）單一功能模塊，測試過程中發(fā)現(xiàn)Bug較多或者無法繼續(xù)進(jìn)行下一步測試，繼續(xù)測試無意義（3）測試過程中，頻繁死機(jī)或系統(tǒng)崩潰5.2 異常情況處理機(jī)制非正常情況下，需要進(jìn)行特別處理的情形，此情況需要主管領(lǐng)導(dǎo)批準(zhǔn)、簽字確認(rèn)：（1）上線時(shí)間緊急的情況下，未經(jīng)測試部充分測試就發(fā)布到外網(wǎng)環(huán)境（2）產(chǎn)品經(jīng)理尚未進(jìn)行驗(yàn)收測試就需要上線5.3 報(bào)告機(jī)制若出現(xiàn)以下情況，需要及時(shí)向部門領(lǐng)導(dǎo)和項(xiàng)目經(jīng)理匯報(bào)的情況：（1）測試后期出現(xiàn)重大邏輯錯(cuò)誤，修改測試影響上線時(shí)間（2） 測試過程中用戶需求出現(xiàn)重大變更（3） 測試負(fù)責(zé)人定期匯報(bào)測試情況6 測試完成的標(biāo)準(zhǔn)6.1 被測試出的、在軟件錯(cuò)誤級(jí)別分類中定義的：Ø 一級(jí)Bug，致命錯(cuò)誤，100%得到修改并且回歸通過Ø 二級(jí)Bug，嚴(yán)重錯(cuò)誤，100%得到修改并且回歸通