软件测试操作指南和规范.docx
《软件测试操作指南和规范.docx》由会员分享，可在线阅读，更多相关《软件测试操作指南和规范.docx（13页珍藏版）》请在冰豆网上搜索。
软件测试操作指南和规范
软件测试操作指南
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输入数据
输入数据包括：
1界面输入数据
2数据库的初始数据
3其他外部输入数据等
输入数据尽可能全面详细列出，并具有典型性。
全面是指：
数据能达到模块所涉及的全部功能，典型是指这个数据能充分反映功能特点。
3.3.3测试描述
测试描述，即测试过程中的具体操作步骤，包括：
（1）前置条件：
测试执行时所必须的条件，即发生这个用例的前提条件；
（2）所执行的动作：
包括鼠标、键盘、加载外部数据等操作；
（3）系统的反应：
包括光标定位、光标聚焦、显示字段值、按钮的状态、系统提示和消息等。
3.3.4预期输出数据
按准备的输入数据和设计的测试过程，模块应输出的数据。
输出数据包括：
屏幕输出数据、输出到数据库的数据、输出到其他外部地方的数据，并指出断点结果或最终结果。
3.4功能测试
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
3.4.1Web功能测试
在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兼容性测试，主要指浏览器兼容性。
需适配的浏览器及其优先顺序为：
IE8.0+、360浏览器、chrome浏览器、Firefox浏览器、搜狗浏览器、QQ浏览器
3.4.2App功能测试
App测试包括android测试、iOS测试，APP测试的时候，建议让开发打好包APK和IPA安装包，测试人员自己安装应用，进行测试。
在测试过程中需要注意的测试点如下：
3.4.2.1安装和卸载
（1）应用是否可以在IOS不同系统版本或android不同系统版本上安装（iOS
系统需适配iOS8.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软件更新必须从苹果应用商店AppStore中更新）用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提提示。
当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）
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版本发布的准则
系统经过所有测试项后，必须符合以下标准
⏹致命错误：
无
⏹功能错误：
无
⏹功能及界面小Bug：
项目经理、测试负责人审核通过
⏹优化及建议：
项目经理、测试负责人审核通过
若不满足以上要求，视为不合格。
3.6.2版本发布流程
3.7测试流程图
4Bug（Bug）管理
4.1Bug管理工具
测试组目前使用的Bug管理工具是“禅道”。
禅道是集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体的一款开源的研发项目管理。
测试组使用禅道提Bug、管理Bug、回归Bug以及记录和执行测试用例。
下图为禅道测试界面。
禅道使用网址：
禅道的详细使用手册见：
4.2Bug的定义及其基本属性
Bug是指在系统开发过程中的针对系统产品和开发过程中的问题，这些问题已经影响或可能会影响软件产品的质量。
Bug应该具备以下属性，也就是往Bug管理库或者Bug列表中提交的Bug应该具备以下属性：
属性名称
描述
Bug标识（ID）
标记某个Bug的一组符号，每个Bug必须有一个唯一的标识
Bug类型
根据Bug的自然属性划分的Bug种类
Bug验证程度
因Bug引起的故障对软件产品的影响程度
Bug所处的模块
或子系统
Bug分步的模块或子系统
Bug出现几率
指发现错误的几率
Bug的重现步骤
详细的Bug重现步骤
附件
与Bug相关的附件（截图、附件、用例等）
备注
对Bug的其他描述
4.3Bug分类
根据Bug的定义，将Bug分为如下列：
（1）功能错误（bug）：
功能上的错误性bug
（2）小错误/细节：
小错误，不影响总体流程和功能
（3）优化建议：
功能已满足但待改善，属于改良性建议
（4）需求变动：
原有的需求基础上的更改
（5）设计Bug：
UI设计Bug
4.4Bug严重性定义
Bug的严重程度反映的是对Bug的发现对象可能造成的影响或后果来定义的。
Bug等级
Bug性质
描述
1
致命错误
系统崩溃、系统死锁以及产品的基本功能有致命影响的Bug等
2
严重Bug
严重错误，严重影响系统的使用
3
一般Bug
次要错误、布局不合理、文字错误等
4
微小Bug
基本不影响系统的运行和功能的实现。
但是与标准、规范和定义不一致
建议优化
不在定义、标准、范围的定义和约束之内，但是从提出者来看是需要完善的建议
4.5Bug优先级定义
Bug优先级
描述
1
需要立刻进行修改
2
一天到两天之内必须修改
3
Bug需要正常排队等待修复或列入软件发布清单
4
留到组后解决，如果项目的进度跟紧张可以在产品发布以前不解决
4.6Bug状态定义
Bug状态
描述
激活
测试人员提交一个新的Bug，等待开发人员修改
打回
开发人员并未重新问题，或要求Bug的报告者再次对Bug进行说明
已分派
指Bug已经分派给相关开发人员，等待修改
已确认
指Bug已被相关开发人员却，等待排期修改
已解决
指Bug已被修改，等待测试人员回归验证。
关闭
测试人员回归验证Bug，并已经修复
重新激活
测试人员回归验证，但Bug并没有修改正确
4.7Bug管理流程
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%得到修改并且通过回归
升级会员 