1.调研阶段
这个阶段通常是老板 和 产品经理做的事情，就是调研 想做的产品
- 大体有哪些功能？
- 到底有没有价值？
- 到底能不能做？
2.需求分析阶段
如果调研阶段决定产品要做，接下来就是确定产品的功能。
调研阶段确定产品的 大体功能 ，而需求分析阶段则是确定 具体的功能 。
这个阶段的工作通常是 产品经理 和 开发经理 讨论制定需求细节， 开发人员 和测试人员参与评审。
比如要做一个 K12在线教育 系统， 需要具体实现哪些具体功能，和功能的细节需求。
功能要一一列出来，比如
- 直播课程
- 录播课程
- 学生、老师 注册
- 学生考试
- 每年学生升级
每个功能点要不断 细化 ，直到可以给开发人员没有什么疑问，可以着手开发工作。
这个阶段，测试人员 需要 做如下事情：
评审需求文档通过评审了解需求，甚至参与需求分析讨论，看看 需求有没有错误、矛盾、遗漏的地方。
整理测试需求什么是整理测试需求？
就是通过需求文档的评审分析（产品、开发人员往往写的比较乱，不全面），
从测试的角度进行 需求和场景的分类，其实这是 更加 具体的、有条理的需求文档。
相当于测试用例的提纲，为后续编写测试用例 准备 测试需求，
这个阶段，建议不用写测试用例，因为后续产品的设计、编码阶段，很可能会对产品需求进行返工修改，此时就写测试用例，很可能是无效的。
而且此时，最终产品细节（包括界面、接口）往往都是没有的，也没有办法写测试用例。
3.设计阶段
搞清楚产品设计细节（甚至一部分实现细节）后，测试团队就应该制定 写测试计划 ，编写 测试用例 。
测试计划要完成：
- 评估工作量和人力配备，风险评估，从而确定测试目标
- 制定测试任务（包括指定测试协调人、编写用例、学习和开发测试工具、准备环境），并且分派到人员
- 其他为了实现测试目标和任务确定必要的测试活动。
这些通常都是测试部门领导干的事情，不是本文的重点。
分派给测试人员的任务，其中最重要的就是 编写测试用例。
编写测试用例有很多方法，个人觉得最重要的就是
- 判定表（因素组合法）
- 边界值法
- 错误猜测法
4.开发阶段
开发阶段 当然 就是 开发工程师（码农们）加班加点、没日没夜 的根据设计开发了。
这时，测试工程师不要闲着，有些事情可以做
- 评审测试用例
- 准备测试工具、学习使用测试工具
- 准备测试环境
- 和开发人员保持沟通，因为开发过程中 开发人员随时可能推翻原来的设计，修改功能，你要相应改变测试用例。
5.发布测试版本，测试开始
在正式测试前，往往会有一个 冒烟测试 。
冒烟测试 是 挑选针对 最基本的功能点 的测试用例， 进行的测试。 如果这些最基本的功能点都有问题，测试不通过， 那么后续的大量测试用例 都是没法测试的。 就会立即打回测试版本，要求开放人员改正后，再进行测试。
如果通过了冒烟测试，就可以进入正式的测试环节。
测试过程中发现的问题（bug） 提交到 问题跟踪系统，比如：BugZilla、禅道、Redmine、JIRA 之类，开发人员根据优先级和严重级别 决定下个版本修正哪些bug。
测试过程中，测试人员往往会发现实际的产品实现 和 需求设计文档（或者从开发人员口头了解的）功能不符， 当然也就和你写的测试用例不符。
这时候就要和开发人员确认，要求修改对应文档。测试人员也要相应更新测试用例。
测试结束后，通常会有一个 测试报告 ，给出这次测试的结果的描述，比如：
- 测试覆盖的功能点有哪些
- 总共多少测试用例，通过了多少，不通过的有多少。
- 发现问题，哪些是特别严重的
测试人员往往会在测试过程中发现测试用例有不足的地方，需要及时改进。
6.回归测试
当一轮测试结束后，会发现一批bug，当然开发人员需要修改这些bug。
并不是所有的bug都会立刻修改，根据发现bug的严重程度和出现几率，开发人员确定优先级，修复一批bug。
修改后会发布一个新的测试版本。
测试人员需要根据这个新的测试版本进行测试，这次测试有两个目的
- 验证开发工程师修复的bug正确修复了
- 确保在修复的过程总没有引入其他bug
要确保第二点，就需要在大量的测试用例中挑选 这次修复可能引发问题的地方。
新版本也可能不只修复bug，可能会添加一些前面没有实现的功能点。
如果是这样，测试的目标就不只是 回归测试，还要包括新功能点的测试。
7.发布正式版本
经过N次内部版本的发布、测试后，产品实现的功能越来越多，并且通常bug会越来越少。
到了某个版本，经过评估，如果实现的功能足够，并剩余的bug，不影响产品发布给客户，就会作为正式版本发布给客户使用。
8.功能添加，产品迭代
虽然产品已经正式发布给客户使用了。
但是产品可能还有后续的需求（可能来自客户，也可能来自产品团队），需要在目前版本的基础上继续开发。
这时就会重复前面 从 需求调研阶段 到 发布正式版本阶段的 流程。
9.引入自动化测试
一个复杂的产品，要经过很多轮的回归测试，才能最终发布。
每轮回归都有大量的测试用例 需要重测，防止修复bug的过程中引入新的bug。
这样的反复测试，非常耗费测试工程师的精力。
一个典型的解决方法，就是使用自动化测试系统，代替人工测试。
合理的分批次挑选用例，进行自动化，从而有效的提高测试效率。
挑选哪些用例自动化呢？可以考虑如下因素：
- 需要反复执行的测试用例
- 对应功能点稳定
- 容易自动化
