一線開發同學，可能或多或少都造成過線上bug甚至故障，打幾個比方，某同學在開發某功能的時候重構了代碼，造成了線上bug或者故障；在開發某個功能時，發現需要修改公共邏輯，害怕影響到其他功能，非常不雅觀地拷貝代碼，重新寫套單獨邏輯來支持，
上面的情況都包含了一個關鍵的問題，無論是功能開發還是邏輯重構，如何來保障代碼開發的質量，
保障的方法每個人都知道，就是測驗，
首先是新功能測驗，保障新功能邏輯正確；其次是回歸測驗，保障原有業務功能邏輯正確，測驗的方式，一般是兩種，人工測驗和自動化測驗，隨著測驗技術和工具的持續發展，人工測驗比例逐步降低，被自動化測驗逐步替代，自動化測驗是可持續和可重復的，甚至是可AI化的，
測驗分層
測驗也是分層的，如下圖所示：
在一個系統內，自動化測驗一般分單元測驗、模塊測驗和介面測驗，
單元測驗
單元測驗的要求基本上是單個類單個方法的測驗，在我們當前模式下，撰寫成本太高，當然，如果是一個工具或者一段比較內聚而又復雜的邏輯(例如演算法邏輯)，還是應該使用單元測驗來保障邏輯的正確性，
模塊測驗
在系統比較大、模塊比較多的情況下，可以建立模塊測驗層，保障各模塊功能的正確性，不過當前的系統發展趨勢是微服務架構，因此模塊測驗層并非十分必要，可以通過介面測驗層來覆寫，
介面測驗
這一層，是從系統入口出發進行集成測驗，應用入口通常是框架服務，訊息，定時任務，
在所有的開發測驗中，介面測驗是必不可少的一項，有效且覆寫完整的介面測驗，不僅能保障新功能的開發質量，還能讓開發在修改功能邏輯的時候有回歸的能力，同時也是能優雅地進行重構的前提，同時，易測性也是代碼結構合理的一個指標，如果發現一段代碼撰寫測驗腳本困難或者無法測驗，那就說明當前代碼結構不合理需要重構，
執行效率
對于介面測驗，執行效率是不得不關注的一個點，若一個介面測驗執行3分鐘以上才能看到結果，會大大降低開發同學撰寫介面測驗的熱情，對于測驗執行效率提高，建議的方案為：
1、及時更新或撰寫是自動生成API檔案
2、使用合適的自動化測驗工具如Eolinker
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/265608.html
標籤：其他
下一篇：【pytest官方檔案】解讀fixtures - 4. 一次請求多個fixtures、fixtures被多次請求