首頁>>技術前沿>>APP開發行業動態

軟件開發與測試6條常規實踐幫你節省時間和避免問題

作者：各地APP開發 | 轉載 來源：軟件開發 | 時間：2017年10月25日| 點擊:0次 | 【評論】

我對軟件測試測試充滿熱情，因為我相信良好的測試實踐既能確保滿足最低質量標準（可悲的是許多軟件開發做不到），并能指導和塑造開發本身。不要寫你認為將來可能需要但現在不需要的代碼。這是為假想的未來用例編碼，這些代碼將不可避免地變成死代碼，或需要重寫，因為未來結果總是與想象的稍有不同。如果你寫代碼用于將來的用例，我將在代碼評審中對其質疑。（你可能而且必須設計 API，并確保未來的用例可用，但這是不同的問題。）這條原則也適用于被注釋掉的代碼；如果一個被注釋掉代碼塊即將進入一個發布版本，那么它就不應該存在。如果代碼可能要還原，請為代碼刪除創建一個問題單并引用提交對象的哈希字符串。

1、用于測試需要的基礎設施、框架和庫需要測試。除非你真的需要不要測試瀏覽器或外部庫。測試你寫的代碼，而不是別人的代碼。
2、當第三次編寫相同的代碼時，也是將其提取成通用的輔助函數（并為其編寫測試）的正確時機。測試中的輔助函數不需要測試；但當你將它們剔除出去然后再重用它們時，它們需要測試。到你第三次編寫類似代碼的時候，你通常會清楚地認識到你正在解決的通用問題的模型是什么。
3. 快速失敗。檢查輸入，如果遇到無意義輸入或非法狀態則盡早失敗，最好是通過異?；蝈e誤響應使問題對調用者變得清晰。允許你的代碼處理“有創意”的用例（例如，除非真的需要，否則在做輸入驗證的時候不要做類型檢查）。
4、現在來談談 API 設計（面向外部的對象API）：把簡單的事情做簡單了，復雜的事情自然成為可能。首先設計簡單的用例，如果有可能最好是零配置或參數化。為更復雜和靈活的用例（如需要）增加選項或額外的 API 方法。
5. 對于單元測試（包括測試基礎設施測試），所有代碼路徑都應該被測到。100% 覆蓋是一個好的開始。你不能覆蓋所有可能狀態的排列/組合（組合性爆炸），因此這個問題需要考慮。只有當有很好理由的情況下才允許有代碼路徑未經測試。沒有時間不是一個好理由，最終會花費更多的時間?？赡艿暮美碛砂ǎ赫嬲牟豢蓽y（以任何有意義的方式），現實中不可能發生，或被其它測試覆蓋。沒有測試的代碼是一種債。測量覆蓋率和拒絕減少覆蓋率 PR(拉取請求) 是確保你在正確的方向演進的一種方式。
6、單元測試測的是行為單元，而不是實現單元。我們的目標是在改動實現的情況下不改動行為，也不必更新測試，盡管這個目標不總是能實現。因此在可能的情況下將測試對象視為黑盒，通過公共 API 測試，而不調用私有方法或玩弄狀態位。在一些復雜的情況可能做不到，如在特定的復雜狀態下測試行為，以找到一個偶發的錯誤。這一點對于寫測試非常有幫助，因為它迫使你在寫測試代碼之前思考你代碼的行為以及你將如何測試它。測試首先鼓勵更小，更模塊化的代碼單元，這通常意味著好代碼。關于“測試優先”方法有一本很好的入門參考書，就是 Kent Beck 寫的《測試驅動開發》(《Test Driven Development by Example》)

此內容DOC下載　此內容PDF下載

【全文完】

關鍵詞標簽:軟件開發　軟件測試　

版權聲明:

弈聰軟件網站內容中凡注明來源為轉載的內容，涉及軟件開發,APP開發公司,APP開發,APP制作,app推廣等內容并不代表本站贊同支持其觀點，并不對其真實性負責。轉載請署名弈聰軟件公司，否則弈聰軟件公司將追究其相關法律責任。

APP開發行業動態