【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
作为一个曾经是测试萌新的我，在首次接收到一个任务时总有一种忐忑慌张激动紧张期望的复杂情绪~~忐忑慌张紧张是怕自己做不好，得不到领导的赏识；激动期望是哇塞，我有任务了耶，终于有我的用武之地了~~~ 就好比今天的主题，如果一个项目完结后，领导要你独立完成测试报告的整理，你会如何？是胸有成竹呢？还是瑟瑟发抖？
希望看完今天这篇文章的人，都能成为胸有成竹得到领导赏识的优秀新人！
言归正传，直入主题。测试报告具体包含的内容包括以下（不同公司提供的模板或许有不同，但大体都一样）：
第1部分：引言包括两部分1.1项目背景 和 1.2参考资料
1.1项目背景
本测试报告的具体编写目的，指出预期的读者范围。(3-4句)
本测试报告为（系统名称）系统测试报告；本报告目的在于总结测试阶段的测试
及测试结果分析，描述系统是否达到需求的目的。
本报告预期参考人员包括测试人员、测试部门经理、项目管理人员、SQA人员和其他质量控制人员。
1.2参考资料
这里主要包括《需求规格说明书》、测试计划、测试用例、缺陷记录
第2部分：测试基本信息主要包含测试范围，测试方案设计思路
2.1测试范围
| 产品 |
模块 |
子模块 |
功能 |
测试点 |
优先级 |
负责人 |
| QQ邮箱 |
收件箱 |
群邮件 |
群邮件的删除功能 |
1、邮件的删除 2、邮件彻底删除 |
高 |
xxx |
| 草稿箱 |
草稿删除功能 |
1、邮件的删除 |
高 |
xxx |
2.2测试案例设计思路
根据上述测试范围测试点进行测试用例的设计。主要采用黑盒用例设计方法等价类划分法、边界值分析法、错误推测法、场景法。
l 功能测试：确保测试对象的功能正常，其中包括业务流程、数据处理、边界值等功能。
l 用户界面 (UI) 测试：核实用户与软件之间的交互，确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能，确保 UI 中的对象按照预期的方式运行，确保各个窗口风格（包括颜色、字体、提示信息、图标、等等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯
l 流程测试:核实实际业务流程在系统中的完整正确实现。应确保各业务流程内部数据流转及流程之间接口数据的正确，确保角色权限对流程的操作的限制的正确性
l 安全性测试：确保用户、管理员的密码管理安全、应用程序级别与系统级别的安全的安全性
l 兼容性测试：确保系统在各种不同版本不同类项浏览器下均能正常实现其功能
第3部分：测试结果及缺陷分析主要包括测试执行情况与记录、缺陷的统计与分析
3.1 测试执行情况与记录
3.1.1测试组织
| 项目经理 |
软件工程师 |
测试工程师 |
业务负责人 |
3.1.2测试时间
|
测试 阶段 |
计划开 始时间 |
计划结 束时间 |
实际开 始时间 |
实际结 束时间 |
计划工作量（人天） |
实际工作量（人天） |
3.1.3冒烟情况
| 冒烟 测试 |
时间 |
是否通过 |
如不通过，请写原因 |
3.1.4测试用例统计
| 案例总数 |
执行个数 |
成功个数 |
失败个数 |
未执行个数 |
案例成功率 |
3.2 缺陷的统计与分析
缺陷汇总：
总缺陷数：59， 已解决：1，激活：58
缺陷分析：
按缺陷类型统计：
从以上数据得出，大量bug类型为代码问题，只有1个是性能问题
按严重程度统计：
按功能模块统计：
按测试阶段统计：
（以上3种来兴统计及分析都参考缺陷类型统计及分析来整理）
残留缺陷与未解决问题：
| bugid |
Bug描述 |
状态 |
未解决说明 |
（以上这块把所有残留未解决的问题按列表进行整理出来）
第4部分：测试结论与建议包括风险分析及建议、测试结论
4.1 风险分析及建议
（列举测试执行过程中比如因资源不足导致测试覆盖不全的问题，例如app测试过程中兼容性测试，因为公司测试机的缺少，存在测试不完全）
4.2测试结论
本项目根据业务需求及开发人员的反馈意见，覆盖了所有的测试需求及案例，均已在ST环境测试完成，有效案例一共 xx个，执行率 xx%,，成功率 xx%，缺陷关闭率为xx%，目前缺陷均已修复并回归关闭；
综上所述，xx项目达到ST项目测试出口标准，本项目ST测试(通过/不通过)，可以进行验收测试/发布
第5部分：交付文档 将测试过程中所有包括的文档进行交付，主要包括测试计划、测试用例/案例、缺陷记录、测试报告
以上就是测试报告中包含的所有内容，如果刚好你们公司没有模板的话，直接按照这个来写吧，so easy~
==========
来源：oschina
链接：https://my.oschina.net/java1314/blog/3147887