一.文檔模板的使用

    往往公司模板更新?lián)Q代了，但測試人員仍然在沿用原來的模板。輕則說明你粗心，重則說明你不關(guān)心公司的變化、磨洋工。筆者曾經(jīng)遇到過真實的例子，有一同事使用舊文檔模板，但實際公司的名字和Logo都發(fā)生了變化，發(fā)送到產(chǎn)品經(jīng)理，后果肯定是測試報告被打回，并通報批評。如果極端點，測試報告放到更高層，如公司主要領(lǐng)導(dǎo)，那后果和影響不言而喻。

二.修訂記錄應(yīng)該在首頁后標(biāo)示清楚

    修訂記錄，是自己勞動成果的過程記錄，這點也是測試人員容易忽視的地方。有的測試人員，每次提交的測試報告，修訂記錄都只有一條。實際測試報告應(yīng)該是有審查和修訂過程的，比如你在發(fā)出測試報告之前，通常都應(yīng)給測試經(jīng)理審查過目，往往過后還會有些問題修訂。如果不標(biāo)識清楚，那么可能提出的一些特別要求，會讓報告顯得用了較長時間。這可能讓公司高層客戶認(rèn)為你的能力不行，也不能讓外部（如ISO審查組織）了解你們的工作合規(guī)性。修訂記錄主要包括：修改時間、版本號、修訂人、修訂內(nèi)容及審查人。

三.內(nèi)容應(yīng)該清晰易懂，簡明扼要

不要把測試報告的內(nèi)容寫成一篇中篇小說。各種修飾詞，流水話一大堆，導(dǎo)致看的人霧里看花，似是而非。我看過有把測試報告寫成文章的，通篇報告都是文字，我認(rèn)為、我想、他們應(yīng)該等一大堆稱謂詞，最后草草下個結(jié)論，讓人不明所以。

測試報告應(yīng)該盡量避免主觀看法，加入一堆的主觀認(rèn)識。而應(yīng)該客觀的、簡明扼要的把過程表述清楚。并且盡可能結(jié)合圖文和表格輔以說明。這樣的測試報告才令人賞心悅目，也讓人一目了然，從而把測試結(jié)果很好的呈現(xiàn)給客戶。

四.絕不放過一個錯字

    軟件測試人員應(yīng)該是一群吹毛求疵的人，如果自己的報告中有一堆錯別字，哪怕是一個錯別字，可能都會尷尬難堪。原來就有同事非常粗心，導(dǎo)致測試報告出現(xiàn)多個錯別字。而開發(fā)人員一句"平時找bug時，連一個錯別字都被你單獨列為一個bug，XX，你看你文檔有好多bug"，這個測試人員鬧得非常尷尬。最好的做法就是，寫完測試報告后，自己一定要通篇檢查一到兩遍，這樣嚴(yán)格要求自己，才能去高要求別人。

五.沒有閉環(huán)的bug，哪怕是往期版本遺留的bug，都應(yīng)該羅列出來

    往往測試人員在一些外部壓力下，容易把承諾修改但還來不及驗證的bug在測試報告中抹去，或者有意疏漏。但這樣不呈現(xiàn)出來，一發(fā)出去，可能高層不知道具體情況而做出錯誤的決策，導(dǎo)致后期出現(xiàn)人為的事故。如以前碰到過軟件系統(tǒng)的一小工具，因為使用頻率不高，所以bug經(jīng)測試經(jīng)理、開發(fā)經(jīng)理和項目經(jīng)理達成一致意見延期修復(fù)，但測試人員沒有在測試報告中把這些bug呈現(xiàn)出來，導(dǎo)致市場人員在給用戶演示時為了說明系統(tǒng)的強大，從而錯誤的展示了該有bug的工具，以至在用戶面前出現(xiàn)冷場。更極端的結(jié)果可能是，用戶拒絕采用該系統(tǒng)。所以我們在測試報告中，應(yīng)該把沒有閉環(huán)的bug，哪怕是往期版本遺留的bug，都應(yīng)該詳細(xì)羅列出來。這樣才能讓高層或推廣部門的同事進行規(guī)避或作出應(yīng)對措施。

六.產(chǎn)出成果恰當(dāng)呈現(xiàn)

這一環(huán)常常是大家極容易忽視的一環(huán)。往往測試人員的做法是，報告寫好了直接發(fā)送一封帶附件的郵件給客戶，好點的可能會加幾行文字。但是，我想說，除了你的直接領(lǐng)導(dǎo)、平級同事外，其他客戶往往是沒有太多時間和耐心下載附件并仔細(xì)查看你的報告的，他們關(guān)心的是"現(xiàn)在的軟件質(zhì)量到底如何，是否能放給用戶使用"。最好的做法是在郵件內(nèi)容頁開頭，寫上測試結(jié)論、問題建議，并可以把主要的測試結(jié)果統(tǒng)計放在后面，最后才是附上完整測試報告的附件。

總結(jié)：其實寫一份測試報告不難，但要寫好一份高質(zhì)量、合格的報告需要花費一定的時間。