簡介GJB軟件測試報(bào)告模版是一套基于GJB標(biāo)準(zhǔn)編寫的文檔范本適用于軍工軟件及強(qiáng)質(zhì)量控制項(xiàng)目可幫助測試人員和管理者建立結(jié)構(gòu)完整、要素齊全的測試報(bào)告框架解決報(bào)告編寫不規(guī)范、關(guān)鍵信息遺漏等問題。資源包內(nèi)包含1個(gè)docx格式的Word模板文件僅277KB輕巧易編輯下載后可直接套用。該模版已有1340人學(xué)習(xí)/下載在測試模板類資源中有一定熱度。模版完整覆蓋了范圍標(biāo)識(shí)、系統(tǒng)概述、文檔概述、引用文檔、測試結(jié)果概述、詳細(xì)測試結(jié)果、測試日志和注釋等章節(jié)并對編寫要點(diǎn)作了細(xì)致說明例如標(biāo)識(shí)部分要求寫明系統(tǒng)名稱、版本號(hào)等測試結(jié)果概述要求給出總體評估、遺留缺陷及影響、測試環(huán)境影響分析、改進(jìn)建議詳細(xì)測試結(jié)果需記錄每個(gè)測試用例的表現(xiàn)并針對遇到的問題和與用例不一致情況提供描述規(guī)范測試日志則強(qiáng)調(diào)按時(shí)間順序記錄測試事件。這些設(shè)計(jì)既保證了報(bào)告的可追溯性和完整性也降低了編寫者的整理成本值得相關(guān)領(lǐng)域從業(yè)者參考。1. GJB軟件測試報(bào)告模版先補(bǔ)追溯鏈再填表格很多團(tuán)隊(duì)在裝備軟件交付節(jié)點(diǎn)上被一份測試報(bào)告攔在門外內(nèi)容填得滿滿的評審卻指出用例跟需求對不上、缺陷描述沒有證據(jù)、結(jié)論下得太滿。這不是文筆問題而是沒看懂GJB軟件測試報(bào)告模版的真正作用。它不只是把測試過程留個(gè)痕跡而是提供一套把需求、用例、缺陷、結(jié)論串成證據(jù)鏈的固定格式讓審查方有據(jù)可查、可追溯、可復(fù)現(xiàn)。這份模版主要面向軟件配置項(xiàng)測試、系統(tǒng)測試和第三方測評場景適合測試工程師、質(zhì)量工程師和負(fù)責(zé)交付文檔的開發(fā)者。你要做的不是填表格而是跟著它的章節(jié)結(jié)構(gòu)把整個(gè)測試過程重新梳理一遍。下面按拿模版、建追溯鏈、填寫、避坑的順序把路徑講清楚。2. 認(rèn)清GJB軟件測試報(bào)告模版適用場景、文檔骨架與版本裁剪2.1 哪些項(xiàng)目必須出這份報(bào)告從承研到測評的流轉(zhuǎn)場景GJB軟件測試報(bào)告模版通常出現(xiàn)在裝備軟件研制流程的測試與測評環(huán)節(jié)。承研單位完成內(nèi)部測試后按模版編寫測試報(bào)告第三方測評機(jī)構(gòu)完成抽測后同樣按這套格式出報(bào)告報(bào)告隨軟件一起歸檔供后續(xù)審查、定型、驗(yàn)收使用。適用對象很明確軟件配置項(xiàng)、子系統(tǒng)、帶嵌入式控制邏輯的軟件以及這些軟件在系統(tǒng)聯(lián)調(diào)之后的測試活動(dòng)。凡是需要向評審方證明軟件確實(shí)按需求實(shí)現(xiàn)、確實(shí)經(jīng)過了驗(yàn)證的項(xiàng)目這份報(bào)告基本繞不開。寫這份報(bào)告的角色不同關(guān)注點(diǎn)也不同。承研方的測試人員要自證測試過程真實(shí)最怕報(bào)告里出現(xiàn)說不清的字段第三方測評人員要拿模版核對測試是否滿足計(jì)劃要求最關(guān)心用例覆蓋是否完整評審組通常不看代碼只看報(bào)告和現(xiàn)場記錄因此報(bào)告里每一個(gè)結(jié)論都必須能反查到支撐證據(jù)。理解了這三個(gè)角色的視角就知道為什么要花力氣把編號(hào)、版本、環(huán)境這些細(xì)節(jié)寫死。還有一層關(guān)系容易被新手忽略測試報(bào)告不是獨(dú)立文檔它是需求鏈的收尾環(huán)節(jié)。上游是需求規(guī)格說明和測試計(jì)劃下游是測試記錄和缺陷單。報(bào)告里大量字段的作用就是把手頭的測試活動(dòng)掛到這條鏈上。所以我拿到模版的第一步從來不是打開編輯軟件開始敲字而是先把上游文檔找齊確認(rèn)需求編號(hào)、版本號(hào)、測試計(jì)劃條目都對得上。這一步做扎實(shí)后面填表才不會(huì)出現(xiàn)編號(hào)對不上的尷尬。2.2 模版的核心骨架測試概述、用例表、結(jié)果分析、結(jié)論把一份GJB軟件測試報(bào)告模版從頭翻到尾章節(jié)順序可能有差異但骨架基本是六塊測試概述、測試環(huán)境、測試用例設(shè)計(jì)、測試執(zhí)行記錄、缺陷報(bào)告、測試結(jié)論。下面這張表列了每個(gè)章節(jié)要回答的問題和常見錯(cuò)誤做填表時(shí)的自檢很方便。章節(jié)回答的問題常見錯(cuò)誤測試概述測了什么、依據(jù)什么、范圍是哪來的照抄需求清單不寫未覆蓋項(xiàng)測試環(huán)境在什么軟硬件組合下測得只寫操作系統(tǒng)和內(nèi)存測試用例設(shè)計(jì)每條需求被哪條用例覆蓋需求編號(hào)斷層、步驟不完整測試執(zhí)行記錄每條用例跑出來的實(shí)際結(jié)果實(shí)際結(jié)果整列寫正常缺陷報(bào)告異常項(xiàng)如何復(fù)現(xiàn)、影響范圍多大復(fù)現(xiàn)步驟缺失、嚴(yán)重級別混亂測試結(jié)論能不能交付、附帶什么條件結(jié)論與缺陷統(tǒng)計(jì)對不上這張表背后有一個(gè)重要的設(shè)計(jì)邏輯模版是按證據(jù)鏈倒著設(shè)計(jì)的。審查方看報(bào)告的順序是先看結(jié)論再查缺陷再追用例最后回到需求。如果報(bào)告前面寫得再漂亮中間的用例表和缺陷單撐不住結(jié)論就是空中樓閣。所以我填報(bào)告的順序和文檔順序是反著的先做用例表再統(tǒng)計(jì)執(zhí)行結(jié)果再整理缺陷最后回頭寫概述和結(jié)論。這樣寫出來的概述每一句話都有出處而不是從需求文檔里抄一段話就交差。補(bǔ)充一個(gè)經(jīng)驗(yàn)測試報(bào)告應(yīng)當(dāng)和測試活動(dòng)同步產(chǎn)生而不是測試結(jié)束之后補(bǔ)寫。如果等到項(xiàng)目收尾才去回憶當(dāng)時(shí)跑出來什么結(jié)果大部分細(xì)節(jié)已經(jīng)模糊報(bào)告里必然會(huì)留下大量含糊表述審查時(shí)一問一個(gè)準(zhǔn)。正確做法是把模版拆成一張張過程記錄表測試執(zhí)行時(shí)順手填寫最后匯總成文。逐節(jié)填寫的過程本質(zhì)上是把分散的記錄歸納成一份有結(jié)構(gòu)的證據(jù)文件。2.3 先確認(rèn)模版版本與裁剪要求再動(dòng)手填同樣是GJB軟件測試報(bào)告模版不同單位手里的版本可能有明顯差異。有的模版帶性能測試章節(jié)有的把它挪到專項(xiàng)測評有的要求每條用例掛測試類型編號(hào)有的只要求需求編號(hào)有的模版里標(biāo)了本表可增加行有的完全封閉。如果不先確認(rèn)版本拿舊模版填新項(xiàng)目等于白寫沒有后悔藥。拿到模版后我一般先確認(rèn)三件事。第一配套的填寫說明或評審檢查單在不在這決定必填項(xiàng)和口徑有沒有官方解釋第二模版支持不支持裁剪如果不支持哪些章節(jié)可以寫不適用而不是直接刪掉整節(jié)第三表結(jié)構(gòu)是否允許擴(kuò)展這決定遇到字段不夠用時(shí)能不能加行、加列。這三條確認(rèn)完后我會(huì)花半小時(shí)把模版拆成一份字段清單用表格逐字段標(biāo)注所屬章節(jié)、字段名、必填還是選填、數(shù)據(jù)類型、填寫來源比如填寫來源是測試執(zhí)行記錄表第幾列還是缺陷單編號(hào)。這個(gè)字段清單是后面所有工作的索引。以前有個(gè)模擬項(xiàng)目X直接沿用了上一個(gè)項(xiàng)目的報(bào)告模版沒發(fā)現(xiàn)新版模版新增了安全性測試一節(jié)直到評審前才被通知要補(bǔ)整章數(shù)據(jù)只能連夜翻原始記錄進(jìn)度整整延后一周。所以我的習(xí)慣是啟動(dòng)測試之前就確認(rèn)模版是受控版本直接從配置管理庫取件而不是從個(gè)人電腦里復(fù)制上一個(gè)項(xiàng)目的文件。模版錯(cuò)了后面的用例、記錄、結(jié)論都得返工越早確認(rèn)越省事。3. 從需求到用例把最關(guān)鍵的測試用例設(shè)計(jì)表填到能追溯3.1 用例表結(jié)構(gòu)一條用例對應(yīng)一條需求在GJB軟件測試報(bào)告模版里測試用例設(shè)計(jì)表是篇幅最大、審查最嚴(yán)的部分。它的核心要求是每一條用例都要能說清自己覆蓋了哪條需求。常見的字段包括用例標(biāo)識(shí)、需求編號(hào)、測試類型、前置條件、測試步驟、輸入數(shù)據(jù)、預(yù)期結(jié)果、實(shí)際結(jié)果和測試結(jié)論。其中最關(guān)鍵的是需求編號(hào)。審查方抽檢時(shí)喜歡挑一條用例先查它對應(yīng)的需求存不存在再追一個(gè)反向問題這個(gè)需求的異常分支你測在哪了如果用例表里找不到這條鏈當(dāng)場斷掉。我的做法是先建需求編號(hào)清單再寫用例。把需求規(guī)格里每個(gè)功能條目編號(hào)化例如REQ-001到REQ-080編號(hào)規(guī)則寫入測試計(jì)劃。然后逐條需求分配用例普通需求至少一條核心需求和復(fù)雜需求按正常流、異常流、邊界值拆成多條。這一步很像給每個(gè)需求開一個(gè)測試賬戶后續(xù)所有執(zhí)行記錄和缺陷都掛在這條編號(hào)下面。等用例表寫完需求清單里不應(yīng)該有沒有用到的編號(hào)用例表里也不該出現(xiàn)清單之外的編號(hào)。需求編號(hào)不是越長越好關(guān)鍵是穩(wěn)定。有的項(xiàng)目在編號(hào)里帶上了模塊名比如NAV-REQ-021看著清楚但需求改版時(shí)模塊合并整個(gè)編號(hào)體系就要重排牽一發(fā)動(dòng)全身。我的建議是用純序號(hào)加前綴模塊信息放單獨(dú)一列不要塞進(jìn)編號(hào)本身。編號(hào)一旦發(fā)布后續(xù)變更走增補(bǔ)流程舊編號(hào)作廢但保留記錄這樣追溯鏈?zhǔn)冀K是完整的。3.2 用可復(fù)制的用例表模版把步驟和預(yù)期結(jié)果寫清楚下面給出一份可以直接復(fù)制到Word里的用例表結(jié)構(gòu)字段覆蓋了常見GJB測試報(bào)告模版的要求。用例標(biāo)識(shí)需求編號(hào)測試類型前置條件測試步驟輸入數(shù)據(jù)預(yù)期結(jié)果實(shí)際結(jié)果測試結(jié)論以一條配置網(wǎng)關(guān)地址的用例為例規(guī)范的填法是這樣前置條件寫系統(tǒng)已登錄網(wǎng)絡(luò)配置頁可訪問測試步驟寫進(jìn)入網(wǎng)絡(luò)配置頁在網(wǎng)關(guān)地址欄輸入192.168.1.1點(diǎn)擊保存觀察頁面提示再進(jìn)入配置列表確認(rèn)記錄狀態(tài)輸入數(shù)據(jù)寫192.168.1.1子網(wǎng)掩碼255.255.255.0預(yù)期結(jié)果寫保存成功后系統(tǒng)返回狀態(tài)碼200配置列表新增一條網(wǎng)關(guān)記錄狀態(tài)為啟用。這樣審查方照著步驟就能復(fù)現(xiàn)不用猜。反過來常見的錯(cuò)誤寫法是測試步驟只寫配置網(wǎng)關(guān)輸入數(shù)據(jù)寫任意合法地址預(yù)期結(jié)果寫保存成功。這三個(gè)字段的毛病一樣信息量不足以讓另一個(gè)人復(fù)現(xiàn)。報(bào)告歸檔后執(zhí)行者本人過兩個(gè)月再看也想不起來任意到底是什么。所以我在團(tuán)隊(duì)里立了一條規(guī)矩測試步驟必須寫成可執(zhí)行的操作序列輸入數(shù)據(jù)必須給具體值或取值范圍預(yù)期結(jié)果必須可觀察、可判定。實(shí)際結(jié)果欄另有一個(gè)高頻問題整列復(fù)制預(yù)期結(jié)果。審查人一眼就能看出這種偷懶甚至?xí)褕?bào)告退回要求重新執(zhí)行。我自己的習(xí)慣是實(shí)際結(jié)果必須寫執(zhí)行時(shí)看到的客觀現(xiàn)象比如點(diǎn)擊保存后頁面返回狀態(tài)碼200刷新列表后新記錄可見記錄狀態(tài)為啟用。就算現(xiàn)象完全符合預(yù)期也要把現(xiàn)象寫出來而不是用與預(yù)期結(jié)果一致一筆帶過。報(bào)告里的證據(jù)價(jià)值就藏在這些具體描述里寫的時(shí)候多敲幾行字評審的時(shí)候就少解釋幾句。3.3 參數(shù)與字段填寫規(guī)范標(biāo)識(shí)符、優(yōu)先級、覆蓋項(xiàng)用例標(biāo)識(shí)符的命名規(guī)則建議項(xiàng)目啟動(dòng)時(shí)就定好。常見格式是項(xiàng)目縮寫-測試階段-序號(hào)比如某平臺(tái)配置項(xiàng)測試的第12條用例可以寫成PLAT-CFG-012。標(biāo)識(shí)符一旦確定就不能改因?yàn)閳?zhí)行記錄、缺陷單、追溯矩陣都會(huì)引用它。中途改號(hào)等于把已經(jīng)寫好的追溯關(guān)系全部作廢。優(yōu)先級字段也要統(tǒng)一口徑例如高優(yōu)先級對應(yīng)核心流程和關(guān)鍵功能中優(yōu)先級對應(yīng)一般業(yè)務(wù)功能低優(yōu)先級對應(yīng)邊界、異常和體驗(yàn)類場景。定義最好寫進(jìn)測試計(jì)劃否則每個(gè)人按自己的理解填統(tǒng)計(jì)結(jié)果沒有可比性。覆蓋項(xiàng)字段最容易寫空。不要只寫覆蓋需求REQ-021要寫覆蓋REQ-021的正常流程和輸入長度邊界值校驗(yàn)或覆蓋REQ-021的非法數(shù)據(jù)容錯(cuò)分支。這樣審查方一眼就知道這條用例測了什么維度不需要再從需求文檔里反推。如果一條用例覆蓋多個(gè)需求在需求編號(hào)欄用逗號(hào)分隔但最好控制在三個(gè)以內(nèi)太多會(huì)讓缺陷定位變困難。一個(gè)實(shí)戰(zhàn)技巧用例表后面單獨(dú)附一張需求映射清單把需求編號(hào)去重逐條統(tǒng)計(jì)覆蓋用例數(shù)。某個(gè)需求編號(hào)沒有用例或只有一條用例卻承擔(dān)了七八個(gè)復(fù)雜分支風(fēng)險(xiǎn)會(huì)在這張清單上直接暴露。我第一次用這個(gè)辦法時(shí)就發(fā)現(xiàn)一個(gè)核心需求只配了一條正常流用例異常分支完全沒人管當(dāng)場補(bǔ)了好幾條用例才敢提交報(bào)告。注意優(yōu)先級和嚴(yán)重級別是兩套體系一個(gè)管測試執(zhí)行的先后順序一個(gè)管缺陷修復(fù)的緊迫程度不要混用。4. 生成測試報(bào)告正文逐節(jié)填寫流程與常見誤用4.1 測試概述與測試環(huán)境讓審查人一眼看到范圍和基線測試概述是整個(gè)報(bào)告的門面。它至少要包含被測軟件名稱和版本號(hào)、測試類型、測試依據(jù)、測試范圍、測試時(shí)間和測試人員。這里最容易被忽略的是版本號(hào)和測試依據(jù)。版本號(hào)要和軟件發(fā)布記錄逐字核對連修訂號(hào)都不能差測試依據(jù)要寫明引用的計(jì)劃與標(biāo)準(zhǔn)編號(hào)不能只寫項(xiàng)目文檔。評審方會(huì)根據(jù)測試依據(jù)判斷報(bào)告覆蓋的階段是否完整依據(jù)寫得模糊整份報(bào)告的分量都會(huì)打折。測試范圍一節(jié)不能只寫對系統(tǒng)進(jìn)行了全面測試。正確寫法是清單式本次測試覆蓋哪些模塊、哪些需求條目哪些未覆蓋未覆蓋的原因是什么。例如未覆蓋在線升級功能原因是該功能尚未完成集成將在下一輪測試中補(bǔ)充。發(fā)現(xiàn)未覆蓋項(xiàng)不丟人藏在細(xì)節(jié)里不說才是問題。評審方寧可看到未覆蓋項(xiàng)也不愿意看到一份聲稱全面測試卻處處有漏洞的報(bào)告。環(huán)境部分除了硬件型號(hào)和操作系統(tǒng)版本還要寫網(wǎng)絡(luò)拓?fù)洹⒀a(bǔ)丁基線、數(shù)據(jù)庫字符集、中間件參數(shù)。環(huán)境是結(jié)果能否復(fù)現(xiàn)的根寫得越細(xì)報(bào)告越硬。我一般會(huì)在環(huán)境節(jié)放一張配置基線表按類目列出關(guān)鍵項(xiàng)服務(wù)器CPU型號(hào)、內(nèi)存、磁盤分區(qū)、操作系統(tǒng)版本及補(bǔ)丁號(hào)、運(yùn)行庫版本、被測軟件版本號(hào)及編譯時(shí)間、網(wǎng)絡(luò)地址分配。這張表在測試開始前生成后續(xù)任何環(huán)境變更都走記錄流程。等報(bào)告評審時(shí)如果有人要求按報(bào)告環(huán)境復(fù)現(xiàn)照著這張表就能把環(huán)境搭回來。這一點(diǎn)在多次評審里驗(yàn)證過省掉過不少解釋的功夫。4.2 測試結(jié)果分析與缺陷描述不寫正常而要寫證據(jù)測試結(jié)果分析章節(jié)要將用例執(zhí)行情況做匯總。至少包含用例總數(shù)、執(zhí)行數(shù)、通過數(shù)、失敗數(shù)、阻塞數(shù)、未執(zhí)行數(shù)再按模塊或需求維度分類統(tǒng)計(jì)。審查方通常會(huì)拿著這份統(tǒng)計(jì)去和用例表核對數(shù)字所以統(tǒng)計(jì)結(jié)果必須能從用例表里直接算出來不能靠拍腦袋。尤其要注意通過率的分母應(yīng)該用已執(zhí)行用例數(shù)而不是用例總數(shù)。阻塞越多的項(xiàng)目如果用總數(shù)做分母通過率會(huì)越難看這個(gè)口徑問題曾被我在評審現(xiàn)場抓過。缺陷描述的關(guān)鍵是證據(jù)完整。標(biāo)準(zhǔn)結(jié)構(gòu)是缺陷編號(hào)、標(biāo)題、復(fù)現(xiàn)步驟、實(shí)際結(jié)果、預(yù)期結(jié)果、嚴(yán)重級別、發(fā)現(xiàn)階段必要時(shí)附日志和截圖。復(fù)現(xiàn)步驟要拆到每一次操作。以前有位同事報(bào)過一條配置保存失敗的缺陷開發(fā)拿到單子怎么都復(fù)現(xiàn)不了后來發(fā)現(xiàn)缺陷單里漏了前置條件必須先切換到只讀模式再退出。這個(gè)教訓(xùn)讓整個(gè)團(tuán)隊(duì)規(guī)定缺陷發(fā)現(xiàn)當(dāng)下立刻按模板記錄完整路徑不能等到寫報(bào)告時(shí)再補(bǔ)。嚴(yán)重級別也要提前統(tǒng)一。同樣一個(gè)內(nèi)存泄漏有人標(biāo)嚴(yán)重有人標(biāo)一般報(bào)告里的缺陷統(tǒng)計(jì)就會(huì)失真。建議在測試計(jì)劃中給出級別定義和判定示例比如致命等于系統(tǒng)崩潰或數(shù)據(jù)丟失嚴(yán)重等于核心功能不可用但有規(guī)避手段一般等于功能受限但不影響主流程。級別定得越具體報(bào)告里缺陷分布越有說服力。判斷缺陷等級靠的是影響分析不是手感更不是玄學(xué)。4.3 測試結(jié)論與遺留問題結(jié)論可以帶條件但必須可驗(yàn)證測試結(jié)論是評審人最先看、看得最細(xì)的一段。這份報(bào)告的質(zhì)量最后都落在結(jié)論的措辭和依據(jù)上。一個(gè)穩(wěn)妥的寫法是本次測試按計(jì)劃執(zhí)行用例N條通過M條失敗K條已提交缺陷單X份其中致命Y份、嚴(yán)重Z份均已關(guān)閉或驗(yàn)證規(guī)避措施無未關(guān)閉的嚴(yán)重及以上缺陷遺留問題清單見附錄軟件具備轉(zhuǎn)入下一階段的條件。這段話里每個(gè)數(shù)字都必須能在前面的章節(jié)找到原始記錄。數(shù)字對不上結(jié)論寫得越滿被質(zhì)疑得越厲害。如果一個(gè)項(xiàng)目確實(shí)存在未關(guān)閉的缺陷結(jié)論可以寫有條件通過。條件是該缺陷有明確的規(guī)避手段且規(guī)避措施經(jīng)過驗(yàn)證。寫遺留問題時(shí)不能只列編號(hào)和影響范圍還要寫明規(guī)避措施和驗(yàn)證結(jié)果。比如受該問題影響的顯示異常已通過切換顯示模式規(guī)避并在回歸測試中驗(yàn)證有效。審查方看了才知道這個(gè)遺留不是無人管的洞。沒有規(guī)避手段的問題不應(yīng)該放進(jìn)遺留清單而應(yīng)作為未關(guān)閉缺陷進(jìn)入結(jié)論的制約條件。寫結(jié)論最容易犯的錯(cuò)是先有結(jié)論后補(bǔ)數(shù)據(jù)。比如負(fù)責(zé)人覺得項(xiàng)目要按時(shí)交付就先把質(zhì)量良好寫上讓測試人員去找數(shù)據(jù)圓。這種順序一旦被評審追問幾乎必然翻車。我自己的習(xí)慣是先統(tǒng)計(jì)缺陷關(guān)閉情況再判斷能否給出無條件結(jié)論最后才動(dòng)筆。結(jié)論是被數(shù)據(jù)推出來的不是被工期逼出來的順序反了報(bào)告就會(huì)變成一張經(jīng)不起追問的紙。5. GJB測試報(bào)告模版的避坑指南審查不過的五個(gè)高頻問題這一章的每一條都是報(bào)告被當(dāng)場駁回?fù)Q來的血淚經(jīng)驗(yàn)。提交前用這五條自查一遍至少能擋掉一半返工。提示下面五條都按現(xiàn)象、原因、解決展開最后一步是可以落到檢查單里的動(dòng)作。5.1 問題一用例表里的需求編號(hào)找不到來源現(xiàn)象審查人隨機(jī)抽三條用例按需求編號(hào)去需求規(guī)格文檔里查發(fā)現(xiàn)編號(hào)不存在或指向了錯(cuò)誤的章節(jié)。現(xiàn)場氣氛通常是沉默加黑臉。原因需求文檔改版后編號(hào)重新分配用例表沒有跟著更新更常見的是用例表從歷史項(xiàng)目里復(fù)制過來舊編號(hào)沒清干凈所有指向都斷在舊文檔上。解決測試啟動(dòng)時(shí)把需求規(guī)格里的編號(hào)清單單獨(dú)導(dǎo)成一份索引表并固定版本。用例表完成后用索引逐條核對重點(diǎn)檢查那些集中出現(xiàn)的編號(hào)段。建議把索引表和用例表一起放入配置管理庫后續(xù)需求變更走正式流程不讓編號(hào)在私下里漂移。5.2 問題二實(shí)際結(jié)果和預(yù)期結(jié)果雷同被懷疑造假現(xiàn)象實(shí)際結(jié)果欄大面積與預(yù)期結(jié)果逐字一致審查方認(rèn)為執(zhí)行人沒有真正跑用例要求重新執(zhí)行并補(bǔ)充現(xiàn)場記錄。原因執(zhí)行人圖省事把預(yù)期結(jié)果復(fù)制到了實(shí)際結(jié)果欄。他們沒意識(shí)到報(bào)告要的是觀察記錄而不是結(jié)論實(shí)際結(jié)果里應(yīng)該有返回值、響應(yīng)時(shí)間、頁面狀態(tài)這些操作現(xiàn)場信息。解決在自查檢查單里加一條規(guī)則實(shí)際結(jié)果欄必須包含至少兩個(gè)觀察點(diǎn)比如界面狀態(tài)加返回結(jié)果或日志輸出加響應(yīng)時(shí)間。提交前專門掃一遍實(shí)際結(jié)果列凡是與預(yù)期結(jié)果字段高度重疊的一律退回重寫。這條檢查不依賴工具人工就能做。5.3 問題三測試環(huán)境信息不完整關(guān)鍵時(shí)刻復(fù)現(xiàn)不了現(xiàn)象評審現(xiàn)場要求復(fù)現(xiàn)某條缺陷測試人員按報(bào)告里的環(huán)境搭環(huán)境結(jié)果現(xiàn)象與原問題不同整個(gè)報(bào)告的可信度被打上問號(hào)。原因報(bào)告的環(huán)境部分只寫了操作系統(tǒng)和內(nèi)存漏了補(bǔ)丁版本、中間件參數(shù)和數(shù)據(jù)庫字符集。軟件行為在這些參數(shù)不同時(shí)可能差異很大尤其是涉及通信協(xié)議和外部服務(wù)調(diào)用的場景。解決把測試環(huán)境當(dāng)作配置項(xiàng)管理。測試開始前生成配置基線表記錄操作系統(tǒng)版本和補(bǔ)丁號(hào)、軟件棧版本、關(guān)鍵配置文件校驗(yàn)值報(bào)告環(huán)境節(jié)直接引用這條基線。環(huán)境有任何變化更新基線并記錄變更時(shí)間保證報(bào)告里的環(huán)境就是執(zhí)行時(shí)的環(huán)境。5.4 問題四缺陷描述里沒有復(fù)現(xiàn)步驟開發(fā)找不著北現(xiàn)象缺陷單寫了系統(tǒng)設(shè)置保存失敗、頻繁閃退沒有前置條件開發(fā)按自己的路徑操作卻復(fù)現(xiàn)不了只能把缺陷退回。原因測試者以為開發(fā)知道自己的操作路徑或者擔(dān)心寫太長于是只寫結(jié)論不寫過程。結(jié)果是把缺陷定位的成本全部轉(zhuǎn)給了開發(fā)來回溝通耗時(shí)嚴(yán)重。解決復(fù)現(xiàn)步驟設(shè)為必填項(xiàng)在字段下方標(biāo)注逐步操作包括前置狀態(tài)和輸入數(shù)據(jù)。缺陷發(fā)現(xiàn)當(dāng)下就按模板記錄以打開某頁面進(jìn)入某配置項(xiàng)、輸入某值、點(diǎn)擊某按鈕的格式寫必要時(shí)附數(shù)據(jù)文件或日志片段。這條規(guī)則一旦堅(jiān)持執(zhí)行開發(fā)側(cè)定位效率會(huì)明顯提升。5.5 問題五測試結(jié)論與缺陷統(tǒng)計(jì)數(shù)據(jù)嚴(yán)重矛盾現(xiàn)象結(jié)論寫軟件質(zhì)量良好、可以提交驗(yàn)收報(bào)告正文的缺陷匯總里卻還有幾十條未關(guān)閉問題且沒有關(guān)閉計(jì)劃或規(guī)避措施。原因結(jié)論模板從別的項(xiàng)目復(fù)制過來或先寫了結(jié)論再補(bǔ)數(shù)據(jù)。評審人一眼就能看出報(bào)告不是為當(dāng)前項(xiàng)目寫的甚至懷疑整個(gè)測試過程的真實(shí)性。解決結(jié)論必須由統(tǒng)計(jì)數(shù)據(jù)生成不能由人先拍板。報(bào)告收尾時(shí)先拉一遍缺陷清單統(tǒng)計(jì)關(guān)閉和未關(guān)閉數(shù)量再看未關(guān)閉項(xiàng)的等級。存在未關(guān)閉的嚴(yán)重以上缺陷時(shí)結(jié)論只能寫有條件通過或不具備轉(zhuǎn)入下一階段條件。把結(jié)論設(shè)計(jì)成帶參數(shù)插入的模板數(shù)字從前面章節(jié)引用既省力又不容易自相矛盾。6. 用需求追溯矩陣把報(bào)告做厚一個(gè)讓審查更順的技巧最后分享一個(gè)我在多份GJB軟件測試報(bào)告中反復(fù)使用的技巧單獨(dú)做一張需求追溯矩陣放進(jìn)報(bào)告附錄或作為評審時(shí)的引導(dǎo)頁。這張矩陣看起來很簡單只有三列需求編號(hào)、用例編號(hào)、執(zhí)行結(jié)果。每一行表示一條需求由哪些用例覆蓋覆蓋后執(zhí)行結(jié)果如何。它等于把整份報(bào)告的證據(jù)鏈壓縮到一頁紙上審查方順著矩陣就能從上到下把報(bào)告讀完。構(gòu)建矩陣有兩種方式按項(xiàng)目規(guī)模選。項(xiàng)目變更少、用例量在幾百條以內(nèi)時(shí)直接用表格手工維護(hù)用例表完成后對照需求清單逐行填。項(xiàng)目規(guī)模大時(shí)從測試管理工具導(dǎo)出用例與執(zhí)行結(jié)果再按需求編號(hào)做匯總前提是工具里的需求和用例綁定關(guān)系一開始就維護(hù)好否則導(dǎo)出后還是要手工補(bǔ)。兩種方式殊途同歸矩陣的價(jià)值在查漏而不在展示哪些需求沒有用例哪些用例沒有執(zhí)行結(jié)果一行一行空在那里比任何口頭解釋都直觀。第一次用這個(gè)技巧時(shí)報(bào)告初稿已經(jīng)有幾十頁我花了一晚上把需求追溯矩陣趕出來第二天評審就從計(jì)劃的兩輪壓縮到一輪。當(dāng)時(shí)最大的感受是報(bào)告不是寫出來讓審查方去挖證據(jù)的而是應(yīng)該主動(dòng)把證據(jù)擺到對方眼前。追溯矩陣就是把幾十頁內(nèi)容翻譯成一張查漏表評審提問都變成了具體指向不再是大而化之的復(fù)看過沒有。如果你也在被測試報(bào)告反復(fù)打回下一個(gè)項(xiàng)目可以從矩陣開始。這個(gè)習(xí)慣用起來不復(fù)雜省下的是整輪評審的溝通成本希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取