测试从需求分析开始介入，测试人员参与需求的分析活动，确定测试的需求。需要了解测试需求及测试进度，即需要验证什么功能需求点，采用什么测试策略，描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）。详细阅读分析需求文档，进行逻辑梳理并勾勒出功能的大概流程图；与产品经理等相关人员探讨表述不清楚的地方，细化业务流程；考虑正常流程中的测试难点；考虑与其他功能的关联；考虑非正常流程；考虑版本数据兼容。

目标：

（1）理解产品的设计意图和设计思路。

（2）功能确认，充分理解个功能的细节。

（3）根据功能的大小、复杂预估测试需要的工具、环境、时间

1.2 项目整体计划及评审

测试计划在需求分析完成后，程序修改完毕前准备。测试计划要描述测试活动的范围、方法、资源和进度。

目标：

（1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。

（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。

（3）开发有效的测试模型，能正确地验证正在开发的软件系统。

（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。

（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。

（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。

输入：

项目计划和测试需求

输出：

《项目测试计划》

《项目测试计划评审会议纪要》

1.3 测试用例设计及评审

内容：使用各种测试用例设计方法进行用例设计。测试用例的基本要素包括测试用例编号、测试标题、重要基本、测试输入、操作步骤、预期结果等。

测试用例文档是“活的”，测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

目标：

（1）使测试用例反映不同的场景、条件或经由产品的事件流

（2）测试用例必须要能完整覆盖测试需求

输入：

测试计划

输出：

《项目测试用例》

《项目测试用例评审会议纪要》

1.4 测试执行

当测试用例编写完成通过评审后，并已提交的可测试的系统，然后按照测试计划和测试用例搭建测试环境，开始测试执行。对修改的bug进行回归测试。

测试的具体步骤：

（1）建立测试系统，搭建测试环境

（2）准备测试材料、测试工具

（3）执行测试

（4）验证预期结果，测试不通过，反馈回给编码人员修改。代码修改重新提交后，返回2继续

（5）记录缺陷

（6）评估测试需求的覆盖率

（7）分析缺陷

测试开始标准：

（1）测试计划评审通过；

（2）测试用例已编写完成，并已通过评审；

（3）存在已提交的可测试的系统；

（4）测试环境已搭建完毕。

测试退出标准：

（1）测试用例全部通过；

（2）存在的问题已得到合理的处理。

测试停止标准：

（1）近半数以上测试用例无法执行；

（2）测试环境与要求不符；

（3）开发中需求频繁变动。

目标：

（1）所有的测试用例都被执行，并每条用例至少被执行一遍。

（2）存在的问题已得到合理的处理。

输入：

测试用例

测试环境

测试脚本

输出：

《测试执行记录》

《系统bug清单》

1.5 测试评估

测试报告是对测试过程和测试结果进行分析和评估，确认测试计划是否得到完整履行、测试覆盖率是否达到预定要求并最终在报告中给出测试和产品质量的评估结论。

输入：

《测试执行记录》

《系统bug清单》

输出：

《测试报告》

1.6 产品试用及客户培训

软件部署后，给客户提供产品试用，给客户做相关培训。

输出：

《用户手册》

《客户培训PPT》

2 软件测试阶段

软件V模型结构图如：

2.1 单元测试

主要是测试程序代码，为的是确保各单元模块被正常编译。有具体到模块的测试，也有具体到类、函数的测试等。——一般是由开发来完成

2.2 集成测试

单元测试后，将各单元组成完整的体系，测试软件单位之间的接口是否正确，数据能否正常传递。——比如注册和充值这两个功能能否连通

2.3 系统测试

把软件系统搭建起来，按照《软件规格说明书》中的要求对各项功能进行测试，看是否符合需求、在系统运行是否存在漏洞等——根据测试用例，进行完整的系统测试

系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。

2.4 验收测试

按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统——用户对软件进行验收

2.5 回归测试

回归测试是指重复以前的全部或部分的相同测试。新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。

3 附录

3.1 测试文档清单

阶段	活动	产出物	模板
设计	系统设计	测试计划
设计	系统设计	测试计划评审会议纪要	无
开发	测试用例设计	测试用例
		测试用例评审记录	无
		需求跟踪表	无
测试	测试执行	测试用例执行记录	无
		测试工作阶段报告	无
		测试日报
	缺陷管理	缺陷bug清单	无
验收	系统验收	验收测试报告
验收	系统发布	用户手册	无

3.2 缺陷管理流程

缺陷状态一般分为：新建、打开、已分配、已修复、关闭、重新打开

中间会有：延期、重复、拒绝等状态

缺陷管理流程：

3.3 缺陷等级划分

A类--严重错误，包括以下各种错误：

　　1、由于程序所引起的死机，非法退出

　　2、死循环

　　3、数据库发生死锁

　　4、因错误操作导致的程序中断

　　5、功能错误

　　6、与数据库链接错误

　　7、数据库通讯错误

B类--较严重错误，包括以下错误：

　　1、程序错误

　　2、程序接口错误

　　3、数据库的表、业务规则、缺省值未加完整性等约束条件

C类--一般性错误，包括以下各种错误：

　　1、操作界面错误(包括数据窗口内列名定义、含义是否一致)

　　2、打印内容、格式错误

　　3、简单的输入显示未放在前台进行控制

　　4、删除操作未给出提示

　　5、数据库表中有过多的空字段

D类--较小错误，包括以下各种错误：

　　1、界面不规范

　　2、辅助说明描述不清楚

　　3、输入输出不规范

　　4、长操作未给用户提示

　　5、提示窗口文字未采用行业术语

　　6、可输入区域和只读区域没有明显的区分标志

E类--测试建议

转：https://wenku.baidu.com/view/53c209e2db38376baf1ffc4ffe4733687e21fc80.html

软件测试流程及产出物

1.1 需求分析