從最開始徘徊在開發(fā)的邊緣，軟件測試正在不斷找到自己的位置。軟件測試不再是低技術(shù)含量、高重復(fù)工作的代名詞，不再是可有可無、不被重視的部門，軟件產(chǎn)品質(zhì)量正在越來越依賴于測試部門的保障。

    除了更多技術(shù)高手開始擔(dān)任測試工作，在管理軟件行業(yè)，對某項業(yè)務(wù)的熟悉同樣可以成為測試人員的利器。注冊會計師出身的張茜就是這樣一個例子?，F(xiàn)在的她是用友u9部門質(zhì)量總監(jiān)，用友公司測試專家。2000年加入用友，她一直在從事管理軟件測試工作，歷任u8 v8.2、v8.5、v8.7系列的產(chǎn)品測試、發(fā)布；作為測試專家參與u9 1.0、1.5系列產(chǎn)品發(fā)布，負(fù)責(zé)u9 v1.5sp、v2.0、v2.0sp系列發(fā)版。從事測試工作10年的她，自己也沒有想到會在好不容易考到注冊會計師后卻轉(zhuǎn)行測試，并且在此后的這么長一段時間里和測試工作為伍。為此，她的惟一解釋是：這是因?yàn)樽鰁rp軟件的測試需要和業(yè)務(wù)邏輯有著非常強(qiáng)的關(guān)聯(lián)。而這一認(rèn)識既來源于她多年測試工作的積累，也經(jīng)過了時間和實(shí)踐的考驗(yàn)。

    2010年4月的一天，在曬滿陽光的辦公室里，張茜將她最為熟悉，為之驕傲的整個u9測試的“那些事”娓娓道來。

    u9的測試體系和架構(gòu)與整個用友產(chǎn)品的體系架構(gòu)類似，但是u9的測試團(tuán)隊是獨(dú)立服務(wù)于u9這個產(chǎn)品的測試團(tuán)隊。u9的整體開發(fā)過程都強(qiáng)調(diào)特性驅(qū)動，測試過程也不例外。

    在產(chǎn)品開發(fā)過程中，特性驅(qū)動表現(xiàn)為特性開發(fā)，由需求設(shè)計、架構(gòu)師、項目經(jīng)理、開發(fā)、測試等人員動態(tài)地構(gòu)成一個虛擬團(tuán)隊，進(jìn)行特性的開發(fā)和測試，以保證該特性如期完成，并達(dá)到一定的穩(wěn)定程度。在此期間，某幾個人會專門負(fù)責(zé)這一特性的測試，比如經(jīng)過兩周時間該特性測試通過并提交主版本后，這幾個人就可以釋放出來，去做別的特性的測試。因此，特性驅(qū)動測試是一個相對動態(tài)的過程。

    從測試過程和人員分工上，u9的測試可以分為這樣幾個階段：

    單元測試：程序員寫完代碼，按照u9的規(guī)范流程，由程序員自己進(jìn)行單元測試，保證一定的質(zhì)量才能提交給測試部門測試。測試人員會有一個接收的過程，進(jìn)行單元驗(yàn)收。

    特性測試：單元驗(yàn)收后，測試人員會比開發(fā)人員更大范圍的，從業(yè)務(wù)的角度，將整個流程特性貫穿起來運(yùn)行測試。在特性范圍內(nèi)，達(dá)到u9的質(zhì)量標(biāo)準(zhǔn)，才能向上一級提交，即特性提交，進(jìn)入下一步特性驗(yàn)證的過程。

    特性驗(yàn)證：由主測人員，即產(chǎn)品設(shè)計層級的人員，對提交的特性進(jìn)行特性驗(yàn)證。特性驗(yàn)證通過的代碼是相對穩(wěn)定的，可以合并入主版本。特性驗(yàn)證通過，將一個一個特性合并入主版后，在一個截止點(diǎn)上，把所有的特性都合并進(jìn)來，進(jìn)入下一步。

    系統(tǒng)測試：在u9團(tuán)隊被稱為聯(lián)調(diào)測試，即把所有的特性放在一起進(jìn)行一個統(tǒng)一測試。聯(lián)調(diào)測試更多地是從功能角度進(jìn)行黑盒測試。模擬企業(yè)的流程從頭到尾過一遍，保證流程、流轉(zhuǎn)、控制等各方面，達(dá)到一定的穩(wěn)定程度，才能進(jìn)入下一步模擬用戶的集成測試。

    集成測試：u9團(tuán)隊所說的集成測試就是收集典型行業(yè)的典型用戶應(yīng)用，將這些典型用戶的行業(yè)案例和實(shí)施方案拿來在系統(tǒng)中進(jìn)行模擬測試，如果整個系統(tǒng)跑下來能夠確認(rèn)符合質(zhì)量標(biāo)準(zhǔn)就可以進(jìn)入發(fā)版。

單元測試由誰測？

    目前，業(yè)內(nèi)基本共識是：單元測試由開發(fā)人員完成。但是，讓開發(fā)人員心甘情愿地進(jìn)行單元測試，并完成好它并不是那么容易的事。在張茜看來，目前u9的開發(fā)人員基本能夠完成單元測試，但還是不能達(dá)到一個理想的狀態(tài)：即開發(fā)人員能夠按照單元測試要求比較高質(zhì)量的提交代碼。在u9開發(fā)團(tuán)隊，開發(fā)人員能夠進(jìn)行基本單元測試工作，但還是需要測試部門對其進(jìn)行驗(yàn)收，一次通過的概率還需要提高。

    一般來說，開發(fā)人員不是很容易接受單元測試工作，都會存在一些抗拒心理。如何讓開發(fā)人員接受并完成單元測試？張茜認(rèn)為：在這個問題上，開發(fā)部門主管的作用非常大。測試部門需要與開發(fā)部門主管在一開始就商量好，明確單元代碼質(zhì)量的提高是最終版本穩(wěn)定的最基礎(chǔ)和重要的方面。前面不穩(wěn)定靠后面彌補(bǔ)只會適得其反。因此，一般u9測試團(tuán)隊會和開發(fā)主管達(dá)成一致?，F(xiàn)在開發(fā)部門經(jīng)理和項目經(jīng)理也都很理解這一點(diǎn)，經(jīng)過以前的實(shí)踐，更加知道單元測試的重要性。因此，總的來說，由上而下對程序員灌輸單元測試的重要性，并通過規(guī)范制度來保證這樣一個流程的貫徹和執(zhí)行，是非常有必要的。

    為了達(dá)到單元測試的目的和保證單元測試的質(zhì)量，u9團(tuán)隊通過checklist表，要求程序員完成代碼后必須按照表格一條一條完成測試項目。這也解決了一開始開發(fā)人員不知道如何測試的問題。一開始，他們必須把最常規(guī)的幾條都走到，把這些都測試完畢后才可以提交代碼。測試用例也是由測試部門提供，開發(fā)人員直接去跑程序測試即可。這些用例相對比較簡單，包括了錄入邊界值、基本功能、性能指標(biāo)等共同項目。

    從單元測試引申到開發(fā)和測試的沖突，在張茜看來，開發(fā)和測試的沖突非常正常。大家必須互相牽制，才能共同保證產(chǎn)品質(zhì)量。在u9團(tuán)隊，通過cq檢出bug，一次修改通過，那么問題就友好地解決了。比較麻煩的是，一個bug多次沒有修改通過怎么辦？張茜的經(jīng)驗(yàn)是：一定要與開發(fā)經(jīng)理溝通，安排其他主程序員對代碼進(jìn)行review，從這一層面來加強(qiáng)解決。畢竟，測試人員的目的是推動產(chǎn)品質(zhì)量和產(chǎn)品發(fā)展，這也是大家共同的目標(biāo)，這一點(diǎn)更需要向開發(fā)人員解釋清楚。其實(shí)，有時候，程序員也可能對自己的代碼也沒底，遇到問題不知道如何去處理，這時程序員也需要測試人員站出來說話，推動整個過程向前發(fā)展。這時，測試人員對開發(fā)人員的幫助，就能形成一個良性的循環(huán)。

測試用例從何來？

    前面談到，單元測試的測試用例由測試部門提供。而集成測試的用例則來源于一線的實(shí)施方案，包括由架構(gòu)師提供的特性和對應(yīng)的場景。在比需求更高一層的架構(gòu)師立項時，就要確定這一版需覆蓋哪些用戶，解決哪些特性，并進(jìn)行場景描述。測試人員根據(jù)場景找到目前正在實(shí)施的項目，將不同場景和不同特性組合并找到典型用戶，這些用戶能夠比較全面地覆蓋以上場景和特性。由測試骨干和專家，結(jié)合特性和企業(yè)情況，與實(shí)施經(jīng)理和實(shí)施顧問深入溝通，與架構(gòu)師充分溝通，找到典型用戶關(guān)注的特性、自身的流程、應(yīng)用，最終形成一個完整的集成測試方案。這一方案要經(jīng)過由架構(gòu)師、需求、開發(fā)、部分市場、實(shí)施組成的評審團(tuán)隊的審慎評審。這是發(fā)版前一個關(guān)鍵的質(zhì)量控制環(huán)節(jié)。

    在u9測試團(tuán)隊，測試人員會與實(shí)施人員有著非常緊密的溝通。一方面是為了盡快解決早一版本在實(shí)施過程中的現(xiàn)有問題。另一方面，是因?yàn)閡9產(chǎn)品屬于起步初期，產(chǎn)品規(guī)模較大，實(shí)施周期較長，一個小版的發(fā)版周期都需要3~6個月。往往是新版本還沒有發(fā)布，但是已經(jīng)有幾個項目在等著了。因此，前期的實(shí)施準(zhǔn)備階段，一方面對發(fā)版構(gòu)成一定壓力，但另一方面也是非常好的資源，它的針對性特別強(qiáng)。張茜談到：測試團(tuán)隊會和這樣的項目密切配合，因?yàn)樗麄円卜浅ＯＭㄟ^測試把關(guān)，讓新產(chǎn)品切合企業(yè)的實(shí)際功能和流程需求。

    性能測試和壓力測試會在聯(lián)調(diào)的時候進(jìn)行。u9的性能測試分幾個方面：單點(diǎn)效率，每一點(diǎn)在一定數(shù)據(jù)量的支持下能夠達(dá)到指標(biāo)；流暢性指標(biāo)，比如一個完整的收貨業(yè)務(wù)或者領(lǐng)料任務(wù)，從頭到尾要花費(fèi)多少時間；壓力測試，主要由loadrunner工具實(shí)現(xiàn)，u9也有與微軟的合作，模擬5000~8000人同時登錄，服務(wù)器、線程、應(yīng)用端、網(wǎng)絡(luò)部署各方面的壓力分別怎樣；200人場景測試（壓力測試），一個真實(shí)的200人場景，進(jìn)一步模擬企業(yè)中的實(shí)際應(yīng)用場景。200人的場景測試算作壓力測試的一部分，結(jié)合集成方案，制訂場景測試，比如10個人做收貨，10個人做領(lǐng)料，10個人做入庫，報表，打印，不同人模擬完成不同業(yè)務(wù)，很實(shí)際地模擬企業(yè)日常工作場景。

測試工具用什么？

    壓力測試中，u9團(tuán)隊主要使用loadrunner工具來實(shí)現(xiàn)，同時，u9也與微軟的合作，來模擬5000~8000人的同時登錄。但整個u9測試團(tuán)隊使用最多的還是
rft工具。目前u9開發(fā)管理都是采用cc、cq進(jìn)行代碼管理、權(quán)限管理和缺陷跟蹤管理等，為了方便與開發(fā)平臺的集成，u9的測試平臺也使用了rtf平臺。但是，張茜也表示：集成的效果并不好。ibm可能自己有很好的實(shí)踐，利用測試工具測試部分代碼，自動化測試后產(chǎn)生結(jié)果，傳到cq，達(dá)到一個集成的效果。而u9團(tuán)隊在這個集成過程中卻有很多問題，所以并沒有真正集成起來。但是，u9團(tuán)隊也在這個過程中慢慢摸索、通過改造等工作實(shí)現(xiàn)測試目標(biāo)。

    u9測試團(tuán)隊從4年前開始使用rft，在其基礎(chǔ)上進(jìn)行了大量框架開發(fā)和成果積累。比如，rft測試主要是一個錄制回放的過程，但是回放的成功率通常不是很高，產(chǎn)品是靠抓ui上的坐標(biāo)方位來實(shí)現(xiàn)，界面一動錄制腳本就廢了。u9在這方面做了大量基礎(chǔ)工作，通過一個測試框架，我們抓的不再是界面上的坐標(biāo)尺寸，而是抓的一個自設(shè)id。不論前臺還是后臺的每一個按鈕，控件都有自己的編碼，編碼具有唯一性，由編碼轉(zhuǎn)換成rft的東西，再進(jìn)行回放。這樣界面上的ui輕微變動是不會影響，在不同的機(jī)器上回放，成功率也高了很多。

如何建設(shè)一個好團(tuán)隊？

    目前，u9的測試團(tuán)隊共有60多名正式人員和20多位外包人員，開發(fā)人員和測試人員的比例基本達(dá)到2:1，遠(yuǎn)遠(yuǎn)優(yōu)于目前國內(nèi)平均水平。而張茜的理想狀態(tài)是1:1。但是，u9測試團(tuán)隊的開發(fā)能力卻不容小覷。

    雖然u9測試團(tuán)隊中從事自動化測試的人員只有4~5位，但卻都個個具有相當(dāng)?shù)拈_發(fā)能力，也愿意做些開發(fā)工作。比如，上面提到的對rft測試框架的改進(jìn)，以及自動抓取id工具等。u9自動化測試力量都強(qiáng)于其他產(chǎn)品。

    在從事測試工作10年，從會計行業(yè)轉(zhuǎn)行而來的張茜看來，做erp軟件的測試和業(yè)務(wù)邏輯有非常強(qiáng)的關(guān)聯(lián)。因此，她面試時會更加注重面試者的業(yè)務(wù)能力，業(yè)務(wù)的背景會比測試的背景重要很多。而測試工作，特別是黑盒測試相對比較簡單，更多地是對產(chǎn)品業(yè)務(wù)流程的把控能力，對數(shù)據(jù)的敏感程度和控制能力。

    目前，u9測試團(tuán)隊層次分開。主測試人員有4~5個，主要負(fù)責(zé)測試架構(gòu)和規(guī)劃方面的工作。主測試的目的是把自己負(fù)責(zé)這一塊的流程把握，測試重點(diǎn)在哪里，測試方案是否合理。而測試的執(zhí)行則需要執(zhí)行力強(qiáng)、更仔細(xì)、更勤勉的人，需要一遍一遍地反復(fù)測試，并能敏銳地發(fā)現(xiàn)問題。邊角工作則可以由實(shí)習(xí)人員完成，比如性能、ui交互，這些比較機(jī)械地工作可以在方案設(shè)計好后由他們來逐條測試。這樣便形成一個完美的金字塔結(jié)構(gòu)的測試團(tuán)隊。

    最后，張茜也透露，u9產(chǎn)品的發(fā)版密度較大，雖然今年已經(jīng)比去年有所減少，但也有1大2小三個版本。每個版本的測試周期和回歸壓力還是比較大的。馬上要發(fā)布的將是u9 2.0sp版本。大版則是在今年8月將要發(fā)布的的u9 2.1版。10月還將推出u9 2.1 sp1版本。