测试工作指导书
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
测试工作指导书XX项目测试组
修改历史
测试工作指导书
目录
一、概要 (5)
1.1 目的 (5)
1.2 内容 (5)
1.3 适用范围 (5)
三、文档测试 (5)
3.1产品说明书属性检查清单 (5)
3.2产品说明书用语检查清单 (5)
四.共通项测试 (6)
4.1页面测试共通项 (6)
五、测试点分析 (8)
5.1功能测试点 (8)
5.2共通测试点 (8)
5.3数据库测试点 (9)
六、测试工作流程 (10)
6.1测试计划 (10)
6.2文档的理解 (10)
6.3测试用例设计 (11)
6.4测试准备 (11)
6.5测试执行 (11)
七、Bug管理 (12)
八、测试实施 (12)
8.1软件项目测试周期 (12)
8.1.1软件项目测试启动 (12)
8.1.2软件项目测试阶段 (12)
8.1.3项目测试的结束 (13)
九、回归测试 (14)
9.1回归测试的步骤 (14)
9.2回归测试的原则 (14)
十、测试部绩效考核 (15)
十一、工作汇报 (15)
一、概要
1.1目的
发布此文档是为了规范测试工作的流程,指导测试人员处理工作中面临的各种情况,确保测试部在整个开发测试工作中扮演正确积极的角色,以保证测试部的正常运作。
1.2内容
对软件测试的工作流程、资源及各项工作要求进行说明,作为测试纲领性文件指导测试工作,确保软件产品满足质量要求。
1.3适用范围
本文档适用于XX项目的开发和测试工作。
三、文档测试
产品说明书包括软件需求功能说明书,软件业务对象说明书。
3.1产品说明书属性检查清单
1.完整性.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
2.准确性.既定解决方案正确吗?目标明确吗?有没有错误?
3.精确性,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
4.一致性.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
5.贴切性.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
6.可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?
3.2产品说明书用语检查清单
对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属
性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
1.总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
2.当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
3.某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
4.等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
5.良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
6.已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
7.如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.
四.共通项测试
4.1页面测试共通项
2、日期项
4、按钮
五、测试点分析
5.1功能测试点
1)系统的用户、数据都按区域等级划分,即全国、地区、地方、交易场,属于不同的区域所对应的权限及数据都不一样,所以要重点检查权限和可操作数据范围的正确性。比如北京市的地方信息员登陆系统后只能操作和看到属于北京平台的数据,其它地方的数据不能看到和操作。
2)数据部分内部数据的关联引用很多,要注意检查相互的影响和限制。比如产品信息中要引用物价信息、认证、资质等信息。
3)在交易部分要测试金额比较大的情况。
4)在采购单部分要测试一个采购单包含上百条记录的情况。
5)测试对于输入的数量为负数、字母、零的情况,系统应该限制不能输入。
6)系统中很多的操作都对应了记录的一种状态,即必须是什么状态可以做什么操作,操作后状态变为另一个状态,所以测试中要注意检查状态的变化是否正确。例如订单有发送、已阅读、已确认、到货中、缺货、作废、完成等状态。
7)用不同的用户同时登陆系统进行操作,检查是否会出现session串的现象。
5.2共通测试点
1)所有的查询均应为模糊查询。
2)在交易部分的药品查询中应该都支持输入拼音、五笔的查询。且输入字母的大小写系统应能自动转换。
3)企业名称显示均为简称。
4)注意检查一个商品记录在各页面的规格包装、大中包装显示是否统一,是几个字段按一定规则组合出来的。
5)点击新增一个项目时,新增是否成功,页面刷新是否正确,初始状态显示的是否正确,点击IE的向前向后退时,数据是否保留。
6)最大长度的限制是否存在,是:输入最大长度,看新增是否成功。
否:输入无限长度,看新增是否成功,是否造成溢出现象。
7)特殊字符的测试:比如(or,and,%,*,like,’)因为是数据库中特殊的符号,所以在测试过程中要注意程序是否对此进行了转换,空格的测
试,前后空格应自动删除,是否会有error抛出。
8)点击修改按钮时,看原数据是否保留,修改数据点击变更,看页面刷新是否正确,修改的数据是否修改成功。
9)点击删除按钮,是否可以进行删除,是否弹出警告,点击确认后,能否删除项目,点击返回后能否删除项目。
10)如果此项目与别的项目有关系,是否可以删除,比如产品信息中要引用物价信息、认证、资质等信息
11)页面项目是否有排序,比如按照药品code的升序或降序排序。
12)弹出的表单的大小,位置风格是否一致。
13)新作成的页面,要查看背景颜色是否变化。
5.3数据库测试点
1)检查每次操作后记录在数据库相应字段中的信息是否正确,比如企业全称要记在企业表的机构全称字段中,而不是简称字段。因为数据是向下引用的,所以上游的数据记录的是否正确直接影响下面的操作。
2)对于已存在的记录进行修改时一定要同时修改记录中的修改时间字段,主要是交易部分用于客户端的同步。
3)在数据库中有很多标志FLAG,它是判断数据可用性或范围的重要标示,所以重点检查标志记录和判断的正确性。
性能测试点
1)合同操作数据量比较大,重点做性能的测试和优化。
2)产品表数据量较大,容易出现操作慢的情况。