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