软件测试的基本流程与测试规范.docx
《软件测试的基本流程与测试规范.docx》由会员分享，可在线阅读，更多相关《软件测试的基本流程与测试规范.docx（36页珍藏版）》请在冰豆网上搜索。
软件测试的基本流程与测试规范
软件测试流程和规范
软件测试的基本流程与测试规范
前言1
一、软件测试的流程2
1.测试基本流程图2
2.测试各阶段工作流程3
2.1需求分析阶段3
2.2计划与设计阶段4
2.3测试实施阶段4
2.4测试结束5
2.5测试验收和归档7
二、软件测试规范8
1.测试阶段所基于的文档（包括但不限于）8
1.1软件需求规格说明书8
1.2软件设计说明（概要设计或详细设计）8
1.3软件设计原型（demo）9
1.4接口文档9
2.测试的种类（按阶段划分）9
2.1单元测试9
2.2集成测试11
2.3冒烟测试（非必须）12
2.4系统测试12
2.5随机测试（非必须）13
2.6验收测试（非必须）13
3.测试的类型（按测试内容划分）14
3.1功能测试14
3.2界面测试（UI测试）19
3.3接口测试20
I
软件测试流程和规范
3.4性能测试20
3.5兼容性测试22
3.6安全测试22
3.7安装测试24
4.缺陷管理25
4.1缺陷提交规范25
4.2缺陷生命周期27
4.3缺陷等级划分27
II
软件测试流程和规范
前言
此文档就项目中测试部分的工作流程进行了一个梳理，参考了不同的资料，
提炼整理的内容为业内已经成型、被大多数项目采用和认可的。
因此，该流程
并不针对某一个具体的企业或者项目，运用到某一个项目中时，可进行必要的
增减和修改。
另外，文章中测试规范部分，也是查阅了网上很多的资料、参考了其他项
目文档，并结合本人经验整理而成，可以覆盖到项目开发过程中会遇到的绝大
部分的测试面，针对不同的测试内容，该规范也能够起到一定的指导和参考作
用。
但是在实际的工作中，放到具体的项目里，也需要根据具体情况和要求进
行适当的调整。
第1页
软件测试流程和规范
一、软件测试的流程
1.测试基本流程图
需求分析
评审、沟通否
是
编写测试计划
评审、完善否
是
提取测试需求
设计测试用例
评审、完善否
是
搭建测试环境
冒烟测试
执行测试用例完善测试用例
缺陷跟踪处理
测试/缺陷报告输出
测试归档
第2页
软件测试流程和规范
2.测试各阶段工作流程
2.1需求分析阶段
测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。
用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础，测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖。
开始分析和提取测试需求的时候，整个项目一定至少已经进入设计阶段，
一定要有需求文档、设计说明文档或者原型作为依据。
而且被确定的测试需求项必须是可核实的、可测的，不能有模棱两可的概念，比如：
大概、约、或者⋯⋯；也不能为无法量化、主观性的概念，比如：
处理速度快、设计页面好看⋯⋯。
它们必须有一个可观察、可评测的结果。
无法核实的需求不是测试需求。
测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据；测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的确定测试方案，设计测试用例。
过程要点
详细说明
输入条件
项目进入软件设计阶段，至少需要有需求文档、软件设计说
明书或者软件原型（demo）
测试人员根据相关文档梳理、提取测试需求，确定测试内容
工作内容
（功能、性能、兼容性等）、使用的测试方法（手工测试、
自动化测试），已保证此次需要测试的内容覆盖完整。
退出标准
提取完整的测试需求点
输出内容
明确测试策略，列出具体的功能列表（非必须项）
第3页
软件测试流程和规范
2.2计划与设计阶段
2.2.1测试计划阶段
当项目进入到实现阶段，测试经理就应该和整个项目的开发人员、需求设计人员研究讨论，并对本次测试的交接时间、投入的人力、拟定测试的轮次、各轮次持续的时间、测试的内容和深度进行规模预估，并制定出测试计划。
过程要点
详细说明
输入条件
项目进入到实现阶段（编码），需求规格说明书、软件设计
说明书（概要设计或详细设计）、原型（
demo）已输出。
工作内容
和整个项目组讨论并确认此次项目测试阶段的人力、时间投
入，测试轮次预估，测试的交接和验收时间
退出标准
明确测试内容、时间、人力安排
输出内容
测试人员提交评审后的《测试计划》
2.2.2测试设计阶段
在项目进入实现阶段的同时，测试人员还需要根据基线版的软件需求规格说明书和产品设计说明书编写测试用例。
根据每一个测试需求点和功能点，运用不同的用例设计方法编写用例，针对不同的测试内容，可能会涉及到的用例包括：
功能测试用例、性能测试用例、接口测试用例和自动化测试用例。
过程要点
详细说明
输入条件
测试需求明确，测试计划明确，已有基线需求和测试计划
工作内容
根据每一步测试计划编写全部的测试用例
退出标准
测试用例需要覆盖所有的测试需求
输出内容
测试人员提交评审后的《测试用例》，测试脚本（性能、自
动化）
2.3测试实施阶段
测试实施阶段是测试人员在整个项目中需要投入最多工作量的阶段，也是
最主要，最重要的一个阶段。
在这个阶段中，测试人员需要根据前期的测试计
第4页
软件测试流程和规范
划、测试策略来执行测试用例，根据设计的测试用例来执行测试，并使用测试管理工具记录、提交、跟踪测试中发现的缺陷，并配合、督促开发人员复现、定位、修复缺陷，然后验证和关闭缺陷。
过程要点
详细说明
输入条件
测试用例
根据测试计划中分配给自己的测试任务，在测试计划的时间
工作内容
段内，执行相应的全部测试用例，并将测试结果记录到测试
管理工具中。
如有需求和设计上的变更，需要不断完善测试
用例。
退出标准
执行完毕所有测试用例，结果被记录
输出内容
测试结果（输出到测试管理工具中）
2.4测试结束
约定的测试周期完成后，测试人员需要总结此次测试的结果，并编写报告。
2.4.1缺陷报告提交
测试结束后，根据项目组的要求和具体情况，可能会要求提交缺陷报告
（非必须），统计此次测试过程中出现的缺陷数量、分布情况、各功能模块发
现的缺陷占比、严重等级和修复情况等。
缺陷报告的内容侧重对于缺陷的统计
和分析。
2.4.2测试报告提交
测试报告是在一个测试阶段结束后，或者项目的全部测试工作结束后需要
提交的，所以报告又分为阶段性测试报告，和总结性测试报告。
报告需要对此
次或此阶段测试的情况进行统计，汇总，分析，以供整个项目组了解软件开发
的质量、开发的进度及软件修复的情况，对项目经理决定上线与否，上线时间，
项目是否会延期等相关决策提供一个重要的参考依据。
过程要点详细说明
输入条件测试人员完成了预定周期的测试任务（一个阶段或整个项
第5页
软件测试流程和规范
目）
测试人员根据此轮测试的结果，编写阶段性测试报告，主要应包含以下内容：
测试报告的版本
测试的人员和时间
测试所覆盖的缺陷——测试组在这轮测试中所有处理的
缺陷情况
工作内容
上一版本活动缺陷的数量（未关闭的缺陷）
（阶段性报告）
经过此轮测试，所有活动缺陷的数量及其状态分类
测试评估——写明在这一版本中，哪些功能被实现了，哪些还没有实现，这里只需写明和上一版本不同之处即可。
急待解决的问题——写明当前项目组中面临的优先级最高的问题（非必须项）
当整个项目的测试工作全部结束后，测试人员应就该项目的测试情况编写总结性测试报告，测试报告必须包含以下内容：
测试资源概述——多少人、多长时间
测试结果摘要——分别描述各个测试需求的测试结果，
产品实现了哪些功能点，哪些没有实现，以及没有实现
工作内容
的原因。
（总结性报告）
缺陷分析——按照缺陷的属性分类分析，比如：
缺陷总数、各模块的缺陷分布、不同严重等级的缺陷、缺陷的修复情况、未修复的缺陷及未修复的原因、对项目整体的影响等等（也可单独写一份《缺陷报告》）测试评估——从总体对项目质量进行评估
测试组建议——从测试组的角度为项目组提出工作建议
退出标准本次测试中所有的相关测试数据统计完毕，完成统计分析
输出内容《缺陷报告》（非必须）、《测试报告》（根据实际的项目
第6页
软件测试流程和规范
规模可细分为阶段性的和总结性的）
2.5测试验收和归档
2.5.1测试验收
当上述所有工作完成后，测试人员应对测试的过程、效果进行验收，宣布测试的所有工作完成（根据实际项目的规模来定，非必须）
过程要点详细说明
输入条件测试实施工作结束，所有测试文档已编写完毕
测试验收工作由测试经理进行，验收内容报告：
测试效果验收——测试是否达到预期目标
测试文档验收——测试过程中文档是否齐全，是否符合
工作内容
标准
测试评估——从总体对测试的质量进行评估
测试建议——对本次测试工作指出不足，并对以后的工
作提出改进、优化建议
宣布测试结束——测试组成员签字宣布本次测试结束
退出标准
签发测试验收报告
输出内容
所有测试人员《测试验收报告》
2.5.2测试归档
测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归档。
过程要点
详细说明
输入条件
测试验收通过
归档测试过程中所有文档，主要包括以下文档（必须）
工作内容
测试计划
测试用例
测试报告
退出标准
全部文档归档完毕
第7页
软件测试流程和规范
输出内容归档清单
二、软件测试规范
测试代码和项目开发代码应该利用配置管理工具（如SVN）分开管理。
测
试代码编写完成后，存放在配置库中。
开发过程中，可根据需要对自己编写代
码进行测试。
并且测试环境和开发环境应分隔开来，以免相互影响，便于缺陷的复现和
定位，在条件允许的情况下，性能测试环境应和功能测试环境分开，以免在性
能测试过程中对功能测试造成影响。
1.测试阶段所基于的文档（包括但不限于）
测试规范形成的前提是需要有有章可循的依据，这些依据需要基于标准的
项目文档，常见的文档包括下面几种：
1.1软件需求规格说明书
软件需求说明书是为了使用户和软件开发者双方对该软件的初始规定有一
个共同的理解，使之成为整个项目组开展工作的基础。
包含硬件、功能、性能、
输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要
求等等。
软件需求说明书的作用在于便于用户、开发人员进行理解和交流，反映出
用户问题的结构，可以作为软件开发工作的基础和依据，并作为确认测试和验
收的依据。
1.2软件设计说明（概要设计或详细设计）
软件设计又划分为概要设计和详细设计。
概要设计是在用户提出的需求和软件的设计实现之间架起桥梁，是将用户
提出的目标和需求转换成具体界面设计解决方案的重要阶段。
概设的主要任务
是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。
设计软件结
构的具体任务是：
将一个复杂系统按功能进行模块划分、建立模块的层次结构
第8页
软件测试流程和规范
及调用关系、确定模块间的接口及人机交互的界面等。
从而设计建立一个目标
系统的逻辑模型。
而详细设计是软件工程中软件开发的一个步骤，就是对概要设计的一个细
化，就是详细设计每个模块实现算法，所需的局部结构。
在详细设计阶段，主
要是通过需求分析的结果，设计出满足用户需求的软件系统产品。
软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将
无法溯源，测试准备的前期工作也是根据软件设计说明来制定的。
1.3软件设计原型（demo）
页面原型是项目人员快速熟悉项目的最佳路径，让开发人员和测试人员更
直观的了解客户的需求和产品的实现方式、业务逻辑，帮助项目人员更快的理
解用户需求、业务逻辑，用更直观，具体的界面化方式来说明用户想要如何来
实现他们需要的功能。
或者在需求不够明确，设计说明书不够全面的情况下，
页面原型也是后期测试用例编写思想的重要根据。
1.4接口文档
当项目中各个子系统间、各个功能模块间有交互，需要开发接口时，接口
文档会定义出参数传递、参数返回的规则，比如：
参数的名称、参数的类型、
长度、是否必填、各个返回码所代表的含义⋯，当项目中有接口测试需求的时
候，此文档是很重要的测试依据。
2.测试的种类（按阶段划分）
测试的阶段也根据项目开发的进度来进行，从先到后划分为下面几种测试
阶段：
（根据项目的实际要求进行相应测试）
2.1单元测试
单元测试是指对软件中的最小可测试单元进行检查和验证。
准入条件
1、源码已实现完成或50%；
2、源码编译能通过；
3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；
第9页
软件测试流程和规范
4、单元测试用例通过评审并归档；
主要测试点和方法
代码静态检查
无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。
独立路径和错误检查
独立路径测试：
在模块中应对每一条独立执行路径进行测试，每条语句至少执行一次。
测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。
错误检查：
首先检查程序是否有错误处理；其次对于程序中的防错处理的完整性和正确性进行检查。
错误处理包括：
不同数据类型的对象之间进行比较；错误地使用逻辑运算符或优先级；因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；比较运算或变量出错；循环终止条件或不可能出现；迭代发散时不能退出；错误地修改了循环变量。
单元测试人员一般是开发自测。
参与组织
需要参与的人员的职责如下表：
编号
角色
职责说明
1
需求经理
对测试中需求不明确地方，进行明确；
2
产品经理
对测试中产品功能实现歧义地方，进行明确；
3
开发人员
负责功能开发、缺陷修复、单元测试；
4
开发责任人
负责软件开发进度、版本提交和相关协调；
5
配置管理员
负责每轮测试前：
代码获取、编译、发布；
6
测试经理
负责项目测试整体计划、协调和质量；
第10页
软件测试流程和规范
2.2集成测试
集成测试，也叫组装测试或联合测试。
在单元测试的基础上，将所有模块
按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
它最
简单的形式是：
把两个已经测试过的单元组合成一个组件，测试它们之间的接
口。
准入条件
1、单元测试用例编写完成；
2、核心功能开发完成；
3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；
4、子系统间接口说明文档通过评审并归档；
5、项目集成测试用例文档通过评审并归档；
主要测试点和方法（详见3.3接口测试章节）
参与组织
需要参与的人员的职责如下表：
编号角色职责说明
1需求经理对测试中需求不明确地方，进行明确；
2产品经理对测试中产品功能实现歧义地方，进行明确；
3开发人员负责功能开发、缺陷修复、单元测试；
4开发责任人负责软件开发进度、版本提交和相关协调；
5配置管理员负责每轮测试前：
代码获取、编译、发布；
6测试经理负责项目测试整体计划、协调和质量；
第11页
软件测试流程和规范
2.3冒烟测试（非必须）
冒烟测试是开发完成后，正式移交测试前做的一个中间测试工作，即在刚
刚编译出来后，开发人员需要进行基本确认测试，例如是否可以正确安装/卸载，
主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。
如果通过了该
测试，则可以移交测试，开始正式测试。
否则，就需要重新编译版本，再次执
行版本可接收确认测试，直到成功。
该工作可由开发人员先行自测，保证移交测试版本的质量，防止出现阻碍
测试的情况出现，也可由测试人员来进行，只有冒烟测试通过后，才进入正式
的测试流程，否则会把版本打回，重新编译。
2.4系统测试
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需
求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的
方案。
也是整个测试工作最重要，最关键的测试部分。
准入条件
1、单元、集成测试完成；
2、前阶段中缺陷修复率100%；
3、功能用例编写完成，覆盖率达100%；
4、项目需求文档、设计文档均通过评审并归档；
5、测试用例通过评审并归档；
主要测试点和方法（详见3.1功能测试章节）
参与组织
需要参与的人员的职责如下表：
编号
角色
职责说明
1
需求经理
对测试中需求不明确地方，进行明确；
2
产品经理
对测试中产品功能实现歧义地方，进行明确；
3
开发人员
负责功能开发、缺陷修复、单元测试；
4
开发责任人
负责软件开发进度、版本提交和相关协调；
5
配置管理员
负责每轮测试前：
代码获取、编译、发布；
第12页
软件测试流程和规范
6测试经理负责项目测试整体计划、协调和质量；
7测试人员负责测试方案编写、测试用例编写、测试执行、质
量分析；
2.5随机测试（非必须）
随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测
试。
主要是根据测试者的经验对软件进行功能和性能抽查。
随机测试是根据测
试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和
过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当
前的测试用例没有覆盖到的部分。
另外，对于软件更新和新增加的功能要重点
测试。
重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。
尤其
对以前测试发现的重大Bug，进行再次测试，可以结合回归测试
2.6验收测试（非必须）
2.6.1β测试（beta测试）
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。
开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发
行前找到。
这种测试一般由最终用户或其他人员完成，不能由程序员或测试员
完成。
2.6.2α测试（Alpha测试）
Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的
用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序
员或测试员完成。
在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变
更。
这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。
第13页
软件测试流程和规范
α测试和β测试的不同之处在于测试的环境，前者是在开发环境，后者是
在实际使用环境（生产环境），故后者模拟真实使用场景程度更高，发现的问
题也更有意义，一般运用在项目的试运行阶段。
3.测试的类型（按测试内容划分）
3.1功能测试
功能测试也叫黑盒测试，是在不看代码的前提下，通过运行软件来进行测试，重点是关注系统的功能实现是否正常、设计是否合理、用户的需求是否全部覆盖，这也是测试工作最主要、最重要的内容。
在版本稳定以后，或者进行回归测试的时候，可根据项目的具体情况，对主要功能通过编写自动化测试脚本，进行自动化测试。
根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。
测试内容
序列分类说明
1基本功能1.正常增、删、改、查；
2.正常业务流程；
3.正常权限功能；
4.正常数据调用（包括数据）。
2边界类1.验证边界值，对16-bit的整数而言32767和-32768
是边界；
2.屏幕上光标在最左上、最右下位置；
3.报表的第一行和最后一行；
4.数组元素的第一个和最后一个；
5.最小值-1/最大值+1/空值；
6.分析规格说明，找出其它可能的边界值条件。
第14页
软件测试流程和规范
3
等价类
1.有效等价类，指符合系统设计有意义的输入输出合集；
2.无效等价类，指不符合系统设计错误的输入输入合集；
4
错误推测
基于经验和直觉推测程序中所有可能存在的各种错误；
5
因果图
设计因果图，将因果图转化为判定表，判定表的每一列作
为一条测试用例。
6
用户场景设
根据不同用户运行该系统时所做的操作，来设计用例。
计
8
APP特有
1.
应用的前后台切换；
功能
2.
数据更新；
3.
离线浏览；
4.
定位、照相机服务，扫描二维码功能；
5.
时间测试；
6.push测试；
7.
运行测试。
App的功能测试具体为：
运行
1）App安装完成后的试运行，可正常打开软件。
2）App打开测试，是否有加载状态进度提示。
3）App打开速度测试，速度是否可观。
4）App页面间的切换是否流畅，逻辑是否正确
5）注册
--同表单编辑页面
--用户名密码长度
--注册后的提示页面
--前台注册页面和后台的管理页面数据是否一致
--注册后，在后台管理中页面提示
6）登录
--使用合法的用户登录系统。
--系统是否允许多次非法的登陆，是否有次数限制。
第15页
软件测试流程和规范
--使用已经登陆的账号登陆系统是否正确处理。
--使用禁用的账号登陆系统是否正确处理。
--用户名、口令（密码）错误或漏填时能否登陆。
--删除或修改后的用户，原用户登陆。
--不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。
--登陆后，页面中登陆信息。
--页面中有注销按钮。
--登陆超时的处理。
7）注销
--注销原
升级会员 