软件测试的6个基本流程阶段
1. 需求分析阶段：
阅读需求，理解需求，主要就是对业务的学习，分析需求点。
1.1 需求定义
软件需求：是对系统运行方式或系统特征和属性的具体描述
(1) 用户解决问题或达到目标所需条件或功能。
(2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或功能。
(3) 一种反映上面(1)或(2)所述条件或功能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是相关人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
1.2 需求分析步骤
仔细、反复阅读需求文档，深入理解
分析整理测试点：
列出所有可测的功能点或测试点
对每个功能点进行分层分析
分析功能点之间有哪些关联关系
考虑有哪些可能的异常流程（可画流程图）
网络环境：网络中断、网络切换、丢包延时
服务器资源：服务器无响应、响应慢、无法连接服务器
系统环境：被测系统文件缺失、PC或手机系统缺少必要组件、权限不足
异常中断：断电、通话中断
找到隐藏需求：
了解需求整体架构
熟悉所有实现细节
代入用户角色，实际场景中推测
1.3 需求分析内容
功能性需求
功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。相关人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。
非功能性需求
作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。
设计约束
一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。
2. 测试计划阶段：
主要任务是编写测试计划，测试计划就是描述所有要完成的测试工作，可参考软件需求说明书，项目总体计划；包括被测试项目的背景、目标、进度安排，人力物力的分配，测试有关的风险。一般有测试主管编写，当然我们也会参与相关的评审工作。
2.1 测试计划内容
概述：概括描述产品\项目，阐述主要功能
测试目的：明确本次测试的目的
测试方法：单元测试、系统测试、验收测试、回归测试
测试环境：测试环境的描述，包括硬件配置及需要的软件环境，包括服务器端、客户端等
测试范围：测试点列表
2.2 测试计划目的
为了更好的管理整个测试工程，以及及时反映测试中遇到的问题。
3. 测试方案阶段：
主要任务是编写测试方案，测试方案就是描述所测软件的测试特性、测试方法、测试用例设计、测试代码设计、测试环境规划、测试工具等。
3.1 测试方案内容
测试需求分析：尽可能在项目前期发现项目存在的潜在缺陷，查看需求原型、UI设计图
测试策略：要进行哪些测试？功能、性能、安全、兼容性、界面
测试资源：人员列表
测试进度安排：时间计划
风险预估：比如时间紧，资源有限，可能造成测试不全面，相应的预案
质量：质量标准
3.2 测试方案目的
在方向上明确要测什么、怎么测，以及达到什么样的质量标准。
4. 用例设计阶段：
主要任务是编写测试用例，会参考需求分析、概要设计、详细设计等文档，有不明确的也会及时和产品人员沟通。用例编写完成后会进行评审。
4.1 测试用例定义
测试用例是一份测试文档，它描述输入、动作和一个期望的结果。
4.2 测试用例目的
确定应用程序的某个特性是否正常的工作。
4.3 测试用例要素
包括测试用例编号、测试用例标题、重要级别（优先级）、测试数据输入（前置条件）、操作步骤、预期结果。
5. 执行阶段：
首先搭建测试环境，执行测试，以判定当前版本可测与否，如果预测通过，正式进入系统测试，遇到问题提交bug到缺陷管理平台，并对bug进行跟踪，直到被测软件达到测试需求要求，没有重大问题，测试结束。
5.1 缺陷的定义
软件未实现需求说明要求的功能
软件出现了需求说明指明不该出现的错误
软件实现了需求说明书未提及的功能
软件未实现需求说明未明确提及但应该实现的内容
软件难以理解，不易使用，运行缓慢，或者最终用户认为不好
测试用例执行中发现的与预期结果不符的现象
5.2 缺陷不修复的原因
没有足够的时间
不算真正的软件缺陷
修复的风险太大
不值得修复
5.3 缺陷的生命周期
5.4 缺陷的状态
New：测试中新报告的软件缺陷，等待分派
Open：已确认的缺陷，等待开发人员修改
Fixed：已经被开发人员修改的缺陷，等待测试人员校验
Rejected：不是缺陷或不需要修复
Reopen：没有修复，重新打开返回开发人员
closed：已经被测试人员确认得到正确修复，可以关闭
5.5 缺陷的等级
致命：软件无法运行或者软件的主要功能，主要业务流程无法运行
严重：软件的次要功能或者基本功能无法使用
一般：不影响执行工作或功能实现，类似操作界面、提示文案不规范、细节问题
轻微：建议类或优化类的问题
5.6 缺陷的基本要素
缺陷ID、缺陷标题、测试环境、缺陷发现的时间、缺陷提交人、缺陷的优先级、缺陷的严重等级、测试类型、发现缺陷的软件版本、缺陷复现步骤、期望结果、实际结果、附件
5.7 执行测试
执行测试用例，并记录结果
提交BUG至缺陷管理平台，指派给相关人员
跟进BUG的修复情况，保持和开发沟通
回归测试，验证BUG
6. 测试报告阶段：
输出测试报告，对整个测试的过程和版本质量做一个评估。
6.1 测试报告内容
数据统计：人力投入（用例设计和测试时间）、用例覆盖率、BUG严重级别统计、 BUG类型统计、BUG状态统计、BUG根源分析
遗留BUG情况：描述遗留的BUG，影响程度、后续的解决措施
测试风险：描述存在的测试风险
测试对象评估：评估是否符合上线条件
测试结论：最终的结论
6.2 测试报告模板
报告名称（软件名称+版本号+XX测试报告）
版本历史
目录
引言
测试人力统计
缺陷统计
测试风险
测试结论
