测试流程及规范
date:2017/8/26
目的
侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问题不在本文档描述范围内。
本规范作为所有测试组成员工作前必须掌握的工作规范，以便于组间的协调沟通，更好的合作完成产品的研发工作。
测试类型和测试方法
测试工作通常分为4个类型，功能测试、联合测试、性能测试及稳定性测试。
| 测试类型 | 测试意义 | 测试方法 |
|---|---|---|
| 功能测试 | 确保功能符合需求定义和所有功能可以正常完成工作 | 以手工黑盒测试为主，手工执行功能测试用例 |
| 联合测试 | 一个新产品或一个产品的新版本发布时，要确保与之相配合的产品可以正常配合使用 | 正规测试和随机测试相结合 |
| 性能测试 | 在产品有性能要求的部分，进行性能测试和调优，确保产品性能符合需求 | 产品在特定工况下可以达到的最高性能（如：测试时将日志等影响性能的选项关闭)与模拟用户真正的使用环境(如：日志功能打开，在一定的用户数量的情况下),产品真实可以达到的性能 |
| 稳定性测试 | 模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行 | 稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保产品可以稳定可靠的长时间运行 |
黑盒测试过程的参考准则：
（1）必须采用边界值分析法；
（2）必要时采用等价类划分法补充测试用例；
（3）采用错误判断法，追加测试用例；
（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当补充更多的测试用例；
（5）测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证测试人员要求
注意：以下为暂定的测试人员要求，如有问题可以提出，大家共同讨论。
测试按照不同的要求会出现在产品开发的不同阶段，所以应按照项目要求决定需要进行何种测试。
确定测试之后参照以下内容执行：
要求
测试前
- 测试人员应按项目需求制定测试计划。
- 测试工具与测试环境应与开发人员或组长进行沟通决定。
测试时
- 测试Bug的描述与具体要求
- 提交的 Bug 一定要描述清楚，写清楚测试环境、操作步骤、Bug 现象与正常的区别。
- Bug级别要按照下面的 Bug 级别表来执行，不要随意填写。
- 避免有共性的 Bug 多次提交，只需提交一个并阐述清楚。
- 对发现的 Bug 做初步的判断并分析原因。
- 遇到不确定的问题应该整合到一起与开发人员沟通再确定。
- 测试的 Bug 要统计到一起提交，切忌一边测试一提交与沟通。
- 应该多与开发人员交流，了解开发思路寻找测试盲区，同时也帮助开发人员整理开发思路。
- 如出现 Bug 修复不完整或没有修复，请与开发人员沟通。
测试后
- 测试人员应定期统计开发人员表现发送给项目负责人。
- 测试报告应包括《每日测试报告》、《阶段性测试报告》和《版本测试报告》
- 如有测试任务，可以每天汇报《每日测试报告》，汇报 Bug 状态。
- 项目每完成一个小模块可以进行《阶段性测试报告》的汇报。
- 项目的版本更新则需要《版本测试报告》的详细而全面的汇报。
- 过程改进在测试实施阶段工作全部结束以后进行。它的目的是评估本次测试工作，总结经验，使下一次的工作做得更好。本项工作不是一个必须的过程，各项目可根据情况采用。
Bug 级别
| 编号 | 等级 | 位置 | 描述 | 图片 | 状态 |
|---|---|---|---|---|---|
| 1 | 重度 | ||||
| 2 | 中度 | ||||
| 3 | 轻度 | ||||
| 4 | 建议 |
重度
阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷。
- 包括但不限于：服务崩溃、功能丧失、页面丢失、数据丢失、死循环、功能卡死、无返回信息、数据泄露、机器宕机、权限泄露、安全漏洞、提权漏洞、数据库注入、易爆破、严重的计算错误等。
中度
Bug导致失去系统主要功能，基本功能能不能完整使用。
- 包括但不限于：轻微计算错误、操作时间长、反应慢、弹框出错、不稳定等。
轻度
操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现。
扫描二维码关注公众号，回复：
5507151 查看本文章
- 包括但不限于：界面出错、错别字、样式出错、排列杂乱、提示模糊、图片不清等。
建议
不影响使用的瑕疵或更好的实现等。
- 包括但不限于：颜色选择、样式更改、使用习惯、用户体验、顺序调整等。
此为小编入门测试整理的一些心得，若有借鉴处望能帮到大家。