軟件測試中如何進行接口自動化測試
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例并通過評審之后，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。
在開發子系統的時候，接口測試是至關重要的，但是往往子系統間的接口也會隨著版本的演進發生變化，這就導致面向接口的測試用例的維護成本提高。為了提升子系統間接口的測試效率，項目考慮自動化的對接口進行測試。
接口自動化用例需要滿足維護成本足夠小，能夠模擬用戶操作的各種參數，測試用例可以無人值守的執行等要求。次要因素包括不包括用戶行為的邏輯性，即自動化測試用例不需要客戶的參與，這是為什么呢？畢竟接口的就是下層系統對上層客戶（系統）提供的服務，客戶的操作是否合理，應該是在系統接口的測試范圍之內�！禔utomated Acceptance Tests Are Not The Right Move》 一文中提到了對這個問題的討論，其中主要的觀點就是寄希望于客戶參與完成自動化測試以滿足客戶使用滿意度，是不現實的。其中主要的問題在于首先客戶可能在系統做出來之前并不知道他想如何操作，那就更別提客戶參與的自動化測試用例能夠描述客戶的真實意圖；其次這樣的自動化用例的維護隨著系統的演進可能變成開發人員的噩夢。
但是問題是如果完全不考慮接口的邏輯的正確性，也是行不通的。所以項目考慮把問題一分為二來看，自動化測試完全是一種隨機構造的參數，它的目的是發現系統的不穩定因素，例如邊值問題，漏洞問題等等，通過自動化測試的子系統能夠保證其魯棒性。第二我們把用戶參與的邏輯性測試采用錄制的方式，來抓取用戶真正的操作。
對于自動生成用例來說，接口參數的取值范圍等約束條件是必要的輸入（否則只能隨機取值了，這樣測試效果可能不是很好）。如果接口是使用XSD來表述的，上述問題應該很好解決。但是目前項目中有很大一部分接口是通過ASN.1來定義的，它只規定了數據結構，而沒有描述字段的取值范圍，也沒有相關的約束條件（如是否是key，是否必填等等），這就導致單純生成的用例可能碰撞效果不明顯。為了提高 ASN.1接口自動化用例的碰撞效果，一種方法是使用EXCEL 或者其他形式對ASN接口進行重描述，另外是通過可配置的生成策略模板。相對來說后一種方式維護工作量可能會小一些。
對于接口邏輯性的測試環節，計劃是采用錄制的方式+手工用例的方式，其中錄制方式有幾個問題有待解決，一是各個接口在真正的操作時序上是有先后順序的，例如上一個接口的輸出時下一個接口的輸入，這種情況下如何模擬接口的返回就是個問題。二是邏輯性嚴重是否需要遍歷各種參數情況，僅嚴重一種邏輯的正確性，再加上自動化測試，能否保證各種邏輯的正確性。
對于第一個問題，我們可以通過自動生成一份mock數據，以便能夠抓取到盡可能多的用戶操作邏輯。對于第二個問題是需要探討的問題，自動化的測試就像上面提到的，有可能碰撞效果并沒有預想的好，那就可能造成通過自動化測試沒有模擬出一種隱蔽的操作邏輯，而偏偏這個邏輯的處理存在漏洞。要解決這個問題單靠一方面是不可能完成的，通過手工枚舉所用的操作邏輯可能明顯是不可行的，單獨靠自動化測試也有可能有漏網之魚。所以如何是二者的結合盡可能做到100%的覆蓋，是我們下一步的重點目標。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
