3MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">、特定切面用例设计...8
4、隐含切面用例设计...8
(1)、无界面的后台功能...8
(2)、与业务流相关的测试...8
(3)、其它测试类型...9
三、测试数据的设计...9
一、测试用例的切面设计
所谓测试切面设计,其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型,也就是从上到下,逐渐细分,大模块包括小模块,小模块包括更小的模块。但仅仅如此是不够的,我们还要从更多的角度切入系统,从不同的角度把系统切分成一块一块的,来进行测试,从而确保测试大项的完整性。
1、功能点切面
这是最常见的切面,通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度,按每个功能;或一个功能点分多页;或多个功能点合成一页来进行用例的撰写。
2、特定切面
除此以外,还有一种特定切面的划分方法,也是用例撰写时经常会用到的。所谓的特定切面,就是忽略掉表面上的功能点,而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能,从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成,这时我们就可以把“授权记录生成”单独拿出来做一个测试项,而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页,也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法,那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面,可以使我们的用例阅读性、理解性、操作性更强。
3、隐含切面
这类用例是最容易被忽略的。它往往不是明显的某个功能项,可能是功能项后台的隐含处理,也可能是多个功能项之间的关联处理,甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解,来进行挖掘。
(1)、后台功能
常见的如一些定时自动启动的服务;以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的,但许多在需求设计中还是会提到,也有一些比较细小的功能可能会被忽略,就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员,写出来的用例就完全是两个层次的。
(2)、完整业务流程的测试
我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线,其中的某个按钮是点,多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。
事实上目前公司的软件本来都是业务型应用软件,将各种功能从业务流中切割出来单独写用例,肯定也会有涉及到整体流程的情况。若不加以区分,将细节与全局搅在一起,不仅思路混乱,也容易考虑不周。因此在系统测试阶段,建议用例设计要有分有合,针对具体功能的就只围着这个功能转:而在业务流程测试项中,再完全从整体的业务流角度出发去考虑用例,这样不仅不容易产生疏漏,用例阅读与执行也更清楚。
(3)、某种特定情况下的系统运行
这类用例的设计往往与系统实际业务情况密不可分。比如财务软件,通常需要在月尾一天、月头一天、年尾一天、年头一天,对所有相关功能中的日期处理进行测试;又比如WIN 2000环境开发测试的系统,要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页,在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑,来进行测试补充。
(4)、其它相关系统
即指在当前项目中直接使用的其它成果,包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚,是否需要测试。若时间紧张或其它原因决定不测的,应在测试计划中说明。若需要测试的,则具体可根据实际情况来设计,可以是通过系统某个功能的测试来涉及,此时就不需要单独划分测试项;若相对比较独立的,也可以通过单独的测试项来对其专门进行测试。
(5)、除功能测试外的其它测试类型
包括可靠性、安全性、恢复性、配置安装测试等等,这些测试类型都是一个单独的测试项。
所谓好的开始是成功的一半,保证测试项划分的完整、合理、正确,会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑,并要在测试过程中随着对软件的深入了解,不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。
文章来源于领测软件测试网 https://www.ltesting.net/