<wbr id="wsjqy"></wbr>

          <form id="wsjqy"></form>
          <sub id="wsjqy"></sub>
          <nav id="wsjqy"><listing id="wsjqy"></listing></nav>
          更多課程 選擇中心


          Python培訓

          400-111-8989

          給Python軟件開發測試的25個忠告!

          • 發布:Python培訓
          • 來源:Python教程知識
          • 時間:2017-10-18 15:15

          今天小編在看文章時,看到了一位資深測試工程師寫下的多年來所學到的軟件工程實踐和原理方面的經驗。今天小編決定分享給大家。

          以下許多建議與測試有關,其中一些原則甚至特定于Python,但絕大多數不是。(對于Python程序員,PEP 8應該是編程風格和指南的第一站。)

          1、不要編寫你認為以后可能需要但目前不需要的代碼。這是對未來想象的用例的編碼,并且這種代碼一定會成為死碼或需要重寫,因為未來的用例總是與程序員的想象略有不同。

          注釋代碼也是如此,如果一段注釋的代碼正在進行發布,它不應該存在。YAGNI是編程的核心要素,最佳參考資料是極限編程解析(Extreme Programming Explained)。

          2、不進行多余的測試。基礎設施,框架和庫是需要測試的,不要測試瀏覽器或外部庫,除非你真的需要。測試你自己編寫的代碼,而不是其他人寫的代碼。

          3、多次重復出現的代碼不需要測試。輔助功能不需要測試,當你把它們分開并重新使用時,需要測試。如果反復編寫類似代碼多次時,您通常會很清楚正在解決的問題。

          4、關于API設計(外部面向對象API):簡單的事情盡量簡單完成,復雜的事情盡力優化。首先為簡單案例設計,如果可能的話,優選為零配置或參數化。Addoptions或附加的API方法,用于更復雜和更靈活的用例(根據需要)。

          5、盡早檢查無意義的輸入或無效狀態,最好是異常或錯誤響應,這將使程序員很清楚問題的確切信息。(除非真的需要,否則不要進行輸入驗證類型的檢查)。

          6、在可能的情況下,將測試對象視為黑盒子,通過公共API進行測試,這就不需要調用私有方法或修改狀態。

          對于一些復雜的場景,編寫測試真的是有幫助的,因為這迫使程序員考慮代碼的行為以及在編寫代碼之后如何進行測試。測試首先鼓勵更小、更模塊化的代碼單元,這通常意味著更好的代碼。

          7、對于單元測試(包括基礎架構測試),應測試所有代碼路徑。 100%的覆蓋是一個良好的開端。除非你無法覆蓋所有可能的排列/組合的狀態,只有一個非常好的理由才能使代碼路徑不全部經過測試,以時間為借口早晚會浪費更多時間。

          8、代碼是敵人:可能出錯,需要維護。盡量有更少的代碼實現必需的功能,刪除不必要的代碼。

          9、努力通過良好的命名規范和已知的編程風格使代碼可讀和形成自我記錄。通常隨著時間的推移,很多程序員都不認識自己寫的代碼了。

          10、代碼注釋——對一些無法明確的代碼,請盡早提供注釋,說明為什么要這么寫,有無其他方法等。

          11、編碼過程中務必想想可能出現的問題,無效輸入會發生什么,哪些情況會導致失敗,這將有助于程序員在發生錯誤之前捕獲更多錯誤。

          12、簡單的邏輯易進行單元測試,將邏輯分解為單獨的函數,而不是將邏輯混合為有狀態和有副作用填充代碼。(測試的開銷越少意味著測試更快)。

          13、使用對象可能比使用復雜的數據結構更好。使用Python的內置類型及其方法將比編寫自己的類型更快(除非您在C中編寫。如果考慮性能,請嘗試了解如何使用標準內置類型而不是自定義對象。

          14、依賴注入是一個有用的編碼模式,用于程序員搞清楚依賴關系以及它們來自哪里(有對象,方法等作為參數接收它們的依賴關系,而不是實例化新對象本身)。關于依賴注入的文章可參考Martin Fowler的“Inversion of Control Containers and the Dependency Injection Pattern”。

          15、代碼越多,代碼越差。程序員的目標應該是小型的可測試單元,以及更高級的集成和功能測試,以測試單元是否正確合作。

          16、設計API時應該考慮到以后可能會遇到的更改,并考慮到未來的用例——真的很重要。改變API對程序員和用戶而言都是一種痛苦,并且創建向后的不兼容性是可怕的(盡管有時不可避免)。

          17、如果函數或方法超過30行代碼,請考慮將其分解。最大模塊尺寸為500行,測試文件往往比這更長。

          18、不要在對象構造函數中工作,這很難測試。不要將代碼放在__init__.py中(除了用于命名空間的導入)。__init__.py不是程序員通常期望找到代碼的地方。

          19、在測試中,單個測試文件的可讀性比可維護性更重要(打破可重用的塊)。這是因為測試被單獨執行和讀取,而不是自己成為較大系統的一部分,顯然過多的重復意味著可以為了方便而創建可重復使用的組件,這不僅僅是生產問題。

          20、盡可能使用重構。編程是抽象的,越接近問題域,代碼越容易理解和維護。隨著系統的發展,用例的結構需要改變和擴展。一本關于重構和測試的書是Michael Feathers的Working Effectively with Legacy Code。

          21、在處理性能問題時,請務必在修復之前進行配置。如果你已經剖析并證明代碼實際上是值得的,編寫一個測試隨時對代碼進行分析,并且保留在測試套件中以防止性能回歸。(添加時間碼總是會改變代碼的性能特征,使性能成為更令人沮喪的任務之一)。

          22、更小,更嚴格的單位測試在失敗時提供更有價值的信息。通常,運行超過0.1秒的測試不是單元測試。單元測試可以提供更具體的錯誤信息,關于單元測試實踐一本不錯的書是Gary Bernhardt的Fast Test, Slow Test。

          23、遵循YAGNI原則:編寫我們需要的特定代碼,而不是不需要的、復雜性的通用代碼。

          24、共享代碼所有權是目標。不分享或許就發現不了更好的編寫方式,比如分享出來,大家集思廣益。

          25、最后,可以告訴產品經理或開發商,一味地增加功能并不是好事,確保核心功能的高效率工作就可以了。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:Python在測試中的應用
          下一篇:Python基礎語法-常量與變量

          Python中類的屬性有哪幾種

          Python語法你知道多少

          Python 中常見的配置文件寫法

          Python爬蟲可以做什么

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          网友自拍 偷拍 校园性爱青青草曰逼视屏老鸭窝国产偷自视频区视频 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>