一、背景
近年来,随着银行业业务品种的激增,各应用系统也日益增多,各应用系统关系错综复杂,支系繁多。缺乏科学的方法来快速明确业务需求所指向的应用系统,导致测试过程中出现覆盖不全、需求遗漏等问题。对于测试工作来说,如何分析需求点、划定测试范围就显得尤为重要。
本文主要介绍根据业务模块来梳理所涉及关联系统和外围系统,并在在此基础上完成测试范围精准划定的一种方法。可以解决如下两个实际问题,一是可能遗漏一些测试点,造成测试不充分;二是可能存在一些重复测试,造成资源浪费。
二、实施过程
首先,通过梳理某个领域的相关项目,分析相关业务规则,提取交易要素。其次,以业务需求为起点,贯穿业务场景的前、中、后台系统的进行测试分层。
最后,根据测试的功能模块快速定位所涉及的外围系统及关系系统,进而解决测试中出现的测试覆盖面不全等问题。
具体过程如下:
三、测试分层框架
整理分析某个业务领域的典型业务场景,完成典型业务场景的梳理,然后通过业务需求,并且结合以往项目经验进行外围系统分析,从而建立业务场景的统一视图,生成了基于业务需求与业务场景视图的测试分层框架(如图1)。
图1
借助该测试分层框架,可以提高精准确定测试范围,降低项目风险。
第一,借助该层次型测试框架,可以划定更加精准的划分的测试范围。由于我们明确了业务场景,那么需求分析也扩展到了业务场景的前、中、后系统层面,这样就避免出现被测试系统遗漏的问题。
第二,借助该层次型测试框架,可以快速定位缺陷。针对该需求点设计的测试案例在执行失败后,就可以追溯到对应系统的后台交易,缩短了定位问题的时间。
四、举例常见问题解答:
基于webdriver的分层自动化框架及平台搭建,目前刚好在做这一块的工作,对于分层次和平台搭建,想问下大神有什么好的建议?
我们拿数据驱动框架来举个例子。下面是我做的一个简单的框架样式:
这样一个结构,分为base层(公共用例),element(元素层),properties(UI map层--properties文件),resource(资源层),task(存储suite的testng文件),testcase(case层),util(底层,方法层)。
用这样一个结构来更容易理解,更便于维护我们的框架。当然,这是一个基本demo哈,可以根据自己的实际情况扩展。总之,没有最好的,只有最适合的,哈哈。
至于平台,习惯上我们有两种思维,一种是平台是负责用来执行已经准备好的脚本或框架,二是平台集成了快速编写脚本、多负载执行等功能。这个也要看你的需求而定。
五、总结:
软件测试这一行有两条路可以选择,我当初走的是技术路线,3年时间过去了,现在我升到了测试主管,月薪2w+,每个人擅长的技能不同,你可以根据自己的发展方向去选择要走的路。前期走的路是一样的,这段时间在于积累测试经验,并决定自己走哪条路线(哪条路线更适合自己)。
下面通过我的个人经验对测试岗位的供求现状,可能存在的片面与不足之处,但是也能说明测试的发展前景,希望对你有所帮助:
1、这个行业的发展已经比较成熟,但是测试开发等高端人才缺口巨大;
2、入门的确容易,但不断提升技术才是重中之重,安于现状终将被淘汰;
3、就业机会多,因为公司产品迭代快,个人技术能力增长也快;
4、学习成本不是很大,相比来说,时间和资金都比开发要少很多。
码了这么多字,分享一部分干货,以上只是我的一些小经验,每个人的经验和技巧,都大不相同,相互交流相互学习是至关重要的。你可以先收藏我的经验=o=,之后进群里去听听其他人的测试经历、测试经验、技术技能、面试技巧啥的,日积月累你一定也会变得很厉害!毋庸置疑,谁都有可能成为下一个技术大牛!