XXX系统测试策略与计划
文件标识: 当前版本: 作 者: 完成日期:
xxx系统测试策略与计划 V1.0 xxx 2015-10-27 历史版本 版本编号 V1.0
修订日期 2015.10.27 修订内容 新建 修订人 xxx 备注 初次拟定 目录
1 前言 ........................................................................................................................................ 4 1.1 编写目的 ........................................................................................................................ 4 1.2 项目概况 ........................................................................................................................ 4 1.3 参考资料 ........................................................................................................................ 5 2 资源需求 ................................................................................................................................ 5 2.1 硬件资源 ........................................................................................................................ 5 2.2 软件资源 ........................................................................................................................ 6 2.3 人力资源 ........................................................................................................................ 6 3 测试策略 ................................................................................................................................ 7 3.1 整体策略 ........................................................................................................................ 7 3.2 测试类型 ........................................................................................................................ 8 3.2.1 功能测试 ................................................................................................................ 8 3.2.2 性能测试 ................................................................................................................ 8 3.2.3 UI测试 .................................................................................................................... 9 3.2.4 安全性测试 .......................................................................................................... 10 3.2.5 兼容性测试 .......................................................................................................... 10 3.2.6 压力测试 .............................................................................................................. 11 3.2.7 回归测试 .............................................................................................................. 11 3.3 测试用例 ...................................................................................................................... 12 3.3.1 编写规范 .............................................................................................................. 12 3.3.2 用例设计方法 ...................................................................................................... 12 3.3.3 用例命名规范 ...................................................................................................... 13 3.3.4 用例编号规范 ...................................................................................................... 13 3.3.5 测试用例模板 ...................................................................................................... 14 3.4 BUG管理 ........................................................................................................................ 14 3.4.1 BUG提交 ................................................................................................................ 14 3.4.2 BUG提交规范 ........................................................................................................ 14 3.4.3 BUG严重级别划分 ................................................................................................ 14 3.5 风险分析 ...................................................................................................................... 14 3.6 质量控制 ...................................................................................................................... 16
3.7 任务分配 ...................................................................................................................... 16 4 测试计划 .............................................................................................................................. 17 4.1 里程碑 .......................................................................................................................... 17 4.2 回归测试标准 .............................................................................................................. 17 4.3 通过标准 ...................................................................................................................... 18 5 交付件 .................................................................................................................................. 18 6 挂起恢复条件 ...................................................................................................................... 19 6.1 挂起条件 ...................................................................................................................... 19 6.2 恢复条件 ...................................................................................................................... 19
1 前言
1.1 编写目的
XXXXXXXXXXXXXXXXXXXXXXXX
本文档的读者范围包括:XXX系统项目内的部门领导、项目经理,测试工程师、软件工程师等。
1.2 项目概况
XXX系统是一个XXXXXXXXXXXX。
1.3 参考资料
资料名称 作者 说明 硬件需求及配置 接口规范和业务流程 整体业务流程中的数据进行规范定义和约束 XXX XXX XXX XXX XXX 客户提供 XXX
客户提供 业务流程,操作步骤 2 资源需求
2.1 硬件资源
机型/设备名 测试样机 PC机/网线 交换机 不同方案的无线路由器 TF卡 安卓手机 苹果手机 HUB xxx xxx 数量 2台 若干 1台 若干 2个 若干 若干 1个 1个 1台 使用时间 20天 20天 20天 20天 20天 20天 20天 20天 20天 20天 资源来源 公司自有板子 申请/自备 已有 申请 已有 已有 申请 已有 申请 申请 xxx xxx 移动/联通/电信3G SIM卡
1台 1个 4张 20天 20天 20天 申请 申请 已有 2.2 软件资源
软件名称 IXChariot InSSIDer SecureCRT Wireshark RouterOS Iperf LoadRunner 测试有线/无线性能 无线信号扫描 串口工具 网络抓包分析工具 用于部署各种服务器,包括DHCP、PPPOE、VPN服务器 模拟发包以及测试网络带宽 Web服务器性能测试或用于大数据生成 用途说明 2.3 人力资源
角色 测试工程师 姓名 职责 负责测试任务安排与进度把控,协调测试资源与人力,输出测试日报和测试报告。并参与软件测试
XXX 3 测试策略
3.1 整体策略
本项目采用瀑布开发模式,第一个转测试版本包括了所有需求和要实现的功能,后续版本仅进行回归测试,不做新功能测试。
第一个版本为XXX,实现需求规格上面的功能包括:XXXXXXXXXXXXXXX。第一版发布时进行全面测试,测试重点关注功能是否满足需求规格上的要求。全面测试的内容包括功能测试、性能测试、压力测试、兼容性测试。所有测试内容按照已经编写的全面测试用例执行,阻塞的用例需备注说明阻塞原因。
第二个版本为XXX,本次为回归测试,测试重点为回归第一版软件中发现BUG,另外还要挑选基本业务流程中的高优先级用例进行测试。
第三个版本为XXX,本次为回归测试,测试重点为回归第二版软件中发现BUG,另外还要挑选基本业务流程中的高优先级用例进行测试。
所以本项目的测试策略为1轮全面+2轮回归,测完后需根据软件实际质量表现确定是否继续进行后续的其他测试。
3.2 测试类型
3.2.1 功能测试
测试范围 测试目标 XXX 核实所有功能均已正常实现,即各个接口功能都正常工作,数据存储和上报都准确无误,完整的业务逻辑全部完成。 技术 采用黑盒测试,使用边界值测试、等价类划分、数据驱动、流程分析、错误猜猜等测试方法 工具与方法 开始标准 完成标准 手工测试 测试用例设计完毕并通过评审且项目组移交系统测试 1、需求规格书上所有功能都已实现 2、测试用例全部执行完毕 测试重点与优先级 需考虑的特殊事项 如果有阻塞的功能模块需在后面测试中补测 3.2.2 性能测试
测试范围 测试目标 技术 工具与方法 系统响应速度 1、达到客户要求的系统响应速度 手工测试&自动化测试 手工测试,LoadRunner 11 开始标准 完成标准 测试重点与优先级 需考虑的特殊事项 1、完成自动化环境安装调试且项目组移交系统测试 XXX 稳定性测试 需研发配合编写接口 3.2.3 UI测试
测试范围 1.手机打开智能终端页面时的页面UI 2.友好性、可操作性(易用性) 测试目标 UI简洁直观,能够保证用户界面的友好性、易操作性,而且符合用户操作习惯。 技术 工具与方法 开始标准 完成标准 WEB测试通用方法 手工测试 项目组移交系统测试 1、UI布局统一,能够保证用户界面的友好性、易操作性,而且符合用户操作习惯 2、页面提示信息,错误码信息,弹出窗体,下拉菜单等要保持内容风格一致 3、无文字拼写错误,无歧义文字出现,无错误标点符号,无字体大小、颜色等不一致出现。文字图片组合正常,页面美观 测试重点与优先级 需考虑的特殊事项 状态信息显示要求及时准确 3.2.4 安全性测试
测试范围 测试目标 技术 工具与方法 开始标准 完成标准 测试重点与优先级 需考虑的特殊事项 XXX XXX 手工测试 黑盒测试 项目组移交系统测试 通过抓包确认数据已经加密 3.2.5 兼容性测试
测试范围 测试目标 技术 工具与方法 开始标准 完成标准 测试重点与优先级 需考虑的特殊事项 XXX XXX 黑盒测试 手工测试 项目组移交系统测试 XXX 如果出现不常用浏览器出现兼容性问题可以不做修改 3.2.6 压力测试
测试范围 测试目标 技术 工具与方法 开始标准 完成标准 测试重点与优先级 需考虑的特殊事项 XXX XXX 黑盒测试 手工测试+自动化测试 1、项目组移交系统测试 XXX 3.2.7 回归测试
测试范围 测试目标 BUG回归,新增功能验证 核实在新的测试版本中是否已经修改了所提交的BUG,是否会引入新的问题;抽取部分优先级高的已测用例进行测试 技术 工具与方法 开始标准 完成标准 测试重点与优先级 需考虑的特殊事项
黑盒测试 手工测试 上一轮提交的BUG都已经修改完毕 回归BUG全部通过 3.3 测试用例
3.3.1 编写规范
1、一个测试用例只测试一个点,避免一个用例中测试内容过多。
2、测试用例标题要能简明概要的说明用例的测试要点,有利于读者对用例的理解。标题不能用重复。如果测试的内容相似,标题无法区分,则可以在标题后面加数字进行区分。
3、测试用例的数据要明确。对于测试中的输入项,要有明确的输入内容来做测试,提高可操作性。不能只用文字描述,导致测试内容模糊不清。
4、测试用例需要保障唯一性,即功能用例之间不存在重叠,流程用例不存在包含关系。没有重复、冗余的测试用例,满足相应的行业标准。
5、描述要清晰明确,简明扼要,没有含糊的概念和易产生歧义的文字。应尽量避免不确定的用词,如:如果、若、否则、大概、可能等。
6、测试用例中需要有充分的异常测试数据,考虑大数据量测试时的数据准备。例如对于数据量的边界值,需要使用工具产生边界数据量来验证。 7、正常的输入测试和异常的输入测试需分开进行
8、测试用例必须包含所有的功能需求点,对于功能模块之间有耦合的,对其他
模块的影响也要体现在预期结果中
3.3.2 用例设计方法
常用的用例设计方法包括等价类、边界值、流程分析法、因果图、错误猜测法等。 ❖ 等价类:等价类是指某个输入域的子集合。在该子集合中,各个输入数据对
于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果。
❖ 边界值:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试
方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
❖ 错误猜测法:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有
针对性的设计测试用例的方法。列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
❖ 流程分析法:基于某一功能点的所有可能的流程进行分析,并对每一个分支
流程都设计测试用例。
❖ 应果图法:因果图法是一种利用图解法分析输入的各种组合情况,从而设计
测试用例的方法,它适合于检查程序输入条件的各种组合情况。等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。
3.3.3 用例命名规范
以实际测试功能模块和测试内容要点进行命名
3.3.4 用例编号规范
用例编号格式为:项目名_测试类型_功能模块_编号
测试类型分为:功能测试(F)、性能测试(P)、安全性测试(S)、压力测试(O)、兼容性测试(C) 编号从001开始
功能模块取被测功能模块的英文标识,例如User(用户管理)、Device(设备管理)、Portal(PORTAL管理)、Statistics(数据分析)、System(系统维护)等。 用例编号实例一:XXX_F_User_001 用例编号实例二:XXX_C_Browser_001
3.3.5 测试用例模板
功能 功能子项 用例标题 用例ID 重要级别 前置条件 操作步骤 预期结果 备注 3.4 BUG管理
3.4.1 BUG提交
项目测试中发现的BUG需与相应的开发进行沟通,确认之后立即提交到BUG系统上。如果对BUG有争议,则提交评审后进行裁决。
3.4.2 BUG提交规范
1、标题需能概括本BUG的大意
2、BUG描述力求清晰准确,解释到位。必须完整描述BUG的复现步骤,如果有前提条件,需明确说明。需写明预期结果和实际结果,能够让其他测试人员和开发人员理解这个BUG是什么意思 3、尽量能附带日志或BUG截图 4、相同的BUG不能重复提交
5、再微小的BUG也要提交,提交BUG宜早不宜晚,不要等到后面的版本再提交。
3.4.3 BUG严重级别划分
参考公司文档《XXX公司BUG严重级别划分及项目通过标准》
3.5 风险分析
风险发生可能性说明:高:>60%,中:30%—60%,低:<30%。
风险类型 风险要素/描述 风险发风险发生带来的生的可能性 影响 减少风险的活动 责任人 资源1.测试人力投入不足 风险 2.样机资源不足 3.测试设备申请后不能及时到位 高 延迟项目测试进1.部门内部协调,测试人员需XXX 度 加班应对 2.尽量提供充足的样机保证测试活动顺利进行 3.转测试前需要所有测试设备到位,如未能到位,需向领导申请,加快设备采购。 软件质量风险 软件致命或严重BUG阻塞测试进行 高 测试时间延期、部分模块无法测试 1.软件开发人员需进行周详的自测试,并出具自测试报告 2.开发人员需及时响应并优先解决阻塞测试的BUG XXX 1、项目开发进度延期,不能准时本身交付测试 研发自测试时风险 2、发现严重问题无法转测试 项目中 测试延期 需保持和开发的紧密沟通,XXX 密切关注项目进度,如果不能及时转测试,需要调整测试时间或人力 1、开发、测试对新技术或测试手风险 段不熟悉 技术低 解决问题花费时间过多,影响测试进度 1.前期已经针对新技术,新内容做了研究并形成了具体用例 2.充分准备测试资源与验证测试环境,对测试工具已经进行了熟练的使用 3.测试中测试人员与开发人员需形成良好沟通 XXX 3.6 质量控制
1、检查软件转测试交付件,必须包括releasenote,自测试报告。releasenote中需明确当前版本开发情况,遗留问题和测试建议。自测试报告中测试用例通过率需达到100%。以上条件任一不满足,做版本退回处理。
2、正常构建版本测试过程中发现bug的严重影响后续测试,或者发现的致命性bug,版本退回。输出测试报告。
3.7 任务分配
NO. 1 2 3 4 5 6 7 8 8 10 11 12 13 14
测试项目 测试计划更新 测试用例设计 测试用例评审 测试用例更新 硬件质量测试 性能测试 功能测试 压力测试 安全性测试 兼容性测试 路由器基本功能 回归测试 测试报告提交 送样测试 是否执行 是 是 是 是 否 是 是 是 是 是 否 是 是 否 责任人 XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX 非软件测试项目 不做测试 暂不进行 说明或不执行的原因 4 测试计划
4.1 里程碑
里程碑任务项 测试计划评审 测试计划修改 测试用例编写 测试用例评审 测试用例修正 起始时间 2015.10.28 2015.10.28 2015.10.29 2015.11.4 2015.11.5 结束时间 2015.10.28 2015.10.28 2015.11.3 2015.11.4 2015.11.5 所有用例都编写完成 根据评审意见修改测试用例 第一轮测试 第二轮测试 第三轮测试
2015.11.11 2015.11.22 2015.11.27 2015.11.18 2015.11.24 2015.11.28 第一次全面测试 第一次回归测试 第二次回归测试 任务明细 4.2 回归测试标准
1、回归测试中,研发需附带自测试报告,自测试用例需通过率达到100%,才能转测试。
2、研发需要将上一轮提交的BUG尽量解决掉才转测试,转测试时需要对遗留BUG进行统计,并计算分值,如果遗留BUG累积分值达到54分,则不接收转测试。BUG的分值计算标准如下:
严重级别 分值 致命 10 5 严重 2 一般 1 提示 4.3 通过标准
编写 1 测试质量目标 测试已实现的产品是否达到设计的要求,包括:各个功能点是否已实现,业务流程是否正确 2 3 4 5 6 7
所有的测试用例已经执行过 所有的自动测试脚本已经执行通过 不允许存严重程度为致命的BUG 不允许存在严重程度为严重的BUG超过3个 不允许存在严重程度为一般的BUG超过5个 缺陷的发现速率正在下降并接近0 确认人以及特殊说明 5 交付件
文档说明 系统测试计划 测试用例 每日测试汇报 系统测试报告
XXX XXX XXX XXX 作者 略 略 通过每日邮件发送 略 文档位置(配置库) 6 挂起恢复条件
6.1 挂起条件
当测试发生4.2中“版本退回”的条件时,应挂起测试,等待条件满足时再重新开始测试;
当由于硬件故障导致测试中断时,需等硬件方面维修调试完毕后再恢复测试;
除此之外,其它由于开发方面、市场方面、或管理决策等导致的项目暂停、停止等,应适时地挂起测试活动,只有决策项目继续开展时,才再次启动测试活动。
6.2 恢复条件
参考6.1中恢复测试说明
因篇幅问题不能全部显示,请点此查看更多更全内容