刚开始从事这个行业,大部分朋友的第一次测试都交给了功能测试,自然而然第一次报告也就被功能测试给“破处”了,可是就是这个写的最多的报告,却越写越困惑,一是我们的报告被重视的不够,二是这个报告每次都按照模板套的,没得新意,自己到最后都写得没信心了。
对于第二个问题,除非你是测试主管或者测试经理,否则你还真没有决定权,领导定的模板也是方便部门内部的统一管理。但是同一套模板每次写的的内容一样么?我们想过没有,第一个问题是不是很大程度上是第二个问题带来的?那么编写优秀的测试报告需要我们做什么?
一、测试功底:
熟练编写测试报告是一个测试工程师的必修课,马虎不得。老手们可能看几眼你的报告就知道你的水品处在什么层次。最先展示的地方是你的内功,你“行走江湖”最大的资本,也是最能体现你能力的地方。对于一份功能测试的报告,应该包括本次测试的目的,结果的概述、总结、分析,用例的执行结果,缺陷结果及分析(收敛趋势等),最后附加一些环境信息(DB,OS、浏览器等),虽然各自的报告可能迥然不同,但是这些共同点还是都需要包括的。而对这些共同点的概括总结和分析,则是分内之事了。对于这种“熟练工种”,没有什么特别好的办法,熟能生巧,多写多看多总结,提高自己对测试结果的敏感度,相信量变一定会引发质变的。
二、语言外功:
测试报告是一个文档程度很强的东西,所以编写这玩意很能考察大家的文字功底。相信各位都有在撰写报告的时候对一些词、一些语句斟酌很久的场景。的确,我们不仅要实事求是的反应本次测试的结果和问题情况,而且还要让这篇文章的阅读对象接受我们的措词。同一句话不同的表达方式换回来的结果完全不同,所以测试报告对测试工程师的语言组织功底则是一次摸底考察,看来这方面平时不积累不行啊。
在编写报告实际操作过程中,我们要根据这份报告的潜在阅读者来调整,即所谓的面向对象“写报告”,每份报告的模板在固定后,第一眼看上去每份报告基本上一样,那我们怎么来提高这份报告的推广程度?我们可以调整每个模块的顺序和写作偏重点。如果对象是项目管理者,他可能更关注版本的整体情况以及对整个系统的总结;开发人员可能更关心缺陷的修复情况和收敛趋势;而团队老大则可能要重点查看分析结果等。我们可以根据不同的“用户”调整我们的侧重点,面向多个对象则要找好这个平衡点了。
测试报告虽然是文档,却体现着编写者的测试和语言功底,因此,不是每个测试人员都可以叫做测试工程师,更别谈熟练了。不过也没什么,今天不是不代表明天不是。多看、多写、多总结对于一个测试人员来说是一项重要的“革命”工作。怎么,没地总结?来测试窝嘛!