傳統軟體産品的測試政策設計
推崇的是邁克的金字塔模型，重單元測試，API測試次之，輕GUI測試。
網際網路産品的測試政策設計
網際網路産品的研發流程就一個字：“快”，釋出周期的巨大差異決定了，傳統軟體産品的測試政策必然不适用于網際網路産品的測試，二者的測試政策必然在測試執行時間和測試執行環境上有巨大差異。
網際網路産品采用菱形的測試政策，遵循“重量級 API 測試，輕量級 GUI 測試，輕量級單元測試”的原則。
第一，GUI 測試
網際網路産品的上線周期，決定了 GUI 測試不可能大範圍開展。
網際網路産品的 GUI 測試通常采用“手工為主，自動化為輔”的測試政策，手工測試往往利用探索性測試思想，針對新開發或者新修改的界面功能進行測試，而自動化測試的關注點主要放在相對穩定且核心業務的基本功能驗證上。是以，GUI 的自動化測試往往隻覆寫最核心且直接影響主營業務流程的 E2E 場景。
第二，API 測試
對于網際網路産品來說，把測試重點放在 API 測試上，才是最明智的選擇。
- API 測試用例的開發與調試效率比 GUI 測試要高得多，而且測試用例的代碼實作比較規範，通常就是準備測試資料，發起 request，驗證 response 這幾個标準步驟。
- API 測試用例的執行穩定性遠遠高于 GUI 測試。 GUI 測試執行的穩定性始終是難題，即使你采用了很多技術手段，它也無法做到 100% 的穩定。
- 單個 API 測試用例的執行時間往往要比 GUI 測試短很多。當有大量 API 測試需要執行時，API 測試可以很友善地以并發的方式執行，是以可以在短時間内完成大批量 API 測試用例的執行。
- 現在很多網際網路産品采用了微服務架構，而對微服務的測試，本質上就是對不同的 Web Service 的測試，也就是 API 測試。在微服務架構下，用戶端應用的實作都是基于對後端微服務的調用，如果做好了每個後端服務的測試，你就會對應用的整體品質有充分的信心。是以，網際網路産品的 API 測試非常重要。
- API 接口的改動一般比較少，即使有改動，絕大多數情況下也需要保證後向相容性（Backward Compatibility）。所謂後向相容性，最基本的要求就是保證原本的 API 調用方式維持不變。顯然，如果調用方式沒有發生變化，那麼原本的 API 測試用例也就不需要做大的改動，這樣用例的可重用性就很高，進而可以保證較高的投入産出比（ROI）。
作者：茹炳晟