谈谈你对测试的理解
我觉得不管是⾃研产品还是其他产品，测试⼈员都要参加需求评审的会议，⼀⽅⾯，便于了解需求进⽽更好地开展之后的测试⼯作，另⼀⽅⾯测试⼈员往往是从⽤户考虑居多，更加能够从客户的⾓度提出符合实际的建议
2 制定测试计划
待需求最终确定下来，则可以开始制定评测⽅案，
确认测试⽬标，测试范围，测试⽅法，测试策略，资源安排，风险评估等
3 测试⽤例设计
待测试计划拟定以后，可开始进⾏⽤例设计，⼀般先使⽤思维导图整理⼤概框架，在使⽤测试⽤例管理⼯具，按照功能模块，使⽤场景进⾏设计
记住我4 测试⽤例评审
因为⼀个⼈的思想是有局限性的，待⽤例设计好之后，最好项⽬组的所有⼈员都参与⽤例评审，以便查漏补缺，尽可能使⽤例覆盖更全⾯
5 冒烟测试：
待研发⼈员提交版本后，测试⼈员便可以进⾏冒烟测试，当然，冒烟测试的⽤例要提前选好
6 ⼀轮测试
待冒烟测试通过。则可以开始执⾏度⼀轮的测试，发现的bug使⽤缺陷管理⼯具（如jira、resmine、禅
道等）记录下来
7 N轮测试：
如果有必要，可以进⾏第⼆轮，第三轮，第N轮的测试
8 回归测试：
待研发⼈员吧本次序修复的bug都修复完成后，即可进⾏回归测试，主要验证缺陷是否真的修复，知否会影响现有系统的使⽤
9 之后就可以开始撰写测试报告、⽤户⼿册等相关⽂档，测试报告会反应本次测试的⽬标，范围，对象，执⾏过程即结论和风险分析
总结了⼀下，⼤概流程就是这样的：
需求评审（有开发⼈员，产品经理，测试⼈员，项⽬经理）－>需求确定(出⼀份确定的需求⽂档)－>开发设计⽂档（开发⼈员在开始写代码前就能输出设计⽂档）－>制定测试计划，写出测试⽤例－>发给开发⼈员和测试经理看看（⾮正式的评审⽤例）－>接到测试版本（可能测试的代码通过冒烟测试的代码）－>执⾏测试⽤例（中间可能会补充⽤例）－>提交bug（有些bug需要开发⼈员的确定（严重级
别的，或突然发现的在测试⽤例范围之外的，难以重现的），有些可以直接写到TD（Test Director 相当于禅道））－>开发⼈员修改（可以在测试过程中快速的修改）－>回归测试（可能⼜会发现新问题，再按流程开始跑）。