海量測試用例如何優化:用狀態矩陣解決有序操作的case爆炸問題

　　一、 簡介

　　我們在測試中可能都會面對case爆炸問題。有的case組合是無序的，我們可以通過pict[1]組合case，讓pict成最優化的case組合，在保證覆蓋率的同時控制case數，這個方式在業界使用廣泛，收效也不錯。

　　但是對于有序操作的case爆炸，pict不能支持。目前沒有很好的辦法，總是讓我們很傷腦筋。

　　本文從狀態矩陣出發，討論了用遍歷狀態矩陣、先生成所有case、再組合case的方法來解決有序操作的case爆炸問題。

　　二、 基于ajax的網站測試遇到的問題

　　1. ajax簡介[2]

　　有序操作的case爆炸問題在java scripts 測試或是應用ajax技術的產品測試中，尤為明顯。

　　AJAX(Asynchronous JavaScript and XML)，異步 JavaScript 和XML，不是一種新的編程語言，而是一種用于創建更好更快以及交互性更強的Web應用程序的技術。

　　傳統的web應用允許用戶填寫表單(form)，當提交表單時就向web服務器發送一個請求。服務器接收并處理傳來的表單，然後返回一個新的網頁。這個做法浪費了許多帶寬，因為在前後兩個頁面中的大部分HTML代碼往往是相同的。由于每次應用的交互都需要向服務器發送請求，應用的響應時間就依賴于服務器的響應時間。這導致了用戶界面的響應比本地應用慢得多。

　　與此不同，AJAX應用可以僅向服務器發送并取回必需的數據，它使用SOAP或其它一些基于 XML的web service接口，并在客戶端采用JavaScript處理來自服務器的響應。因為在服務器和瀏覽器之間交換的數據大量減少，結果我們就能看到響應更快的應用。同時很多的處理工作可以在發出請求的客戶端機器上完成，所以Web服務器的處理時間也減少了。

　　但應用ajax技術也面臨著許多問題。無可避免的第一個問題即是瀏覽器的兼容性問題。各家瀏覽器對于JavaScript/DOM/CSS的支持總有部分不太相同或是有Bug，甚至同一瀏覽器的各個版本間對于JavaScript/DOM/CSS的支持也有可能部分不一樣。這導致程序員在寫 Ajax應用時花大部分的時間在調試瀏覽器的兼容性而非在應用程序本身。

　　Ajax技術之主要目的在于局部交換客戶端及服務器之間的數據。如同傳統之主從架構，無可避免的會有部分的業務邏輯會實現在客戶端，或部分在客戶端部分在服務器。由于業務邏輯可能分散在客戶端及服務器，采用異步交互的方式，而javascript語言本身之能力可能不足以處理復雜的業務邏輯，這導致 Ajax應用程序極難維護。

　　2. 測試中遇到的問題

　　測試過java script的同學都知道，js有一些功能，單獨驗證時不會有問題，而將幾個功能組合起來時，卻很容易出現bug。一些bug可能需要3~4次操作才能夠發現。

　　基于ajax的網站測試中，關于組合操作的測試設計通常依賴測試人員的經驗和開發者的設計文檔，將可能發生關聯的case組合起來。測試執行時也加入一些 “隨意測試”，即隨意組合各種操作，以發現組合操作的問題。這個測試方法在較簡單的場景中取得了一定的效果，可以用較小的投入發現問題。但隨著網站的 ajax技術越來越復雜，更新越來越快，這樣做可能存在一些問題：

　　1. 測試設計的覆蓋率不能保證。只憑測試人員的經驗，可能不能覆蓋到大多數情況，容易漏掉一些分支。

　　2. 測試執行時的“隨意測試”沒有依據，測試效果可能因測試人員的不同或測試人員的狀態而異。

　　因此，我們亟待解決的一對矛盾是：

　　 測試設計的覆蓋率。

　　 測試case要在有限的范圍內。

　　三、 現成的解決方案?

　　想解決覆蓋率和case爆炸的矛盾，目前了解到的解決辦法有：

　　1. pict[1]

　　 優勢：

　　有一些組合可能是我們不需要進行測試的。通過給組合間加入條件限制，pict可以自動生成需要測試的組合。通過pict的優化和篩選，case組合可以有效的減少。pict工具成熟，應用很廣泛，取得了不錯的效果。

　　 不足：

　　pict所處理的組合之間是無序的，也就是說用pict得到的是一個“組合”而不是“排列”。有時候我們需要處理的是一個操作序列，例如 1-2-3、1-3-2、2-3-1 都是不一樣的。而pict對這種順序關系不能區分。

　　2. 狀態圖

　　 優勢：

　　操作間順序關系一目了然。

　　 不足：

　　無法得出操作序列，仍然只能是看圖隨機操作。

　　四、 我們的解決辦法

　　既然狀態圖可以反映有序操作的關系，我們打算從狀態圖著手來解決這個問題。

　　1. 應用場景

　　我們假設一個常規的電子商務網站。

　　這個網站中，用戶首先進入首頁，然后可以搜索產品，進入產品列表頁;也可以直接點擊首頁中的促銷產品，進入產品的詳細介紹頁。

　　進一步，在產品列表頁中，用戶可以點擊“加入購物車”將商品放入購物車或點擊購買直接進入訂單頁，或對搜索結果不滿意而再次搜索;在詳細介紹頁中，也可以進行如上的操作。

　　在購物車的頁面中，用戶可以增、刪、改購物車的內容，或繼續購物;在訂單頁中，用戶也可以一步步提交訂單或繼續購物。

　　我們發現涉及的頁面越來越多，其間的關聯關系也越來越復雜，大概像下面一張狀態圖，圖中加入了一些“其他功能頁”，并假定了他們之間的跳轉關系。

　　2. 首先要解決的是覆蓋率問題

　　對這樣一個網站，只測試單個頁面時，一般問題不大。按照通常的思路來處理，例如搜索產品，訂購產品，提交訂單，那么問題也不大?？墒怯袝r有這樣的情況：

　　 用戶習慣先添加到購物車，再統一提交

　　 提交到一半，發現有的東西不想要了，去掉一兩件，重新提交。

　　 有一部分商品來自購物車，有一部分商品來自新選擇的東西。

　　 已經提交的訂單，后臺還沒處理時，用戶有權力修改。

原文轉自：http://www.kjueaiud.com