20170612-日报

从上周五开始写短信平台压力测试报告，周末下午也在写，感觉写了好久，但是最后的报告还是一样，感觉比较乱。

今天上午在测试web端的一个大屏图，重点是数据的正确性。问开发要相关的sql，一个一个去对，发现还是有许多bug，比如统计数据容量：

SELECT SUM(DATA_LENGTH)+SUM(INDEX_LENGTH) AS dataTotal FROM information_schema.tables

WHERE table_schema ='DCN_MYH_TEST';

统计的是数据库的容量，默认单位为B,我从库里边查到经计算才1.几个G,前台界面显示800多个G,有点吓人。测试完成后，老大要求出测试报告（以前都没说出过）。

下午弄了一下午的全网视窗测试报告，写文档可真不是件容易的事情，从没写个，咨询别人。发现自己写这类文档，必须要有参考，没有参考，是一点都不会写。同时发现自己对细小的事情没有耐心，比如页码，页眉页脚等。终于在下班之前搞定了。

BY  老徐建议

测试报告核心要素

1. 测试结论

从测试工程师的专业角度分析，是否达到发布标准，是否可发布 。如果你的测试报告，结论都没有，那这份报告的意义是什么？

2. 风险

已知风险 & 未知风险 ，抛出。

项目经理、产品经理等多部门，需要根据这份风险分析，确定最终这个版本是否发布出去。

3. 测试时间 & 测试人员

这是非常重要的，投入了哪些人，用了多少时间，测试起止时间。

4. 测试环境、测试设备

用到哪些测试手机，什么客户端环境，什么浏览器等等。

5. 需求大纲

当前的这个版本，到底包含了哪些大的需求点。

6. Bug数据分析（非常重要的一点）

可以从多个维度分析，

比如，Bug等级分布，遗留Bug分析，Bug类型分布，模块Bug分布，Bug激活次数分析 等等（具体可根据公司实际情况，进行多维度分析）。

7. 测试总结

从测试角度，对这个版本，你觉得存在的一些问题，一些建议，等等。

OK，有了如上的测试报告关键要素，还差模板吗？有正常word能力的同学，整理下格式，然后根据你公司的事情情况，简单调整，模板就出来了。