什么是层次型测试框架？探讨一下分层测试与传统测试方法的差别

一、背景

近年来，随着银行业业务品种的激增，各应用系统也日益增多，各应用系统关系错综复杂，支系繁多。缺乏科学的方法来快速明确业务需求所指向的应用系统，导致测试过程中出现覆盖不全、需求遗漏等问题。对于测试工作来说，如何分析需求点、划定测试范围就显得尤为重要。

本文主要介绍根据业务模块来梳理所涉及关联系统和外围系统，并在在此基础上完成测试范围精准划定的一种方法。可以解决如下两个实际问题，一是可能遗漏一些测试点，造成测试不充分；二是可能存在一些重复测试，造成资源浪费。

二、实施过程

首先，通过梳理某个领域的相关项目，分析相关业务规则，提取交易要素。其次，以业务需求为起点，贯穿业务场景的前、中、后台系统的进行测试分层。

最后，根据测试的功能模块快速定位所涉及的外围系统及关系系统，进而解决测试中出现的测试覆盖面不全等问题。

具体过程如下:

三、测试分层框架

整理分析某个业务领域的典型业务场景，完成典型业务场景的梳理，然后通过业务需求，并且结合以往项目经验进行外围系统分析，从而建立业务场景的统一视图，生成了基于业务需求与业务场景视图的测试分层框架（如图1）。

图1

借助该测试分层框架，可以提高精准确定测试范围，降低项目风险。

第一，借助该层次型测试框架，可以划定更加精准的划分的测试范围。由于我们明确了业务场景，那么需求分析也扩展到了业务场景的前、中、后系统层面，这样就避免出现被测试系统遗漏的问题。

第二，借助该层次型测试框架，可以快速定位缺陷。针对该需求点设计的测试案例在执行失败后，就可以追溯到对应系统的后台交易，缩短了定位问题的时间。

四、举例常见问题解答：

基于webdriver的分层自动化框架及平台搭建，目前刚好在做这一块的工作，对于分层次和平台搭建，想问下大神有什么好的建议？

我们拿数据驱动框架来举个例子。下面是我做的一个简单的框架样式：

这样一个结构，分为base层（公共用例），element（元素层），properties（UI map层--properties文件），resource（资源层），task（存储suite的testng文件），testcase（case层），util（底层，方法层）。

用这样一个结构来更容易理解，更便于维护我们的框架。当然，这是一个基本demo哈，可以根据自己的实际情况扩展。总之，没有最好的，只有最适合的，哈哈。

至于平台，习惯上我们有两种思维，一种是平台是负责用来执行已经准备好的脚本或框架，二是平台集成了快速编写脚本、多负载执行等功能。这个也要看你的需求而定。

五、总结：

软件测试这一行有两条路可以选择，我当初走的是技术路线，3年时间过去了，现在我升到了测试主管，月薪2w+，每个人擅长的技能不同，你可以根据自己的发展方向去选择要走的路。前期走的路是一样的，这段时间在于积累测试经验，并决定自己走哪条路线（哪条路线更适合自己）。

下面通过我的个人经验对测试岗位的供求现状，可能存在的片面与不足之处，但是也能说明测试的发展前景，希望对你有所帮助：

1、这个行业的发展已经比较成熟，但是测试开发等高端人才缺口巨大；

2、入门的确容易，但不断提升技术才是重中之重，安于现状终将被淘汰；

3、就业机会多，因为公司产品迭代快，个人技术能力增长也快；

4、学习成本不是很大，相比来说，时间和资金都比开发要少很多。

码了这么多字，分享一部分干货，以上只是我的一些小经验，每个人的经验和技巧，都大不相同，相互交流相互学习是至关重要的。你可以先收藏我的经验=o=，之后进群里去听听其他人的测试经历、测试经验、技术技能、面试技巧啥的，日积月累你一定也会变得很厉害！毋庸置疑，谁都有可能成为下一个技术大牛！