-
项目经理：对整个项目负责，是所有人的直属领导
-
产品经理：负责对软件要做成什么样子进行负责，画原型图
-
开发
-
测试
-
运维：对项目硬件进行管理
-
UI设计：画设计图
-
运营
软件的研发过程：公司领导告诉项目经理，需要做一个xxx项目，项目经理接受任务告知产品经理，产品经理开始画原型图，画好图之后给项目经理查看，没问题后项目经理召集开发、产品经理，测试、UI开会，产品经理讲解原型图，everybody提问讨论，讨论好之后后端开始设计数据库之类的，测试开始编写测试用例，等UI把设计图做好之后，前端也开始干活了，最后前后端代码写好之后，项目交付给测试，一轮一轮的测试and开发修改，直到测试找不出问题，测试把项目交付给运维，运维把正式的环境搭建好，交付给运营，运营就开始做宣传
二、测试流程
1、需求分析阶段
①拿到需求（需求指的是原型图——最好、需求文档、口述）
②分析需求：
-
熟悉需求
-
理清项目业务流程：通过画流程图可以很好地理清——圆形：开始和结束；菱形：判断、分支；矩形：过程
-
确定项目中存在的每个功能点：通过画思维导图，注意要找到最小的功能点
前台提取功能点可以根据上一步的业务流程图灵活来理，也可以根据页面从上至下，从左至右提取；后台功能点的提取一般就是根据CRUD的方式提取
-
确定每个功能点的具体的规则和要求 ：就是根据功能点，扩展开来的详细的功能及其规则和要求。
一般在产品原型图上不能体现出来，我们需要去问产品经理或者根据自己的经验，也可以参考同类型的成熟的功能设计来了解规则
③整理成需求分析文档
2、测试设计阶段（文档的编写）
①测试计划
②测试策略：
-
-
不需要测试的内容及原因；
-
哪些内容先做测试哪些后做；
-
风险分析——找出有可能会遇到的问题且做好预备方案，例如需求风险（需求变更、新增需求）、人员风险（人手不够、技术风险）、硬件风险（服务器坏了）等
③测试方案：对每部分测试的内容（如兼容性测试、UI测试部分）制定具体的方案
④测试用例
- 写测试用例的工具：Excel（最好用）、禅道、ALM等
- 测试用例内容：编号（唯一不重复，不一定只要求数字），用例标题（言简意赅，一个场景就是一条用例），前置条件，优先级（和时间有关），重要级（和功能是否核心业务有关），测试数据（控制变量法），测试步骤，预期结果，实际结果（此处写测试用例时先不写，等之后测试执行的时候再写）
注：测试计划、测试策略、测试方案一般都由测试组长编写，测试策略和测试方案就是对测试计划的补充，有的公司都直接合写成一个测试计划书，测试计划根据5W1H编写
3、测试执行阶段
①执行测试用例
②bug的跟踪管理
- bug管理工具：禅道，ALM（老版本交QC），bugfree，testlink，jira，bugzilla等
- bug生命周期（面试常考题）
- bug的常见状态：新建，已确定，拒绝，已解决（fixed），关闭（closed），reopen
- bug的六要素：bug编号，bug名称，优先级，严重级（bug的等级），复现步骤（要写清楚），附件（对bug的佐证，一般可以是截图，视频，错误日志等）
- bug的等级：致命的（和钱有关的任何bug、导致了软件无法正常使用、导致了核心业务流程无法推进），严重的（核心功能有问题、正向场景有问题），一般的（普通功能以及逆向场景有问题），轻微的（UI，易用性等等）
③对测试的迭代管理
- 第一轮测试的时候，测试会提出很多bug给开发，开发修改完之后发布新版本并重新指派给测试，测试完成回归测试，这就是一次迭代。
- 迭代分为版本迭代（开发发布新版本）和测试迭代（拿到新版本，又重新做一次测试），在版本迭代的过程中，有一个很重要的事就是更新测试环境（开发会把新的代码给测试，测试需要删除原来的代码将新的代码部署到环境中，如果是APP的话就是需要安装新的APP），一般又把更新测试环境叫做测试环境的维护。
- 迭代周期，一周迭代一个版本，实际会迭代多少次？这个就不确定了，如果软件是在开发过程中，开发一边做一边测试，这个就会有很多次，如果是产品出来了才开始测试，一般会有4-5轮测试。
- 测试迭代会分为两种，一种是全量测试（在完成回归测试之后，再把整个软件再全部整体测试一遍，因为开发都不确定他改的代码会不会对其他的功能产生影响），一种是增量测试（当被测软件达到一定体量的时候，做全量测试就显得不那么合理了，需要做增量测试，即只测试开发新增和修改的功能，但是如何判断开发修改的代码是否会对其他功能模块产生影响呢，这个时候就需要引入自动化测试了——由自动化去帮忙处理测试以前那些已经测试通过的功能）
4、测试总结阶段（职场中，测试报告抢着写）
可以每个版本总结一次，整个软件开发结束总结一次。
- 做测试报告中，应该包括工作总结，bug的统计与分析（可以以bug等级，各功能模块的bug，不同测试提出的bug，不同开发出现的bug，不同开发解决的bug数，不同版本发现的bug等维度考虑），质量评估（一共有多少需求，已经完成了多少，还有多少没完成；目前还有多少bug是打开的，已经关闭了多少bug；得出结论：下一个版本应该怎么去做，怎么提高工作效率）
软件评估是有一定标准的，这里的质量评估是由测试来决定这个软件是否已经做完，评估标准：所有需求都完成了或者所有的123级bug都关闭了，之后就可以交付了。
三、一个优秀的测试人员的个人修养
1、开发能力
2、文档能力
依据5W1H——六合分析法来编写测试的一系列文档
-
what：测试的对象，测试的项目，测试的内容的介绍
-
where：测试环境，相关的文档资料的管理
-
when：时间安排
-
how：具体的测试方法
-
why：为什么要这么去做
-
who：人员安排
| 测试阶段 | 输入 | 输出 |
| 需求分析阶段 | 原型图/需求文档 | 业务流程图、功能点的思维导图、需求分析文档 |
| 测试设计阶段 | 业务流程图、功能点的思维导图、需求分析文档 | 测试计划、测试策略、测试方案、测试用例等文档 |
| 测试执行阶段 | 测试计划、测试策略、测试方案、测试用例等文档 | bug |
| 测试总结阶段 | bug | 测试报告 |