這是《落葉》文集里第?156?片落葉，希望你能喜歡，不為別的，只為這份堅持。
【背景】
前天，有個同學(xué)問了我一個基礎(chǔ)問題，軟件測試報告跟回歸測試報告有何區(qū)別？測試細則又是什么呢？如果簡單說來，軟件測試報告你可以理解成一個統(tǒng)稱，而回歸測試報告只是其中一個子項。而測試細則，按我的理解，它其實是測試計劃里的具體測試策略和步驟，是用于執(zhí)行參考的，如果把它放到測試報告中，那應(yīng)該就是表示測試的執(zhí)行步驟和細節(jié)。而在實際的項目中，大家真正容易混淆分不清的其實是“測試報告”和“質(zhì)量報告”。
【你問】
測試報告和質(zhì)量報告應(yīng)該如何區(qū)分？
【我答】
開篇先簡單再補充回答一下背景中的問題，如果把軟件測試報告定義成狹義的一種報告的叫法，那它就是每個項目在完成所有測試，準備發(fā)布上線時，由測試部門出具的一份測試報告，運維部門以此為上線活動的開始標志，我之前的公司就是如此，US 的 Release Manager 不收到測試部門（QA）發(fā)出的 QA Release Report，她是不會發(fā)出 Engineer Release Report 的。
而回顧測試報告，其實可以理解成是跟每個測試包一一對應(yīng)的回歸測試總結(jié)，在很多公司，包括我之前那家公司，其實就是 Daily Project Report 中的一項內(nèi)容，并沒有出具單獨的報告。
言歸正傳，想問問你，能分的清測試報告和質(zhì)量報告嗎？你知道應(yīng)該如何去區(qū)分它們嗎？
你也許會跟我說，你當(dāng)然能分的清楚，畢竟都做了這么多年項目了。
可我如果真的讓你去寫一份測試報告，可能你就會不那么清楚了，你可能會詳細的羅列出項目中的所有測試環(huán)節(jié)、步驟、方法，發(fā)現(xiàn)的所有缺陷，以及缺陷產(chǎn)生的原因和分析，在各個環(huán)節(jié)中遇到的問題，甚至于你會把因為開發(fā)自測質(zhì)量不高而導(dǎo)致需求提測時間延遲的問題也羅列其中，諸如此類的測試數(shù)據(jù)和問題分析混雜在一起，洋洋灑灑幾十頁，這是我們常見的一份“漂亮”且“充實”的測試報告。
我先不對這種報告做任何正確與否的評判，因為我一直認為，很多東西都沒有明確的對錯之分，有的只是是否適用于當(dāng)下的場景。
還是讓我先說說我是依據(jù)什么將測試報告和質(zhì)量報告區(qū)分開來的，然后，我們再回過頭來看看上述報告是否合適吧。
1、報告的閱讀對象決定了這兩種報告本質(zhì)上的區(qū)別：
測試報告，閱讀對象主要為負責(zé)產(chǎn)品版本發(fā)布的經(jīng)理，在我之前的公司，職位名稱叫 Release Manager，他閱讀這份報告的目的是想從其中獲取到相應(yīng)版本的質(zhì)量，是否已經(jīng)達到了可發(fā)布的標準，Pass, Faile or Pass with Risk，我們完成了哪些測試工作，當(dāng)前遺留的未解決 Bug 有多少，已知問題有哪些等等，當(dāng)然，他也需要從這份報告中了解到這個版本有哪些需求和改動；
質(zhì)量報告，閱讀對象主要為負責(zé)產(chǎn)品研發(fā)的經(jīng)理，在一些規(guī)模很大的企業(yè)，還有一個崗位的人員會看這份報告，那就是 EPG，他們閱讀這份報告的目的是想從羅列的問題和原因分析中找到所有可以改進的點，有可能是流程上的，也有可能是技術(shù)方法上的，當(dāng)然，也可能就是人的問題，總之，他們就是想通過這份報告里的問題，找到可改進的地方，然后對其進行有計劃地、循序漸進的改進。
我們再回到前文提到的那個“混合型”的報告，你現(xiàn)在應(yīng)該能告訴我，它是否是一份合適的報告了吧？
對于產(chǎn)品研發(fā)經(jīng)理或者 EPG 來說，要么就是對版本需求和改動很熟悉了，要么就是只關(guān)注整個研發(fā)過程，并不關(guān)注產(chǎn)物本身的，你在報告里花大量篇幅羅列了需求和改動，沒有任何意義。
對于發(fā)布經(jīng)理來說，我只想你告訴我，當(dāng)前質(zhì)量是否能發(fā)布了，其他的問題都是你們研發(fā)過程或者研發(fā)團隊的問題，我不關(guān)心（如果站在產(chǎn)品研發(fā)團隊的經(jīng)理角度來說，那些研發(fā)過程或研發(fā)團隊的問題其實都是“家丑”，那你覺得該“外揚”嗎？）
2、報告的編寫人角色決定了這兩種報告直觀上的區(qū)別：
測試報告，編寫人是測試經(jīng)理或測試項目負責(zé)人；
質(zhì)量報告，編寫人是 QA，在 QA 由測試兼任的公司，也是由測試經(jīng)理或測試負責(zé)人編寫（我之前所在的外企就把測試和 QA 的職責(zé)合在一個崗位里，叫做 QA）
3、最后，我列出一些我認為在兩種報告中較為關(guān)鍵的條目，但可以因地制宜，不全是必選項。
測試報告：
1、版本信息：包括所有發(fā)布組件的名稱和版本號；
2、依賴關(guān)系：所有組件之間的依賴關(guān)系，是強依賴，還是弱依賴，如果有依賴關(guān)系，就一定要說清楚上線的部署順序和原因，以免出現(xiàn)問題；
3、測試環(huán)境配置：包括服務(wù)器的系統(tǒng)版本、中間件的版本、數(shù)據(jù)庫的版本、客戶端的瀏覽器類型/版本，OS 類型/版本等等；
4、已完成的測試范圍、類型和方法，包括結(jié)果，如果做了性能測試，附上性能測試結(jié)果，如果做了安全測試，附上 APPScan 的掃描結(jié)果，如果執(zhí)行了手工用例，附上用例的 Run Infomation 等等；
5、測試結(jié)論：版本發(fā)布的標準是什么？依據(jù)標準，該版本是否已經(jīng)可發(fā)布，如果不可發(fā)布，原因是什么？如果是可帶著風(fēng)險發(fā)布，那風(fēng)險有哪些？
6、已知問題清單：該版本截止到發(fā)布日期，還有哪些是未在當(dāng)前版本得到修復(fù)的仍然存在的缺陷；
質(zhì)量報告：
1、同類型項目的歷史質(zhì)量數(shù)據(jù)比對；
2、當(dāng)前版本的質(zhì)量期望目標；
3、經(jīng)過統(tǒng)計分析過的缺陷分布圖和缺陷修復(fù)曲線圖；
4、針對過程中遇到的問題，所做的 3W 分析：
? ?4.1 What's the problem？
? ?4.2 What's the root cause？
? ?4,3 What's the solution？
5、針對當(dāng)前版本的質(zhì)量問題（數(shù)據(jù)的和過程的）所作的總結(jié)分析和改進建議；
《測試路上你問我答》里的?Q&A 21，如果是你要的，甚好！如果不是，你問，我答！
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
