成熟的軟件測(cè)試是確保軟件質(zhì)量的一種重要手段，自動(dòng)化測(cè)試技術(shù)的出現(xiàn)，對(duì)于提高測(cè)試單位績(jī)效比起了重要作用，被廣泛應(yīng)用于回歸測(cè)試中，但是由于被測(cè)試系統(tǒng)的不確定性和復(fù)雜性，使得軟件自動(dòng)化測(cè)試變得異常困難。本文基于商業(yè)工具結(jié)合實(shí)際項(xiàng)目，分析自動(dòng)化測(cè)試實(shí)施期間出現(xiàn)的各種問題，以提高大家對(duì)自動(dòng)化測(cè)試項(xiàng)目的真正認(rèn)識(shí)與理解。
現(xiàn)在自動(dòng)化測(cè)試工具很多，商業(yè)的或者開源的，以對(duì)象識(shí)別為基礎(chǔ)的或者以語言特性為基礎(chǔ)的等等。在挑選的時(shí)候，首先我們要明確被操作軟件的范疇和特性，可預(yù)知風(fēng)險(xiǎn)，培訓(xùn)潛在成本及是否具備被虛擬化等一系列問題，這些問題可制成標(biāo)準(zhǔn)檢查列表，以便確定一個(gè)解決一個(gè)。在本次自動(dòng)化測(cè)試實(shí)施中，首先可知的是被測(cè)試軟件屬于行業(yè)金融軟件，使用Borland C++Builder語言開發(fā)，測(cè)試范疇鎖定在軟件前臺(tái)需配對(duì)后臺(tái)數(shù)據(jù)驗(yàn)證，前臺(tái)由RedHat Linux服務(wù)端、自研發(fā)中間件和Oracle數(shù)據(jù)庫(kù)支撐。一般來說，這種軟件應(yīng)用架構(gòu)比較清晰，但是GUI層使用了大量的非標(biāo)準(zhǔn)第三方控件，有可能會(huì)導(dǎo)致部分對(duì)象無法捕獲造成實(shí)施困難，所以在進(jìn)入真正的實(shí)施前作充分、快速的實(shí)驗(yàn)性評(píng)估是非常重要的。
職業(yè)化的自動(dòng)化測(cè)試團(tuán)隊(duì)，應(yīng)當(dāng)非常熟悉當(dāng)前主流的商業(yè)或者開源測(cè)試工具，這種團(tuán)隊(duì)的定義是：技術(shù)讓位與成本控制，快速實(shí)施且能快速遞交，精確控制每12周為一周期，項(xiàng)目延時(shí)誤差小于2天?？紤]到腳本會(huì)被移交給其他團(tuán)隊(duì)執(zhí)行，所以我們選擇了目前在國(guó)內(nèi)應(yīng)用范圍比較廣、相關(guān)技術(shù)資料比較豐富的HP Winrunner和HP QuickTestPro。第一個(gè)被評(píng)估的是QuickTestPro 9.5版本不帶任何插件，結(jié)果大量的GUI對(duì)象無法被捕捉，不能捕捉意味著不能被操作，所以團(tuán)隊(duì)快速轉(zhuǎn)換到Winrunner 9.2版本不帶任何插件，實(shí)驗(yàn)結(jié)果是基本可以正確識(shí)別和捕獲我們所要操作的GUI對(duì)象，滿足了對(duì)工具的需求。其實(shí)QuickTestPro 9.5版本帶Delphi插件也可大大增加捕獲率，但是使用插件違反了團(tuán)隊(duì)定義的工具應(yīng)用管理規(guī)范，也不符合“有對(duì)象即可操作”的強(qiáng)硬編程作風(fēng)。
在工具定義后，需要立刻選擇2組典型業(yè)務(wù)進(jìn)行試驗(yàn)性測(cè)試，這時(shí)需要業(yè)務(wù)專家和腳本專家一起工作。帶GUI界面軟件測(cè)試用例的設(shè)計(jì)核心問題是：需要精確區(qū)分正常測(cè)試用例和異常測(cè)試用例，按照先異常后正常的實(shí)際執(zhí)行方式，組織終的測(cè)試數(shù)據(jù)存放關(guān)系，一般合適的比例控制在異常75%—正常25%范圍內(nèi)。腳本專家需要快速處理對(duì)象識(shí)別庫(kù)，如果涉及到重定義則需要在指定文件中加以注明，因?yàn)檫@部分工作可被復(fù)用到后續(xù)的項(xiàng)目實(shí)施中，避免造成人力成本重復(fù)投入。通常實(shí)驗(yàn)性階段主要產(chǎn)生的問題是：
● 該階段是否會(huì)產(chǎn)生腳本框架?答案是否定的，首先自動(dòng)化測(cè)試不一定要有框架，框架產(chǎn)生的目的就是犧牲一部分腳本性能，而對(duì)測(cè)試數(shù)據(jù)進(jìn)行高效、有序的管理。不過在試驗(yàn)性階段可以考慮這個(gè)問題，如果框架是個(gè)平臺(tái)，那么我們可以在這個(gè)平臺(tái)上放置一些我們需要的單位腳本性能監(jiān)視器或者其他一些東西。由于 Winrunner的描述性編程機(jī)能不夠，那么在后續(xù)正常項(xiàng)目實(shí)施中，框架更多被定位于為可測(cè)量、可伸縮、可動(dòng)態(tài)、可智能解析測(cè)試數(shù)據(jù)的執(zhí)行管理。
● 該階段是否需要考慮測(cè)試數(shù)據(jù)存放問題?答案是否定的，沒有必要浪費(fèi)太多的時(shí)間在這種地方，一個(gè)文本文件或者干脆不要文件的數(shù)據(jù)存放形式都可以，關(guān)鍵是成本。
該階段對(duì)于人員的要求是什么?答案是人員需要精干，一個(gè)業(yè)務(wù)專家，一個(gè)腳本專家，一個(gè)統(tǒng)計(jì)專家足夠，自動(dòng)化測(cè)試實(shí)施非常注重績(jī)效比，績(jī)效比不夠根本沒必要執(zhí)行后續(xù)的項(xiàng)目，你必須通過實(shí)驗(yàn)性測(cè)試得出一個(gè)準(zhǔn)確的結(jié)論，就是重復(fù)執(zhí)行多少次腳本，總績(jī)效才可以由負(fù)轉(zhuǎn)正。
● 該階段是否需要考慮環(huán)境的問題?答案是的，在這之前就應(yīng)該安裝好虛擬系統(tǒng)了，如果腳本專家的一邊開著即時(shí)通訊工具一邊錄制腳本，我們認(rèn)為這是非常不專業(yè)的。系統(tǒng)環(huán)境的清潔程度如同醫(yī)院的手術(shù)室，需要提前對(duì)各種必須的軟件(例如殺毒軟件，網(wǎng)管軟件等)做好適應(yīng)性選擇，有干擾的，或者影響系統(tǒng)機(jī)能的堅(jiān)決卸載掉。
● 該階段的硬件是怎么規(guī)劃的?前端的測(cè)試主機(jī)需要有同時(shí)承受開2—3個(gè)虛擬系統(tǒng)的準(zhǔn)備，不能產(chǎn)生明顯的切換和操作停頓甚至系統(tǒng)假死。雖然 32位的 Windows XP系統(tǒng)不支持4G物理內(nèi)存，但是經(jīng)驗(yàn)告訴我們內(nèi)存容量多多益善，至于CPU和顯卡處于正常水平即可。后端使用的硬件需要穩(wěn)定，因?yàn)椴皇切阅軠y(cè)試所以不作太多要求，一切為了成本。
● 該階段的管理模式和輸出是什么?答案是沒有太復(fù)雜的管理模式，實(shí)驗(yàn)性評(píng)估一般都會(huì)在1周內(nèi)被關(guān)閉，重要的就是實(shí)施評(píng)估報(bào)告，報(bào)告內(nèi)容大致包含：周期定義、工具定型描述、應(yīng)用軟件描述、系統(tǒng)框架描述、可能采用的框架描述、可能遞交工件描述、可加入業(yè)務(wù)列表、預(yù)測(cè)腳本規(guī)模、
可實(shí)施技術(shù)分析、評(píng)估人/時(shí)分析、預(yù)測(cè)實(shí)際人/時(shí)分析、評(píng)估腳本價(jià)值、預(yù)測(cè)實(shí)際腳本價(jià)值、可能遇到的問題警告等，這些條目都必須一一做出詳實(shí)而且準(zhǔn)確的描述。
實(shí)驗(yàn)性評(píng)估結(jié)束后，需要確定自動(dòng)化測(cè)試實(shí)施項(xiàng)目的時(shí)間及周期里程碑，我們采用12周為一個(gè)周期里程碑，快速發(fā)布快速遞交的方式以確保整個(gè)測(cè)試項(xiàng)目的實(shí)施成功。在開始的1周內(nèi)，管理專家需要快速定義對(duì)象控制表、項(xiàng)目跟蹤表、需求跟蹤表、周/發(fā)布項(xiàng)目進(jìn)度、日/問題跟蹤表、配置管理須知，腳本專家需要快速定義代碼規(guī)范、腳本設(shè)計(jì)維護(hù)手冊(cè)、數(shù)據(jù)作用說明及填寫規(guī)范，環(huán)境專家需要快速定義虛擬環(huán)境配置手冊(cè)、維護(hù)與復(fù)制手冊(cè)，培訓(xùn)專家需要制定實(shí)施階段課程培訓(xùn)體系等，專家都是角色可復(fù)用，工作都是實(shí)打?qū)嵉?，需要認(rèn)真對(duì)待，缺一不可。
我們通常將項(xiàng)目在快要接近380個(gè)可操作對(duì)象或者腳本代碼接近25000行的時(shí)候稱之為一個(gè)“混亂點(diǎn)”，之所以稱為“混亂點(diǎn)”完全是這種項(xiàng)目執(zhí)行過程中的必然現(xiàn)象，如同飛機(jī)速度超過音速時(shí)產(chǎn)生的音障一樣，正確的對(duì)待和處理有助于后續(xù)項(xiàng)目實(shí)施的健康成長(zhǎng)，否則后果不堪設(shè)想。
● 經(jīng)典問題一、文檔混亂了。這里的文檔混亂并非指文檔丟失、殘缺或者缺少維護(hù)這些低級(jí)錯(cuò)誤，事實(shí)上這里的文檔混亂是多個(gè)文檔內(nèi)產(chǎn)生了部分內(nèi)容相同的冗余數(shù)據(jù)，且這些冗余數(shù)據(jù)在可控制范圍內(nèi)?！叭哂嗉磻卸琛保詫?duì)應(yīng)的解決方案就是將所有文檔轉(zhuǎn)交EPG團(tuán)隊(duì)，由專人看管做日終處理，只要不增加本團(tuán)隊(duì)的成本我們是非常樂于這么做的。
● 經(jīng)典問題二、培訓(xùn)熱度過高。為了確保腳本周遞交轉(zhuǎn)移速度，我們?cè)诿恐苣┬枰獙?duì)接應(yīng)團(tuán)隊(duì)做一定培訓(xùn)，很多人(非合作團(tuán)隊(duì))都想增加自己在這方面的知識(shí)，所以原來的2小時(shí)培訓(xùn)時(shí)間被延長(zhǎng)到4小時(shí)，原來一場(chǎng)25人小團(tuán)隊(duì)培訓(xùn)被擴(kuò)展為二場(chǎng)各180人的培訓(xùn)，很累。直接造成的后果就是很多人要內(nèi)部轉(zhuǎn)崗來我們團(tuán)隊(duì)，這也違背了“簡(jiǎn)單既是美”。
● 經(jīng)典問題三、腳本的增加突出了性能的缺失。一旦對(duì)象突破380 個(gè)(不包含描述性對(duì)象)，腳本突破25000行(不包含注釋及空行)，不優(yōu)化，那么在一臺(tái)機(jī)器上的綜合運(yùn)行時(shí)間超過了4個(gè)小時(shí)，所以對(duì)代碼優(yōu)化的工作在后續(xù)幾周的實(shí)施中急待解決。對(duì)于腳本性能調(diào)優(yōu)，需要綜合考慮語言特性、數(shù)據(jù)結(jié)構(gòu)、外調(diào)和對(duì)象識(shí)別處理，這里需要對(duì)TestPackage – TestSuite – TestCase的組合模式進(jìn)行事務(wù)級(jí)的時(shí)間分析，精確到毫秒。調(diào)優(yōu)的處理有多種，每個(gè)團(tuán)隊(duì)的方法各不一樣，經(jīng)過綜合處理，現(xiàn)在我們能做到35532行腳本、451個(gè)對(duì)象、37個(gè)虛擬對(duì)象，合計(jì)78個(gè)綜合處理包全部一臺(tái)機(jī)器上運(yùn)行，時(shí)間可控制在2小時(shí)之內(nèi)。繼續(xù)壓縮時(shí)間的資源投入大于產(chǎn)出，這不符合成本控制團(tuán)隊(duì)的初衷，所以終放棄。
● 經(jīng)典問題四、原來工具的函數(shù)有BUG。實(shí)際上大規(guī)模的代碼運(yùn)用對(duì)測(cè)試工具本身也是一種考驗(yàn)，一切軟件皆有問題，隨著時(shí)間的推移會(huì)逐漸暴露出來。我們發(fā)現(xiàn)了測(cè)試工具部分函數(shù)的會(huì)在某些特定環(huán)境下出現(xiàn)問題，所以替換這些函數(shù)是非常必要的。替換的方法是，使用第三方開發(fā)工具(例如VC)開發(fā)出可被腳本直接調(diào)用的函數(shù)(例如各種動(dòng)態(tài)庫(kù)技術(shù))，以替換原自帶問題函數(shù)，這樣既增加了整體代碼的穩(wěn)定性，又提升了團(tuán)隊(duì)的研發(fā)能力。例如Winrunner偶爾出現(xiàn)的菜單丟失的問題，都可用自研發(fā)函數(shù)給予解決。
另外測(cè)試工具本身提供的語言也可能存在某些局限性，所以測(cè)試團(tuán)隊(duì)具備自我開發(fā)能力也關(guān)系著項(xiàng)目是否能被順利實(shí)施。
● 經(jīng)典問題五、腳本不動(dòng)了。實(shí)際上這是讓人討厭的問題，可能涉及的方面非常多，例如系統(tǒng)交互、網(wǎng)絡(luò)環(huán)境、本機(jī)環(huán)境、軟件沖突等等，我們總結(jié)了一條處理該類型事件的方法，先排除系統(tǒng)本身，排除干擾軟件，再分析比和對(duì)卡死位置數(shù)據(jù)，后分析腳本本身，例如我們發(fā)現(xiàn)部分問題跟字符處理函數(shù)有關(guān)，這對(duì)提高腳本本身的健壯，提出了很高的要求。
項(xiàng)目進(jìn)行到距離里程碑后一周，大部分的問題列表需要被提前被關(guān)閉，相關(guān)遞交工件需要被整理評(píng)審，腳本經(jīng)過驗(yàn)證被終集成轉(zhuǎn)交，這里都需要配置管理來提供良好的控制環(huán)境。必須指明的是，日腳本構(gòu)建和測(cè)試是貫穿整個(gè)項(xiàng)目周期的，這種做法能使腳本的開發(fā)狀態(tài)得到頻繁的更新，以及盡早發(fā)現(xiàn)設(shè)計(jì)和集成的缺陷。為了充分利用時(shí)間與設(shè)備資源，夜晚21點(diǎn)后，腳本的自動(dòng)執(zhí)行測(cè)試(這里多數(shù)指的是系統(tǒng)測(cè)試或回歸測(cè)試)是一個(gè)非常行之有效的方法。一切都順利的話，等到第二天上班時(shí)，測(cè)試結(jié)果就已經(jīng)在相關(guān)人員的郵箱里面了，通過這份報(bào)告，你可以知道那些腳本是必須修改的，如果不太清楚還有一份更詳細(xì)的截圖列表輔助定位，準(zhǔn)確告訴你當(dāng)時(shí)軟件究竟出現(xiàn)了什么現(xiàn)象導(dǎo)致了問題的產(chǎn)生。
終該項(xiàng)目第一階段在12周且延長(zhǎng)6個(gè)小時(shí)后被準(zhǔn)確的關(guān)閉，并且通過了嚴(yán)格的部門驗(yàn)收，6人參與到這個(gè)項(xiàng)目中，合計(jì)2916個(gè)有效工作時(shí)。經(jīng)過計(jì)算每行代碼價(jià)值為1.77元，總的來說還算是成功的，那么接下來第二個(gè)階段里面，我們能否將每行代碼價(jià)值控制在1元以下，請(qǐng)各位拭目以待。
現(xiàn)在自動(dòng)化測(cè)試工具很多，商業(yè)的或者開源的，以對(duì)象識(shí)別為基礎(chǔ)的或者以語言特性為基礎(chǔ)的等等。在挑選的時(shí)候，首先我們要明確被操作軟件的范疇和特性，可預(yù)知風(fēng)險(xiǎn)，培訓(xùn)潛在成本及是否具備被虛擬化等一系列問題，這些問題可制成標(biāo)準(zhǔn)檢查列表，以便確定一個(gè)解決一個(gè)。在本次自動(dòng)化測(cè)試實(shí)施中，首先可知的是被測(cè)試軟件屬于行業(yè)金融軟件，使用Borland C++Builder語言開發(fā)，測(cè)試范疇鎖定在軟件前臺(tái)需配對(duì)后臺(tái)數(shù)據(jù)驗(yàn)證，前臺(tái)由RedHat Linux服務(wù)端、自研發(fā)中間件和Oracle數(shù)據(jù)庫(kù)支撐。一般來說，這種軟件應(yīng)用架構(gòu)比較清晰，但是GUI層使用了大量的非標(biāo)準(zhǔn)第三方控件，有可能會(huì)導(dǎo)致部分對(duì)象無法捕獲造成實(shí)施困難，所以在進(jìn)入真正的實(shí)施前作充分、快速的實(shí)驗(yàn)性評(píng)估是非常重要的。
職業(yè)化的自動(dòng)化測(cè)試團(tuán)隊(duì)，應(yīng)當(dāng)非常熟悉當(dāng)前主流的商業(yè)或者開源測(cè)試工具，這種團(tuán)隊(duì)的定義是：技術(shù)讓位與成本控制，快速實(shí)施且能快速遞交，精確控制每12周為一周期，項(xiàng)目延時(shí)誤差小于2天?？紤]到腳本會(huì)被移交給其他團(tuán)隊(duì)執(zhí)行，所以我們選擇了目前在國(guó)內(nèi)應(yīng)用范圍比較廣、相關(guān)技術(shù)資料比較豐富的HP Winrunner和HP QuickTestPro。第一個(gè)被評(píng)估的是QuickTestPro 9.5版本不帶任何插件，結(jié)果大量的GUI對(duì)象無法被捕捉，不能捕捉意味著不能被操作，所以團(tuán)隊(duì)快速轉(zhuǎn)換到Winrunner 9.2版本不帶任何插件，實(shí)驗(yàn)結(jié)果是基本可以正確識(shí)別和捕獲我們所要操作的GUI對(duì)象，滿足了對(duì)工具的需求。其實(shí)QuickTestPro 9.5版本帶Delphi插件也可大大增加捕獲率，但是使用插件違反了團(tuán)隊(duì)定義的工具應(yīng)用管理規(guī)范，也不符合“有對(duì)象即可操作”的強(qiáng)硬編程作風(fēng)。
在工具定義后，需要立刻選擇2組典型業(yè)務(wù)進(jìn)行試驗(yàn)性測(cè)試，這時(shí)需要業(yè)務(wù)專家和腳本專家一起工作。帶GUI界面軟件測(cè)試用例的設(shè)計(jì)核心問題是：需要精確區(qū)分正常測(cè)試用例和異常測(cè)試用例，按照先異常后正常的實(shí)際執(zhí)行方式，組織終的測(cè)試數(shù)據(jù)存放關(guān)系，一般合適的比例控制在異常75%—正常25%范圍內(nèi)。腳本專家需要快速處理對(duì)象識(shí)別庫(kù)，如果涉及到重定義則需要在指定文件中加以注明，因?yàn)檫@部分工作可被復(fù)用到后續(xù)的項(xiàng)目實(shí)施中，避免造成人力成本重復(fù)投入。通常實(shí)驗(yàn)性階段主要產(chǎn)生的問題是：
● 該階段是否會(huì)產(chǎn)生腳本框架?答案是否定的，首先自動(dòng)化測(cè)試不一定要有框架，框架產(chǎn)生的目的就是犧牲一部分腳本性能，而對(duì)測(cè)試數(shù)據(jù)進(jìn)行高效、有序的管理。不過在試驗(yàn)性階段可以考慮這個(gè)問題，如果框架是個(gè)平臺(tái)，那么我們可以在這個(gè)平臺(tái)上放置一些我們需要的單位腳本性能監(jiān)視器或者其他一些東西。由于 Winrunner的描述性編程機(jī)能不夠，那么在后續(xù)正常項(xiàng)目實(shí)施中，框架更多被定位于為可測(cè)量、可伸縮、可動(dòng)態(tài)、可智能解析測(cè)試數(shù)據(jù)的執(zhí)行管理。
● 該階段是否需要考慮測(cè)試數(shù)據(jù)存放問題?答案是否定的，沒有必要浪費(fèi)太多的時(shí)間在這種地方，一個(gè)文本文件或者干脆不要文件的數(shù)據(jù)存放形式都可以，關(guān)鍵是成本。
該階段對(duì)于人員的要求是什么?答案是人員需要精干，一個(gè)業(yè)務(wù)專家，一個(gè)腳本專家，一個(gè)統(tǒng)計(jì)專家足夠，自動(dòng)化測(cè)試實(shí)施非常注重績(jī)效比，績(jī)效比不夠根本沒必要執(zhí)行后續(xù)的項(xiàng)目，你必須通過實(shí)驗(yàn)性測(cè)試得出一個(gè)準(zhǔn)確的結(jié)論，就是重復(fù)執(zhí)行多少次腳本，總績(jī)效才可以由負(fù)轉(zhuǎn)正。
● 該階段是否需要考慮環(huán)境的問題?答案是的，在這之前就應(yīng)該安裝好虛擬系統(tǒng)了，如果腳本專家的一邊開著即時(shí)通訊工具一邊錄制腳本，我們認(rèn)為這是非常不專業(yè)的。系統(tǒng)環(huán)境的清潔程度如同醫(yī)院的手術(shù)室，需要提前對(duì)各種必須的軟件(例如殺毒軟件，網(wǎng)管軟件等)做好適應(yīng)性選擇，有干擾的，或者影響系統(tǒng)機(jī)能的堅(jiān)決卸載掉。
● 該階段的硬件是怎么規(guī)劃的?前端的測(cè)試主機(jī)需要有同時(shí)承受開2—3個(gè)虛擬系統(tǒng)的準(zhǔn)備，不能產(chǎn)生明顯的切換和操作停頓甚至系統(tǒng)假死。雖然 32位的 Windows XP系統(tǒng)不支持4G物理內(nèi)存，但是經(jīng)驗(yàn)告訴我們內(nèi)存容量多多益善，至于CPU和顯卡處于正常水平即可。后端使用的硬件需要穩(wěn)定，因?yàn)椴皇切阅軠y(cè)試所以不作太多要求，一切為了成本。
● 該階段的管理模式和輸出是什么?答案是沒有太復(fù)雜的管理模式，實(shí)驗(yàn)性評(píng)估一般都會(huì)在1周內(nèi)被關(guān)閉，重要的就是實(shí)施評(píng)估報(bào)告，報(bào)告內(nèi)容大致包含：周期定義、工具定型描述、應(yīng)用軟件描述、系統(tǒng)框架描述、可能采用的框架描述、可能遞交工件描述、可加入業(yè)務(wù)列表、預(yù)測(cè)腳本規(guī)模、
可實(shí)施技術(shù)分析、評(píng)估人/時(shí)分析、預(yù)測(cè)實(shí)際人/時(shí)分析、評(píng)估腳本價(jià)值、預(yù)測(cè)實(shí)際腳本價(jià)值、可能遇到的問題警告等，這些條目都必須一一做出詳實(shí)而且準(zhǔn)確的描述。
實(shí)驗(yàn)性評(píng)估結(jié)束后，需要確定自動(dòng)化測(cè)試實(shí)施項(xiàng)目的時(shí)間及周期里程碑，我們采用12周為一個(gè)周期里程碑，快速發(fā)布快速遞交的方式以確保整個(gè)測(cè)試項(xiàng)目的實(shí)施成功。在開始的1周內(nèi)，管理專家需要快速定義對(duì)象控制表、項(xiàng)目跟蹤表、需求跟蹤表、周/發(fā)布項(xiàng)目進(jìn)度、日/問題跟蹤表、配置管理須知，腳本專家需要快速定義代碼規(guī)范、腳本設(shè)計(jì)維護(hù)手冊(cè)、數(shù)據(jù)作用說明及填寫規(guī)范，環(huán)境專家需要快速定義虛擬環(huán)境配置手冊(cè)、維護(hù)與復(fù)制手冊(cè)，培訓(xùn)專家需要制定實(shí)施階段課程培訓(xùn)體系等，專家都是角色可復(fù)用，工作都是實(shí)打?qū)嵉?，需要認(rèn)真對(duì)待，缺一不可。
我們通常將項(xiàng)目在快要接近380個(gè)可操作對(duì)象或者腳本代碼接近25000行的時(shí)候稱之為一個(gè)“混亂點(diǎn)”，之所以稱為“混亂點(diǎn)”完全是這種項(xiàng)目執(zhí)行過程中的必然現(xiàn)象，如同飛機(jī)速度超過音速時(shí)產(chǎn)生的音障一樣，正確的對(duì)待和處理有助于后續(xù)項(xiàng)目實(shí)施的健康成長(zhǎng)，否則后果不堪設(shè)想。
● 經(jīng)典問題一、文檔混亂了。這里的文檔混亂并非指文檔丟失、殘缺或者缺少維護(hù)這些低級(jí)錯(cuò)誤，事實(shí)上這里的文檔混亂是多個(gè)文檔內(nèi)產(chǎn)生了部分內(nèi)容相同的冗余數(shù)據(jù)，且這些冗余數(shù)據(jù)在可控制范圍內(nèi)?！叭哂嗉磻卸琛保詫?duì)應(yīng)的解決方案就是將所有文檔轉(zhuǎn)交EPG團(tuán)隊(duì)，由專人看管做日終處理，只要不增加本團(tuán)隊(duì)的成本我們是非常樂于這么做的。
● 經(jīng)典問題二、培訓(xùn)熱度過高。為了確保腳本周遞交轉(zhuǎn)移速度，我們?cè)诿恐苣┬枰獙?duì)接應(yīng)團(tuán)隊(duì)做一定培訓(xùn)，很多人(非合作團(tuán)隊(duì))都想增加自己在這方面的知識(shí)，所以原來的2小時(shí)培訓(xùn)時(shí)間被延長(zhǎng)到4小時(shí)，原來一場(chǎng)25人小團(tuán)隊(duì)培訓(xùn)被擴(kuò)展為二場(chǎng)各180人的培訓(xùn)，很累。直接造成的后果就是很多人要內(nèi)部轉(zhuǎn)崗來我們團(tuán)隊(duì)，這也違背了“簡(jiǎn)單既是美”。
● 經(jīng)典問題三、腳本的增加突出了性能的缺失。一旦對(duì)象突破380 個(gè)(不包含描述性對(duì)象)，腳本突破25000行(不包含注釋及空行)，不優(yōu)化，那么在一臺(tái)機(jī)器上的綜合運(yùn)行時(shí)間超過了4個(gè)小時(shí)，所以對(duì)代碼優(yōu)化的工作在后續(xù)幾周的實(shí)施中急待解決。對(duì)于腳本性能調(diào)優(yōu)，需要綜合考慮語言特性、數(shù)據(jù)結(jié)構(gòu)、外調(diào)和對(duì)象識(shí)別處理，這里需要對(duì)TestPackage – TestSuite – TestCase的組合模式進(jìn)行事務(wù)級(jí)的時(shí)間分析，精確到毫秒。調(diào)優(yōu)的處理有多種，每個(gè)團(tuán)隊(duì)的方法各不一樣，經(jīng)過綜合處理，現(xiàn)在我們能做到35532行腳本、451個(gè)對(duì)象、37個(gè)虛擬對(duì)象，合計(jì)78個(gè)綜合處理包全部一臺(tái)機(jī)器上運(yùn)行，時(shí)間可控制在2小時(shí)之內(nèi)。繼續(xù)壓縮時(shí)間的資源投入大于產(chǎn)出，這不符合成本控制團(tuán)隊(duì)的初衷，所以終放棄。
● 經(jīng)典問題四、原來工具的函數(shù)有BUG。實(shí)際上大規(guī)模的代碼運(yùn)用對(duì)測(cè)試工具本身也是一種考驗(yàn)，一切軟件皆有問題，隨著時(shí)間的推移會(huì)逐漸暴露出來。我們發(fā)現(xiàn)了測(cè)試工具部分函數(shù)的會(huì)在某些特定環(huán)境下出現(xiàn)問題，所以替換這些函數(shù)是非常必要的。替換的方法是，使用第三方開發(fā)工具(例如VC)開發(fā)出可被腳本直接調(diào)用的函數(shù)(例如各種動(dòng)態(tài)庫(kù)技術(shù))，以替換原自帶問題函數(shù)，這樣既增加了整體代碼的穩(wěn)定性，又提升了團(tuán)隊(duì)的研發(fā)能力。例如Winrunner偶爾出現(xiàn)的菜單丟失的問題，都可用自研發(fā)函數(shù)給予解決。
另外測(cè)試工具本身提供的語言也可能存在某些局限性，所以測(cè)試團(tuán)隊(duì)具備自我開發(fā)能力也關(guān)系著項(xiàng)目是否能被順利實(shí)施。
● 經(jīng)典問題五、腳本不動(dòng)了。實(shí)際上這是讓人討厭的問題，可能涉及的方面非常多，例如系統(tǒng)交互、網(wǎng)絡(luò)環(huán)境、本機(jī)環(huán)境、軟件沖突等等，我們總結(jié)了一條處理該類型事件的方法，先排除系統(tǒng)本身，排除干擾軟件，再分析比和對(duì)卡死位置數(shù)據(jù)，后分析腳本本身，例如我們發(fā)現(xiàn)部分問題跟字符處理函數(shù)有關(guān)，這對(duì)提高腳本本身的健壯，提出了很高的要求。
項(xiàng)目進(jìn)行到距離里程碑后一周，大部分的問題列表需要被提前被關(guān)閉，相關(guān)遞交工件需要被整理評(píng)審，腳本經(jīng)過驗(yàn)證被終集成轉(zhuǎn)交，這里都需要配置管理來提供良好的控制環(huán)境。必須指明的是，日腳本構(gòu)建和測(cè)試是貫穿整個(gè)項(xiàng)目周期的，這種做法能使腳本的開發(fā)狀態(tài)得到頻繁的更新，以及盡早發(fā)現(xiàn)設(shè)計(jì)和集成的缺陷。為了充分利用時(shí)間與設(shè)備資源，夜晚21點(diǎn)后，腳本的自動(dòng)執(zhí)行測(cè)試(這里多數(shù)指的是系統(tǒng)測(cè)試或回歸測(cè)試)是一個(gè)非常行之有效的方法。一切都順利的話，等到第二天上班時(shí)，測(cè)試結(jié)果就已經(jīng)在相關(guān)人員的郵箱里面了，通過這份報(bào)告，你可以知道那些腳本是必須修改的，如果不太清楚還有一份更詳細(xì)的截圖列表輔助定位，準(zhǔn)確告訴你當(dāng)時(shí)軟件究竟出現(xiàn)了什么現(xiàn)象導(dǎo)致了問題的產(chǎn)生。
終該項(xiàng)目第一階段在12周且延長(zhǎng)6個(gè)小時(shí)后被準(zhǔn)確的關(guān)閉，并且通過了嚴(yán)格的部門驗(yàn)收，6人參與到這個(gè)項(xiàng)目中，合計(jì)2916個(gè)有效工作時(shí)。經(jīng)過計(jì)算每行代碼價(jià)值為1.77元，總的來說還算是成功的，那么接下來第二個(gè)階段里面，我們能否將每行代碼價(jià)值控制在1元以下，請(qǐng)各位拭目以待。