转行测试。从一本书、一门考试、一遍咨询之后，便开始了测试之路的摸索。
重画已走过的路线，希望得到指点，少走冤枉路。
起点：最基本（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关闭后。把运行失败的用例运行一遍，直到全部运行成功。主要功能的用例，不管之前运行成功与否，也全运行一遍。
此流程规范根据工作实际情况制定，希望得到同行们的建议，提高效率。
一个人走起的测试，很多不确定性，亟需得到认证。
