如何编写 App测试报告

原创木木简尚

2017年08月24日 00:09

此文作者：木木，百人计划成员。

--正文开始--

写在前面的话：

自从转到测试，已经5年了，我一直从事App测试工作，测过的App很多，有益智答题类，购物类，陌生人交友类，网游类，直播，纯视频游戏等，每天的工作说一样又不一样，重复着透漏着小创新。

前4年，产品测试完毕后就上线，没有编写测试报告的要求和习惯，所以没什么进步，近一年来，因为年龄大了，加上没什么一技之长，压力很大，想着不能再这么下去了，于是给自己定了一个个小目标，从当前工作着手，从细节开始提高工作能力，把好的东西沉淀下来。

于是测试部从我开始，每次发版后，都会提供一份测试报告给到项目相关人员。

没想到简短的版本总结得到了意想不到的效果，自上而下都很赞同，抛出的问题也会得到高层的重视，后面的自测、bug推进都得到了不同程度的提升。

所以，在我看来，每次发版后，测试报告的输出必不可少。

言归正传，

那么我写的测试报告具体包含哪些内容呢？

1、产品什么时候通过测试并发版或提审，一般Android和iOS上线时间不一样，所以要分别说明。

这个是整个测试工作的结果，需简明扼要说明，突出重点。

每一版都有个主要功能，所以在App名称后可带上功能和版本号，例如：有书共读Android V2.0.1直播版本于2017年7月20日测试通过并发布上线。

2、注明Android和iOS提测时间，以及分别花费测试时间。

用例评审时间和评审会后小结。

测试用例分别执行多少条？并在附件添加上用例，注明可查看附件测试用例（每一条需注明测试结果）。

3、记录测试人员。

4、本期功能，以列表形式简单总结实现了哪些功能。

5、bug数按平台进行分类统计，用表格记录；

6、bug数按严重程度进行分类统计，用表格记录；

7、Android和iOS测试覆盖到的机型、系统版本与分辨率，用表格分别记录；

8、本期遗留问题统计，需列出来已知未修复的问题，这类问题一般不影响大的功能流程，跟产品，开发讨论后，因各种原因可下个版本再改。

9、针对本期功能的测试过程进行整体分析，测试过程中遇到哪些问题，如何高效解决的？

哪些问题是测试没测到的？原因在哪？项目推进过程中，好的方面和待改进方面？要肯定对的，但是不对的也要提出来晒晒，以求后续测试工作中扬长避短，提高测试效率，保证产品质量。

10、测试报告以邮件方式发送，发送目标是项目中所有人员，邮件结尾注明编写人员和编写时间。

整个测试报告写完要自检，自检完再发给项目中成员（或组长）一起检查无误后再提交，尽量避免错别字之类的，细节决定成败，你的每一次用心对待，相信在经历了岁月沉淀后定会有很多收获。

最后说明一下，一般测试报告在发版前编写完成并发出。

我们是发版后一天内输出，因为产品迭代快，开发测试时间卡的都很紧，所以选择适合自己项目的方式即可。

整个测试报告的编写内容就是这些，欢迎提出异议。

作者：木木0524
链接：http://www.jianshu.com/p/40e1a3b99f16

文章可分享转发；如转载，联系作者授权。

--正文结束--

End，正文结束。

如上文章，来自百人计划成员，作者“木木”，转载联系作者授权。

此篇APP测试报告，毋庸置疑，是一篇非常完整的执行落地分享。非常具备参考性。

希望大家吸取价值，参与讨论。

如果你认为的做法，底部留言。

曾经，老徐分享过一篇测试报告的标准套路。

可以看看，业内通用。

从业多年，依然写不好一份测试报告！归因于此。

End

此文适合所有软件测试从业者阅读，强烈建议。

太多从业者缺乏报告输出的能力。

以为测试只是点点点，发现问题。

完全没有定位问题、追溯问题的能力。

更别说，问题归纳、同步、分析的能力。

测试报告，是一个很好的形式。

别总在那追求自动化测试，自动化，是一种测试手段，能力到了，自然就有了。

大家以为的自动化门槛 “ 脚本语言 ”，并不是门槛。

最后，

文章，如果有帮助，欢迎转发。

谢谢。

写自己认为有价值的文章，每天分享一点点。

邀请你一起加入。

20000名软件测试工程师一起搞事情，你怕不怕？

最后，推荐几篇有价值的文章（得对得起大家打开此文）：

软件测试从业者，Linux知识从入门到玩转（必读）

学会使用Fiddler抓包

如何保证发版质量？

测试用例评审，他们是这样做的。