软件测试操作指南和规范.doc

软件测试操作指南

1 概述
1.1 目的
为确保软件产品质量，使产品能够顺利交付和通过验收，同时提升测试组的工作秩序和效率，特编写本文档，以作参考。
1.2 对象范围
本文档适用于测试人员在项目不同阶段（内网环境测试及正式环境测试）的功能测试。
2 职责
Ø 配合产品经理、项目经理了解需求
Ø 编写《测试计划》、《测试方案》、搭建测试环境
Ø 完成所承担的测试任务，并按要求提交Bug、优化建议等到Bug管理平台（禅道）。
Ø 配合开发人员修复Bug、回归Bug。
Ø 配合项目的顺利发布。

3 测试流程
3.1 前期准备
3.1.1 需求
详细的需求是测试的重点依据， 因此测试人员需提前介入，充分了解需求。
3.1.2 原型和设计
原型，是需求和功能的具象化表达，它能帮助测试人员更形象的了解各个需求和功能的实现。
UI设计图，是在原型的基础上综合考虑产品目标、功能需求场景、用户体验等因素后设计出的产品各版块、界面和元素。是测试最终的参考依据。因此测试人员必须对认真阅读，真正弄懂系统需求和详细设计。

3.2 制订《测试计划和方案》
在测试之前，测试人员需根据项目需求制定《测试计划和方案》，其内容应包括以下内容：
Ø 测试时间安排；
Ø 测试人员安排；
Ø 测试环境、工具和测试软件等；
Ø 测试用例、测试数据和预期的结果。
3.3 编写测试用例
3.3.1测试点
将测试模块分解成多个功能点，测试点应涵盖功能点，也涵盖了正常测试和异常测试。
3.3.2输入数据
输入数据包括：
① 界面输入数据
② 数据库的初始数据
③ 其他外部输入数据等
输入数据尽可能全面详细列出，并具有典型性。全面是指：数据能达到模块所涉及的全部功能，典型是指这个数据能充分反映功能特点。
3.3.3测试描述
测试描述，即测试过程中的具体操作步骤，包括：
（1） 前置条件：测试执行时所必须的条件，即发生这个用例的前提条件；
（2） 所执行的动作：包括鼠标、键盘、加载外部数据等操作；
（3） 系统的反应：包括光标定位、光标聚焦、显示字段值、按钮的状态、系统提示和消息等。
3.3.4预期输出数据
按准备的输入数据和设计的测试过程，模块应输出的数据。
输出数据包括：屏幕输出数据、输出到数据库的数据、输出到其他外部地方的数据，并指出断点结果或最终结果。

3.4 功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
3.4.1 Web功能测试
在Web功能测试过程中，常用的测试方法如下
3.4.1.1 链接测试
测试每一个链接是否都有对应的页面，并且页面之间切换正确。
3.4.1.2 表单测试
当用户在web应用系统上向服务器提交信息时，就需要使用表单操作，在表单测试过程中，一般关注N点
（1） 格式规范：空格检查、输入法半角全角检查、密码检查、字符串长度检查、字符类型检查、标点符号检查、特殊字符检查、中文字符处理等；
（2） 提交信息完整性：比如，用户注册，登录，信息变更等等；这种情况下，我
们必须测试提交信息的完整性，以检验提交给服务器的数据的正确性 ；
（3） 考虑常理逻辑，如：出生日期、工作年限是否恰当，填写手机号码的表单是否符合号码逻辑，所在地省份城市区域间的匹配等，如果设定使用默认值，也需要测试。
3.4.1.3 导航测试
所谓的导航测试，就是在不同的页面跳转之间或者按钮，对话框，列表以及窗口等，通过考虑这些因素，去判断一个应用系统是否易于导航：是否直观？系统的主要模块是否可以通过主页访问或者到达？站点是否需要站内地图或者搜索引擎等其他帮助？
web系统导航的另外一个重点就是页面结构、导航、菜单、风格等是否一致，确保用户可以凭借直觉或者简单的判断就可以找到自己想要的内容。
3.4.1.4 图形测试
即UI界面测试，其中包括图片、动画、边框、颜色、字体、背景、按钮等等。其中要考虑的几个重点：
（1） 界面是否符合系统现有逻辑，是否符合需求，
（2）图片有明确的用途、代表，如：常见的分享按钮，是否使用准确，让用户看图即能知其意
（3）页面整体风格是否和系统的用途一致
（4）背景颜色，字体，搭配是否合理
（5）整体界面测试，常说的用户体验。用户浏览时是否感觉舒适，整体风格等等
3.4.1.5 相关性测试
（1）功能相关性：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形；
（2）数据相关性：下拉列表默认值检查，下拉列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见；
（3）内容相关性：主要用来检测web系统提供信息的准确性、相关性。比如：商品的价格，文字描述；信息的准确性，是否有拼写错误等。
3.4.1.6 兼容性测试
Web兼容性测试，主要指浏览器兼容性。需适配的浏览器及其优先顺序为：IE 8.0+ 、360浏览器、chrome浏览器、Firefox浏览器、搜狗浏览器、QQ浏览器
3.4.2 App功能测试
App测试包括android测试、iOS 测试，APP测试的时候，建议让开发打好包APK和IPA安装包，测试人员自己安装应用，进行测试。在测试过程中需要注意的测试点如下：
3.4.2.1安装和卸载
（1） 应用是否可以在IOS不同系统版本或android不同系统版本上安装（iOS
系统需适配iOS 8.0+ 、android需适配4.4 +）
（2）软件安装后是否可以正常运行，安装过程中是否可以取消，安装空间不足时是否有相应提示；
（3）是否可以正常卸载，若卸载过程中出现死机，断电，重启等意外的情况，待环境恢复后是否可以正确卸载，卸载是否支持取消功能，单击取消后软件卸载情况是否正常。
3.4.2.2运行
（1）测试APP安装完成后，是否可以正常打开软件APP运行时，是否有加载图示（2）APP的速度是可以让人接受，切换是否流畅 （3）用户登录状态太久，session会过期，会出现“虽然是登录状态，系统会提示用户没有登录。
3.4.2.3异常测试
异常指非正常性用户操作，如：手机断网、中途电话接入、手机断电等异常情况。
（1）对于无网络时，是否可以浏览本地数据，不能获取数据时，能否给出友好提示，离线获取不到数据时，离线后又连上网，能否重新获取数据。
（2）退出APP再开启APP时，是否能正常浏览；切换到后台再切回APP应用时可以正常浏览；锁屏后再解锁回到应用前台可以正常浏览；
（3）正在操作App时，突然电话接入或突然离线，是否对操作有影响等。
（4）反复操作某个功能，不断点击，刷新时，是否会闪退

3.4.2.4数据更新
（1）确认有数据更新后，哪些地方需要手动刷新，哪些地方需自动刷新。
（2）确认从后台切换回前台时，哪些页面需要进行数据更新
（3）根据需求和逻辑，确认哪些数据是从服务端请求实时响应，哪些是缓存到本地的数据。
3.4.2.5软件更新
当客户端有新版本时，有更新提示软件更新一定要测，确保android软件更新可以正确更新新版本，且安装运行正确。（iOS软件更新必须从苹果应用商店App Store中更新 ) 用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提提示。当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）
3.4.2.6网络环境
（1）测试２G、３Ｇ，４Ｇ，wifi 网络下应用运应的速度
（2）内网测试时，选择到外网操作是否有异常处理
（3）网络不好时 ， 提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒
（4）有网到无网再到有网环境时，数据是否可以自动恢复，正常加载
3.4.1.7 其他
链接测试、导航测试、图片测试、内容测试、UI测试等各项功能测试，和Web功能测试类似，此处不做详细描述。

3.5 回归测试
回归测试是指开发人员修复bug后，重新进行测试以确认修改完成，以及没有引入新的错误或导致其他模块错误。回归测试过程如下：
(1) 准确辨别出系统被修改的部分；
(2) 从测试用例库中，排除所有不再适用的测试用例，如果必要，适当增加新用例，形成新的测试用例库。
(3) 依据新的测试用例，执行修改后的系统。

3.6 版本发布
3.6.1版本发布的准则
系统经过所有测试项后，必须符合以下标准
n 致命错误：无
n 功能错误：无
n 功能及界面小Bug：项目经理、测试负责人审核通过
n 优化及建议：项目经理、测试负责人审核通过
若不满足以上要求，视为不合格。
3.6.2版本发布流程

3.7 测试流程图

4 Bug(Bug)管理
4.1 Bug管理工具
测试组目前使用的Bug管理工具是“禅道”。禅道是集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体的一款开源的研发项目管理。
测试组使用禅道提Bug、管理Bug、回归Bug以及记录和执行测试用例。下图为禅道测试界面。
禅道使用网址：
禅道的详细使用手册见：
4.2 Bug的定义及其基本属性
Bug是指在系统开发过程中的针对系统产品和开发过程中的问题，这些问题已经影响或可能会影响软件产品的质量。Bug应该具备以下属性，也就是往Bug管理库或者Bug列表中提交的Bug应该具备以下属性：
属性名称
描述
Bug标识(ID)
标记某个Bug的一组符号，每个Bug必须有一个唯一的标识
Bug类型
根据Bug的自然属性划分的Bug种类
Bug验证程度
因Bug引起的故障对软件产品的影响程度
Bug所处的模块
或子系统
Bug分步的模块或子系统
Bug出现几率
指发现错误的几率
Bug的重现步骤
详细的Bug重现步骤
附件
和Bug相关的附件（截图、附件、用例等）
备注
对Bug的其他描述

4.3 Bug分类
根据Bug的定义，将Bug分为如下列：
（1）功能错误（bug）：功能上的错误性bug
（2）小错误/细节：小错误，不影响总体流程和功能
（3）优化建议：功能已满足但待改善，属于改良性建议

（4）需求变动：原有的需求基础上的更改
（5）设计Bug：UI设计Bug
4.4 Bug严重性定义
Bug的严重程度反映的是对Bug的发现对象可能造成的影响或后果来定义的。
Bug等级
Bug性质
描 述
1
致命错误
系统崩溃、系统死锁以及产品的基本功能有致命影响的Bug等
2
严重Bug
严重错误，严重影响系统的使用
3
一般Bug
次要错误、布局不合理、文字错误等
4
微小Bug
基本不影响系统的运行和功能的实现。但是和标准、规范和定义不一致
建议优化
不在定义、标准、范围的定义和约束之内，但是从提出者来看是需要完善的建议
4.5 Bug优先级定义

Bug优先级
描 述
1
需要立刻进行修改
2
一天到两天之内必须修改
3
Bug需要正常排队等待修复或列入软件发布清单
4
留到组后解决，如果项目的进度跟紧张可以在产品发布以前不解决

4.6 Bug状态定义

Bug状态
描 述
激活
测试人员提交一个新的Bug，等待开发人员修改
打回
开发人员并未重新问题，或要求Bug的报告者再次对Bug进行说明
已分派
指Bug已经分派给相关开发人员，等待修改
已确认
指Bug已被相关开发人员却，等待排期修改
已解决
指Bug已被修改，等待测试人员回归验证。
关 闭
测试人员回归验证Bug，并已经修复
重新激活
测试人员回归验证，但Bug并没有修改正确

4.7 Bug管理流程

5 处理机制
5.1 退回机制
若在测试过程中发生如下情况，可将系统退回到相关开发负责人员：
（1）经过测试后，发现和需求不符，或功能项存在较大的差异
（2）单一功能模块，测试过程中发现Bug较多或者无法继续进行下一步测试，继续测试无意义
（3）测试过程中，频繁死机或系统崩溃
5.2 异常情况处理机制
非正常情况下，需要进行特别处理的情形，此情况需要主管领导批准、签字确认：
（1）上线时间紧急的情况下，未经测试部充分测试就发布到外网环境
（2）产品经理尚未进行验收测试就需要上线
5.3 报告机制
若出现以下情况，需要及时向部门领导和项目经理汇报的情况：
（1）测试后期出现重大逻辑错误，修改测试影响上线时间
（2） 测试过程中用户需求出现重大变更
（3） 测试负责人定期汇报测试情况
6 测试完成的标准
6.1 被测试出的、在软件错误级别分类中定义的：
Ø 一级Bug，致命错误，100%得到修改并且回归通过
Ø 二级Bug，严重错误，100%得到修改并且回归通过
Ø 三级Bug，一般错误，90%得到修改并且回归通过
Ø 四级Bug，轻微错误，85%得到修改并且回归通过
6.2 用户可以接受未修改的软件错误
6.3 测试超过了预定时间表，由项目经理决定是否停止测试
6.4 测试结论及评价标准
测试结论
评价标准
不能发布
遗留了一级、二级Bug
测试通过版本
不能遗留以一、二类Bug
三类 一般Bug90%得到修改并且通过回归
四类 轻微Bug85%得到修改并且通过回归
推荐发布版本
不能遗留以一、二类Bug
三类 一般Bug92%得到修改并且通过回归
四类 轻微Bug88%得到修改并且通过回归

17 / 17