一、背景
近年來，隨著銀行業業務品種的激增，各應用系統也日益增多，各應用系統關系錯綜復雜，支系繁多。缺乏科學的方法來快速明確業務需求所指向的應用系統，導致測試過程中出現覆蓋不全、需求遺漏等問題。對于測試工作來說，如何分析需求點、劃定測試范圍就顯得尤為重要。
本文主要介紹根據業務模塊來梳理所涉及關聯系統和外圍系統，并在在此基礎上完成測試范圍精準劃定的一種方法。可以解決如下兩個實際問題，一是可能遺漏一些測試點，造成測試不充分；二是可能存在一些重復測試，造成資源浪費。
二、實施過程
首先，通過梳理某個領域的相關項目，分析相關業務規則，提取交易要素。其次，以業務需求為起點，貫穿業務場景的前、中、后臺系統的進行測試分層。
最后，根據測試的功能模塊快速定位所涉及的外圍系統及關系系統，進而解決測試中出現的測試覆蓋面不全等問題。
具體過程如下:
三、測試分層框架
整理分析某個業務領域的典型業務場景，完成典型業務場景的梳理，然后通過業務需求，并且結合以往項目經驗進行外圍系統分析，從而建立業務場景的統一視圖，生成了基于業務需求與業務場景視圖的測試分層框架（如圖1）。
圖1
借助該測試分層框架，可以提高精準確定測試范圍，降低項目風險。
第一，借助該層次型測試框架，可以劃定更加精準的劃分的測試范圍。由于我們明確了業務場景，那么需求分析也擴展到了業務場景的前、中、后系統層面，這樣就避免出現被測試系統遺漏的問題。
第二，借助該層次型測試框架，可以快速定位缺陷。針對該需求點設計的測試案例在執行失敗后，就可以追溯到對應系統的后臺交易，縮短了定位問題的時間。
四、舉例常見問題解答：
基于webdriver的分層自動化框架及平臺搭建，目前剛好在做這一塊的工作，對于分層次和平臺搭建，想問下大神有什么好的建議？
我們拿數據驅動框架來舉個例子。下面是我做的一個簡單的框架樣式：
這樣一個結構，分為base層（公共用例），element（元素層），properties（UI map層--properties文件），resource（資源層），task（存儲suite的testng文件），testcase（case層），util（底層，方法層）。
用這樣一個結構來更容易理解，更便于維護我們的框架。當然，這是一個基本demo哈，可以根據自己的實際情況擴展。總之，沒有最好的，只有最適合的，哈哈。
至于平臺，習慣上我們有兩種思維，一種是平臺是負責用來執行已經準備好的腳本或框架，二是平臺集成了快速編寫腳本、多負載執行等功能。這個也要看你的需求而定。
五、總結：
軟件測試這一行有兩條路可以選擇，我當初走的是技術路線，3年時間過去了，現在我升到了測試主管，月薪2w+，每個人擅長的技能不同，你可以根據自己的發展方向去選擇要走的路。前期走的路是一樣的，這段時間在于積累測試經驗，并決定自己走哪條路線（哪條路線更適合自己）。
下面通過我的個人經驗對測試崗位的供求現狀，可能存在的片面與不足之處，但是也能說明測試的發展前景，希望對你有所幫助：
1、這個行業的發展已經比較成熟，但是測試開發等高端人才缺口巨大；
2、入門的確容易，但不斷提升技術才是重中之重，安于現狀終將被淘汰；
3、就業機會多，因為公司產品迭代快，個人技術能力增長也快；
4、學習成本不是很大，相比來說，時間和資金都比開發要少很多。
碼了這么多字，分享一部分干貨，以上只是我的一些小經驗，每個人的經驗和技巧，都大不相同，相互交流相互學習是至關重要的。你可以先收藏我的經驗=o=，之后進群里去聽聽其他人的測試經歷、測試經驗、技術技能、面試技巧啥的，日積月累你一定也會變得很厲害！毋庸置疑，誰都有可能成為下一個技術大牛！
