軟體架構中對於可自動化測試的設計思考

2021-05-08 07:18:25 字數 2162 閱讀 1968

在過去的一年,專案組推行自動化測試

工作

,從目前的實際成果上看,感覺效果不是很理想。我們的系統是基於j2ee b/s架構的軟體系統,目前的問題主要具體體現在以下幾個方面:

1. 自動化用例指令碼編寫複雜費時。以前乙個人一天只能寫6個用例,目前一天最多也只能編寫20個用例。乙個story的開發周期是3到5天(含簡單設計、編碼及開發自測)。乙個story平均有80個測試用例,測試人員的精力大部分都要花在自動化指令碼的編寫上,而不是更應該關注的「測試用例設計」上。

2. 基於b/s的自動化用例指令碼編寫複雜。雖然有工具支撐,但目前的前台介面技術也是日新月異,對於一些介面元素工具不能很好的支撐,有針對工具的二次開發工作量。且很多複雜的組合介面,即使進行二次開發也無法很好的支撐。基於介面驅動的自動化測試很容易遇到瓶頸與阻塞。

3. 受需求影響,介面不穩定,經常變化。這點可能不具有普遍意義,但目前我們的系統受需求影響較大,介面經常變化,介面穩定度不高。這也導致每個新版本都會導致大量的自動化用例指令碼維護工作量。

4. 開發與測試配合不順。由於乙個story只有開發完畢後,介面才會穩定下來(在當前版本內),此時,測試人員已無太多的時間去進行自動化測試指令碼的編寫。這也是導致自動化用例覆蓋率不高的原因。

5. 基於介面的自動化指令碼執行效率低。大致80多個自動化用例就需要執行5個小時。如果2000多個用例都進行了自動化,那麼執行時間將非常不可接受。根本無法做到每日持續整合的快速、完整測試。

6. 軟體架構

上的問題。另外,我個人認為更為關鍵的問題是,現有的自動化測試都是基於現有的系統架構開展的。很多解決方案都是基於現有架構做適配的。也就是說,系統的架構從一開始就沒有考慮到對可自動化測試的支撐考慮。並且,我認為在架構上進行適當的重構,甚至是可以解決前面5個主要問題中的大部分場景。(系統架構是我在05年中制定的,幾年下來,已不能適應最新的要求了)

基於以上目前存在的問題,初步設定了以下自動化測試優化的目標:

*目標一:自動化測試用例覆蓋率要能提高到至少80%以上,且所有的自動化測試指令碼的執行時間能控制在5小時以內;

*目標三:在story的開發階段,編碼及自動化用例指令碼能同步進行,story開發完畢後即可開始每天持續的自動化測試;

*目標四:解決b/s架構下介面不穩定,自動化用例指令碼維護工作量大的問題;

在前文中,主要是描述了一下目前在自動化測試工作開展中主要面臨的問題與困難,並設定了乙個初步的目標。在接下來的文章中,我將重點闡述一下在系統架構方面應該如何考慮自動化測試要求,即dfx中的可測試性要求。

在對系統架構優化和動手之前,我們首先要做的是對自動化測試進行深入的理解。對基於b/s架構的j2ee系統,大部分人在做自動化測試時,基本都是在做和研究如何從介面驅動進行一次業務測試。這其實是一種誤區,自動化測試是需要分層分級的。我們可以從下表中看出測試的分類:

測試型別白盒/黑盒

st黑盒

it黑盒

ut白盒

* ut是單元測試,是基於方法級的,屬於白盒測試;

* it是整合測試,是基於業務服務級的,屬於黑盒測試;層次要比ut高;

* st是系統測試,是基於業務服務及功能使用場景下的測試,也是屬於黑盒測試;層次要比it高;

ut的測試關注主體是開發人員,而且也每什麼難度,ut的自動化也非常容易,這裡就不再闡述。

如果軟體架構不清晰,那麼it和st之間的界限將會比較模糊,自動化測試往往就會跳過it直接進入st測試自動化中。而st是基於複雜使用場景下的測試,這又導致st的自動化指令碼編寫異常複雜,且易隨著場景的變化而變化。

舉個例子:各位可以通過登陸www.blogger.com

登陸自己的部落格撰寫博文,也可以iphone上的部落格客戶端方式來寫博文,其使用場景在例子中就有兩種:1、登陸blogger提交博文 2、通過客戶端程式提交博文。並且,更為頭疼的是,我們不知道這種使用場景還有多少,這是無法窮舉的。但google是怎麼做到無論使用場景有多少,形式如何,最終仍能提供優質、穩定的部落格服務呢?

從上面這個例子中,你是否悟出了些什麼呢?

軟體測試自動化

只有當系統的介面元素不會頻繁的變化 系統功能基本穩定,已經通過一至兩輪的手工測試,確定系統不會存在重大缺陷時,才可以考慮自動化的實施。使用自動化測試工具代替手工完成一些測試任務,現在國內主流的測試工具是loadrunner 和qtp。lr 效能測試工具 和qtp 自動化測試工具 的區別 1 lr 基...

appium python自動化測試連線裝置

1.命令獲取裝置的udid開啟cmd,輸入adb devices,通過adb命令獲取裝置的udid,devicename為裝置名隨便填什麼都可以,主要是udid一定要正確要不然會報錯 adb shell pm list package grep 包名的模糊查詢 在cmd中輸入aapt dump ba...

軟體測試之自動化測試

自動化測試的優勢 能夠極大地提公升測試的效率,測試人員可以迅速地在指定平台部署測試指令碼且對相應功能進行測試。弱化 了軟體測試人員個體差異對測試結果的影響。提高整個測試團隊的技能水平。自動化測試的缺陷 自動化測試的缺陷在於 總是按照既定的流程往下走,不能像人一樣隨機應變。一旦功能發生變動,就需要重新...