<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          軟件測試中的單元測試算績效評估嗎?

          • 發布:軟件測試培訓
          • 來源:軟件測試問答
          • 時間:2017-07-25 15:00

          本文要點

          ●如果確保開發人員正在投身于流行的開發實踐

          ●如果區分開好的單元測試和差的單元測試

          ●單元測試的好處

          ●如何度量單元測試,既要定量也要定性

          ●好的績效評估看起來是什么樣的

          績效評估對雇主和雇員都有好處。它是個針對未來工作績效提建議、識別指標和設置預期的時機。它還是個坦誠交流績效以及可以如何提升績效的時機,而這種交流往往都很缺乏。不斷進行績效討論有助于避免未來出現嚴重的問題。

          但是,針對軟件開發人員和你的開發組織的績效評估看起來應該是什么樣子的呢?

          沒錯,你已經實現了迭代,甚至為單元測試引入了培訓機制。但是,除非你換掉全部研發人員和頂層敏捷專家(只是沒有足夠的人才供得上),否則你就需要確保你的開發人員掌握了流行的開發實踐,比如單元測試。

          怎么做呢?通過頻繁、每年四次的績效評估來進行績效度量。通過把單元測試納入到績效評估中,表彰那些做單元測試的開發人員,以及確保預期清晰一致的管理和研發團隊。

          年度績效評估已經受到了許多的非議,許多公司正在想要廢棄它。對于了解、改變和改進來說,一年僅僅一次是不夠的。年度績效評估不是敏捷的!

          但是不管怎樣,都要經常評估團隊的工作,確保你所度量的開發人員正在進行專業的編程工作,其中包括單元測試。

          單元測試可達成幾個重要的業務目標:質量改進、具有測試遺留代碼的能力、開發人員在最新的代碼和最好的方法論之上開展工作,是的,好的單元測試甚至會增加開發人員的積極性。

          編寫好的不會因單個代碼變更造成損壞的單元測試并不難,遵循以下簡單實踐即可完成:

          單元測試應該是自動化的

          單元測試不應該依賴于環境設置、其他測試、完成順序或運行的特定順序。運行同一單元測試1000次應該返回同一結果。

          使用靜態變量、外部數據(比如注冊表、數據庫)或環境設置等全局狀態可能會導致測試間的“泄漏”。測試運行的順序應該不影響測試的結果,所以在多個測試運行之間應確保適當地初始化和清理每個全局狀態,或從根本上避免去使用它。

          清楚你正在測什么

          測試特定場景或對象的每個方面是沒有錯的。問題是開發人員往往喜歡把幾個這類的測試塞進一個單獨的方法里,創建一個非常復雜而脆弱的“單元測試”。

          我找到一個小技巧,就是把場景測試和預期的結果作為測試方法名稱的一部分。如果開發人員這么命名他的測試時覺得有問題,就意味著她不確信正被測試的是什么。

          只測試一件事還有額外的好處,那就是測試更加可讀。當一個簡單的測試失敗時,比冗長復雜的測試更容易找出失敗的原因并修復它。

          專注于測試范圍

          測試范圍與它的脆弱程度之間有著直接的關系。大多數測試有一個待測對象,它作為該測試的一部分響應或調用其他對象。這些外部依賴的內部工作方式對這個測試來說并不重要,可以予以偽造。使用隔離(也稱做模擬),以便這些測試不必初始化和設置這些會用到但不是實際被測試的對象,這樣可以使其中的對象變更時不會影響到測試。

          避免過于規格化

          通過設立每個單獨的對象并測試每個單獨的方面,創建良好定義的、可控的和嚴謹的測試,它們能在測試時遵循精確處理流程,這是件非常具有吸引力的事。問題是這么做使其與待測場景“緊緊鎖定”,即使不會對最終結果產生影響的變更也無法進行了。

          最終我們要的是可維護的代碼。可維護的代碼即可變更的代碼。且不說按時完成任務了,你還可以度量代碼的可維護性是多少,做這件事的最佳方式就是通過單元測試進行度量。

          通過度量你的代碼的可維護性是多少,包括每個開發人員通過單元測試為這個重要質量KPI所做的貢獻,當下個開發人員到來時,提速將是輕而易舉之事。

          你正在評估團隊為質量做了多少貢獻嗎?

          我們現在都清楚,單元測試會提升軟件的質量。通過單元測試,技術債會降低,所發布代碼的缺陷會降低。開發人員對他們的代碼更具信心,因為測試人員能幫他們了解到什么運轉正常什么運轉不正常。它還能幫開發人員回溯和修復遺留代碼。

          如果你不度量它,它就不會改進。我們看到過很多不寫單元測試的團隊,因為他們不評估它,而且不會根據它來升職。沒有包括單元測試在內的績效評估,開發質量會受到損害,你的代碼將難以維護。開發人員很難從一個項目換到另一個項目中。

          好的績效評估有定量和定性的指標。所以,在你的員工激勵計劃和績效評估中對它是否有所體現呢?畢竟,如果他們不清楚你對單元測試的認可和獎勵,在嚴格要求期一過恐怕就將偷工減料了。

          通過包括對每個開發人員的職責(有些人更專注于糾錯,還有些人涉及的是遺留代碼,而有些人正在使用簡單的框架開發全新的特性)進行適當的定性和定量度量,你可以鼓勵好的軟件開發實踐。這有助于你的團隊,確保你們可以發布高質量的軟件,且更加快速。

          單元測試應如何正式地包含在評估之中?

          你可以考慮以下度量:


          如今,對績效評估有些非議。敏捷開發不僅僅是一組實踐,更是一種心態。當它變成一紙檢查表而不是一個流程時,它的失敗率就已經增高了。可能有些單元測試就不會增加商業價值,比如測試不相干的代碼,因此增加代碼覆蓋率也不會增加價值。

          因為它是好的實踐,而不是因為尖頭發的上司(譯注:pointy-haired boss是Scott Adams創造的一個形象)想要提交一份度量報告,所以最好的開發人員才想要做些什么,只關注于度量而不是目標的績效評估在管理中很常見,可是它并沒有多大效果。

          因此,好的績效評估應關注于商業目標和打開溝通交流的渠道。

          很幸運,甚至大型公司現在也正在拋棄年度績效評估,而采用更頻繁的自由形式的反饋。具有定性和定量目標的頻繁反饋是個好的實踐。

          頻繁評估還有助于帶你的組織接近理想的敏捷。敏捷宣言價值觀“響應變化勝過遵循計劃”以及Scrum項目管理所謂的快速優先、頻繁反饋早已人盡皆知。

          自由形式的反饋還鼓勵專注于商業目標而不是各種度量。

          但是不論你的評估有多么頻繁,是周、月、季度還是年度,只要它們與獎金和升職有關,單元測試就應該成為其中的一部分。

          我們舉一個例子,看看績效評估大概看起來是什么樣子的:

          業務目標:編寫持久、健壯的代碼

          Susan Bar一直都提倡在團隊內部開展單元測試。她的代碼有著良好的覆蓋率,針對復雜的問題我們的單元測試儀表盤會給出警示。她發現了10%以上更關鍵的問題,否則這些就會發給質保人員,使發布時間推遲。她還測試已有和遺留的代碼,這有助于其他開發人員持續編寫代碼。這有助于降低未來增加特性時所需的時間。

          把單元測試視為績效評估中重要的KPI是對員工的認可,表示你重視代碼質量和流行的軟件方法論。把單元測試涵蓋到績效評估中會讓你獲得更好的質量、更積極的員工和更好的、缺陷更少的代碼。所有這些正在讓你實現敏捷理想:更好的軟件、更快。

          單元測試不能簡單地看成績效評估上的一條線。你需要把它看做貫穿整個開發組織的一些東西:從提供最好的工具(比如‘ Typemock Suggest ’ 建議的單元測試),到像Scrum之類的工作流以及軟件技術和極限編程之類的開發實踐,確保單元測試是日常工作天然的一部分,與整個軟件工程組織良好地集成在一起,包括DevOps和質保。

          采用這種方式,你的績效評估將更加自然,你的團隊將不會去過慮他們的評估,而是想要成為更好的程序員。

          預約申請免費試聽課

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

          上一篇:軟件測試中的保姆式的測試是什么意思?
          下一篇:大公司軟件測試怎么做?小公司如何做軟件測試?

          軟件測試都會都用到哪些工具?

          女生能做游戲測試嗎?應該從哪兒入手?

          • 掃碼領取資料

            回復關鍵字:視頻資料

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

          • 視頻學習QQ群

            添加QQ群:1143617948

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

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

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>