一.文檔模板的使用
往往公司模板更新換代了,但測試人員仍然在沿用原來的模板。輕則說明你粗心,重則說明你不關心公司的變化、磨洋工。筆者曾經遇到過真實的例子,有一同事使用舊文檔模板,但實際公司的名字和Logo都發生了變化,發送到產品經理,后果肯定是測試報告被打回,并通報批評。如果極端點,測試報告放到更高層,如公司主要領導,那后果和影響不言而喻。
二.修訂記錄應該在首頁后標示清楚
修訂記錄,是自己勞動成果的過程記錄,這點也是測試人員容易忽視的地方。有的測試人員,每次提交的測試報告,修訂記錄都只有一條。實際測試報告應該是有審查和修訂過程的,比如你在發出測試報告之前,通常都應給測試經理審查過目,往往過后還會有些問題修訂。如果不標識清楚,那么可能提出的一些特別要求,會讓報告顯得用了較長時間。這可能讓公司高層客戶認為你的能力不行,也不能讓外部(如ISO審查組織)了解你們的工作合規性。修訂記錄主要包括:修改時間、版本號、修訂人、修訂內容及審查人。
三.內容應該清晰易懂,簡明扼要
不要把測試報告的內容寫成一篇中篇小說。各種修飾詞,流水話一大堆,導致看的人霧里看花,似是而非。我看過有把測試報告寫成文章的,通篇報告都是文字,我認為、我想、他們應該等一大堆稱謂詞,最后草草下個結論,讓人不明所以。
測試報告應該盡量避免主觀看法,加入一堆的主觀認識。而應該客觀的、簡明扼要的把過程表述清楚。并且盡可能結合圖文和表格輔以說明。這樣的測試報告才令人賞心悅目,也讓人一目了然,從而把測試結果很好的呈現給客戶。
四.絕不放過一個錯字
軟件測試人員應該是一群吹毛求疵的人,如果自己的報告中有一堆錯別字,哪怕是一個錯別字,可能都會尷尬難堪。原來就有同事非常粗心,導致測試報告出現多個錯別字。而開發人員一句"平時找bug時,連一個錯別字都被你單獨列為一個bug,XX,你看你文檔有好多bug",這個測試人員鬧得非常尷尬。最好的做法就是,寫完測試報告后,自己一定要通篇檢查一到兩遍,這樣嚴格要求自己,才能去高要求別人。
五.沒有閉環的bug,哪怕是往期版本遺留的bug,都應該羅列出來
往往測試人員在一些外部壓力下,容易把承諾修改但還來不及驗證的bug在測試報告中抹去,或者有意疏漏。但這樣不呈現出來,一發出去,可能高層不知道具體情況而做出錯誤的決策,導致后期出現人為的事故。如以前碰到過軟件系統的一小工具,因為使用頻率不高,所以bug經測試經理、開發經理和項目經理達成一致意見延期修復,但測試人員沒有在測試報告中把這些bug呈現出來,導致市場人員在給用戶演示時為了說明系統的強大,從而錯誤的展示了該有bug的工具,以至在用戶面前出現冷場。更極端的結果可能是,用戶拒絕采用該系統。所以我們在測試報告中,應該把沒有閉環的bug,哪怕是往期版本遺留的bug,都應該詳細羅列出來。這樣才能讓高層或推廣部門的同事進行規避或作出應對措施。
六.產出成果恰當呈現
這一環常常是大家極容易忽視的一環。往往測試人員的做法是,報告寫好了直接發送一封帶附件的郵件給客戶,好點的可能會加幾行文字。但是,我想說,除了你的直接領導、平級同事外,其他客戶往往是沒有太多時間和耐心下載附件并仔細查看你的報告的,他們關心的是"現在的軟件質量到底如何,是否能放給用戶使用"。最好的做法是在郵件內容頁開頭,寫上測試結論、問題建議,并可以把主要的測試結果統計放在后面,最后才是附上完整測試報告的附件。
總結:其實寫一份測試報告不難,但要寫好一份高質量、合格的報告需要花費一定的時間。
知識產權一站式服務
卓科服務熱線: 0755-21675761
Copyright ? 2018 深圳市卓科知識產權代理有限公司 粵ICP備18069424號-1 網站設計:沙漠風