刚开始从事这个行业，大部分朋友的第一次测试都交给了功能测试，自然而然第一次报告也被功能测试给“破处”了，可是是这个写的多的报告，却越写越困惑，一是我们的报告被重视的不够，二是这个报告每次都按照模板套的，没得新意，自己到后都写得没信心了。

　　对于第二个问题，除非你是测试主管或者测试经理，否则你还真没有决定权，领导定的模板也是方便部门内部的统一管理。但是同一套模板每次写的的内容一样么？我们想过没有，第一个问题是不是很大程度上是第二个问题带来的？那么编写的测试报告需要我们做什么？

　　一、测试功底：

　　熟练编写测试报告是一个测试工程师的必修课，马虎不得。老手们可能看几眼你的报告知道你的水品处在什么层次。先展示的地方是你的内功，你“行走江湖”大的资本，也是能体现你能力的地方。对于一份功能测试的报告，应该包括本次测试的目的，结果的概述、总结、分析，用例的执行结果，缺陷结果及分析（收敛趋势等），后附加一些环境信息（DB，OS、浏览器等），虽然各自的报告可能迥然不同，但是这些共同点还是都需要包括的。而对这些共同点的概括总结和分析，则是分内之事了。对于这种“熟练工种”，没有什么特别好的办法，熟能生巧，多写多看多总结，提高自己对测试结果的敏感度，相信量变一定会引发质变的。

　　二、语言外功：

　　测试报告是一个文档程度很强的东西，所以编写这玩意很能考察大家的文字功底。相信各位都有在撰写报告的时候对一些词、一些语句斟酌很久的场景。的确，我们不仅要实事求是的反应本次测试的结果和问题情况，而且还要让这篇文章的阅读对象接受我们的措词。同一句话不同的表达方式换回来的结果完全不同，所以测试报告对测试工程师的语言组织功底则是一次摸底考察，看来这方面平时不积累不行啊。

　　三、面向对象：

　　在编写报告实际操作过程中，我们要根据这份报告的潜在阅读者来调整，即所谓的面向对象“写报告”，每份报告的模板在固定后，第一眼看上去每份报告基本上一样，那我们怎么来提高这份报告的推广程度？我们可以调整每个模块的顺序和写作偏重点。如果对象是项目管理者，他可能更关注版本的整体情况以及对整个系统的总结；开发人员可能更关心缺陷的修复情况和收敛趋势；而团队老大则可能要重点查看分析结果等。我们可以根据不同的“用户”调整我们的侧重点，面向多个对象则要找好这个平衡点了。

　　四、总结：

　　测试报告虽然是文档，却体现着编写者的测试和语言功底，因此，不是每个测试人员都可以叫做测试工程师，更别谈熟练了。不过也没什么，不是不代表明天不是。多看、多写、多总结对于一个测试人员来说是一项重要的“革命”工作。