软件测试大致分为几个阶段
世界万物都要经历的，出生--> 婴儿--> 少年--> 青年--> 中年--> 老年--> 死亡的生命周期
同样，软件测试，也有其生命周期：
- 需求分析
- 测试计划
- 测试用例设计与开发
- 测试执行
- 测试评估
一、需求分析
1 什么是测试需求？
确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where），测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。
2 为什么要做测试需求？
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把“软件”两个字全部替换成了“测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
3 测试需求分析方法
（1） 测试需求分析依据
通常是以被测产品的需求为原型进行分析转变而来，测试需求主要通过以下途径来进行收集：
与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。
与客户或系统分析员的沟通。
业务背景资料。如待测软件业务领域的知识等。
正式与非正式的培训。
其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。
（2）测试需求架构划分
测试需求分析应首先进行测试需求架构划分并先进行评审，通过后才进行后续的测试需求展开分析，从产品整体上考虑有哪些功能、测试类型需要进行分析，列出测试特性列表，也方便下一步展开具体分析。
首先，这里需要对功能进行一下定义以达成共识，功能是指能独立实现一个基本业务处理要求，为了降低测试需求设计的复杂性及依赖性，测试需求架构罗列的功能是指最小功能点，即不可再继续分解。
应用程序：
A.一般是最底层的菜单项为最小功能点，若最底层的菜单项不能体现一个独立的业务流程时，可采用上一层的菜单项为最小功能点。 B. 还有某些比较特殊没有体现在菜单项的功能也需要作为最小功能点考虑，如POS应用程序中交易的冲正功能等。
驱动：一般是以一个API为最小功能点。 然后，再考虑产品实际用户使用的场合及用户特点考虑哪些测试类型，如故障及恢复、功能集成、性能要求、安装测试、软硬件兼容性等，此处需要从产品层面考虑，而不是从功能点层面考虑。
（3） 测试需求分析过程
测试需求收集
测试需求的收集主要通过对测试依据进行分析整理，最后生成一个以测试的观点出发的checklist（检查表），用来作为测试该软件的主要工作内容。检查表的检查要点包括需求的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性：
在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。
测试类型划分
根据测试需求收集获得的checklist(检查表)，对每一条测试需求，从GB/T16260.1定义的软件质量子特性角度出发，确定所对应的质量子特性。即，从适用性、准确性、互操作性、保密安全性、成熟性、容错性、易恢复性、易理解性、易学性、以操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依从性方面的定义出发，确定每一条测试需求所对应的质量子特性。从而对这些质量子特性进行测试类型划分，如：功能测试、易用性测试（安装测试、功能易用性测试、用户界面测试、辅助系统测试）、兼容性测试、可靠性测试、文档测试、性能测试，强度测试等。
测试类型细化
对划分的每个测试类型进行细化。软件测试需求是开发测试用例的依据，测试需求分解得越详细精准，表明对软件的了解越深，对所有要进行的任务就越清晰，对测试用例的设计质量的帮助也越大，详细的测试需求还是衡量测试覆盖度的重要指标，测试需求是计算测试覆盖的分母，没有详细的测试需求就无法有效的进行软件测试覆盖计算。最好达到细化的结果是分支的最末端（测试项）针对的测试目的是单一的最小的功能点的测试，即每个测试项为一个测试功能点。
生成测试需求树
已细化的测试需求中，由于在提取时，可能存在着重复或冗余，需要进行删除和合并需求。删除测试需求中存在的重复的、冗余的含有关系的测试项。如果有类似的测试项，则需要对其进行合并。最终生成测试需求树。
测试风险分析
由于软件的输入、输出、处理存在一定的限制和约束，另一方面由于测试树中进行了必要的删除和合并，这导致测试需求不可能是全面的覆盖，从而形成了一定的测试风险。测试需求中必须对不分析或不测试部分给出相应的风险分析说明。
3.总结
以上主要描述了测试需求相关理论和获得测试需求树的一般过程。为具体项目实施测试中提供了一套获取测试需求树的参考方案。实际的测试类型划分和测试需求树生成的形式或粒度，因项目而不同，需灵活应用。
二、测试计划
定义
那么，什么是测试计划？
测试计划，是一个叙述预定测试活动范围（测试哪些模块）、测试资源（软硬件）及进度安排的文档，它确认了测试项、被测特征、测试任务、人员安排及任何偶发事件的风险。
因此，一份完整的测试计划，应包含产品概述、测试策略、测试方法、测试范围、时间安排、测试人力、风险分析等内容。
对于一个研发团队，测试计划的作用有：
使软件测试工作进行更顺利：
计划使测试工作能够预先安排，为整个测试工作明确方向
能促进项目参与人员彼此的交流：
测试人员能够了解整个项目测试情况，以及项目测试不同阶段要进行的工作等，使测试与开发工作紧密联系
使软件测试工作更易于管理：
上级能够根据测试计划做宏观调控，进行相应资源配置等；其他人员了解测试人员的工作内容，进行相关配合工作，使得资源与变更成为一个可控的风险
接下来，可能会有疑问，测试计划什么时候写？谁来写？
一般来说，测试计划是在需求评审完成后，测试团队对于需求文档没有疑问了，才可以开始编写测试计划。
关于谁来编写测试计划？这项工作，需要编写者对项目非常了解，对测试工作所接触到的方方面面都有系统把握。
因此，通常情况下是由具有丰富经验的项目测试负责人，或者测试负责人来编写。
测试计划编写原则
1、制定测试计划应尽早开始
越早制定测试计划，能从最根本的地方去了解被测对象及其内容，方便后续完善。
2、保持测试计划简洁和易读
测试计划应该能够让测试人员清楚自己的任务和工作安排。
3、尽可能争取多渠道评审测试计划
通过团队中的产品、开发等相关负责人进行评审，发现测试计划中的不足与缺陷，能很好地提升测试计划的质量。
4、计算测试的投入
投入到测试中的项目成本是有限的，在制定测试计划时，一定要注意测试计划的费用情况，要量力而行。
三、测试用例设计与开发
测试人员通过需求分析，了解软件相关功能的测试点，使用在测试计划中确定的测试技术与测试方法，对于已确定的测试条件进行逐步推敲，精炼而设计出来的，重点用于说明如何操作，产生何种结果的测试用例。
当然，一个人的思维往往存在局限性，所以，还需要由产品、开发以及测试团队内部的相关人员一起来评审测试用例，从而提高测试的覆盖率。
四、测试执行
定义：根据编写的测试用例，按照用例步骤进行执行，查看预期结果和实际结果是否一致，如果不一致则为BUG
参考依据：测试用例
执行人：软件测试工程师
开始时间：测试用例编写完成并且通过评审，且达到测试执行的启动条件
时间周期：占整个测试流程的40%的时间
测试用例执行结果状态：
new：用例编写完成，未开始执行状态
pass：用例执行结果与预期结果一致
fail：执行用例结果和实际结果不一致
block：因为软件缺陷导致后续用例执行无法进行，导致结果未知的状态
investigate：测试用例正在执行中需要更多时间观察结果
测试执行中的注意事项：
搭建软件测试环境
测试用例需要全部执行
不忽视任何偶现BUG
加强测试过程中的记录
提交缺陷和开发关系处理恰当
提交一份优秀的问题报告单
及时更新测试用例
缺陷分布的特征：
缺陷的群集现象
随着测试的进行，缺陷也越来越难被发现，此时需要调整测试思路，寻找新的突破点
不是所有的BUG都需要解决
（1）修改代价太大，不值得修复
（2）修改时间不够，并且遗留的BUG不会影响版本发布新功能
出现幽灵BUG的处理方法：
对出现的BUG进行记录，保留证据（视频，截图，抓包，日志文件）
尝试重现BUG，如果重现就提交BUG单
如果失败就在其他设备上尝试重现
如果还是失败，就请开发进行定位
开发也无法重现BUG就挂起BUG单，观察程序后续版本是否存在
五、测试评估
1.测试评估标准
（1）标准应用场景
用于评估需求/项目/迭代是否需要测试介入
（2）标准详情（标准值制定未有数据依据，可根据执行效果进一步优化调整）
满足任一标准，即需测试介入，同时参考开发人员的意见。
影响程度
关联影响模块：3个或以上
功能使用人群：部门及50人以上
功能使用人职级：经理级或以上
成本影响：涉及较大金额、公司/部门形象、出错后数据无法修复或修复成功高(数据量大等)
控件、框架、公共模块调整
复杂度
对数据库表字段(类型、长度)进行修改
所改模块及关联模块，非本人开发
与其他系统存在对接情况的
涉及复杂的逻辑或计算公式
介入成本/产出比
无需测试介入的标准：
权限更改：菜单权限、按钮权限、数据权限
界面调整：布局、排序
前端简单逻辑调整：如必填项调整等
2.过程规范
无需测试介入，但需做到以下：
需求文档完整，记录到JIRA需求中，对接测试需知悉。
测试人员在时间许可时提供测试用例，协助开发人员、产品经理及用户进行测试及验收。
自动化覆盖情况下，进行功能回归；未覆盖情况下，评估影响范围。