《软件测试的基本流程及测试规范方案31106.pdf》由会员分享，可在线阅读，更多相关《软件测试的基本流程及测试规范方案31106.pdf（27页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、.软件测试的基本流程与测试规范 目录 前言 1 一、软件测试的流程1 1.测试基本流程图 1 2.测试各阶段工作流程1 2.1 需求分析阶段 1 2.2 计划与设计阶段 2 2.3 测试实施阶段 3 2.4 测试结束 3 2.5 测试验收和归档 4 二、软件测试规范 5 1.测试阶段所基于的文档6 1.1 软件需求规格说明书6 1.2 软件设计说明6 1.3 软件设计原型6 1.4 接口文档 7 2.测试的种类7 2.1 单元测试 7 2.2 集成测试 8 2.3 冒烟测试9 2.4 系统测试 9 2.5 随机测试10 2.6 验收测试10 3.测试的类型11 3.1 功能测试 11 3.2
2、界面测试16 3.3 接口测试 16 .3.4 性能测试 17 3.5 兼容性测试 19 3.6 安全测试 19 3.7 安装测试 21 4.缺陷管理 22 4.1 缺陷提交规范 22 4.2 缺陷生命周期 23 4.3 缺陷等级划分 24 .前言 此文档就项目中测试部分的工作流程进行了一个梳理,参考了不同的资料,提炼整理的内容为业内已经成型、被大多数项目采用和认可的.因此,该流程并不针对某一个具体的企业或者项目,运用到某一个项目中时,可进行必要的增减和修改.另外,文章中测试规范部分,也是查阅了网上很多的资料、参考了其他项目文档,并结合本人经验整理而成,可以覆盖到项目开发过程中会遇到的绝大部分
3、的测试面,针对不同的测试内容,该规范也能够起到一定的指导和参考作用.但是在实际的工作中,放到具体的项目里,也需要根据具体情况和要求进行适当的调整.一、软件测试的流程 1.测试基本流程图 2.测试各阶段工作流程 2.1 需求分析阶段 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用.用来确定整个测试工作并作为测试覆盖的基础,测试需求是计算测试覆盖的分母,没有测试需求就无法有效地进行测试覆盖.开始分析和提取测试需求的时候,整个项目一定至少已经进入设计阶段,一定要有需求文档、设计说明文档或者原型作为依据.而且被确定的测试需求项必须是可核实的、可测的,不能有模棱两可的概念,比如：大概
4、、约、或者；也不能为无法量化、主观性的概念,比如：处理速度快、设计页面好看.它们必须有一个可观察、可评测的结果.无法核实的需求不是测试需求.测试需求是制订测试计划的基本依据,确定了测试需求能够为测试计划提供客观依据；测试需求是设计测试用例的指导,确定了要测什么、测哪些方面后才能有针对性的确定测试方案,设计测试用例.过程要点 详细说明 输入条件 项目进入软件设计阶段,至少需要有需求文档、软件设计说明书或者软件原型 工作内容 测试人员根据相关文档梳理、提取测试需求,确定测试内容、使用的测试方法,已保证此次需要测试的内容覆盖完整.退出标准 提取完整的测试需求点 输出内容 明确测试策略,列出具体的功能
5、列表 2.2 计划与设计阶段 2.2.1 测试计划阶段 当项目进入到实现阶段,测试经理就应该和整个项目的开发人员、需求设计人员研究讨论,并对本次测试的交接时间、投入的人力、拟定测试的轮次、各轮次持续的时间、测试的内容和深度进行规模预估,并制定出测试计划.过程要点 详细说明 输入条件 项目进入到实现阶段,需求规格说明书、软件设计说明书、原型已输出.工作内容 和整个项目组讨论并确认此次项目测试阶段的人力、时间投入,测试轮次预估,测试的交接和验收时间 退出标准 明确测试内容、时间、人力安排 输出内容 测试人员提交评审后的测试计划 测试设计阶段 在项目进入实现阶段的同时,测试人员还需要根据基线版的软件
6、需求规格说明书和产品设计说明书编写测试用例.根据每一个测试需求点和功能点,运用不同的用例设计方法编写用例,针对不同的测试内容,可能会涉及到的用例包括：功能测试用例、性能测试用例、接口测试用例和自动化测试用例.过程要点 详细说明 输入条件 测试需求明确,测试计划明确,已有基线需求和测试计划 工作内容 根据每一步测试计划编写全部的测试用例 退出标准 测试用例需要覆盖所有的测试需求 .输出内容 测试人员提交评审后的测试用例,测试脚本 2.3 测试实施阶段 测试实施阶段是测试人员在整个项目中需要投入最多工作量的阶段,也是最主要,最重要的一个阶段.在这个阶段中,测试人员需要根据前期的测试计划、测试策略来
7、执行测试用例,根据设计的测试用例来执行测试,并使用测试管理工具记录、提交、跟踪测试中发现的缺陷,并配合、督促开发人员复现、定位、修复缺陷,然后验证和关闭缺陷.过程要点 详细说明 输入条件 测试用例 工作内容 根据测试计划中分配给自己的测试任务,在测试计划的时间段内,执行相应的全部测试用例,并将测试结果记录到测试管理工具中.如有需求和设计上的变更,需要不断完善测试用例.退出标准 执行完毕所有测试用例,结果被记录 输出内容 测试结果 2.4 测试结束 约定的测试周期完成后,测试人员需要总结此次测试的结果,并编写报告.2.4.1 缺陷报告提交 测试结束后,根据项目组的要求和具体情况,可能会要求提交缺
8、陷报告,统计此次测试过程中出现的缺陷数量、分布情况、各功能模块发现的缺陷占比、严重等级和修复情况等.缺陷报告的内容侧重对于缺陷的统计和分析.2.4.2 测试报告提交 测试报告是在一个测试阶段结束后,或者项目的全部测试工作结束后需要提交的,所以报告又分为阶段性测试报告,和总结性测试报告.报告需要对此次或此阶段测试的情况进行统计,汇总,分析,以供整个项目组了解软件开发的质量、开发的进度及软件修复的情况,对项目经理决定上线与否,上线时间,项目是否会延期等相关决策提供一个重要的参考依据.过程要点 详细说明 .输入条件 测试人员完成了预定周期的测试任务 工作内容 测试人员根据此轮测试的结果,编写阶段性测
9、试报告,主要应包含以下内容：测试报告的版本 测试的人员和时间 测试所覆盖的缺陷测试组在这轮测试中所有处理的缺陷情况 上一版本活动缺陷的数量 经过此轮测试,所有活动缺陷的数量及其状态分类 测试评估写明在这一版本中,哪些功能被实现了,哪些还没有实现,这里只需写明和上一版本不同之处即可.急待解决的问题写明当前项目组中面临的优先级最高的问题 工作内容 当整个项目的测试工作全部结束后,测试人员应就该项目的测试情况编写总结性测试报告,测试报告必须包含以下内容：测试资源概述多少人、多长时间 测试结果摘要分别描述各个测试需求的测试结果,产品实现了哪些功能点,哪些没有实现,以及没有实现的原因.缺陷分析按照缺陷的
10、属性分类分析,比如：缺陷总数、各模块的缺陷分布、不同严重等级的缺陷、缺陷的修复情况、未修复的缺陷及未修复的原因、对项目整体的影响等等 测试评估从总体对项目质量进行评估 测试组建议从测试组的角度为项目组提出工作建议 退出标准 本次测试中所有的相关测试数据统计完毕,完成统计分析 输出内容 缺陷报告、测试报告 2.5 测试验收和归档 2.5.1 测试验收 当上述所有工作完成后,测试人员应对测试的过程、效果进行验收,宣布测试的所有工作完成 .过程要点 详细说明 输入条件 测试实施工作结束,所有测试文档已编写完毕 工作内容 测试验收工作由测试经理进行,验收内容报告：测试效果验收测试是否达到预期目标 测试
11、文档验收测试过程中文档是否齐全,是否符合标准 测试评估从总体对测试的质量进行评估 测试建议对本次测试工作指出不足,并对以后的工作提出改进、优化建议 宣布测试结束测试组成员签字宣布本次测试结束 退出标准 签发测试验收报告 输出内容 所有测试人员测试验收报告 2.5.2 测试归档 测试归档是在测试验收结束宣布测试有效,结束测试后,对测试过程中涉及到各种标准文档进行归档.过程要点 详细说明 输入条件 测试验收通过 工作内容 归档测试过程中所有文档,主要包括以下文档 测试计划 测试用例 测试报告 退出标准 全部文档归档完毕 输出内容 归档清单 二、软件测试规范 测试代码和项目开发代码应该利用配置管理工
12、具分开管理.测试代码编写完成后,存放在配置库中.开发过程中,可根据需要对自己编写代码进行测试.并且测试环境和开发环境应分隔开来,以免相互影响,便于缺陷的复现和定位,在条件允许的情况下,性能测试环境应和功能测试环境分开,以免在性能测试过程中对功能测试造成影响.1.测试阶段所基于的文档 测试规范形成的前提是需要有有章可循的依据,这些依据需要基于标准的项目文档,常见的文档包括下面几种：1.1 软件需求规格说明书 软件需求说明书是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解,使之成为整个项目组开展工作的基础.包含硬件、功能、性能、输入输出、接口需求、警示信息、*安全、数据与数据库、文档
13、和法规的要求等等.软件需求说明书的作用在于便于用户、开发人员进行理解和交流,反映出用户问题的结构,可以作为软件开发工作的基础和依据,并作为确认测试和验收的依据.1.2 软件设计说明 软件设计又划分为概要设计和详细设计.概要设计是在用户提出的需求和软件的设计实现之间架起桥梁,是将用户提出的目标和需求转换成具体界面设计解决方案的重要阶段.概设的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构.设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机交互的界面等.从而设计建立一个目标系统的逻辑模型.而详细设计是软件工程中软件开发
14、的一个步骤,就是对概要设计的一个细化,就是详细设计每个模块实现算法,所需的局部结构.在详细设计阶段,主要是通过需求分析的结果,设计出满足用户需求的软件系统产品.软件设计说明对测试工作开展有很大影响,没有软件设计说明很多问题将无法溯源,测试准备的前期工作也是根据软件设计说明来制定的.1.3 软件设计原型 页面原型是项目人员快速熟悉项目的最佳路径,让开发人员和测试人员更直观的了解客户的需求和产品的实现方式、业务逻辑,帮助项目人员更快的理解用.户需求、业务逻辑,用更直观,具体的界面化方式来说明用户想要如何来实现他们需要的功能.或者在需求不够明确,设计说明书不够全面的情况下,页面原型也是后期测试用例编
15、写思想的重要根据.1.4 接口文档 当项目中各个子系统间、各个功能模块间有交互,需要开发接口时,接口文档会定义出参数传递、参数返回的规则,比如：参数的名称、参数的类型、长度、是否必填、各个返回码所代表的含义,当项目中有接口测试需求的时候,此文档是很重要的测试依据.2.测试的种类 测试的阶段也根据项目开发的进度来进行,从先到后划分为下面几种测试阶段：2.1 单元测试 单元测试是指对软件中的最小可测试单元进行检查和验证.准入条件 1、源码已实现完成或 50%；2、源码编译能通过；3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；4、单元测试用例通过评审并归档；主要测试点和方法 代码静态
16、检查 无需运行被测代码,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性,找出代码隐藏的错误和缺陷,如参数不匹配,有歧义的嵌套语句,错误的递归,非法计算,可能出现的空指针引用等等.独立路径和错误检查 独立路径测试：在模块中应对每一条独立执行路径进行测试,每条语句至少执行一次.测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误.错误检查：首先检查程序是否有错误处理；其次对于程序中的防错处理的完整性和正确性进行检查.错误处理包括：不同数据类型的对象之间进行比较；错误地使用逻辑运算符或优先级；因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等；比较
17、运算或变量出错；循环终止条件或不可能出现；迭代发散时不能退出；错误地修改了循环变量.单元测试人员一般是开发自测.参与组织 需要参与的人员的职责如下表：编号 角色 职责说明 1 需求经理 对测试中需求不明确地方,进行明确；2 产品经理 对测试中产品功能实现歧义地方,进行明确；3 开发人员 负责功能开发、缺陷修复、单元测试；4 开发责任人 负责软件开发进度、版本提交和相关协调；5 配置管理员 负责每轮测试前：代码获取、编译、发布；6 测试经理 负责项目测试整体计划、协调和质量；2.2 集成测试 集成测试,也叫组装测试或联合测试.在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集
18、成测试.它最简单的形式是：把两个已经测试过的单元组合成一个组件,测试它们之间的接口.准入条件 1、单元测试用例编写完成；2、核心功能开发完成；3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；4、子系统间接口说明文档通过评审并归档；5、项目集成测试用例文档通过评审并归档；主要测试点和方法 参与组织 需要参与的人员的职责如下表：.编号 角色 职责说明 1 需求经理 对测试中需求不明确地方,进行明确；2 产品经理 对测试中产品功能实现歧义地方,进行明确；3 开发人员 负责功能开发、缺陷修复、单元测试；4 开发责任人 负责软件开发进度、版本提交和相关协调；5 配置管理员 负责每轮测试前：
19、代码获取、编译、发布；6 测试经理 负责项目测试整体计划、协调和质量；2.3 冒烟测试 冒烟测试是开发完成后,正式移交测试前做的一个中间测试工作,即在刚刚编译出来后,开发人员需要进行基本确认测试,例如是否可以正确安装/卸载,主要功能是否实现,是否存在严重死机或数据严重丢失等 Bug.如果通过了该测试,则可以移交测试,开始正式测试.否则,就需要重新编译版本,再次执行版本可接收确认测试,直到成功.该工作可由开发人员先行自测,保证移交测试版本的质量,防止出现阻碍测试的情况出现,也可由测试人员来进行,只有冒烟测试通过后,才进入正式的测试流程,否则会把版本打回,重新编译.2.4 系统测试 系统测试是针对
20、整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方,从而提出更加完善的方案.也是整个测试工作最重要,最关键的测试部分.准入条件 1、单元、集成测试完成；2、前阶段中缺陷修复率100%；3、功能用例编写完成,覆盖率达 100%；4、项目需求文档、设计文档均通过评审并归档；5、测试用例通过评审并归档；主要测试点和方法 参与组织 .需要参与的人员的职责如下表：编号 角色 职责说明 1 需求经理 对测试中需求不明确地方,进行明确；2 产品经理 对测试中产品功能实现歧义地方,进行明确；3 开发人员 负责功能开发、缺陷修复、单元测试；4 开发责任人 负责软件
21、开发进度、版本提交和相关协调；5 配置管理员 负责每轮测试前：代码获取、编译、发布；6 测试经理 负责项目测试整体计划、协调和质量；7 测试人员 负责测试方案编写、测试用例编写、测试执行、质量分析；2.5 随机测试 随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试.主要是根据测试者的经验对软件进行功能和性能抽查.随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程.随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例没有覆盖到的部分.另外,对于软件更新和新增加的功能要重点测试.重点对一些特殊点情况点、特殊的使用环境、
22、并发性、进行检查.尤其对以前测试发现的重大Bug,进行再次测试,可以结合回归测试 2.6 验收测试 测试 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试.开发者通常不在测试现场,Beta 测试不能由程序员或测试员完成.当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到.这种测试一般由最终用户或其他人员完成,不能由程序员或测试员完成.测试 Alpha 测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha 测试不能由该系统的程序员或测试员完成.在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设
23、计变更.这种测试一般由最终用户或其他人员来完成,不能由程序员或测试员完成.测试和 测试的不同之处在于测试的环境,前者是在开发环境,后者是在实际使用环境,故后者模拟真实使用场景程度更高,发现的问题也更有意义,一般运用在项目的试运行阶段.3.测试的类型 3.1 功能测试 功能测试也叫黑盒测试,是在不看代码的前提下,通过运行软件来进行测试,重点是关注系统的功能实现是否正常、设计是否合理、用户的需求是否全部覆盖,这也是测试工作最主要、最重要的内容.在版本稳定以后,或者进行回归测试的时候,可根据项目的具体情况,对主要功能通过编写自动化测试脚本,进行自动化测试.根据被测功能点的特性列丼出相应类型的测试用例
24、对其进行覆盖,如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖.在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况,及时修正业务或需求理解错误.测试内容 序列 分类 说明 1 基本功能 1.正常增、删、改、查；2.正常业务流程；3.正常权限功能；4.正常数据调用.2 边界类 1.验证边界值,对 16-bit 的整数而言 32767 和-32768 .是边界；2.屏幕上光标在最左上、最右下位置；3.报表的第一行和最后一行；4.数组元素的第一个和最后一个；5.最小值-1/最大值+1/空值；6.分析规格说明,找出其它可能的边界值条件.3 等价类 1.
25、有效等价类,指符合系统设计有意义的输入输出合集；2.无效等价类,指不符合系统设计错误的输入输入合集；4 错误推测 基于经验和直觉推测程序中所有可能存在的各种错误；5 因果图 设计因果图,将因果图转化为判定表,判定表的每一列作为一条测试用例.6 用户场景设计 根据不同用户运行该系统时所做的操作,来设计用例.8 APP 特有功能 1.应用的前后台切换；2.数据更新；3.离线浏览；4.定位、照相机服务,扫描二维码功能；5.时间测试；6.push 测试；7.运行测试.App 的功能测试具体为：运行 1App 安装完成后的试运行,可正常打开软件.2App 打开测试,是否有加载状态进度提示.3App 打开
26、速度测试,速度是否可观.4App 页面间的切换是否流畅,逻辑是否正确 5注册-同表单编辑页面-用户名密码长度-注册后的提示页面 .-前台注册页面和后台的管理页面数据是否一致-注册后,在后台管理中页面提示 6登录-使用合法的用户登录系统.-系统是否允许多次非法的登陆,是否有次数限制.-使用已经登陆的账号登陆系统是否正确处理.-使用禁用的账号登陆系统是否正确处理.-用户名、口令错误或漏填时能否登陆.-删除或修改后的用户,原用户登陆.-不输入用户口令和用户、重复点是否允许登陆.-登陆后,页面中登陆信息.-页面中有注销按钮.-登陆超时的处理.7注销-注销原模块,新的模块系统能否正确处理.-终止注销能否
27、返回原模块,原用户.-注销原用户,新用户系统能否正确处理.-使用错误的账号、口令、无权限的被禁用的账号进行注销 应用的前后台切换 1 APP 切换到后台,再回到 app,检查是否停留在上一次操作界面.2 APP 切换到后台,再回到 app,检查功能及应用状态是否正常,IOS4 和IOS5 的版本的处理机制有的不一样.3 app 切换到后台,再回到前台时,注意程序是否崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候.4 手机锁屏解屏后进入 app 注意是否会崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候.5 当 App 使用过程中有进来中断后再切换到
28、 app,功能状态是否正常 6 当杀掉 app 进程后,再开启 app,app 能否正常启动.7 出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在,有时候会出现应用自动跳过提示框的缺陷.8 对于有数据交换的页面,每个页面都必需要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃.免登录 很多应用提供免登录功能,当应用开启时自动以上一次登录的用户身份来使用app.1 app有免登录功能时,需要考虑IOS版本差异.2 考虑无网络情况时能否正常进入免登录状态.3 切换用户登录后,要校验用户登录信息及数据内容是否相应更新,确保原用户退出.4 根据MTOP的现有规则,一个*只允许登录
29、一台机器.所以,需要检查一个*登录多台手机的情况.原手机里的用户需要被踢出,给出友好提示.5 app切换到后台,再切回前台的校验 6 切换到后台,再切换回前台的测试 7 密码更换后,检查有数据交换时是否进行了有效身份的校验 8 支持自动登录的应用在进行数据交换时,检查系统是否能自动登录成功并且数据操作无误.9 检查用户主动退出登录后,下次启动app,应停留在登录界面 数据更新 根据应用的业务规则,以及数据更新量的情况,来确定最优的数据更新方案.1 需要确定哪些地方需要提供手动刷新,哪些地方需要自动刷新,哪些地方需要手动+自动刷新.2 确定哪些地方从后台切换回前台时需要进行数据更新.3 根据业务
30、、速度及流量的合理分配,确定哪些内容需要实时更新,哪些需要定时更新.4 确定数据展示部分的处理逻辑,是每次从服务端请求,还是有缓存到本地,这样才能有针对性的进行相应测试.5 检查有数据交换的地方,均有相应的异常处理.离线浏览 很多应用会支持离线浏览,即在本地客户端会缓存一部分数据供用户查看.1 在无网络情况可以浏览本地数据 2 退出 app 再开启 app 时能正常浏览 3 切换到后台再切回前台可以正常浏览 4 锁屏后再解屏回到应用前台可以正常浏览 5 在对服务端的数据有更新时会给予离线的相应提示 App 更新 当客户端有新版本时,有更新提示.2 当版本为非强制升级版时,用户可以取消更新,老版
31、本能正常使用.用户在下次启动 app 时,仍能出现更新提示.3 当版本为强制升级版时,当给出强制更新后用户没有做更新时,退出客户端.下次启动 app 时,仍出现强制升级提示.4 当客户端有新版本时,在本地不删除客户端的情况下,直接更新检查是否能正常更新.5 当客户端有新版本时,在本地不删除客户端的情况下,检查更新后的客户端功能是否是新版本.6 当客户端有新版本时,在本地不删除客户端的情况下,检查资源同名文件如图片是否能正常更新成最新版本.如果以上无法更新成功的,也都属于缺陷.定位、照相机服务 1 App 有用到相机,定位服务时,需要注意系统版本差异 2 有用到定位服务、照相机服务的地方,需要进
32、行前后台的切换测试,检查应用是否正常.3 当定位服务没有开启时,使用定位服务,会友好性弹出是否允许设置定位提示.当确定允许开启定位时,能自动跳转到定位设置中开启定位服务.4 测试定位、照相机服务时,需要采用真机进行测试.时间测试 客户端可以自行设置手机的时区、时间,因此需要校验该设置对 app 的影响.-中国为东 8 区,所以当手机设置的时间非东 8 区时,查看需要显示时间的地方,时间是否展示正确,应用功能是否正常.时间一般需要根据服务器时间再转换成客户端对应的时区来展示,这样的用户体验比较好.比如发表一篇微博在服.务端记录的是 10：00,此时,华盛顿时间为 22：00,客户端去浏览时,如果
33、设置的是华盛顿时间,则显示的发表时间即为 22:00,当时间设回东 8 区时间时,再查看则显示为 10：00.PUSH 测试 1 检查 push 消息是否按照指定的业务规则发送 2 检查不接受推送消息时,检查用户不会再接收到 push.3 如果用户设置了免打扰的时间段,检查在免打扰时间段内,用户接收不到 PUSH.在非免打扰时间段,用户能正常收到 push.4 当 push 消息是针对登录用户的时候,需要检查收到的 push 与用户身份是否相符,没有错误地将其它人的消息推送过来.一般情况下,只对手机上最后一个登录用户进行消息推送.5 测试 push 时,需要采用真机进行测试.3.2 界面测试
34、界面测试简称 UI 测试,测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯.测试内容 1、导航、链接、Cookie、页面结构包括菜单、背景、颜色、字 体、按钮名称、TITLE、提示信息的一致性等；2、界面内容完整性检查,通过浏览器测试,确认对象可以正确的反应业务的功能和需求,包括窗口与窗口之间的跳转,字段与字段之间的浏览,各种快捷键的使用.3、窗口的对象和特征都符合标准.3.3 接口测试 当模块之间、子系统之间有接口交互时,需要根据接口文档进行测试,接口测试也叫集成测试或灰盒测试,主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点.测试的
35、重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等.测试内容 .1、输入的实际参数与形式参数的个数是否相同；2、输入的实际参数与形式参数的属性是否匹配；3、输入的实际参数与形式参数的量纲是否一致；4、调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；5、调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；6、调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；7、调用预定义函数时所用参数的个数、属性和次序是否正确；8、是否存在与当前入口点无关的参数引用；9、是否修改了只读型参数；10、对全局变量的定义各模块是否一致；11、是否把某些约束作
36、为参数传递.12、如果模块功能包括外部输入输出,还应该考虑以下因素：-文件属性是否正确；-OPEN/CLOSE语句是否正确；13、格式说明与输入输出语句是否匹配；14、缓冲区大小与记录长度是否匹配；15、文件使用前是否已经打开；16、是否处理了文件尾；17、是否处理了输入/输出错误；18、输出信息中是否有文字性错误.3.4 性能测试 性能测试是通过性能测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试.性能测试包括的测试内容主要概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试.通常情况下,三方面有效、合理的结合,可以达到对系统性能全
37、面的分析和瓶颈的预测.性能测试的目的是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试.一个系统需要达到的性能指标也是来源于需求,和用户对该软件的性能要求.常见的性能指标如下：.响应时间 1事务处理类 快速响应类 普通响应类 2查询类 3统计类 吞吐量与关键量 事务成功率 服务器资源 CPU 使用率 内存使用率 I/O 吞吐量 测试内容 性能测试类型包括负载测试,强度测试,容量测试等.负载测试：是一种主要为了测试软件系统是否达到需求文档设计的目标,譬如软件在一定时期内,最大支持多少并发用户数,软件请求出错率等,测试的主要是软件系统的性能.压力测试：强度测试也就是
38、压力测试,压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标,譬如在一定时期内,系统的 cpu 利用率,内存使用率,磁盘 I/O 吞吐率,网络吞吐量等,压力测试和负载测试最大的差别在于测试目的不同.容量测试：确定系统最大承受量,譬如系统最大用户数,最大存储量,最多处理的数据流量等.另外,并发测试是应用在客户端,以客户端做为入口进行的一项重要性能测试,它是一个负载测试和压力测试的过程,即逐渐增加负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程.3.5 兼容性测试 web 兼容性测试范围主要从操作系统、浏览器、分辨率这三方面考虑,而
39、系统和浏览器是重点考虑方向,系统应该支持什么系统和浏览器,也是应以需求为依据.APP 兼容性主要考虑内部和外部兼容性 1与本地及主流 App 是否兼容；2基于开发环境和生产环境的不同,检验在各种网络连接下WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA 等,App 的数据和运用是否正确；3与各种设备是否兼容,若有跨系统支持则需要检验是否在各系统下,各种行为是否一致：-不同操作系统的兼容性,是否适配-不同手机屏幕分辨率的兼容性-不同手机品牌的兼容性 3.6 安全测试 安全测试是在 IT 软件产品的生命周期中,特别是产品开发基本完成到发布阶段,对产品进行
40、检验以验证产品符合安全需求定义和产品质量标准的过程.如需求上对软件产品有具体的安全等级要求,那么我们需要从下面几个方面进行安全测试：可测试性和通用性上划分为：权限管理测试、认证测试、会话管理测试、服务器测试、数据注入测试,其余方面可在部署和运维中保证.测试内容 权限管理测试 验证用户是否可以进行横向越权和纵向越权操作 页面是否进行权限判断 页面资源标志是否和用户信息匹配 用户登录后,应以会话中的用户 session 的用户身份信息为准.每个 URL 必须坚定权限,不能通过菜单屏蔽或按钮 disable 作为限制条件.认证测试 认证测试是为了避免用户账号和密码遭到暴力破解而进行的测试 系统存在验
41、证码机制.不允许简单面的存在.如纯英文、纯数字等.认证失败的错误提示不应该提示详细信息,避免攻击者根据提示信息改良破解方式.系统存在锁定策略.系统不存在认证绕过的漏洞.找回密码和修改密码不存在漏洞.使用安全的数据传输.强口令策略.会话管理测试 会话管理用于保持用户的整个会话活动与计算机系统跟踪过程,根据项目需求,关注 WEB 服务器的会话管理.用户登录后,身份信息由服务器端会话的 Session 中的用户信息为准.cookie 中不会带有 session ID 信息.用户操作停止后会话保持时间不会超过 10 分钟,超过 10 分钟会跳转回登录界面.用户登录后,每次请求服务器数据后 sessio
42、n ID 都会改变.注销后用户信息被清除.服务器测试 服务器运行账号不应该是特权账号或高级别权限账号,如rootadministrator等.未使用的端口应为关闭状态.不能通过任何方式获得服务器的详细版本信息.数据注入测试 当系统接受数据注入时,可能会造成数据泄露、数据被修改等严重影响,.导致业务中断.不存在注入点.页面中不包含类似系统命令的返回信息.3.7 安装测试 安装测试只针对 C/S 架构的系统,需要验证 App 是否能正确安装、运行、卸载以及操作过程和操作前后对系统资源的使用情况.测试内容 安装 1软件在不同操作系统下安装是否正常.2软件安装后的是否能够正常运行,安装后的文件夹及文件
43、是否写到了指定的目录里.3软件安装各个选项的组合是否符合概要设计说明 4软件安装向导的 UI 测试 5软件安装过程是否可以取消,点击取消后,写入的文件是否如概要设计说明处理 6软件安装过程中意外情况的处理是否符合需求 7安装空间不足时是否有相应提示 8安装后没有生成多余的目录结构和文件 9对于需要通过网络验证之类的安装,在断网情况下尝试一下 10还需要对安装手册进行测试,依照安装手册是否能顺利安装 卸载 1直接删除安装文件夹卸载是否有提示信息.2测试系统直接卸载程序是否有提示信息.3测试卸载后文件是否全部删除所有的安装文件夹.4卸载过程中出现的意外情况的测试.5卸载是否支持取消功能,单击取消后
44、软件卸载的情况.6系统直接卸载 UI 测试,是否有卸载状态进度条提示.4.缺陷管理 4.1 缺陷提交规范 4.1.1 缺陷应有的基本要素*缺陷 ID *缺陷的标题 测试的软件和硬件环境 *测试的软件版本 *缺陷的类型 *缺陷的严重程度 缺陷的处理优先级 *复现缺陷的操作步骤 复现缺陷的测试数据 *缺陷的实际结果描述 *期望的正确结果描述 缺陷产生的原因分析 注释文字和截取的缺陷图像 4.1.2 缺陷的书写规范 缺陷标题 1.标题应该保持简短、准确,提供缺陷的本质信息,并便于读者搜索查寻.2.良好的缺陷标题应该按照以下方式书写：尽量按缺陷发生的原因与结果的方式书写 3.避免使用模糊不清的词语,例
45、如功能中断,功能不正确,行为不起作用,等.应该使用具体文字说明功能如何中断,如何不正确,或如何不起作用 4.为了方便搜索和查询,请使用关键字 5.为了便于他人理解,避免使术语、俚语或过分具体的测试细节 .复现步骤 复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤.为了达到这个要求,复现步骤的信息必须是完整的、准确的、简明的、可复现的.不友好的重现步骤：1.复现步骤包含了过多的多余步骤,而且句子结构混乱,可读性很差,难于理解；2.复现步骤包含了过少的信息,丢失操作的必要步骤.由于提供的步骤不完整,开发人员经常需要种种猜测,努力尝试复现的步骤,浪费了大量时间.由于缺少关键步骤,这些缺陷通常被
46、工程师以不能复现为由拒绝给测试人员.3.测试人员没有对软件缺陷发生的条件和影响区域进行隔离,软件开发人员无法判断该缺陷影响的软件部分,不能进行彻底修正.正确的重现步骤：1.准确无误的重现操作步骤,步骤不多余,无遗漏 2.每一个步骤尽量只记录一个操作 3.每一个步骤前使用数字对步骤编号 4.尽量使用短语和短句,避免复杂句型和句式 5.将常见步骤合并为较少步骤 6.只记录各个操作步骤是什么,不要包括每个操作步骤执行后的结果 实际结果 1.在实际结果部分,仅列出缺陷的一到两个表现特征.使用注释部分列出缺陷的其它问题；2.在缺陷的第一个表现特征后,将随后的步骤和缺陷表现特征移到注释部分.4.2 缺陷生
47、命周期 1.测试人员发现并记录缺陷 2.测试人员将缺陷提交给项目经理,项目经理会对该缺陷进行确认 2.1 如果确认为是一个缺陷,那么项目经理会将该缺陷进行分配 2.2 如果项目经理认为这不是一个缺陷,那么会将该缺陷打回给测试人员,或者直接关闭 .3.开发人员在接到这个缺陷后,也需要先对缺陷进行判断 3.1 如果是缺陷,就对缺陷进行打开,处理完成后将缺陷重新返回给测试人员；3.2 如果不是缺陷,则增加注释,填写拒绝原因,可直接返回给测试人员；3.3 如果无法复现,则与测试人先沟通复现方式,若还是无法复现,则添加注释,问题到待跟踪；3.4 对于暂不修改、目前无法解决或经项目组评估修复成本比较高的,
48、需要放在后面版本修改的,则添加注释将问题挂起 4.测试人员接收到开发人员返回的缺陷后,需要做如下处理 4.1 对于开发人员修复的缺陷进行回归测试,如果测试通过则置为关闭,测试不通过可以重开,重新将缺陷打回给开发人员 4.2 对于开发人员拒绝的缺陷,一般是存在争议的缺陷,经过项目组讨论或评定后,确认不是缺陷可以直接对其进行关闭,如果确认是缺陷,需要对其进行重开,如果该缺陷可暂缓修复或修复成本较高,需另行找时间修复,可将缺陷挂起 5.对于由于需求或产品设计引起的问题 5.1 需求不明确,打开,添加注释,并分配到需求组人员；5.2 产品重新设计,则问题打开、添加注释、分配給产品设计人员 4.3 缺陷
49、等级划分 缺陷的严重等级-按 5 类划分 分类 严重等级 等级描述 5 致命性的 Critical 不能执行正常工作功能或重要功能,或者危及人身安全的,主要表现在：1.由于程序所引起的死机,非法退出 2.死循环 3.导致数据库发生死锁 4.数据通讯错误 5.严重的数值计算错误 4 严重的 Major 严重影响系统要求或基本功能实现的,主要表现在：1.功能不符 .2.数据流错误 3.程序接口错误 4.轻微的数值计算错误 3 一般的 Generic 一般性错误,比较容易修复的,主要表现在：1.界面错误详细文档 2.打印内容、格式错误 3.简单的输入限制未放在前端进行控制 4.删除操作未给出提示 2 轻微的 Minor 比较轻微的错误,一般是使用方面的问题,主要表现在：1.辅助说明描述不清楚 2.显示格式不规范 3.长时间操作未给用户进度提示 4.提示窗口文字未采用行业术语 5.可输入区域和只读区域没有明显的区分标志 6.系统处理未优化 1 建议性的 Suggestion 从测试人员角度提出的一些建议性的问题,不一定是缺陷