软件测试的基本流程与测试规范标准

1、软件测试的基本流程与测试规目录前言1一、软件测试的流程21. 测试基本流程图22. 测试各阶段工作流程32.1需求分析阶段32.2计划与设计阶段42.3测试实施阶段52.4测试结束52.5测试验收和归档7二、软件测试规81测试阶段所基于的文档（包括但不限于）911软件需求规格说明书91.2软件设计说明（概要设计或详细设计）91.3软件设计原型（demo） 101.4接口文档102测试的种类（按阶段划分）102.1单元测试102.2集成测试122.3冒烟测试（非必须）132.4系统测试132.5随机测试（非必须）142.6验收测试（非必须）143. 测试的类型（按测试容划分）153.1功能测试1

2、53.2界面测试（UI测试）223.3接口测试223.4性能测试233.5兼容性测试253.6安全测试253.7安装测试274. 缺陷管理284.1缺陷提交规284.2缺陷生命周期304.3缺陷等级划分31前吕此文档就项目中测试部分的工作流程进行了一个梳理，参考了不同的资 料，提炼整理的容为业已经成型、被大多数项目采用和认可的。因此，该流程 并不针对某一个具体的企业或者项目，运用到某一个项目中时，可进行必要的 増减和修改。另外，文章中测试规部分，也是查阅了网上很多的资料、参考了其他项目 文档，并结合本人经验整理而成，可以覆盖到项目开发过程中会遇到的绝大部 分的测试面，针对不同的测试容，该规也能

3、够起到一定的指导和参考作用。但 是在实际的工作中，放到具体的项目里，也需要根据具体情况和要求进行适当 的调整。软件测试的流程1 测试基本流程图2. 测试各阶段工作流程2.1需求分析阶段测试需整个测试过程的基础；确定测试对象以及测试工作的围和作用。用 来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础， 测试需计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖。开始分析和提取测试需求的时候，整个项目一定至少已经进入设计阶段， 一定要有需求文档、设计说明文档或者原型作为依据。而且被确定的测试需求项必须是可核实的、可测的，不能有模棱两可的概 念，比如：大概、约、或者；也不能为无

4、法量化、主观性的概念，比如： 处理速度快、设计页面好看。它们必须有一个可观察、可评测的结果。无 法核实的需求不是测试需求。测试需制订测试计划的基本依据，确定了测试需求能够为测试计划提供客 观依据；测试需设计测试用例的指导，确定了要测什么、测哪些方面后才能有 针对性的确定测试方案，设计测试用例。过程要点详细说明输入条件项目进入软件设计阶段，至少需要有需求文档、软件设计说明书或者软件原型（demo）工作容测试人员根据相关文档梳理、提取测试需求，确定测试容（功能、性能、兼容性等）、使用的测试方法（手工测试、自动化测试），已保证此次需要测试的容覆盖完整。退出标准提取完整的测试需求点输出容明确测试策略，

5、列出具体的功能列表（非必须项）2.2计划与设计阶段2.2.1测试计划阶段当项目进入到实现阶段，测试经理就应该和整个项目的开发人员、需求设 计人员研究讨论，并对本次测试的交接时间、投入的人力、拟定测试的轮次、 各轮次持续的时间、测试的容和深度进行规模预估，并制定出测试计划。过程要点详细说明输入条件项目进入到实现阶段（编码），需求规格说明书、软件设计 说明书（概要设计或详细设计）、原型（demo）已输出。工作容和整个项目组讨论并确认此次项目测试阶段的人力、时间投 入，测试轮次预估，测试的交接和验收时间退出标准明确测试容、时间、人力安排输出容测试人员提交评审后的测试计划2.2.2测试设计阶段在项目进

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、过程要点详细说明输入条件测试验收通过工作容归档测试过程中所有文档，主要包括以下文档（必须）测试计划测试用例测试报告退出标准全部文档归档完毕输出容归档清单二软件测试规测试代码和项目开发代码应该利用配置管理工具（如SVN）分开管理。测 试代码编写完成后，存放在配置库中。开发过程中，可根据需要对自己编写代 码进行测试。并且测试环境和开发环境应分隔开来，以免相互影响，便于缺陷的复现和 定位，在条件允许的情况下，性能测试环境应和功能测试环境分开，以免在性 能测试过程中对功能测试造成影响。1测试阶段所基于的文档（包括但不限于）测试规形成的前提是需要有有章可循的依据，这些依据需要基干标准的项 目文档，常见的

13、文档包括下面几种：1.1软件需求规格说明书软件需求说明书是为了使用户和软件开发者双方对该软件的初始规定有一 个共同的理解，使之成为整个项目组开展工作的基础。包含硬件、功能、性 能、输入输出、接口需求、警示信息、安全、数据与数据库、文档和法规的要 求等等。软件需求说明书的作用在于便于用户、开发人员进行理解和交流，反映出 用户问题的结构，可以作为软件开发工作的基础和依据，并作为确认测试和验 收的依据。1.2软件设计说明（概要设计或详细设计）软件设计又划分为概要设计和详细设计。概要设计是在用户提出的需求和软件的设计实现之间架起桥梁，是将用户 提出的目标和需求转换成具体界面设计解决方案的重要阶段。概设

14、的主要任务 是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结 构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构 及调用关系、确定模块间的接口及人机交互的界面等。从而设计建立一个目标 系统的逻辑模型。而详细设计是软件工程中软件开发的一个步骤，就是对概要设计的一个细 化，就是详细设计每个模块实现算法，所需的局部结构。在详细设计阶段，主 要是通过需求分析的结果，设计出满足用户需求的软件系统产品。软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将无法溯源，测试准备的前期工作也是根据软件设计说明来制定的。1.3软件设计原型（demo）页面原型是项目人

15、员快速孰悉项目的最佳路径，让开发人员和测试人员更 直观的了解客户的需求和产品的实现方式、业务逻辑，帮助项目人员更快的理 解用户需求、业务逻辑，用更直观，具体的界面化方式来说明用户想要如何来 实现他们需要的功能。或者在需求不够明确，设计说明书不够全面的情况下， 页面原型也是后期测试用例编写思想的重要根据。1.4接口文档当项目中各个子系统间、各个功能模块间有交互，需要开发接口时，接口 文档会定义出参数传递、参数返回的规则，比如：参数的名称、参数的类型、 长度、是否必填、各个返回码所代表的含义，当项目中有接口测试需求的时 候，此文档是很重要的测试依据。2测试的种类（按阶段划分）测试的阶段也根据项目开

16、发的进度来进行，从先到后划分为下面几种测试 阶段：（根据项目的实际要求进行相应测试）2.1单元测试单元测试是指对软件中的最小可测试单元进行检查和验证。准入条件1、源码已实现完成或50%;2、源码编译能通过；3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；4、单元测试用例通过评审并归档；主要测试点和方法代码静态检査无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口 等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义 的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。独立賂径和谋检查独立路径测试：在模块中应对每一条独立执行路径进行测试，每条语

17、句至 少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的 控制流造成的错误。错误检查：首先检查程序是否有错误处理；其次对干程序中的防错处理的 完整性和正确性进行检查。错误处理包括：不同数据类型的对象之间进行比 较；错误地使用逻辑运算符或优先级；因计算机表示的局限性，期望理论上相 等而实际上不相等的两个量相等；比较运算或变量出错；循环终止条件或不可 能出现；迭代发散时不能退出；错误地修改了循环变量。单元测试人员一般是开发自测。參与组织需要参与的人员的职责如下表:编号角色职责说明1需求经理对测试中需求不明确地方，进行明确；2产品经理对测试中产品功能实现歧义地方，进行明确；3开发人

18、员负责功能开发、缺陷修复、单元测试；4开发责任人负责软件开发进度、版本提交和相关协调；5配置管理员负责每轮测试前：代码获取、编译、发布；6测试经理负责项目测试整体计划、协调和质量；2.2集成测试集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块 按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。它最 简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接 口。准入条件1、单元测试用例编写完成；2、核心功能开发完成；3、项目需求文档、概要设计文档、详细设计文档均通过评审并归档；4、子系统间接口说明文档通过评审并归档；5、项目集成测试用例文档通过评审并归档

19、；主要测试点和方法（详见33接口測试章节）參与组织需要参与的人员的职责如下表：编号角色职责说明1需求经理对测试中需求不明确地方，进行明确；2产品经理对测试中产品功能实现歧义地方，进行明确；3开发人员负责功能开发、缺陷修复、单元测试；4开发责任人负责软件开发进度、版本提交和相关协调；5配置管理员负责每轮测试前：代码获取、编译、发布；6测试经理负责项目测试整体计划、协调和质量；2.3冒烟测试（非必须）冒烟测试是开发完成后，正式移交测试前做的一个中间测试工作，即在刚 刚编译出来后，开发人员需要进行基本确认测试，例如是否可以正确安装/卸 载，主要功能是否实现，是否存在严重死机或数据严重丢失等Eug。如

20、果通过 了该测试，则可以移交测试，开始正式测试。否则，就需要重新编译版本，再 次执行版本可接收确认测试，直到成功。该工作可由开发人员先行自测，保证移交测试版本的质量，防止出现阻碍 测试的情况出现，也可由测试人员来进行，只有冒烟测试通过后，才进入正式 的测试流程，否则会把版本打回，重新编译。2.4系统测试系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需 求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的 方案。也是整个测试工作最重要，最关键的测试部分。准入条件1、单元、集成测试完成；2、前阶段中缺陷修复率100%;3、功能用例编写完成，覆盖率达100%;4、项目

21、需求文档、设计文档均通过评审并归档；5、测试用例通过评审并归档；主要测试点和方法（详见3.1功能测试章节）參与组织需要参与的人员的职责如下表：编号角色职责说明1需求经理对测试中需求不明确地方，进行明确；2产品经理对测试中产品功能实现歧义地方，进行明确；3开发人员负责功能开发、缺陷修复、单元测试；4开发责任人负责软件开发进度、版本提交和相关协调；5配置管理员负责每轮测试前：代码获取、编译、发布；6测试经理负责项目测试整体计划、协调和质量；7测试人员负责测试方案编写、测试用例编写、测试执行、质 量分析；2.5随机测试（非必须）随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测 试。主

22、要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测 试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和 过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当 前的测试用例没有覆盖到的部分。另外，对干软件更新和新増加的功能要重点 测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其 对以前测试发现的重大Eug,进行再次测试，可以结合回归测试2.6验收测试（非必须）2.6.1 B测试（beta测试）B测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。当开发和测

23、试根本完成时所做的测试，而最终的错误和问题需要在最终发 行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员 完成。2.6.2 a 测试（Alpha 测试）Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司部的用 户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员 或测试员完成。在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变 更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完 成。a测试和B测试的不同之处在于测试的环境，前者是在开发环境，后者是 在实际使用环境（生产环境），故后者模拟真实使用场景程度更高，发现

24、的问 题也更有意义，一般运用在项目的试运行阶段。3测试的类型（按测试容划分）3.1功能测试功能测试也叫黑盒测试，是在不看代码的前提下，通过运行软件来进行测 试，重点是关注系统的功能实现是否正常、设计是否合理、用户的需否全部覆 盖，这也是测试工作最主要、最重要的容。在版本稳定以后，或者进行回归测 试的时候，可根据项目的具体情况，对主要功能通过编写自动化测试脚本，进 行自动化测试。根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，女口；涉 及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试 等测试类型对其进行覆盖。在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时

25、修正业务或需求理解错误。測试容序列分类说明1基本功能1正常増、删、改、查；2. 正常业务流程；3. 正常权限功能；4. 正常数据调用（包括数据）。2边界类1 验证边界值，对16-bit的整数而言32767和-32768 是边界；2. 屏幕上光标在最左上、最右下位置；3. 报表的第一行和最后一行；4. 数组元素的第一个和最后一个；5. 最小值-1/最大值+1/空值；6. 分析规格说明，找出其它可能的边界值条件。3等价类1. 有效等价类，指符合系统设计有意义的输入输出合集；2. 无效等价类，指不符合系统设计错误的输入输入合集；4错误推测基于经验和直觉推测程序中所有可能存在的各种错误；5因果图设计因

26、果图，将因果图转化为判定表，判定表的每一列作 为一条测试用例。6用户场景设计根据不同用户运行该系统时所做的操作，来设计用例。8APP特有功能1应用的前后台切换；2. 数据更新；3. 离线浏览；4. 定位、照相机服务，扫描二维码功能；5时间测试;6. push 测试;7. 运行测试。App的功能測试具体为：运行1）App安装完成后的试运行，可正常打开软件。2）App打开测试，是否有加载状态进度提示。3）App打开速度测试，速度是否可观。4）App页面间的切换是否流畅，逻辑是否正确5）注册同表单编辑页面用户名密码长度注册后的提示页面前台注册页面和后台的管理页面数据是否一致注册后，在后台管理中页面提

27、示6）登录使用合法的用户登录系统。系统是否允许多次非法的登陆，是否有次数限制。使用已经登陆的账号登陆系统是否正确处理。使用禁用的账号登陆系统是否正确处理。用户名、口令（密码）错误或漏填时能否登陆。删除或修改后的用户，原用户登陆。不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。登陆后，页面中登陆信息。页面中有注销按钮。登陆超时的处理。7）注销注销原模块，新的模块系统能否正确处理。一终止注销能否返回原模块，原用户。一注销原用户，新用户系统能否正确处理。使用错误的账号、口令、无权限的被禁用的账号进行注销应用的前后台切换1）APP切换到后台，再回到Qpp,检査是否停留在上一次操作界面。2）

28、APP切换到后台，再回到Qpp,检查功能及应用状态是否正常，I OS 4 和IOS 5的版本的处理机制有的不一样。3）app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正 常，尤其是对于从后台切换回前台数据有自动更新的时候。4）手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是 对于从后台切换回前台数据有自动更新的时候。5）当App使用过程中有进来中断后再切换到Rpp,功能状态是否正常6）当杀掉QPP进程后，再开启RPP, &PP能否正常启动。7）出现必须处理的提示框后，切换到后台，再切换回来，检査提示框是否 还存在，有时候会出现应用自动跳过提示框的缺陷。8）对于有数

29、据交换的页面，每个页面都必需要进行前后台切换、锁屏的测 试，这种页面最容易出现崩溃。免登录很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来 使用mpp.1）QPP有免登录功能时，需要考虑IOS版本差异。2）考虑无网络情况时能否正常进入免登录状态。3）切换用户登录后，要校验用户登录信息及数据容是否相应更新，确保原 用户退出。4）根据MTOP的现有规则，一个只允许登录一台机器。所以，需要检査一 个登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。5）app切换到后台，再切回前台的校验6）切换到后台，再切换回前台的测试7）密码更换后，检査有数据交换时是否进行了有效身份的校验

30、8）支持自动登录的应用在进行数据交换时，检査系统是否能自动登录成功 并且数据操作无误。9）检査用户主动退出登录后，下次启动QPP，应停留在登录界面数据更新根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方 案。1）需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地 方需要手动+自动刷新。2）确定哪些地方从后台切换回前台时需要进行数据更新。3）根据业务、速度及流量的合理分配，确定哪些容需要实时更新，哪些需 要定时更新。4）确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本 地，这样才能有针对性的进行相应测试。5）检查有数据交换的地方，均有相应的异常处理。离线

31、浏览很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户査 看。1）在无网络情况可以浏览本地数据2）退出app再开启app时能正常浏览3）切换到后台再切回前台可以正常浏览4）锁屏后再解屏回到应用前台可以正常浏览5）在对服务端的数据有更新时会给予离线的相应提示 App更新当客户端有新版本时，有更新提示。2）当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用 户在下次启动app时，仍能出现更新提示。3）当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客 户端。下次启动次PP时，仍出现强制升级提示。4）当客户端有新版本时，在本地不删除客户端的情况下，直接更新检査是 否

32、能正常更新。5）当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客 户端功能是否是新版本。6）当客户端有新版本时，在本地不删除客户端的情况下，检査资源同名文 件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属干缺 陷。定位、照相机服务1）App有用到相机，定位服务时，需要注意系统版本差异2）有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检 査应用是否正常。3）当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定 位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。4）测试定位、照相机服务时，需要采用真机进行测试。时间测试客户端可以

33、自行设置手机的时区、时间，因此需要校验该设置对QPP的影 响。中国为东8区，所以当手机设置的时间非东8区时，査看需要显示时间 的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时 间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇 微博在服务端记录的是10: 00,此时，华盛顿时间为22: 00,客户端去浏览 时，如果设置的是华盛顿时间，则显示的发表时间即为22:00,当时间设回东8 区时间时，再查看则显示为10: 00o PUSH测试1）检査push消息是否按照指定的业务规则发送2）检査不接受推送消息时，检査用户不会再接收到push.3）如果用户设置了免打扰

34、的时间段，检査在免打扰时间段，用户接收不到 PUSHo在非免打扰时间段，用户能正常收到push04）当push消息是针对登录用户的时候，需要检査收到的push与用户身 份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上 最后一个登录用户进行消息推送。5）测试push时，需要采用真机进行测试。3.2界面测试（UI测试）界面测试（简称ui测试），测试用户界面的功能模块的布局是否合理、整 体风格是否一致、各个控件的放置位置是否符合客户使用习惯。測试容1、导航、Cookie、页面结构包括菜单、背景、颜色、字体、按钮名 称、TITLE.提示信息的一致性等；2、界面容完整性检查，通过浏览

35、器测试，确认对象可以正确的反应业务 的功能和需求，包括窗口与窗口之间的跳转，字段与字段之间的浏览，各种快 捷键的使用。3、窗口的对象和特征（例如：菜单、大小、位置、状态和中心）都符合标 准。3.3接口测试当模块之间、子系统之间有接口交互时，需要根据接口文档进行测试，接 口测试也叫集成测试或灰盒测试，主要用于检测外部系统与系统之间以及部各 个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过 程，以及系统间的相互逻辑依赖关系等。测试容1、输入的实际参数与形式参数的个数是否相同；2、输入的实际参数与形式参数的属性是否匹配；3、输入的实际参数与形式参数的量纲是否一致；4、调用其他模块

36、时所给实际参数的个数是否与被调模块的形参个数相 同；5、调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹 配；6、调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;7、调用预定义函数时所用参数的个数、属性和次序是否正确；8、是否存在与当前入口点无关的参数引用；9、是否修改了只读型参数；10、对全局变量的定义各模块是否一致；11、是否把某些约束作为参数传递。12、如果模块功能包括外部输入输出，还应该考虑下列因素：-文件属性 是否正确；-OPEN/CLOSE语句是否正确；13、格式说明与输入输出语句是否匹配；14、缓冲区大小与记录长度是否匹配；15、文件使用前是否已经打开；1

37、6、是否处理了文件尾；17、是否处理了输入/输出错误；输出信息中是否有文字性错误。3.4性能测试性能测试是通过性能测试工具模拟多种正常、峰值以及异常负载条件来对 系统的各项性能指标进行测试。性能测试包括的测试容主要概括为三个方面：应用在客户端性能的测试、 应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面 有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。性能测试的目的是通过确定一个系统的瓶颈或者不能接受的性能点，来获 得系统能提供的最大服务级别的测试。一个系统需要达到的性能指标也是来源 于需求，和用户对该软件的性能要求。常见的性能指标如下：响应时间（按照不同的处理

38、细分）1）事务处理类快速响应类普通响应类2）查询类3）统计类吞吐量与关键量事务成功率服务器资源CPU使用率存使用率I/O吞吐量測试容性能测试类型包括负载测试，强度测试，容量测试等。负载测试：是一种主要为了测试软件系统是否达到需求文档设计的目 标，晉如软件在一定时期，最大支持多少并发用户数，软件请求出错 率等，测试的主要是软件系统的性能。压力测试：强度测试也就是压力测试，压力测试主要是为了测试硬件系 统是否达到需求文档设计的性能目标，晉如在一定时期，系统的cpu 利用率，存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负 载测试最大的差别在于测试目的不同。容量测试：确定系统最大承受量，晉如系

39、统最大用户数，最大存储量， 最多处理的数据流量等另外，并发测试是应用在客户端，以客户端做为入口进行的一项重要性能 测试，它是一个负载测试和压力测试的过程，即逐渐増加负载，直到系统的瓶 颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定 系统并发性能的过程。3.5兼容性测试web兼容性测试围主要从操作系统、浏览器、分辨率这三方面考虑，而系 统（如不同的Windows版本）和浏览器（如IE9、谷歌、火狐）是重点考虑 方向，系统应该支持什么系统和浏览器，也是应以需求为依据。APP兼容性主要考虑部和外部兼容性1）与本地及主流App是否兼容；2）基于开发环境和生产环境的不同，检验在各种

40、网络连接下（WiFi、GSM、GPRS、EDGE、WCDMA、CDMAlx、CDMA2000、HSPDA 等）， App的数据和运用是否正确；3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下， 各种行为是否一致：不同操作系统的兼容性，是否适配一不同手机屏幕分辨率的兼容性一不同手机品牌的兼容性3.6安全测试安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布 阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。如需求上对软件产品有具体的安全等级要求，那么我们需要从下面几个方 面进行安全测试：可测试性和通用性上划分为：权限管理测试、认证测试、会话管理测试

41、、 服务器测试、数据注入测试，其余方面（如环境安全、媒体安全）可在部署和 运维中保证。测试容权限管理测试验证用户是否可以进行横向越权和纵向越权操作页面是否进行权限判断页面资源标志是否和用户信息匹配用户登录后，应以会话中的用户session的用户身份信息为准。每个URL必须坚定权限，不能通过菜单屏蔽或按钮disable作为 限制条件。认证测试认证测试是为了避免用户账号和密码遭到暴力破解而进行的测试系统存在验证码机制。不允许简单面的存在。如纯英文、纯数字等。认证失败的错误提示不应该提示详细信息，避免攻击者根据提示信 息改良破解方式。系统存在锁定策略。系统不存在认证绕过的漏洞。找回密码和修改密码不存

42、在漏洞。使用安全的数据传输。强口令策略。会话管理测试会话管理用于保持用户的整个会话活动与计算机系统跟踪过程，根据 项目需求，关注WEB服务器的会话管理。用户登录后，身份信息由服务器端会话的Session中的用户信息 为准。 coolde中不会带有session ID信息。用户操作停止后会话保持时间不会超过10分钟，超过10分钟会 跳转回登录界面。用户登录后，每次请求服务器数据后session ID都会改变。注销后用户信息被清除。服务器测试服务器运行账号不应该是特权账号或高级别权限账号，如“root” “administrator” 等。未使用的端口应为关闭状态。不能通过任何方式获得服务器的详细

43、版本信息。数据注入测试当系统接受数据注入时，可能会造成数据泄露、数据被修改等严重影 响，导致业务中断。不存在注入点。页面中不包含类似系统命令的返回信息。3.7安装测试安装测试只针对C/S架构的系统（即App）,需要验证App是否能正确 安装、运行、卸载以及操作过程和操作前后对系统资源的使用情况。测试容安装1）软件在不同操作系统（Android、iOS）下安装是否正常（手机端）。2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了 指定的目录里。3）软件安装各个选项的组合是否符合概要设计说明4）软件安装向导的UI测试5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设 计

44、说明处理6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）7）安装空间不足时是否有相应提示8）安装后没有生成多余的目录结构和文件9）对于需要通过网络验证之类的安装，在断网情况下尝试一下10）还需要对安装手册进行测试，依照安装手册是否能顺利安装卸载1）直接删除安装文件夹卸载是否有提示信息。2）测试系统直接卸载程序是否有提示信息。3）测试卸载后文件是否全部删除所有的安装文件夹。4）卸载过程中出现的意外情况的测试（如死机、断电、重启）。5）卸载是否支持取消功能，单击取消后软件卸载的情况。6）系统直接卸载UI测试，是否有卸载状态进度条提示。4. 缺陷管理41缺陷提交规4.1.1缺陷应有

45、的基本要素 广号为必须要素）*缺陷ID （由系统自动生成，唯一的）*缺陷的标题测试的软件和硬件环境（特殊环境下可注明）*测试的软件版本（缺陷发现版本和修复版本，发现版本是指当前版本, 修复版本一般由项目经理确认）*缺陷的类型（功能的、性能的、使用方面、安全的等等）*缺陷的严重程度（由测试人员确定）缺陷的处理优先级（一般由项目经理确定）复现缺陷的操作步骤（操作步骤）复现缺陷的测试数据（特定数据需要注明，比如特定的账号）*缺陷的实际结果描述（错误描述）期望的正确结果描述（期望结果）缺陷产生的原因分析（如果测试人员能判定原因就给出，不能判定就 无需给出，以免误导开发人员）注释文字和截取的缺陷图像4.1.2缺陷的书写规缺陷标题1. 标题应该保持简短、准确，提供缺陷的本质信息，并便于读者搜索査 寻。2. 良好的缺陷标题应该按照下列方式书写：尽量按缺陷发生的原因与结果的方式书写（执行完A后，发生B, ”或 者发生E,当A执行完后”）3避免使用模糊不清的词语，例如“功能中断，功能不正确，行为不起作 用，”等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作 用4为了方便搜索和査询，请使用关键字5为了便于他人理解，避免使术