軟件測試中的一個項目的自動化測試實踐
隨著社會的不斷發展和信息化的不斷普及,各種軟件越來越多,在日常生活中也起著越來越重要的作用,再加上客觀系統的復雜性,無論經驗多豐富的開發人員、無論采用哪種開發模型開發出來的軟件,每個階段的技術復審也不可能毫不遺漏地查出和糾正所有的錯誤,因此如何才能把新的軟件做得更穩定、錯誤更少呢?測試! 統計表明,在典型的軟件開發項目中,軟件測試工作量往往占軟件開發總工作量的40%以上。
測試是軟件能否通向市場的最后也是最重要的一關。傳統的測試方法是手工測試,目前大部分都是采用此方法,其特點就是簡單,但是它存在的問題非常多。手工測試可能引入人為的輸入錯誤,尤其在數據量大的情況下;另外大量重復性的手工測試可能成本較高,如果考慮軟件發生改動而需要重復手工測試的情況,這個成本還會更高;沒有辦法對組件進行隔離的測試,從而導致發現問題和解決問題的成本都太高。在很多項目中,測試人員的所有任務實際上都是手動處理的,而實際上有很大一部分重復性強的測試工作是可以獨立出來自動實現的。
針對手工測試的缺點,自動化測試應運而生。相比手工測試,自動化測試的優勢很多;規范測試流程,提高測試效率、測試覆蓋率等。很多人對自動化測試存在誤區,把其理解為找到一種自動化測試工具,把它應用到軟件工程項目中,自動化測試工具只是被看作是一種錄制和回放的工具。事實上自動化測試遠不止這么簡單,錄制和回放僅是自動化測試中的最低級別。目前常把自動化測試分為5個級別,如圖l所示。
現在常用的是基于數據驅動的測試,它是以數據來控制自動化測試的流程和動作的測試,其中數據是獨立于測試用例腳本的,通常以文本文件形式、Excel文件形式、XML文件等形式存在。
項目上線,有時間總結一下當前的項目,對自己而言,一直是一個學習的過程。本篇總結我們的測試實踐。本文分5部分,分別是:項目背景、系統架構與模塊劃分、我們的測試實踐、自動化測試在項目中的價值與對自動化測試的進一步思考。
一、項目背景
所有對項目的介紹一定是從客戶開始。
客戶:我們的客戶是一家全球領先的時尚內容提供商,通過遍布全球的員工,客戶每天獲取大量關于時裝發布、產品設計、街邊流行、城市熱點等信息,這些信息的絕大部分以圖片的形式上傳到公司服務器,然后由專職編輯對這些圖片進行整理和歸類(打標簽),最后再由設計人員根據這些信息書寫分析報表。
關鍵內容:分類細致的海量高清圖片和具有前瞻性的分析報表。
商業模式:網站,行業內用戶訂閱-付費。
客戶面臨的問題:同質化競爭、客戶流失。
新系統的關鍵詞:CMS、更精確的內容分類、更好的全文檢索、更好的用戶體驗(更有表現力的內容展現)、更快的內容發布。
二、系統架構與模塊劃分
1、REST的架構風格
系統采用了Sling作為WEB框架,JCR作為了底層內容存儲框架。
系統的特點:
URI唯一標識資源
通過URI能夠直接映射到JCR節點,例如http://localhost:80/content/section/news.html能夠映射到JCR里的/content/section/news節點
GET/POST/DELETE標準方法對資源進行操作
支持標準方法對資源的直接操作
資源的多重表述
同一資源可以存在多種表述形式,例如http://localhost:80/content/section/news.html展現網頁,
http://localhost:80/content/section/news.json展現資源信息的JSON描述,
http://localhost:80/content/section/news.pdf展現網頁的PDF。
服務器端的無狀態
通過JS獲取當前用戶信息并緩存在客戶端。
2、系統分層
系統分為四層:JS、Servlet、Domain Model和JCR。
因為JCR提供了一套節點模型,所以Domain Model是在節點模型上的行為增強,例如所有對圖片節點的操作我們封裝在Asset領域模型里。
3、程序劃分
程序分為兩個大的模塊:Migration和Bundles。為什么叫Bundles?因為Sling使用了OSGI框架Felix。
Migration負責導入客戶的遺留數據到新系統。之前客戶的CMS運行已有10多年的時間,積累有大量數據。主要是各種類型的報表和圖片。
Bundles實現系統功能。主要包括了定義報表模板、定義報表各種所見即所得的展現組件、實現對圖片的管理、搜索(包括基于圖片的可視化搜索)和其他七七八八。
三、測試實踐
1、Migration的測試
自動化測試
對Migration,我們采用了TDD的方式。
輸入是客戶實際提供的xml文件,輸出是JCR里的節點。測試環境的搭建主要是在本地建立起Jackrabbit實例。我們的工作方式是這樣:每天早上領到一張migration故事卡,然后先寫一個xml到jcr節點的集成測試描述出該類型報表的功能需求,接下來就是讓這個測試通過。經過開始階段的熟悉過程,我們的速度保持在一對Pair一天一種報表類型的導入。
原文轉自:http://www.anti-gravitydesign.com