测试流程初探

转行测试。从一本书、一门考试、一遍咨询之后，便开始了测试之路的摸索。

重画已走过的路线，希望得到指点，少走冤枉路。

起点：最基本（LOW）的Web功能测试（无技术含量，不得不使用这个描述，很沉重）

工具：禅道项目管理软件

测试流程：

（一）熟悉被测试系统

读需求文档，与需求人员确认有疑问的需求

（二）制定测试计划

1. 制定测试计划模板；

2. 测试计划内容，主要确认：测试范围、测试方法、测试工具、测试提交物、测试进度，这几项是每个项目都不同的。其他差异性不大的内容（如测试通过准则、风险和应急等），参考相关网络资源给出的标准。

（三）测试需求分析

1. 分模块

2. 提取功能点，写测试点

（四）测试需求分析组内评审

审核所写测试点是否完整，确保达到足够的覆盖率。

（五）设计测试用例

1.下载禅道的用例模板，编写完用例再上传至禅道管理；

2.测试用例的编写，需遵循一定的规范。

（六）执行功能测试

执行逻辑功能测试、界面测试、易用性测试、兼容性测试

1.在禅道运行测试用例并转bug

2.运行完所有用例，再进行随机测试，新增用例并提bug

（七）整理、上报测试结果

1.统计用例的执行情况、bug的分布情况；

2.提交缺陷详细列表、测试报告。

（八）回归测试

1.推动并跟进bug的解决，验证bug的解决，关闭bug；

2.重跑测试用例。

禅道工具相关使用规范：

（一）用例

1.用例标题、内容描述要简洁规范，一看就懂；

2.注明用例的优先等级；

3.运行用例时，若发现用例描述的UI名称、样式跟实际开发结果差异较大，要找需求人员进行确认：确认通过，则对用例进行修改；确认不通过，则提bug；

4.运行完一个模块的用例，思考是否需要添加新的用例；

5.测试输入数据要规范：

（1）尽量使用规范的名称。

譬如：姓名，使用常用的人名；部门，使用常用的部门名。

（2）影响界面美观的输入数据，酌情删减。

譬如：做完超长字符串的验证，没出现bug的，尽量把超长字符串删除，不影响界面整齐。

（3）尽量保留测试输入数据，方便开发人员确认bug。

（二）Bug

1. Bug标题、内容描述要简洁规范，一看就懂；

2. 兼容性的Bug，标题格式突出关键字，方便开发人员区分、指派人员解决

如：兼容性【IE11】-用户列表-新增操作，弹窗中的按钮错位

3. Bug截图建议做上标记，突出问题所在；

4. 注明Bug的严重程度；

5. 用例转Bug，Bug标题必须重新修改；

6. 发现Bug，此Bug没有对应的用例，需先添加用例，再转Bug；

7. Bug有属主。谁提的Bug，需每天跟进直到Bug解决。若有新任务在身，也要保持跟进所提Bug，或交接他人跟进；

8. 建议开发人员在禅道提交Bug的解决方案时，在备注栏填写此Bug的类型，便于后期的缺陷分析，及为提高开发质量提供参考数据。

9. 所有Bug关闭后。把运行失败的用例运行一遍，直到全部运行成功。主要功能的用例，不管之前运行成功与否，也全运行一遍。

---

此流程规范根据工作实际情况制定，希望得到同行们的建议，提高效率。

一个人走起的测试，很多不确定性，亟需得到认证。

---