
來源頭條作者:迅速fast 測試報告作為測試人員的核心輸出項,是體現自己工作價值的重要承載工具,需要我們認真對待,所以我們要重視測試報告的輸出,那么在編寫測試報告的時候,我們有哪些點需要注意的呢? 01 不要亂用模板 很多測試新人在編寫測試報告時,都會去找別人要一份所謂的測試報告模板,總感覺別人的報告是好的,而沒有考慮到自己團隊的實際情況,不是說不能套用模塊,這里有兩個小坑需要注意下: 頁眉頁腳:在正規的公司里,對于文檔的頁眉頁腳都有會明確的要求。但我們的閱讀習慣又是會把這塊內容隱藏起來。這就會導致你在套用模板的時候,忽略了這部分內容的修改,筆者曾經閱讀過一份測試報告,頁眉頁腳上的說明和Logo竟然是別的公司,這就很尷尬了。 空白標題:模板一般會講究大而全,所以會有很多標題項,給到有需要的人去填寫,比如項目背景、術語解釋等,但是這些內容是需要根據實際情況去做裁剪的。但新手們可能不知道怎么寫,就放在那里,也不刪除。筆者見過一份測試報告,里面有2~3項只有標題而沒有內容,你是想讓讀者給你補上么? 02 沒有明確測試范圍 在測試報告中,我們需要明確的給出測試范圍是哪些,如果版本的內容較多,可以適當的簡寫,但不能不寫。產品給的版本內容好比是預售出去的火車票。而測試報告中的測試范圍,就是上車前的檢票環節,要對齊,不能有缺失,也盡量不能有夾帶,否則火車可能會失控。 變更的點要明確出來:如果版本周期比較長,或者在研發過程中需求發生了變化,需要在測試范圍中明確的標注出來,讓閱讀報告的人能夠清楚的知道哪些點是做過變更的,有助于他們評估影響范圍。 裁剪的要特別明確出來:由于各種原因,原來計劃的功能或者需求沒有得到實現,被裁剪的功能要特別的明確標注出來,讓大家清楚的知道最終上線的是哪些內容。避免因為信息不對稱引發誤解。 03 內容描述不清晰 不要把測試報告的內容寫成一篇中篇小說。各種修飾詞,流水話一大堆,導致看的人霧里看花,似是而非。我看過有把測試報告寫成文章的,通篇報告都是文字,我認為、我想、他們應該等一大堆稱謂詞,最后草草下個結論,讓人不明所以。 測試報告應該盡量避免主觀看法,加入一堆的主觀認識。而應該客觀的、簡明扼要的把過程表述清楚。并且盡可能結合圖文和表格輔以說明。這樣的測試報告才令人賞心悅目,也讓人一目了然,從而把測試結果很好的呈現給客戶。 04 沒有風險說明 這點是在測試報告經常被忽略但又非常重要的一個點。在一些核心版本、變更較大的版本中,我們需要明確給出一些風險項,最好能給出必要的解決方案或者應對方法。常見的風險一般會有以下幾類: 缺陷遺留風險:有些版本缺陷并會被完全修復,那么遺留缺陷的風險是什么,如何應對,是否需要對外統一話述等。 測試策略風險:在測試時間緊張、業務功能特別復雜的場景中,我們使用了特定的測試策略,可能引發或者遺留的風險項是什么,是否做好了預案。 發布升級風險:重要的變更、涉及歷史數據遷移、中間件版本升級等內容時,除了做好全面的驗證外,還需要給出必要的回退方案。 業務風險:是否依賴其它子系統的同步升級配合,是否有第三方系統參與升級,新業務帶來的用戶操作變更是否做好了對應的培訓或者有對應的操作文檔(特別是To B的產品),是否預留了用戶意見反饋通道等等。 05 沒有測試結論 你見過沒有測試結論的測試報告么?嗯,我見過。給某個版本的測試工作下結論是需要非常謹慎的,因為你需要對測試結論負責(很多人忽略了這一點,然后就被甩鍋了)。在結合測試過程和測試風險后,我們需要給出明確的測試結論:通過、不通過、有條件通過(某些功能被裁剪了,或者某些場景是通過Mock等方式能過的,可能存在風險)。誰說測試結論一定要是通過呢? 在編寫測試報告時,還有些小坑需要特別注意的,比如: 不能有錯別字、排版要規范、圖表要清晰等,不要讓這些小細節讓別人對整個測試報告留下不好映象。 06 小結 一份好的測試報告至少應當包含以下幾點內容: 測試范圍:你最終的測試范圍是什么,覆蓋了哪些功能點。哪些是原來迭代規劃的,哪些是臨時增加的,又有哪些轉動了下個迭代中。這些都是需要明確出來的,看報告的人并不一定會全程參與到研發過程中,所以需要你的測試報告來體現真實的迭代內容是什么。 測試結論:從測試人員專業的角度,給出迭代的質量評估,是否達到了發布標準,是否可以發布,如果不能,說清楚原因。 測試風險:在測試過程中遇的考慮到的風險,上線后可能發生的風險,如果你知道,請明確出來,讓團隊各角色(研發、產品、部門負責人等)根據你的風險分析,一起來決定是否發布版本。 當然,測試報告不僅僅只包含以上內容,但是以上內容是看報告的人最注的內容,除此以外,還應該包含但不限于測試策略、人員投入、BUG分析(對研發團隊很重要)、測試改進意見等等。
暫時沒有評論,來搶沙發吧~