关于测试流程

工作至今，都没有对测试进行过一个很好的总结。感觉还是需要整理归纳一下我对于测试的一些理解，希望这对于接下来的测试工作能有更一步的帮助。可能在有更多经验后，回过头来看，也会有更成熟的想法。

测试流程

系统性的测试流程一般分为以下几个步骤，包括需求分析，测试计划设计，测试用例设计，测试用例评审，测试执行，bug追踪，最后的测试报告总结。
在各个公司的实践形式可能会有出入，但基本上都是这样的主线。

需求分析

需求分析主要是为了了解测试的需求是什么。通过需求文档等资料，或与产品，开发等各方的沟通，测试人员需要对测试的产品有着清楚的认识，从而避免测试遗漏和误解。
如果有详细的需求文档，这对于测试人员来说是一件很友好的事情。但在很多时候，由于各个因素的影响，产品没有提供详细的需求文档，这时候测试人员可以直接参与需求评审的会议。

测试计划设计

在了解需求后，测试团队需要决定怎么测试、明确测试时间、确定测试人员、确定测试环境。同时明确测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。
一般在这个过程中，我会根据需求进行测试点的一个提炼，类似于测试需求点的提纲。

测试用例设计

根据需求文档完成详细的设计用例设计，设计用例一般包含以下几个因素

• 用例编号：一般工具会自动生成
• 用例标题：对用例的一个描述，一般一个行为就是一个用例
• 预置条件：一些前期的准备条件
• 测试步骤：具体的测试步骤，越详细越好
• 测试数据：一些测试数据
• 预期结果：预期的现象
• 优先级：该测试用例的优先级，一般高、中、低三级
• 状态：未执行、执行成功、执行失败等状态
• 分配的执行人：即分配给谁运行
• …

公司都会有专门管理测试用例的工具，包括Testlink，Jira等等，

测试用例评审

在完成测试用例之后，需要对用例进行评审，主要是为了review以下问题

• 测试用例是否覆盖全面
• 是否有较高的可执行性
• 优先级分配是否符合预期
• …

测试执行

在产品正式提测后，测试人员就开始根据测试用例进行测试，测出bug及时提给对应的开发人员。开发人员及时进行修复。

一条bug记录中，应该包含以下一些因素

• 编号：由系统直接生成
• 标题：问题的一个摘要总结，力求简洁明了
• 所属模块：这是被测平台的模块划分
• 发现版本：测试的版本
• 问题描述：出现的问题，可以加上一些截图
• 重现步骤：复现该问题的步骤
• 预期结果：预期的一些现象
• 发现环境：发现该问题的测试环境信息，更详细的可以将浏览器版本等信息均加上
• 优先级：该问题的优先级，一般高、中、低三级
• 严重程度：对平台造成的影响是否巨大，一般分为致命、严重、一般、轻微等
• 创建人：Bug的发现人
• 经办人：即指派给谁
• …

Bug的追踪

每个产品发布都需要进行多轮测试，每轮测试都需要验证前一轮的bug，并对新功能进行测试，同时需要进行一定的冒烟测试。如果时间太短，在发布前无法完成Bug的修复，产品需要评估那些Bug可以留至下一个版本发布。
一般来说，Bug是测不完的。

测试报告总结

在测试完成后，需要对测试进行一个总结，即测试报告的输出。测试报告主要包括以下几个部分：

• 首页
• 引言（目的、背景、缩略语、参考文献）
• 测试概要（测试方法、范围、测试环境、工具）
• 测试结果与缺陷分析（功能、性能）
• 测试结论与建议（项目概况、测试时间、测试情况、结论汇总）
• 附录（缺陷统计）

参考文献

[1]软件测试工作流程概括与总结
[2]测试用例评审过程以及相关人员参与详解
[3]一条缺陷（Bug）记录包含哪些记录