银行软件研发中心培训资料:测试案例新模板改进材料

对案例新模板改进总结.doc
案例新模板改进整体构思.doc
测试准备、需求理解.xls
测试计划、执行监测表.xls
测试设计案例库.xls
测试设计案例库(模板).xls
测试设计案例库(示例).xls

案例新模板改进整体构思.doc

1,分成3个excel:
(1)测试理解流程图
(2)测试计划/过程监测表
(3)测试案例

2,测试理解流程图的构成
包括封面、目录、变更过程、主要对象图、对象迁移图、流程图、功能分解图

3,测试计划监测表
包括封面、目录、概要、变更过程、项目信息、工作分工、导入功能模块清单、测试记录明细表、项目进度总体情况、过程监控图、项目测试情况日报、项目进度历史明细表、培训计划、风险管理。

4,测试案例
包括封面、目录、概要、变更过程、通用测试案例、公共管理模板测试案例、A流程测试案例、B流程测试案例、C流程测试案例、……。

关于对案例新模板改进建议的答复.doc

1.在批量案例的编写中,案例模板的形式不太方便案例展开描述。像一个批量流程,案例编写时,批量操作的中间过程很难被写成一条案例,如果不写中间过程,案例又显得比较简单,故批量案例的编写可能需要探索如何更好描述批量测试的特点。
批量案例的编写规则确实需要总结讨论一下。我总结,批量测试案例编写的几点:
1)流程的划分
将若干相似功能的jobstep作为一个测试流程来编写案例。划分标准就以批量作业功能为主线,比如早间批量流程、日终批量流程、切后批量流程、年终结转批量处理流程、供数文件生成批量流程等等。
不要将一个项目中所有的批量步骤混在一个流程标签页中写,会显得凌乱。

4)一级验证点
大家一定要充分理解“验证点”,发现和描述“验证点”是整个案例设计的核心。
“验证点”要描述的是这个案例要验证的目标。
“测试要点”是测试设计人员在充分了解需求后用概括性的语言简明扼要的对测试点的描述,是测试步骤编写时针对的焦点,是在RN上登记时填写“测试内容”的依据。
“测试步骤”是为了验证点而进行的操作步骤。此部分是针对测试要点,通过运用各种测试方法、测试角度以及测试数据名称对如何测试进行的描述。为了增加可阅读性,提高可执行性,如果需要测试设计与测试执行分离,此部分的描述应尽可能的步骤明确化,操作明细化,使得执行人员对要到达测试要点的路径一目了然。
弄清楚以上三点的区别,有利于大家编写优秀的测试案例。而实际上很多同志把验证点写上了操作步骤,很不好读。通常批量要考虑的一级验证点,我理解:
A,“输入场测试”,比如批量日期的输入。
B,“权限测试”:比如允许谁跑批量,特殊批量还是日常批量,切前还是切后等等。
C,“功能验证”:
D,“输出验证”:
E,并发测试:按照什么并发,并发度多少等等。
F,调度测试:调度策略、调度的正确性。
G,容错测试:写文件时文件已存在、磁盘空间满了、能否支持断点重跑、错误数据容错处理(比如,会不会导致批量中断、insert不成功后通过update保持数据的更新而批量不中断等等),这一块很重要,也是大家容易疏忽的。。
H,批量日志:批量日志记载的正确性、尤其是断点日志的正确性。

5)二级验证点
是在一级验证点上面的细分。比如批量日期输入场验证,可以划分三个二级验证点,“非法日期”“特殊日期”“合法日期”。这里为了案例瘦身,没有设置多级验证点。有些人觉得两级验证点不够用,实际可以变通处理。可以通过一级验证点、二级验证点、测试要点三层来化解,不具体描述。

6)关于批量中间过程的描述
经过以上流程、环节、模块的划分后,剩下就是每一个批量模块中,每个步骤的中间过程的测试描述了。可以重点在“功能测试”一级验证点下面,每个中间过程的提炼出多个二级验证点,再通过测试要点、测试步骤进行阐述。
这里注意,验证点一定要简明扼要,通俗易懂,并且和后面的要点、步骤一一对应。

2.模板中子环节和一级子模块的填写很容易让人混淆。咨询了一些同事,采取了一级子模块采用最小的软需章节的方法;同时子环节取软需中功能描述的方法,不少同事写得两者差不多。建议在第一页面加以区分性说明。
这个是要界定一下,将划分粒度统一起来。上面也简单讲了环节和模块的划分。一个流程可能包括1个或者多个环节,一个环节又可能包括1个或者多个模块。在案例中引入“流程”“环节”“模块”划分的概念,主要是从我们目前负责的多数产品线出发,具有业务流程较多,关联度较大的特点。
结合我们正在起草的“测试过程管理”模板,要求“一级子模块”必须与rational中导入的功能模块对应起来。而rational中功能模块通常是和软需的功能模块对应的。
至于如何划分,由测试经理在测试方案阶段就画出清晰的示意图,案例设计者以此为刚。示意图模板如下:

4.对象的抽取标准和原则在新案例模版中体现不出,每个人的理解以及项目的不同,对对象的抽取都非常不一样。
这个问题也需要梳理一下。目前的案例模板只要求提取主要对象。
合理的对象抽取,有利于对整个项目的理解和把握;主要对象是系统的一根主线,通过主要对象的状态变迁,能够将系统的整体功能(交易行为)穿起来,形成一个脉络。对象的两大主要属性:状态、交易行为。
对象的抽取,是测试经理的必备技能。简单地说,如果数据库逻辑设计中,涉及某张表有“状态“字段,就要设法把状态的主体作为对象提炼出来。
在测试方案阶段,测试经理就需要提炼出主要对象,还包括每个主要对象的状态属性、状态变迁的交易行为等,供案例设计人员参考。对象示意图如下:

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注