软件测试的基本作业流程与测试标准规范.docx

软件测试基础步骤和测试规范
目录
前言 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
3.4性能测试 20
3.5兼容性测试 22
3.6安全测试 22
3.7安装测试 24
4.缺陷管理 25
4.1缺陷提交规范 25
4.2缺陷生命周期 27
4.3缺陷等级划分 28

序言
此文档就项目中测试部分工作步骤进行了一个梳理，参考了不一样资料，提炼整理内容为业内已经成型、被大多数项目采取和认可。所以，该步骤并不针对某一个具体企业或项目，利用到某一个项目中时，可进行必需增减和修改。
另外，文章中测试规范部分，也是查阅了网上很多资料、参考了其它项目文档，并结合本人经验整理而成，能够覆盖到项目开发过程中会碰到绝大部分测试面，针对不一样测试内容，该规范也能够起到一定指导和参考作用。不过在实际工作中，放到具体项目里，也需要依据具体情况和要求进行合适调整。
一、软件测试步骤
1.测试基础步骤图

2.测试各阶段工作步骤
2.1需求分析阶段
测试需求是整个测试过程基础；确定测试对象和测试工作范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖基础，测试需求是计算测试覆盖分母，没有测试需求就无法有效地进行测试覆盖。
开始分析和提取测试需求时候，整个项目一定最少已经进入设计阶段，一定要有需求文档、设计说明文档或原型作为依据。
而且被确定测试需求项必需是可核实、可测，不能有模棱两可概念，比如：大约、约、或……；也不能为无法量化、主观性概念，比如：处理速度快、设计页面好看……。它们必需有一个可观察、可评测结果。无法核实需求不是测试需求。
测试需求是制订测试计划基础依据，确定了测试需求能够为测试计划提供客观依据； 测试需求是设计测试用例指导，确定了要测什么、测哪些方面后才能有针对性确实定测试方案，设计测试用例。
过程关键点
具体说明
输入条件
项目进入软件设计阶段，最少需要有需求文档、软件设计说明书或软件原型（demo）
工作内容
测试人员依据相关文档梳理、提取测试需求，确定测试内容（功效、性能、兼容性等）、使用测试方法（手工测试、自动化测试），已确保此次需要测试内容覆盖完整。
退出标准
提取完整测试需求点
输出内容
明确测试策略，列出具体功效列表（非必需项）
2.2计划和设计阶段
2.2.1测试计划阶段
当项目进入到实现阶段，测试经理就应该和整个项目标开发人员、需求设计人员研究讨论，并对此次测试交接时间、投入人力、确定测试轮次、各轮次连续时间、测试内容和深度进行规模预估，并制订出测试计划。

过程关键点
具体说明
输入条件
项目进入到实现阶段（编码），需求规格说明书、软件设计说明书（概要设计或具体设计）、原型（demo）已输出。
工作内容
和整个项目组讨论并确定此次项目测试阶段人力、时间投入，测试轮次预估，测试交接和验收时间
退出标准
明确测试内容、时间、人力安排
输出内容
测试人员提交评审后《测试计划》
2.2.2测试设计阶段
在项目进入实现阶段同时，测试人员还需要依据基线版软件需求规格说明书和产品设计说明书编写测试用例。依据每一个测试需求点和功效点，利用不一样用例设计方法编写用例，针对不一样测试内容，可能会包含到用例包含：功效测试用例、性能测试用例、接口测试用例和自动化测试用例。
过程关键点
具体说明
输入条件
测试需求明确，测试计划明确，已经有基线需求和测试计划
工作内容
依据每一步测试计划编写全部测试用例
退出标准
测试用例需要覆盖全部测试需求
输出内容
测试人员提交评审后《测试用例》，测试脚本（性能、自动化）
2.3测试实施阶段
测试实施阶段是测试人员在整个项目中需要投入最多工作量阶段，也是最关键，最关键一个阶段。在这个阶段中，测试人员需要依据前期测试计划、测试策略来实施测试用例，依据设计测试用例来实施测试，并使用测试管理工具统计、提交、跟踪测试中发觉缺点，并配合、督促开发人员复现、定位、修复缺点，然后验证和关闭缺点。
过程关键点
具体说明
输入条件
测试用例
工作内容
依据测试计划中分配给自己测试任务，在测试计划时间段内，实施对应全部测试用例，并将测试结果统计到测试管理工具中。如有需求和设计上变更，需要不停完善测试用例。
退出标准
实施完成全部测试用例，结果被统计
输出内容
测试结果（输出到测试管理工具中）

2.4测试结束
约定测试周期完成后，测试人员需要总结此次测试结果，并编写汇报。
2.4.1缺点汇报提交
测试结束后，依据项目组要求和具体情况，可能会要求提交缺点汇报（非必需），统计此次测试过程中出现缺点数量、分布情况、各功效模块发觉缺点占比、严重等级和修复情况等。缺点汇报内容侧重对于缺点统计和分析。
2.4.2测试汇报提交
测试汇报是在一个测试阶段结束后，或项目标全部测试工作结束后需要提交，所以汇报又分为阶段性测试汇报，和总结性测试汇报。汇报需要对此次或此阶段测试情况进行统计，汇总，分析，以供整个项目组了解软件开发质量、开发进度及软件修复情况，对项目经理决定上线是否，上线时间，项目是否会延期等相关决议提供一个关键参考依据。
过程关键点
具体说明
输入条件
测试人员完成了预定周期测试任务（一个阶段或整个项目）
工作内容
（阶段性汇报）
测试人员依据此轮测试结果，编写阶段性测试汇报，关键应包含以下内容：
l 测试汇报版本
l 测试人员和时间
l 测试所覆盖缺点——测试组在这轮测试中全部处理缺点情况
l 上一版本活动缺点数量（未关闭缺点）
l 经过此轮测试，全部活动缺点数量及其状态分类
l 测试评定——写明在这一版本中，哪些功效被实现了，哪些还没有实现，这里只需写明和上一版本不一样之处即可。
l 急待处理问题——写明目前项目组中面临优先级最高问题（非必需项）
工作内容
（总结性汇报）
当整个项目标测试工作全部结束后，测试人员应就该项目标测试情况编写总结性测试汇报，测试汇报必需包含以下内容：
l 测试资源概述——多少人、多长时间
l 测试结果摘要——分别描述各个测试需求测试结果，产品实现了哪些功效点，哪些没有实现，和没有实现原因。
l 缺点分析——根据缺点属性分类分析，比如：缺点总数、各模块缺点分布、不一样严重等级缺点、缺点修复情况、未修复缺点及未修复原因、对项目整体影响等等（也可单独写一份《缺点汇报》）
l 测试评定——从总体对项目质量进行评定
l 测试组提议——从测试组角度为项目组提出工作提议
退出标准
此次测试中全部相关测试数据统计完成，完成统计分析
输出内容
《缺点汇报》（非必需）、《测试汇报》（依据实际项目规模可细分为阶段性和总结性）
2.5测试验收和归档
2.5.1测试验收
当上述全部工作完成后，测试人员应对测试过程、效果进行验收，宣告测试全部工作完成（依据实际项目标规模来定，非必需）
过程关键点
具体说明
输入条件
测试实施工作结束，全部测试文档已编写完成
工作内容
测试验收工作由测试经理进行，验收内容汇报：
l 测试效果验收——测试是否达成预期目标
l 测试文档验收——测试过程汉字档是否齐全，是否符合标准
l 测试评定——从总体对测试质量进行评定
l 测试提议——对此次测试工作指出不足，并对以后工作提出改善、优化提议
l 宣告测试结束——测试组组员签字宣告此次测试结束
退出标准
签发测试验收汇报
输出内容
全部测试人员《测试验收汇报》
2.5.2测试归档
测试归档是在测试验收结束宣告测试有效，结束测试后，对测试过程中包含到多种标准文档进行归档。
过程关键点
具体说明
输入条件
测试验收经过
工作内容
归档测试过程中全部文档，关键包含以下文档（必需）
l 测试计划
l 测试用例
l 测试汇报
退出标准
全部文档归档完成
输出内容
归档清单

二、软件测试规范
测试代码和项目开发代码应该利用配置管理工具（如SVN）分开管理。测试代码编写完成后，存放在配置库中。开发过程中，可依据需要对自己编写代码进行测试。
而且测试环境和开发环境应分隔开来，以免相互影响，便于缺点复现和定位，在条件许可情况下，性能测试环境应和功效测试环境分开，以免在性能测试过程中对功效测试造成影响。
1.测试阶段所基于文档（包含但不限于）
测试规范形成前提是需要有有章可循依据，这些依据需要基于标准项目文档，常见文档包含下面多个：
1.1软件需求规格说明书
软件需求说明书是为了使用户和软件开发者双方对该软件初始要求有一个共同了解， 使之成为整个项目组开展工作基础。包含硬件、功效、性能、输入输出、接口需求、警示信息、保密安全、数据和数据库、文档和法规要求等等。
软件需求说明书作用在于便于用户、开发人员进行了解和交流，反应出用户问题结构，能够作为软件开发工作基础和依据，并作为确定测试和验收依据。
1.2软件设计说明（概要设计或具体设计）
软件设计又划分为概要设计和具体设计。
概要设计是在用户提出需求和软件设计实现之间架起桥梁，是将用户提出目标和需求转换成具体界面设计处理方案关键阶段。概设关键任务是把需求分析得到系统扩展用例图转换为软件结构和数据结构。设计软件结构具体任务是：将一个复杂系统按功效进行模块划分、建立模块层次结构及调用关系、确定模块间接口及人机交互界面等。从而设计建立一个目标系统逻辑模型。
而具体设计是软件工程中软件开发一个步骤，就是对概要设计一个细化，就是具体设计每个模块实现算法，所需局部结构。在具体设计阶段，关键是经过需求分析结果，设计出满足用户需求软件系统产品。
软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将无法溯源，测试准备前期工作也是依据软件设计说明来制订。
1.3软件设计原型（demo）
页面原型是项目人员快速熟悉项目标最好路径，让开发人员和测试人员更直观了解用户需求和产品实现方法、业务逻辑，帮助项目人员愈加快了解用户需求、业务逻辑，用更直观，具体界面化方法来说明用户想要怎样来实现她们需要功效。或在需求不够明确，设计说明书不够全方面情况下，页面原型也是后期测试用例编写思想关键依据。
1.4接口文档
当项目中各个子系统间、各个功效模块间有交互，需要开发接口时，接口文档会定义出参数传输、参数返回规则，比如：参数名称、参数类型、长度、是否必填、各个返回码所代表含义…，当项目中有接口测试需求时候，此文档是很关键测试依据。
2.测试种类（按阶段划分）
测试阶段也依据项目开发进度来进行，从先到后划分为下面多个测试阶段：（依据项目标实际要求进行对应测试）
2.1单元测试
单元测试是指对软件中最小可测试单元进行检验和验证。
准入条件
1、 源码已实现完成或50%；
2、 源码编译能经过；
3、 项目需求文档、概要设计文档、具体设计文档均经过评审并归档；
4、 单元测试用例经过评审并归档；

关键测试点和方法
l 代码静态检验
无需运行被测代码，仅经过分析或检验源程序语法、结构、过程、接口等来检验程序正确性，找出代码隐藏错误和缺点，如参数不匹配，有歧义嵌套语句，错误递归，非法计算，可能出现空指针引用等等。
l 独立路径和错误检验
独立路径测试：在模块中应对每一条独立实施路径进行测试，每条语句最少实施一次。测试目标关键是为了发觉因错误计算、不正确比较和不合适控制流造成错误。
错误检验：首先检验程序是否有错误处理；其次对于程序中防错处理完整性和正确性进行检验。错误处理包含：不一样数据类型对象之间进行比较；错误地使用逻辑运算符或优先级；因计算机表示不足，期望理论上相等而实际上不相等两个量相等；比较运算或变量犯错；循环终止条件或不可能出现；迭代发散时不能退出；错误地修改了循环变量。
单元测试人员通常是开发自测。
参与组织
需要参与人员职责以下表：
编号
角色
职责说明
1
需求经理
对测试中需求不明确地方，进行明确；
2
产品经理
对测试中产品功效实现歧义地方，进行明确；
3
开发人员
负责功效开发、缺点修复、单元测试；
4
开发责任人
负责软件开发进度、版本提交和相关协调；
5
配置管理员
负责每轮测试前：代码获取、编译、公布；
6
测试经理
负责项目测试整体计划、协调和质量；

2.2集成测试
集成测试，也叫组装测试或联合测试。在单元测试基础上，将全部模块根据设计要求（如依据结构图）组装成为子系统或系统，进行集成测试。它最简单形式是：把两个已经测试过单元组合成一个组件，测试它们之间接口。
准入条件
1、 单元测试用例编写完成；
2、 关键功效开发完成；
3、 项目需求文档、概要设计文档、具体设计文档均经过评审并归档；
4、 子系统间接口说明文档经过评审并归档；
5、 项目集成测试用例文档经过评审并归档；

关键测试点和方法（详见3.3接口测试章节）
参与组织
需要参与人员职责以下表：
编号
角色
职责说明
1
需求经理
对测试中需求不明确地方，进行明确；
2
产品经理
对测试中产品功效实现歧义地方，进行明确；
3
开发人员
负责功效开发、缺点修复、单元测试；
4
开发责任人
负责软件开发进度、版本提交和相关协调；
5
配置管理员
负责每轮测试前：代码获取、编译、公布；
6
测试经理
负责项目测试整体计划、协调和质量；

2.3冒烟测试（非必需）
冒烟测试是开发完成后，正式移交测试前做一个中间测试工作，即在刚刚编译出来后，开发人员需要进行基础确定测试，比如是否能够正确安装/卸载，关键功效是否实现，是否存在严重死机或数据严重丢失等Bug。假如经过了该测试，则能够移交测试，开始正式测试。不然，就需要重新编译版本，再次实施版本可接收确定测试，直到成功。
该工作可由开发人员先行自测，确保移交测试版本质量，预防出现阻碍测试情况出现，也可由测试人员来进行，只有冒烟测试经过后，才进入正式测试步骤，不然会把版本打回，重新编译。
2.4系统测试
系统测试是针对整个产品系统进行测试，目标是验证系统是否满足了需求规格定义，找出和需求规格不符或和之矛盾地方，从而提出愈加完善方案。也是整个测试工作最关键，最关键测试部分。
准入条件
1、 单元、集成测试完成；
2、 前阶段中缺点修复率100%；
3、 功效用例编写完成，覆盖率达100%；
4、 项目需求文档、设计文档均经过评审并归档；
5、 测试用例经过评审并归档；
关键测试点和方法（详见3.1功效测试章节）
参与组织
需要参与人员职责以下表：
编号
角色
职责说明
1
需求经理
对测试中需求不明确地方，进行明确；
2
产品经理
对测试中产品功效实现歧义地方，进行明确；
3
开发人员
负责功效开发、缺点修复、单元测试；
4
开发责任人
负责软件开发进度、版本提交和相关协调；
5
配置管理员
负责每轮测试前：代码获取、编译、公布；
6
测试经理
负责项目测试整体计划、协调和质量；
7
测试人员
负责测试方案编写、测试用例编写、测试实施、质量分析；
2.5随机测试（非必需）
随机测试没有书面测试用例、统计期望结果、检验列表、脚本或指令测试。关键是依据测试者经验对软件进行功效和性能抽查。随机测试是依据测试说明书实施用例测试关键补充手段，是确保测试覆盖完整性有效方法和过程。
随机测试关键是对被测软件部分关键功效进行复测，也包含测试那些目前测试用例没有覆盖到部分。另外，对于软件更新和新增加功效要关键测试。关键对部分特殊点情况点、特殊使用环境、并发性、进行检验。尤其对以前测试发觉重大Bug，进行再次测试，能够结合回归测试
2.6验收测试（非必需）
2.6.1 β测试 （beta测试）
β测试是软件多个用户在一个或多个用户实际使用环境下进行测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
当开发和测试根本完成时所做测试，而最终错误和问题需要在最终发行前找到。这种测试通常由最终用户或其它人员完成，不能由程序员或测试员完成。
2.6.2 α测试（Alpha测试）
Alpha测试是由一个用户在开发环境下进行测试，也能够是企业内部用户在模拟实际操作环境下进行受控测试，Alpha测试不能由该系统程序员或测试员完成。
在系统开发靠近完成时对应用系统测试;测试后，仍然会有少许设计变更。这种测试通常由最终用户或其它人员来完成，不能由程序员或测试员完成。
α测试和β测试不一样之处于于测试环境，前者是在开发环境，后者是在实际使用环境（生产环境），故后者模拟真实使用场景程度更高，发觉问题也更有意义，通常利用在项目标试运行阶段。
3.测试类型（按测试内容划分）
3.1功效测试
功效测试也叫黑盒测试，是在不看代码前提下，经过运行软件来进行测试，关键是关注系统功效实现是否正常、设计是否合理、用户需求是否全部覆盖，这也是测试工作最关键、最关键内容。在版本稳定以后，或进行回归测试时候，可依据项目标具体情况，对关键功效经过编写自动化测试脚本，进行自动化测试。
依据被测功效点特征列丼出对应类型测试用例对其进行覆盖，如；包含输入地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
在测试实现各个阶段跟踪测试实现和需求输入覆盖情况，立即修正业务或需求了解错误。
测试内容
序列
分类
说明
1
基础功效
1.正常增、删、改、查；
2.正常业务步骤；
3.正常权限功效；
4.正常数据调用（包含数据）。
2
边界类
1.验证边界值，对16-bit 整数而言 32767 和 -32768 是边界；
2.屏幕上光标在最左上、最右下位置；
3.报表第一行和最终一行；
4.数组元素第一个和最终一个；
5.最小值-1/最大值+1/空值；
6.分析规格说明，找出其它可能边界值条件。
3
等价类
1.有效等价类，指符合系统设计有意义输入输出合集；
2.无效等价类，指不符合系统设计错误输入输入合集；
4
错误推测
基于经验和直觉推测程序中全部可能存在多种错误；
5
因果图
设计因果图，将因果图转化为判定表，判定表每一列作为一条测试用例。
6
用户场景设计
依据不一样用户运行该系统时所做操作，来设计用例。
8
APP特有功效
1.应用前后台切换；
2.数据更新；
3.离线浏览；
4.定位、摄影机服务，扫描二维码功效；
5.时间测试；
6.push测试；
7.运行测试。

App功效测试具体为：
l 运行
1）App安装完成后试运行，可正常打开软件。
2）App打开测试，是否有加载状态进度提醒。
3）App打开速度测试，速度是否可观。
4）App页面间切换是否流畅，逻辑是否正确
5）注册
--同表单编辑页面
--用户名密码长度
--注册后提醒页面
--前台注册页面和后台管理页面数据是否一致
--注册后，在后台管理中页面提醒
6）登录
--使用正当用户登录系统。
--系统是否许可数次非法登陆，是否有次数限制。
--使用已经登陆账号登陆系统是否正确处理。
--使用禁用账号登陆系统是否正确处理。
--用户名、口令（密码）错误或漏填时能否登陆。
--删除或修改后用户，原用户登陆。
--不输入用户口令和用户、反复点（确定或取消按钮）是否许可登陆。
--登陆后，页面中登陆信息。
--页面中有注销按钮。
--登陆超时处理。
7）注销
--注销原模块，新模块系统能否正确处理。
--终止注销能否返回原模块，原用户。
--注销原用户，新用户系统能否正确处理。
--使用错误账号、口令、无权限被禁用账号进行注销

l 应用前后台切换
1) APP切换到后台，再回到app，检验是否停留在上一次操作界面。
2) APP切换到后台，再回到app，检验功效及应用状态是否正常，IOS 4和IOS 5版本处理机制有不一样。
3) app切换到后台，再回到前台时，注意程序是否瓦解，功效状态是否正常，尤其是对于从后台切换回前台数据有自动更新时候。
4) 手机锁屏解屏后进入app注意是否会瓦解，功效状态是否正常，尤其是对于从后台切换回前台数据有自动更新时候。
5) 当App使用过程中有电话进来中止后再切换到app，功效状态是否正常
6) 当杀掉app进程后，再开启app，app能否正常开启。
7) 出现必需处理提醒框后，切换到后台，再切换回来，检验提醒框是否还存在，有时候会出现应用自动跳过提醒框缺点。
8) 对于有数据交换页面，每个页面全部必需要进行前后台切换、锁屏测试，这种页面最轻易出现瓦解。

l 免登录
很多应用提供免登录功效，当应用开启时自动以上一次登录用户身份来使用app.
1) app有免登录功效时，需要考虑IOS版本差异。
2) 考虑无网络情况时能否正常进入免登录状态。
3) 切换用户登录后，要校验用户登录信息及数据内容是否对应更新，确保原用户退出。
4) 依据MTOP现有规则，一个帐户只许可登录一台机器。所以，需要检验一个帐户登录多台手机情况。原手机里用户需要被踢出，给出友好提醒。
5) app切换到后台，再切回前台校验
6) 切换到后台，再切换回前台测试
7) 密码更换后，检验有数据交换时是否进行了有效身份校验
8) 支持自动登录应用在进行数据交换时，检验系统是否能自动登录成功而且数据操作无误。
9) 检验用户主动退出登录后，下次开启app，应停留在登录界面

l 数据更新
依据应用业务规则，和数据更新量情况，来确定最优数据更新方案。
1) 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。
2) 确定哪些地方从后台切换回前台时需要进行数据更新。
3) 依据业务、速度及流量合理分配，确定哪些内容需要实时更新，哪些需要定时更新。
4) 确定数据展示部分处理逻辑，是每次从服务端请求，还是有缓存到当地，这么才能有针对性进行对应测试。
5) 检验有数据交换地方，全部有对应异常处理。

l 离线浏览
很多应用会支持离线浏览，即在当地用户端会缓存一部分数据供用户查看。
1) 在无网络情况能够浏览当地数据
2) 退出app再开启app时能正常浏览
3) 切换到后台再切回前台能够正常浏览
4) 锁屏后再解屏回到应用前台能够正常浏览
5) 在对服务端数据有更新时会给离线对应提醒

l App更新
当用户端有新版本时，有更新提醒。
2) 当版本为非强制升级版时，用户能够取消更新，老版本能正常使用。用户在下次开启app时，仍能出现更新提醒。
3) 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出用户端。下次开启app时，仍出现强制升级提醒。
4) 当用户端有新版本时，在当地不删除用户端情况下，直接更新检验是否能正常更新。
5) 当用户端有新版本时，在当地不删除用户端情况下，检验更新后用户端功效是否是新版本。
6) 当用户端有新版本时，在当地不删除用户端情况下，检验资源同名文件图片是否能正常更新成最新版本。假如以上无法更新成功，也全部属于缺点。

l 定位、摄影机服务
1) App有用到相机，定位服务时，需要注意系统版本差异
2) 有用到定位服务、摄影机服务地方，需要进行前后台切换测试，检验应用是否正常。
3) 当定位服务没有开启时，使用定位服务，会友好性弹出是否许可设置定位提醒。当确定许可开启定位时，能自动跳转到定位设置中开启定位服务。
4) 测试定位、摄影机服务时，需要采取真机进行测试。

l 时间测试
用户端能够自行设置手机时区、时间，所以需要校验该设置对app影响。
--中国为东8区，所以当手机设置时间非东8区时，查看需要显示时间地方，时间是否展示正确，应用功效是否正常。时间通常需要依据服务器时间再转换成用户端对应时区来展示，这么用户体验比很好。比如发表一篇微博在服务端统计是10：00，此时，华盛立即间为22：00，用户端去浏览时，假如设置是华盛立即间,则显示发表时间即为22:00,当初间设回东8区时间时，再查看则显示为10：00。

l PUSH测试
1) 检验push消息是否根据指定业务规则发送
2) 检验不接收推送消息时，检验用户不会再接收到push.
3) 假如用户设置了免打搅时间段，检验在免打搅时间段内，用户接收不到PUSH。在非免打搅时间段，用户能正常收到push。
4) 当push消息是针对登录用户时候，需要检验收到push和用户身份是否相符，没有错误地将其它人消息推送过来。通常情况下，只对手机上最终一个登录用户进行消息推送。
5) 测试push时，需要采取真机进行测试。
3.2界面测试（UI测试）
界面测试（简称UI测试)，测试用户界面功效模块布局是否合理、整体风格是否一致、各个控件放置位置是否符适用户使用习惯。
测试内容
1、 导航、链接、Cookie、页面结构包含菜单、背景、颜色、字 体、按钮名称、TITLE、提醒信息一致性等；
2、 界面内容完整性检验，经过浏览器测试，确定对象能够正确反应业务功效和需求，包含窗口和窗口之间跳转，字段和字段之间浏览，多种快捷键使用。
3、 窗口对象和特征（比如：菜单、大小、位置、状态和中心）全部符合标准。
3.3接口测试
当模块之间、子系统之间有接口交互时，需要依据接口文档进行测试，接口测试也叫集成测试或灰盒测试，关键用于检测外部系统和系统之间和内部各个子系统之间交互点。测试关键是要检验数据交换，传输和控制管理过程，和系统间相互逻辑依靠关系等。
测试内容
1、 输入实际参数和形式参数个数是否相同；
2、 输入实际参数和形式参数属性是否匹配；
3、 输入实际参数和形式参数量纲是否一致；
4、 调用其它模块时所给实际参数个数是否和被调模块形参个数相同；
5、 调用其它模块时所给实际参数属性是否和被调模块形参属性匹配；
6、 调用其它模块时所给实际参数量纲是否和被调模块形参量纲一致；
7、 调用预定义函数时所用参数个数、属性和次序是否正确；
8、 是否存在和目前入口点无关参数引用；
9、 是否修改了只读型参数；
10、 对全局变量定义各模块是否一致；
11、 是否把一些约束作为参数传输。
12、 假如模块功效包含外部输入输出，还应该考虑下列原因：-文件属性是否正确；-OPEN/CLOSE语句是否正确；
13、 格式说明和输入输出语句是否匹配；
14、 缓冲区大小和统计长度是否匹配；
15、 文件使用前是否已经打开；
16、 是否处理了文件尾；
17、 是否处理了输入/输犯错误；
18、 输出信息中是否有文字性错误。
3.4性能测试
性能测试是经过性能测试工具模拟多个正常、峰值和异常负载条件来对系统各项性能指标进行测试。
性能测试包含测试内容关键概括为三个方面：应用在用户端性能测试、应用在网络上性能测试和应用在服务器端性能测试。通常情况下，三方面有效、合理结合，能够达成对系统性能全方面分析和瓶颈估计。
性能测试目标是经过确定一个系统瓶颈或不能接收性能点，来取得系统能提供最大服务等级测试。一个系统需要达成性能指标也是起源于需求，和用户对该软件性能要求。
常见性能指标以下：
l 响应时间（根据不一样处理细分）
1）事务处理类
快速响应类
一般响应类
2）查询类
3）统计类
l 吞吐量和关键量
l 事务成功率
l 服务器资源
CPU使用率
内存使用率
I/O吞吐量
测试内容
性能测试类型包含负载测试，强度测试，容量测试等。
l 负载测试：是一个关键为了测试软件系统是否达成需求文档设计目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求犯错率等，测试关键是软件系统性能。
l 压力测试：强度测试也就是压力测试，压力测试关键是为了测试硬件系统是否达成需求文档设计性能目标，譬如在一定时期内，系统cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大差异在于测试目标不一样。
l 容量测试：确定系统最大承受量，譬如系统最大用户数，最大存放量，最多处理数据流量等。
另外，并发测试是应用在用户端，以用户端做为入口进行一项关键性能测试，它是一个负载测试和压力测试过程，即逐步增加负载，直到系统瓶颈或不能接收性能点，经过综合分析交易实施指标和资源监控指标来确定系统并发性能过程。
3.5兼容性测试
web兼容性测试范围关键从操作系统、浏览器、分辨率这三方面考虑， 而系统（如不一样Windows版本）和浏览器（如IE9、谷歌、火狐）是关键考虑方向，系统应该支持什么系统和浏览器，也是应以需求为依据。
APP兼容性关键考虑内部和外部兼容性
1）和当地及主流App是否兼容；
2）基于开发环境和生产环境不一样，检验在多种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA、HSPDA等)，App数据和利用是否正确；
3）和多种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，多种行为是否一致：
--不一样操作系统兼容性，是否适配
--不一样手机屏幕分辨率兼容性
--不一样手机品牌兼容性
3.6安全测试
安全测试是在IT软件产品生命周期中，尤其是产品开发基础完成到公布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准过程 。
如需求上对软件产品有具体安全等级要求，那么我们需要从下面多个方面进行安全测试：
可测试性和通用性上划分为：权限管理测试、认证测试、会话管理测试、服务器测试、数据注入测试，其它方面（如环境安全、媒体安全）可在布署和运维中确保。
测试内容
l 权限管理测试
验证用户是否能够进行横向越权和纵向越权操作
Ø 页面是否进行权限判定
Ø 页面资源标志是否和用户信息匹配
Ø 用户登录后，应以会话中用户session用户身份信息为准。
Ø 每个URL必需坚定权限，不能经过菜单屏蔽或按钮disable作为限制条件。
l 认证测试
认证测试是为了避免用户账号和密码遭到暴力破解而进行测试
Ø 系统存在验证码机制。
Ø 不许可简单面存在。如纯英文、纯数字等。
Ø 认证失败错误提醒不应该提醒具体信息，避免攻击者依据提醒信息改良破解方法。
Ø 系统存在锁定策略。
Ø 系统不存在认证绕过漏洞。
Ø 找回密码和修改密码不存在漏洞。
Ø 使用安全数据传输。
Ø 强口令策略。
l 会话管理测试
会话管理用于保持用户整个会话活动和计算机系统跟踪过程，依据项目需求，关注WEB服务器会话管理。
Ø 用户登录后，身份信息由服务器端会话Session中用户信息为准。
Ø cookie中不会带有session ID信息。
Ø 用户操作停止后会话保持时间不会超出10分钟，超出10分钟会跳转回登录界面。
Ø 用户登录后，每次请求服务器数据后session ID全部会改变。
Ø 注销后用户信息被清除。
l 服务器测试
Ø 服务器运行账号不应该是特权账号或高等级权限账号，如“root”“administrator”等。
Ø 未使用端口应为关闭状态。
Ø 不能经过任何方法取得服务器具体版本信息。
l 数据注入测试
当系统接收数据注入时，可能会造成数据泄露、数据被修改等严重影响，造成业务中止。
Ø 不存在注入点。
Ø 页面中不包含类似系统命令返回信息。
3.7安装测试
安装测试只针对C/S架构系统（即App），需要验证App是否能正确安装、运行、卸载和操作过程和操作前后对系统资源使用情况。
测试内容
l 安装
1）软件在不一样操作系统（Android、iOS）下安装是否正常（手机端）。
2）软件安装后是否能够正常运行，安装后文件夹及文件是否写到了指定目录里。
3）软件安装各个选项组合是否符合概要设计说明
4)）软件安装向导UI测试
5）软件安装过程是否能够取消，点击取消后，写入文件是否如概要设计说明处理
6）软件安装过程中意外情况处理是否符合需求（如死机，重启，断电）
7）安装空间不足时是否有对应提醒
8）安装后没有生成多出目录结构和文件
9）对于需要经过网络验证之类安装，在断网情况下尝试一下
10）还需要对安装手册进行测试，依据安装手册是否能顺利安装
l 卸载
1）直接删除安装文件夹卸载是否有提醒信息。
2）测试系统直接卸载程序是否有提醒信息。
3）测试卸载后文件是否全部删除全部安装文件夹。
4）卸载过程中出现意外情况测试（如死机、断电、重启）。
5）卸载是否支持取消功效，单击取消后软件卸载情况 。
6）系统直接卸载UI测试，是否有卸载状态进度条提醒 。
4.缺点管理
4.1缺点提交规范
4.1.1缺点应有基础要素（*号为必需要素）
*缺点ID（由系统自动生成，唯一）
*缺点标题
测试软件和硬件环境（特殊环境下可注明）
*测试软件版本（缺点发觉版本和修复版本，发觉版本是指目前版本，修复版本通常由项目经理确定）
*缺点类型（功效、性能、使用方面、安全等等）
*缺点严重程度（由测试人员确定）
缺点处理优先级（通常由项目经理确定）
*复现缺点操作步骤（操作步骤）
复现缺点测试数据 （特定数据需要注明，比如特定账号）
*缺点实际结果描述（错误描述）
*期望正确结果描述（期望结果）
缺点产生原因分析 （假如测试人员能判定原因就给出，不能判定就无需给出，以免误导开发人员）
注释文字和截取缺点图像

4.1.2缺点书写规范
l 缺点标题
1.标题应该保持简短、正确，提供缺点本质信息，并便于读者搜索查寻。
2.良好缺点标题应该根据下列方法书写：
尽可能按缺点发生原因和结果方法书写（“实施完A后，发生B，”或“发生B， 当A实施完后”）
3.避免使用模糊不清词语，比如“功效中止，功效不正确，行为不起作用，”等。应该使用具体文字说明功效怎样中止，怎样不正确，或怎样不起作用
4.为了方便搜索和查询，请使用关键字
5.为了便于她人了解，避免使术语、俚语或过分具体测试细节

l 复现步骤
复现步骤包含怎样使她人能够很轻易复现该缺点完整步骤。为了达成这个要求，复现步骤信息必需是完整、正确、简明、可复现。
不友好重现步骤：
1.复现步骤包含了过多多出步骤，而且句子结构混乱，可读性很差，难于了解；
2.复现步骤包含了过少信息，丢失操作必需步骤。
因为提供步骤不完整，开发人员常常需要种种猜测，努力尝试复现步骤，浪费了大量时间。因为缺乏关键步骤，这些缺点通常被工程师以“不能