論系統測試技術及應用

論系統測試技術及應用

原創 微笑的螞蟻人 開源測試聯盟 今天
論系統測試技術及應用

摘要：
2017年7月，我作為專案負責人，參加了某銀行的統計資料釋出系統建設專案，該專案合同金額200萬元，合同工期為半年，該系統的主要目標是為該行建設企業級的資料統計、分析、釋出平臺，實現定製化的資料應用、分析、展示功能；實現靈活的綜合查詢分析、明細資料查詢、固定報表展示、移動裝置資料展示、風險分析、自助取數等功能，達到“統一資料來源、統一資料口徑、統一資料出口”的資料管理目標。
本文結合本人在該專案中的實踐， 討論了我們在單元測試、功能測試、整合測試和效能測試中針對應用系統和ETL指標加工採取的不同的測試措施和策略，並重點討論了效能測試的型別和在如何在專案中實踐這些效能測試型別。

正文：
某銀行在各項經營活動中積累了大量資料資源，這些資料除了支援銀行生產業務流程運轉之外，也越來越多地被用於支撐監管報送、精準營銷、戰略決策、風險控制、績效考核等運營管理和決策過程的資料分析需求。為了滿足業務部門和管理人員不斷增長的報表資料需求，為決策分析提供依據，反映全行業務發展情況，識別和監測風險狀況，迫切需要規劃和建立科學、規範、易於擴充套件、靈活性強的統計資料釋出平臺，進一步完善全行報表體系，降低該行報表開發成本和難度，縮短報表開發週期，規範報表使用流程，降低管理與維護複雜度，實現統計資料集中及統計報表統一、規範管理。
2017年7月，我作為專案負責人，參與並主導了該銀行的統計資料釋出平臺專案，該專案合同金額230萬元，實施週期為半年。本專案產品架構基於JAVA開發的BS架構，資料庫平臺是oracle11g，中介軟體為weblogic，報表展現工具採用國內知名的SMARTBI產品，排程工具為國內產品TASKCTL,資料採集工具採用開源的Kettle。
我們在IBM完全生命週期測試模型的基礎上，根據本專案的具體特點和要求，結合成本效率進行了裁剪，形成本專案的測試策略、總體測試計劃和詳細測試計劃，並得到了行方技術部門的認可。整體劃分為單元測試、功能測試、整合測試、效能測試和驗收測試。驗收測試主要由行方業務人員進行，因此本文重點討論前面4個階段的測試。
一、單元測試階段
分為應用系統測試和ETL開發單元測試。
應用系統測試由於是用java開發，所以採用了JUNIT進行單元測試，由於本專案是基於標準產品的二次開發，類的數量不多，因此我們要求開發人員對每個新開發的類都要寫對應的測試類，測試通過後需要寫單元測試報告，並要求組內人員交叉檢查執行。
ETL開發是採用perl指令碼+儲存過程的方式進行開發，單元測試階段主要採用公司自主研發的ETL開發自動化測試工具，通過進行一定的配置，可對ETL指令碼進行自動化執行，可進行空值檢查、主鍵重複檢查等。
二、 功能測試階段
由於本系統既要在pc端展示，同時也需要在移動端進行展示，因此要求應用系統的功能測試主要通過編寫一份測試案例，能在多個終端執行。我們使用公司自主研發的基於STAF自動化測試框架的測試工具進行功能測試，確保頁面功能在跨平臺，如PC端、手機安卓端、手機蘋果端都能執行正常，並確保在各個終端的連結跳轉都是符合預期的。
三、整合測試階段
整合階段，需要將每個ETL作業配置在排程工具上，因此整合測試階段主要測試排程作業是否按照各種序列、並行機制分別執行，確保依賴作業的先後順序執行。
本階段另一個測試重點是測試資料加工的準確性。主要採用以下幾種測試手段：1、每個欄位的值域範圍測試，譬如某個指標的歷史波動範圍在100萬~300萬之間，那麼加工後的指標就不應該超過這個範圍。2、藉助於業務經驗，採用總分比對的方式。銀行一般有兩本賬，分戶賬和彙總賬，通過按照機構、科目分類從明細彙總後，應當和現有的總賬指標一致。以上測試時都可用公司自主研發的ETL測試工具，在上面配置校驗規則後進行測試執行。另外，測試資料的完整性是確保資料準確性的關鍵所在，因此我們在測試案例編寫過程中便同步進行測試資料的申請。
對於資訊類系統，資料指標的正確性是重中之重，以往專案中，由於對資料準確性測試不充分，導致試執行階段不斷返工，不僅增加了開發人月投入，還導致了驗收期的延長。
四、效能測試
效能測試的目的是驗證軟體系統是否能夠達到使用者提出的效能指標，同時發現軟體系統中存在的效能瓶頸，並優化軟體，最後起到優化系統的目的。具體來說，包括以下四個方面。（1）發現缺陷：軟體的某些缺陷與軟體效能密切相關，針對這些缺陷的測試一般需要伴隨著效能測試進行。 （2）效能調優：與除錯不同，效能調優並不一定針對發現的效能缺陷，也可能是為了更好地發揮系統的潛能。 （3）評估系統的能力：軟體效能測試不僅需要測試軟體在規定條件下是否滿足效能需求，往往還需要測試能夠滿足效能需求的條件極限。（4）驗證穩定性和可靠性：在一定負載下測試一定的時間，是評估系統穩定性和可靠性是否滿足要求的唯一方法。
效能測試型別包括： 基準測試：在給系統施加較低壓力時，檢視系統的執行狀況並記錄相關數做為基礎參考； 負載測試：是指對系統不斷地增加壓力或增加一定壓力下的持續時間，直到系統的某項或多項效能指標達到安全臨界值， 例如某種資源已經達到飽和狀態等； 壓力測試：壓力測試是評估系統處於或超過預期負載時系統的執行情況，關注點在於系統在峰值負載或超出最大載荷情況下的處理能力；穩定性測試：在給系統載入一定業務壓力的情況下，使系統執行一段時間，以此檢測系統是否穩定。 併發測試：測試多個使用者同時訪問同一個應用、同一個模組或者資料記錄時是否存在死鎖或者其他效能問題，
專案實際中，我們採用RoadRunner作為效能測試工具。基準測試方面，我們主要測試系統在使用者登入數處於非月初正常水平下，系統的各項執行指標。將各項指標進行記錄作為參考。在月初，系統使用者數會有一個激增的過程，主要是因為月初為各業務部門進行資料統計報送的高併發期，因此需要基於這個使用者數量再加上未來5年內該行業務部門統計人員增加的預估情況進行負載測試和壓力測試，我們要求系統的負載測試能至少10個工作日的時間，壓力測試要求系統執行的各項指標不能低於基準測試的指標的80%。這些基準指標中，我們重點關注資料查詢響應效率指標，要求1千萬級記錄數以下的表查詢響應時間為1秒以內，1千萬級~3千萬級記錄數的查詢響應時間為3秒以內,3千萬~6千萬為6秒以內。同時，在測試過程中，還要及時發現ELT作業執行時間超過基準指標的作業進行整改，避免了這些作業在上生產後由於執行緩慢導致整體時間視窗延長。
2017年12月，本專案歷時半年，在雙方專案領導的大力支援下，在雙方專案組成員的共同持續奮戰下，專案最終成功實施完成並順利驗收，客戶的高層領導在手機移動端看到了準確資料組織的業務指標，而且介面美觀、功能流暢，因此高度認可，於是客戶的科技部門給我們公司發來了表揚信，並與公司快速簽約專案的二期建設。本專案的成功有很大程度上得力於採用了科學測試技術、測試方法的應用，測試取得了不錯的效果，有力保障了專案的質量，但是仍然有不足的地方，具體存在以下幾方面：開發人員測試觀念不過強，雖然要求進行單元測試，但是開發人員沒有很好的執行，導致在整合測試階段發現較多問題。公司自主研發的測試工具在配置上不夠靈活，無法快速配置大量測試案例，這也是開發人員沒有很好執行的原因之一。測試案例的準備方面，有些資料準備的不夠完備。
我們從實踐中領會到測試確實可以在保證軟體質量方面起到很大的作用，但同時我們也認識到測試中還有很多領域和知識點需要繼續研究和實踐，新技術的發展對測試也提出了新的要求和挑戰，需要我們繼續研究探索。