何偉文

(廣州南洋理工職業(yè)學院，廣東 廣州 510510)

一、分層測試_基本思想

分層是復雜軟件系統常見的設計思路。比如互聯網的七層/五層模型，Android系統的APP/FWK/JNI/Kernel等，都是通過分層、解耦，達到簡化問題，易于維護，便于擴展的效果。分層測試以調用接口驅動被測系統，盡量不依賴于打樁。

按照V模型進行劃分層次：單元測試；集成測試；系統測試；

unit層的測試對象是函數或方法；service層的測試對象是模塊和接口；UI層的主要測試對象是展示和交互。

unit層的測試策略：

1、代碼走查：開發(fā)人員自己檢查自己的代碼

2、代碼評審code review：開發(fā)團隊組織評審會，應避免走馬觀花，應注重效率

3、單元測試：自動化單元測試，編寫測試代碼或使用測試工具，缺點：入門門檻高，沒有好的實踐方法（覆蓋率和編寫標準），則可能無法推行，最終淪為雞肋或是詬病。優(yōu)點能盡快的執(zhí)行，降低測試成本，復用性好，可反復執(zhí)行。

我們需要規(guī)范的來做單元測試同樣需要相應的單元測試框架，如java的Junit、testNG，C#的NUint，Python的unittest、pytest等，幾乎所有的主流語言，都會有其對應的單元測試框架。

service層的測試策略：自動化的組件測試；自動化的集成測試；自動化的API測試與單元測試比較：運行速度慢，測試環(huán)境搭建困難，case數量較少。

UI層的測試：大部分測試人員的大部分工作都是對UI層的功能進行測試。例如，我們不斷重復對一個表單提交，結果查詢等功能進行測試，我們可以通過相應的自動化測試工具來模擬這些操作，從而解放重復的勞動。

UI層的測試策略：

手工測試：純手工測試執(zhí)行速度慢，無法重復使用；

自動化測試：穩(wěn)定模塊，與其它層面的測試比較：自動化開發(fā)難度大，運行速度慢，測試環(huán)境搭建困難。

這樣我們可以做到單元測試盡量多做，UI級的測試可以少做一點；因為UI測試難度相對較大；UI測試更接近于真實用戶；手工UI測試只占據了塔頂一點點的位置，而大部分的測試工作是手工測試人員所難以介入的，這讓只會手工測試的人有一定的危機感；

開發(fā)人員是質量保障的最關鍵因素，因為測試金字塔的大部分測試工作都需要開發(fā)或者是具備開發(fā)技能的技術員去完成；

測試金字塔是穩(wěn)固的，如果按照測試金字塔的模型去組織測試工作的話，在一切相對正常的情況下，產品/項目/系統的質量是處在可控的狀態(tài)下的。

現實生活中能做到測試金字塔的團隊往往是少數，大部分測試技術員接觸到的團隊應該是倒三角的，也就是沒有或只有少量的單元測試，隨心所欲做一些接口測試，把大量的人力集中在UI測試。這樣的產品質量往往難以控制或者需要花費大量的時間和人力成本才能控制。

有一些的產品剛橫空出世的時候往往是沒有單元測試和UI自動化測試的，但這些產品剛發(fā)布時的質量卻是可以接受的或者甚至是優(yōu)秀的，這是為什么呢？這是因為這些產品往往由天才的開發(fā)者創(chuàng)建或實現，天才的代碼在不做單元測試的情況下也是質量可期的，這就等于是測試金字塔的最底層相當牢固，整個產品質量就自然由保障了；另外這些產品發(fā)布的初期規(guī)模也相對較小，也比較難出現一些在頻繁協作過程中會出現的問題（比如修改了不是自己寫的代碼而造成了缺陷），規(guī)模小質量控制起來也相對容易些。

總而言之，如果你的產品/項目/系統的開發(fā)團隊大部分人都不是天才而且需要進行頻繁協作的話，按照測試金字塔模型去做可能是一個比較好的方式。

二、分層測試的好處

（一）精準。我們都知道，離問題產生的地方越近，就越容易觸發(fā)問題。如果問題發(fā)生在底層，以白盒測試的方法，很難精確打擊，特別是一些復雜場景或異常流程，可能無法構造。而分層測試的切入點就是層與層之間的接口，從機制上更接近出問題的地方，因此也更容易命中目標。

（二）低成本。這個優(yōu)勢源于可測試性。舉例來說：我們要測試Android系統下撥號的性能，黑盒怎么測呢？測試人員需要打開秒表，同時進行撥號的操作，并觀測電話是否撥通。操作麻煩不說，誤差也很大。如果用分層測試的方式，只要提供撥號和檢查是否撥通兩個對外開放的接口，通過用例腳本調用，并記錄兩者的時間，就可以方便準確地得到耗時。更進一步，我們還可以在不同層次的接口調用時均記錄下時間，在腳本中直接對各個環(huán)節(jié)的耗時進行分析，從而自動分析流程的瓶頸，找到影響性能的關鍵環(huán)節(jié)。

（三）高效。這里是指用例執(zhí)行速度快。首先自動化測試的速度就明顯優(yōu)于手工測試，基于API調用的自動化又比UI自動化要快，分層測試的高效就建立在API調用高效的基礎上。從我們收集的數據來看，相同的用例，手工執(zhí)行的耗時平均在5-8分鐘，UI自動化一般也需要1-2分鐘，而分層測試通常10-20秒就完成了，效率提升達10倍。

（四）易定位。易定位其實是和精準對應的。在用例設計的時候就考慮到用例所針對的代碼，一旦出現問題，自然就容易定位了。

（五）穩(wěn)定?？蛻粜枨笫且鬃兊?，內部實現也是易變的，但是層與層之間的接口是不同開發(fā)人員之間的約定，通常會盡量保持穩(wěn)定。這里也有一組數據：從Android 4.0到Android 5.0，我們設計的JNI層用例變更不到10%，而針對APP界面開發(fā)的用例，變更率高達40%。