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