如何保證介面測試的覆蓋率？

我們公司做了一段時間介面測試了。但是目前，我覺得還是黑盒的。QA們並不關注介面的內部邏輯。只是按自己的理解去設計不同的參數組合當做用例，但是RD和QA們的溝通還是很有問題的，QA也都不是業務線上的QA，對業務了解有限。 這樣怎麼能保證覆蓋率呢。 我是想在測試框架里引代碼覆蓋率工具，但是這樣還只是在事後補救。無法在一開始設計用例的時候就能覆蓋的更好。而且還是要QA們去看代碼。我們大部分的QA妹子們是不懂代碼的。 小弟是寫這個測試框架的人。一開始本著減少測試學習成本的原則，寫了個框架讓她們不用寫代碼就能測試。 因為老大們是不同意招人和培訓她們寫代碼的，覺得成本太高。 但現在又回到原來這個問題上了。我如何在設計用例的時候就能保證覆蓋率呢。

代碼覆蓋率只是覆蓋率的一種衡量方式，相對來說算是強覆蓋了。如果不好做和不好推動代碼覆蓋率的話，可以先做介面的功能（需求）覆蓋率。而這樣做，你必須先搞到明確的功能（需求）定義。下面來說我們是如果做介面測試的。

首先，需要開發將所有需要測試的介面定義下來。

1. 每個介面的url是什麼？
2. 接受什麼樣的參數？
3. 每種參數的類型是什麼？
4. 哪些參數是可選的，哪些是必選的？
5. 輸入參數正確/參數異常，介面的返回是什麼？介面行為是什麼？

接下來，有了詳細和明確的介面定義後，你就可以用各種方法來設計測試用例了。

• 一般來說，至少應該覆蓋所有的輸出可能，這樣就達到了弱覆蓋。
• 如果對於同一種輸出，把所有有效等價的輸入情況也測到了，那就達到了中等覆蓋。
• 如果在此基礎上，對後端的數據內容和服務狀態也進行了驗證，那麼基本上就是強覆蓋了。
• 如果再能考慮更多的異常場景，那麼基本上這個介面就測得比較有信心了。

最後，統計下所有的介面中，哪些測得強，哪些測得弱，這樣就大致對介面的測試覆蓋心中有數了。

當然有條件的話，還可以讓開發做做介面的單元測試，不過這事測試人員也不一定能推得動。

我在知識星球[軟體測試之道]等你，我們星球的id是:78466829，期待你的加入。

覺得有道理的話別忘了點贊讓更多人看到。

介面測試？

如何保證介面測試的覆蓋率？

做介面測試的流程一般是怎麼樣的？

介面測試的數據如何回歸？

如何寫出高效的軟體測試用例？

軟體測試工程師，2年半工作經驗，第一次跳槽，如何快速融入團隊？

做測試，寫了一周的測試 用例，感覺自己已經是個文員了,怎麼辦？

該怎麼樣才能讓所有測試人員迅速學會自動化測試呢？

測試人力不足時，測試技術層面有什麼方法可以提高測試效率？

怎麼判斷哪些功能能實現自動化？

做了一年的軟體功能測試，想轉自動化測試。目前在看了一些Python資料，感覺無從下手，求指導？

看業務邏輯代碼，看懂代碼，哪個業務邏輯走哪個方法，調用哪個函數，返回什麼，異常如何處理的，其他情況如何處理，這樣你可以設計一個基於業務的非常完全的測試案例，並且也能減少一些不必要的測試案例，但是這需要一定時間和積累，並且非常高效。

雖然軟體測試理論告訴我們不要關心內部邏輯，但是不關心內部邏輯會造成，很多無用的測試案例，浪費大量的人力物力。

最近在測http介面，說一下我的看法啊！

保證覆蓋率的話，寫測試用例的時候，就得把各種情況考慮到，正常的、異常的情況等等吧！

其實吧，我個人感覺，測試首先要保證主要的業務流程能覆蓋，保證產品在「正常」的情況下能使用，其次再考慮一些異常的情況，保證產品的健壯性！

歡迎關注我的微信公眾號：小期科技

我在北京做測試工作，可以一起交流哈！

不過我覺得，1、你的痛點不在如何保證介面測試的覆蓋率，而是你們公司的QA妹子都不懂代碼，這就讓你的測試框架的維護層面不能是腳本級別的；2、你不熟悉業務，所以你設計出來的測試框架或多或少跟你們公司的代碼有不太兼容的地方，從功能用途上你也無法保證你框架的高效率（無論是框架本身，還是使用需求上）；3、不知道你們公司不同項目對於公共方法的處理是否一致，如果不一致，你的這套框架估計擴展會很累，比如我現在是被老大要求做全公司統一的介面測試平台，但每個項目的https介面對於簽名串的生成方法都不一樣（從參數到原理），我每接一個項目就要補充每個項目對應的公共方法，但測試框架本身的結構又是統一的。

---------------------------解決完上面這三個問題，我覺得你再考慮功能級別上的覆蓋率吧（比如一條業務測試的流程涵蓋了哪幾個介面，上下游參數福承接關係，被測環境測試數據復用問題等等）