3、 要有分析，并提醒相關問題（如，培訓方面），使報告更有價值。
面向管理層的測試報告，一般是綜述性報告，用于判斷質量情況，做出相關決策。
這時的報告要考慮：
1、 有分析模型（公司要有自己的模型），有判斷和結論。
2、 與歷史數據有比較，評估風險。
3、 是一定范圍的集體意見的反映，也反映其它項目相關人的意見（作為代言人）。
公司對各類測試報告要有模板和寫作要求，并通過這些指引，培養一致的風格，有利于報告的理解。
看一個對話：為何這么明顯的問題沒有報告出來？我以為別人已報告了這個問題。
因此，不要假設明顯的程序錯誤已經寫入報告。大家都有這種假設時則會遺漏。
設計錯誤誰來報告？當然還是由測試員來報告。測試員的測試可以作為設計的后期評判。為了能對設計進行測試，測試組只要有一定比例的領域專業人員。
（3）：測試數據能用于考核嗎？
這還真是個問題，不知你想過沒有。
在強調績效考核、量化考核的今天，企業常常拿測試數據直接作為考核指標，因為，這是容易拿到的數據，也容易推理到績效上去（測試數據——>產品質量——>績效）。
我們看一下幾種情形：
1、 將測試BUG個數用來考核程序員：這會使程序員與測試員之間產生極大的矛盾，不利于二者之間的溝通，程序員爭辯設計問題并不是程序問題將導致仲裁的管理成本�；驕y試員被程序員拉攏會使數據失真（問題數變小或合并填報）；
2、 將測試BUG個數用來考核測試員：則他既是運動員又是裁判員，會夸大數據，其方式有重復（一個問題的多個實例）和擴大（將膚淺的事項擴大成問題），這時測試員不愿幫助程序員改正BUG（因他下一次又能發現）。
測試數據的跟進屬技術管理范疇，而考核是屬人力資源管理范疇，前者要求真實性，后者要求公正合理。因此，選取測試數據作考核要慎重。
比較合理的考核指標：將缺陷清除率作為程序員的質量考核指標，將產品投產后一定周期內客戶發現的問題密度作為考核測試員的質量指標。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
