软件测试流程
测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议
测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。
测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。
测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束
测试评估阶段：出测试报告，确认是否可以上线
- 测试需求分析：
为什么测试人员要参加需求分析？也就是进行测试需求分析的目的是什么？
第一、把用户需求转化为功能需求：
1）对测试范围进度量
2）对处理分支进行度量
3）对需求业务的场景进行度量
4）明确其功能对应的输入、处理和输出
5）把隐式需求转变为明确。
第二、明确测试活动的五个要素：
测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
怎么进行测试需求分析？
第一、确认功能（业务功能、辅助功能、数据约束、易用性需求、编辑约束、参数需求、权限需求、性能约束）：
1、业务功能：与用户实际业务直接相关的功能或者细节
2、辅助功能：辅助完成业务功能的一些功能或者细节，例如：设置过滤条件
3、数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围，数据之间的关系等
4、易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，例如：快捷键等
5、编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束条件，例如：只能输入数字等
6、参数需求：功能的细节，在功能执行时，需要根据参数设置不同，进行不同处理的细节
7、权限需求：功能的细节，在功能执行的过程，根据不同的权限进行不同的处理，不包括直接限制某个功能的权限
8、性能约束：功能的细节，执行功能时，必须满足的性能需求
第二、场景分析
- 考虑场景的调用者：
考虑每一个场景提供的服务是供哪些外部模块或者系统调用的，找出所有调用者。调用前提，约束都要考虑。每一个调用都可以考虑成一个大的业务流程（一般和外部有交互的业务出错率比较大，需要重点关注）
2考虑系统内部各个场景之间的：
形成内部业务流程，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图
第三、挖掘隐性需求
这需要测试工程师的经验积累：
- 常用的或者规定的业务流程
- 各个业务流程分支的遍历
- 明确规定不可使用的业务流程
- 没有明确规定但是应该不可使用的业务流程
- 其他异常或者不符合规定的操作
- 测试计划：
1.明确测试目标，确定测试需求。根据当前测试工作目标不同，测试需求的确定方式有所不同。如当前为新项目的测试工作，则测试需求可能为该项目能按时上线并按用户需求的功能正常使用等；而对于产品的阶段性测试，测试需求可以以列表形式展现，列表可以列出本次测试工作所需要测试的更新及影响的测试点等。
2.制定测试策略的时候，需要考虑：
根据测试项目特点，确定本次测试需要经历的测试阶段。确定测试阶段后，确考虑每个测试阶段的目标、进入条件及退出条件（完成标准）。
根据确定的测试阶段，分析每个测试阶段需要包含的各种测试类型，如是否需要性能测试、安装测试等。确定测试类型后，确定每种测试的测试目标、测试方法、完成标准及特殊事项考虑。
确定测试阶段、测试类型后，针对需要，确定测试方式及测试工具。
特别的：在考虑测试策略时，还应结合系统的特点及系统功能的优先级及难易程度，分析各项测试的重点及难点。另外，根据测试时间的长短不同，测试策略也需要有相应体现。
3.确定测试资源：测试资源的确定，需要充分调研，基本确定系统规模、功能复杂度、系统运行环境等，结合测试策略，考虑所需要的测试资源。确定测试资源，主要包括：
明确测试过程中角色分配。这点在测试计划阶段必须明确到人的是测试负责人这个角色。其他角色，如测试参与人员，可以不明确到具体的人员姓名。
明确测试人力资源及测试环境：考虑人力资源时，需要考虑所需人力资源的数量、各人力的知识或技能程度等。在测试计划阶段，测试负责人就可以开始协调测试资源，需要在该阶段就确定测试资源，包括人员资源及环境资源。有些项目可能测试资源比较紧张，测试计划制定者在制定计划时应该考虑最少测试资源与充足测试资源这两种条件下的测试策略调整。
4.测试里程碑设计：一般测试里程碑在模版上已经列示出来，测试计划制定者按照之前分析的测试需求、确定的测试策略及明确的测试资源，作相应的风险分析，从而确定测试里程碑及里程碑的起始时间。在制定里程碑起始时间时，可能出现项目留给测试的时间在当前实际下不足，则应及时与项目经理沟通或者重新考虑测试策略或者重新调配资源。
5.测试管理及任务的制定：这部分内容的计划，对顺利完成测试任务，保证计划执行有着重要意义。这部分内容，主要包括接收测试条件、测试时间（测试轮次）的设计、测试人员任务的分配、测试过程管理策略、测试完成标准确定及测试过程评审机制。这里，主要对测试时间、测试人员任务、测试过程管理作特别说明：
（1）测试时间设计和测试人员任务分配可以作为一体考虑。测试计划制定者需要有运筹的思想，根据当前测试资源的状况结合测试策略，确定测试需要经历多少轮次，各人员分别承担什么样的测试任务。测试计划制定者应该始终明确，成功的测试工作是用尽可能少的时间发现最多的缺陷。对于测试时间的评估，可以根据编写的文档页数、测试用例条数、执行测试用例数量及回归测试大约用时来衡量。但是目前工作中，除了上述标准，还应按项目实际情况和计划制定者的经验综合考虑。
测试轮次设计：设计测试轮次时，一般必须有回归测试环节。回归测试之前往往会经历多轮测试。但是建议不要设计太多轮次测试，以避免资源耗用过于频繁。每一轮测试都应有各自明确的目标与测试策略。如第一轮保证功能正确，第二轮保证流程顺畅，性能稳定等。最终应该设计回归测试环节，保证之前缺陷被正确修改，在该阶段还可以配合进行安装测试。如果系统庞大或测试工作复杂，对每一轮次测试，可以单独做小的测试计划，保证更好的测试效果。在测试时间控制上，应该略微预留一点时间，以控制突发事件。
在测试任务设计上，需要统筹分析考虑，合理安排人力资源。每个人测试什么任务，和谁一起承担，都应有特别的考虑；测试任务分配要均衡，避免出现一些任务特别紧张，一些任务很快完成的情况。
（2）测试过程管理设计中，需要考虑BUG管理流程，项目测试进度控制。
BUG管理中，需要考虑： BUG管理的工具是什么，BUG管理系统中各角色人员的权限是什么（测试准备一部分），研发人员解决BUG花费的时间限制，研发人员反馈BUG修改的规范、测试人员确认BUG的时间限制。总之，需要制定一个BUG管理流程，从一个BUG产生到BUG关闭这个流程中，所经历的过程规范。
测试过程管理规范的约定：如是否采用周报制度，对于项目较紧时是否采用日报的形式。对项目组成员可以要求进行日志形式提交测试情况等。
三、测试用例设计
测试用例是测试工作的最核心的模块，在执行任何测试之前，首先必须完成测试用例的编写。测试用例是指导你执行测试，帮助证明软件功能或发现软件缺陷的一种说明。用例设计好后进行审核。这个地方该讲的东西就多了，如何设计测试用例，设计测试用的方法，怎么进行测试用例的审核等等。
第一、如何进行测试用例的设计
编写测试用例之前我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。
步骤：
1、测试需求分析：从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。
2、业务流程分析：分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：
A、 主流程是什么?
B、 条件备选流程是什么?
C、 数据流向是什么?
D、 关键的判断条件是什么?
3、测试用例设计
完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。设计测试用例的常见方法：1）等价类 2）边界值 3）因果图 4) 判定表 5) 状态迁移 6) 正交实验 7) 场景法 8) 错误推断（注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类）
4.编写完成后自我检查以及部门内部评审：
1）测试用例本身的描述是否清晰，语言准确；是否存在二义性；
2）测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；
3）测试用例中使用的测试数据是否恰当，准确；
4）测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；
5）是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；
6）画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；
7）测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。
具体详细内容可参考《如何有效的进行测试用例评审》
5.测试用例更新完善
测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。
四、测试用例执行
首先搭建测试环境，准备好测试数据，进行预测，预测通过之后，按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。根据个人测试工作经验，好的测试执行应该包含如下内容：
1、测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。
2、测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。
3、未执行用例、标志为删除或者无效的用例，需注明原因。
4、执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。
5、测试执行需对用例描述的检查点逐一检查，避免遗漏。
6、重视不易重现的缺陷场景，可能是一个bug。
7、执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。
8、建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。
9、如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。
10、已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。
11、跟踪问题单修复情况并回归验证问题单。
12、每轮次测试结束，find一下是否有core文件产生。
13、测试结束，将最终测试用例文档上传到归档目录，实现用例重用。
以上是争对一般的软件测试流程，如果是自动化测试得话，应该还有根据测试用例进行脚本编写，运行脚本等。此处可能写的不详细，希望大家可以再下方评论让我完善。
在测试用例执行过程中，包含了：功能测试阶段、缺陷跟踪阶段（bug tracking）、回归测试阶段、系统测试阶段、验收测试阶段等（系统已满足测试条件（开发完成），按照已经评审过的测试用例依次执行，执行过程中及时记录问题，将问题及时提交到QC上，要跟踪缺陷。等开发修复后进行回归测试，确认修复后关闭缺陷，如果说该问题要更新而生产上未进行验证，就把缺陷状态改为生产未验证。对有异议的缺陷经甲方、开发和测试三方进行沟通讨论，由甲方最终确定处理方式。在测试过程中也会碰到对需求有异议，会反馈给经理，由经理与甲方沟通来对该需求提出一些可行性建议，最终还是由甲方来确定具体根据各个公司的业务流程而不一样）。
五、测试报告
测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。
测试报告的内容可以总结为以下目录：
首页
引言（目的、背景、缩略语、参考文献）
测试概要(测试方法、范围、测试环境、工具)
测试结果与缺陷分析（功能、性能）
测试结论与建议（项目概况、测试时间 测试情况、结论性能汇总）
附录（缺陷统计）
至此并不算最后的完结工作，软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议 等。这样才算是软件测试最终结束，软件测试是贯穿于整个软件生命周期的。