對(duì)軟件系統(tǒng)分層測(cè)試的初探

何偉文

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

一、分層測(cè)試_基本思想

分層是復(fù)雜軟件系統(tǒng)常見(jiàn)的設(shè)計(jì)思路。比如互聯(lián)網(wǎng)的七層/五層模型，Android系統(tǒng)的APP/FWK/JNI/Kernel等，都是通過(guò)分層、解耦，達(dá)到簡(jiǎn)化問(wèn)題，易于維護(hù)，便于擴(kuò)展的效果。分層測(cè)試以調(diào)用接口驅(qū)動(dòng)被測(cè)系統(tǒng)，盡量不依賴于打樁。

按照V模型進(jìn)行劃分層次：?jiǎn)卧獪y(cè)試；集成測(cè)試；系統(tǒng)測(cè)試；

unit層的測(cè)試對(duì)象是函數(shù)或方法；service層的測(cè)試對(duì)象是模塊和接口；UI層的主要測(cè)試對(duì)象是展示和交互。

unit層的測(cè)試策略：

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

2、代碼評(píng)審code review：開(kāi)發(fā)團(tuán)隊(duì)組織評(píng)審會(huì)，應(yīng)避免走馬觀花，應(yīng)注重效率

3、單元測(cè)試：自動(dòng)化單元測(cè)試，編寫(xiě)測(cè)試代碼或使用測(cè)試工具，缺點(diǎn)：入門(mén)門(mén)檻高，沒(méi)有好的實(shí)踐方法（覆蓋率和編寫(xiě)標(biāo)準(zhǔn)），則可能無(wú)法推行，最終淪為雞肋或是詬病。優(yōu)點(diǎn)能盡快的執(zhí)行，降低測(cè)試成本，復(fù)用性好，可反復(fù)執(zhí)行。

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

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

UI層的測(cè)試：大部分測(cè)試人員的大部分工作都是對(duì)UI層的功能進(jìn)行測(cè)試。例如，我們不斷重復(fù)對(duì)一個(gè)表單提交，結(jié)果查詢等功能進(jìn)行測(cè)試，我們可以通過(guò)相應(yīng)的自動(dòng)化測(cè)試工具來(lái)模擬這些操作，從而解放重復(fù)的勞動(dòng)。

UI層的測(cè)試策略：

手工測(cè)試：純手工測(cè)試執(zhí)行速度慢，無(wú)法重復(fù)使用；

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

這樣我們可以做到單元測(cè)試盡量多做，UI級(jí)的測(cè)試可以少做一點(diǎn)；因?yàn)閁I測(cè)試難度相對(duì)較大；UI測(cè)試更接近于真實(shí)用戶；手工UI測(cè)試只占據(jù)了塔頂一點(diǎn)點(diǎn)的位置，而大部分的測(cè)試工作是手工測(cè)試人員所難以介入的，這讓只會(huì)手工測(cè)試的人有一定的危機(jī)感；

開(kāi)發(fā)人員是質(zhì)量保障的最關(guān)鍵因素，因?yàn)闇y(cè)試金字塔的大部分測(cè)試工作都需要開(kāi)發(fā)或者是具備開(kāi)發(fā)技能的技術(shù)員去完成；

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

現(xiàn)實(shí)生活中能做到測(cè)試金字塔的團(tuán)隊(duì)往往是少數(shù)，大部分測(cè)試技術(shù)員接觸到的團(tuán)隊(duì)?wèi)?yīng)該是倒三角的，也就是沒(méi)有或只有少量的單元測(cè)試，隨心所欲做一些接口測(cè)試，把大量的人力集中在UI測(cè)試。這樣的產(chǎn)品質(zhì)量往往難以控制或者需要花費(fèi)大量的時(shí)間和人力成本才能控制。

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

總而言之，如果你的產(chǎn)品/項(xiàng)目/系統(tǒng)的開(kāi)發(fā)團(tuán)隊(duì)大部分人都不是天才而且需要進(jìn)行頻繁協(xié)作的話，按照測(cè)試金字塔模型去做可能是一個(gè)比較好的方式。

二、分層測(cè)試的好處

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

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

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

（四）易定位。易定位其實(shí)是和精準(zhǔn)對(duì)應(yīng)的。在用例設(shè)計(jì)的時(shí)候就考慮到用例所針對(duì)的代碼，一旦出現(xiàn)問(wèn)題，自然就容易定位了。

（五）穩(wěn)定。客戶需求是易變的，內(nèi)部實(shí)現(xiàn)也是易變的，但是層與層之間的接口是不同開(kāi)發(fā)人員之間的約定，通常會(huì)盡量保持穩(wěn)定。這里也有一組數(shù)據(jù)：從Android 4.0到Android 5.0，我們?cè)O(shè)計(jì)的JNI層用例變更不到10%，而針對(duì)APP界面開(kāi)發(fā)的用例，變更率高達(dá)40%。