代碼審查如何保證軟件質量

時間 2019-11-18

標籤代碼審查如何保證軟件質量简体版

原文原文鏈接

研究使用Selenium 進行自動化測試的代碼檢查最佳實踐和代碼檢查清單。java

在軟件行業，您可能常常會聽到術語「代碼審查」。可是，代碼審查的概念常常被誤解。人們一般認爲它在軟件開發生命週期中被忽視執行測試應足以知足驗證過程。所以，他們傾向於對代碼審查過程視而不見。可是，忽略代碼審查過程可能會反彈併產生重大後果。咱們也有一個誤解，認爲代碼審查過程是開發團隊的責任。它不是！代碼審查是一個過程，不只應包括開發人員，還應包括質量保證人員和產品經理。本文是個人嘗試，旨在幫助您意識到代碼審查的重要性以及您應該如何參加質量檢查。程序員

什麼是代碼審查及其目標？

代碼審查是一種將源代碼分解成小段的作法，由團隊的主管或前輩檢查這些源代碼，而後在測試以前進行檢查。這是敏捷方法中主要遵循的一個過程。面試

代碼審查的主要目的是發現錯誤，及時發現錯誤並確保代碼遵循標準作法。能夠將其稱爲雙向交流，在這種狀況下，編碼人員和檢查代碼的人員均可以互相學習，並消除可能會影響產品的任何潛在錯誤。編程

在敏捷環境中工做，您可能常常低估了代碼審查過程的重要性。您可能會認爲代碼審查會很耗時，尤爲是在期限緊迫的狀況下。可是，這變得愈來愈重要。您越早檢查代碼並消除任何阻塞或錯誤的可能性，之後就能夠按照發布過程越早交付產品。在發佈週期的後期發現錯誤或在將其移植到生產中後，發現它們更昂貴，更耗時。這就是爲何組織如今沿用Shift-Left測試的現代方法，將您從客戶需求收集階段開始的測試歸入其中的緣由。數組

爲何須要進行代碼審查？

若是您認爲只要進行測試就不須要進行代碼審查，那麼如下提到的好處可能會使您的想法轉向不一樣的想法。瀏覽器

早期錯誤檢測：在開發階段的早期階段檢測到錯誤時，能夠減小測試階段的大量時間。整個過程變得很便宜。儘管現在，自動化測試減小了測試工做量和花費的時間，可是，沒有比檢測和糾正其餘人所犯錯誤的人性更好的天賦了。
指導低年級學生：當新生參加項目時，高年級學生可能沒有太多時間來指導或指導大三學生進行編碼實踐或培訓他們如何工做。在這種狀況下，對於高級開發人員而言，理想的解決方案是花費至少20-30分鐘的時間來審查初級用戶編寫的代碼。按期的反饋將使新生可以發展本身的編碼技能。
敏捷時代：現在，大多數組織都遵循敏捷方法論，要求及時交付高質量的工做。代碼審查將使組織可以開發出完好陷且遵循標準協議進行開發的高質量原型。
團隊凝聚力：頻繁的討論討論使團隊更加緊密，使他們意識到彼此的長處和短處，並避免他們陷入孤立的環境中。
符合標準：在敏捷時代，客戶常常要求咱們遵照特定的編碼標準。可是，較新的開發人員一般不瞭解行業標準編碼。常常檢查有助於確保代碼遵照利益相關者設定的規則和標準。

代碼審查和測試能夠互相替代嗎？

對於初學者來講，代碼複查和測試都是包含在軟件開發生命週期中的最佳實踐。可是，二者在其各自的方式上都是獨特的，不能混淆。認爲您不須要代碼審查是錯誤的，由於您已經在SDLC中進行了測試，反之亦然。安全

代碼審查涉及檢查代碼，該檢查可能包括也可能不包括檢查錯誤。它涉及檢查代碼風格是否符合全部策略，是否存在違反安全性的問題，最重要的是，是否易於理解代碼。目的是檢查代碼是否簡單，是否遵循全部策略和標準，最重要的是，是否達到目的。網絡

另外一方面，測試具備幾個類別。測試的主要目的不是檢查代碼，而是檢查應用程序是否正常運行。測試包括檢測應用程序不一樣層中是否存在任何錯誤，應用程序是否知足涉衆的全部要求並確保將檢測到的問題傳達給相關團隊。架構

假設地，代碼審查能夠代替測試。在很小的應用程序中，若是有多個審閱者仔細地檢查代碼，他們可能會肯定執行單元測試時可能引發缺陷的部分。僅假設，不現實。框架

手動或自動化測試一般採用固定方法來檢查應用程序流，並肯定是否有任何異常的行爲。

可是，代碼審查須要人工干預。人類的大腦很複雜，可能會想到編寫測試腳本時可能還沒有預編程的方案。有經驗的代碼審查員能夠在編寫有效測試用例的過程當中，在測試人員可能沒有想到的特定狀況下，檢測出可能致使破壞的任何錯誤代碼行。

可是，僅當應用程序很是小且可能僅包含一百行代碼時，代碼審查才能代替測試。在大型應用程序的狀況下，範圍會變大，不管有多少審閱者一塊兒檢查代碼，集成代碼時，應用程序均可能會形成損壞。這就是測試起做用的地方。

可是，測試不能以假設或現實的方式代替代碼審查。儘管測試能夠檢測到全部錯誤並由開發人員修復它們，但讓咱們討論一個方案，該方案將清楚說明爲何它不能代替代碼審查。

我將分享個人我的經驗。咱們的團隊正在開發大型動態Web應用程序。通過最後的測試階段，整個應用程序能夠知足每一個用戶的需求。可是，存在一個問題–加載時間。即便以最快的網絡鏈接速度，該應用程序也須要4-5秒鐘來加載。經過代碼審查階段，咱們發現CSS和腳本很是複雜，能夠將它們最小化幾百行。這樣作，咱們將加載時間減小到2秒。所以，能夠得出結論，實際上，代碼審查和測試都是軟件開發階段不可或缺的一部分，而且永遠不可能徹底替代。

如何做爲QA參加代碼審查？

代碼審查被認爲是靜態測試的一部分，該活動一般由質量分析人員執行，以在測試階段開始以前發現是否能夠較早發現任何錯誤。若是測試團隊積極參與代碼審查，則能夠節省大量時間。

您可能想知道當您不參加測試時如何開始進行代碼審查，而沒有任何開發經驗。可是事實是，代碼審查只須要您的觀察技能，而不須要您的編碼能力。對於初學者，您能夠從自動化腳本開始。嘗試查找可能致使錯誤測試順序的小錯誤。每當有時間時，請並行瀏覽應用程序的存儲庫，並嘗試瞭解開發人員在該處所作的事情。

另外，若是您團隊中的某人正在檢查代碼，請與他們討論或坐在一塊兒，並嘗試瞭解他們的工做方式。檢查他們是否在看

記錄易於理解的消息
語法錯誤
-拼寫錯誤致使的錯誤
命名約定
最初，當測試人員有機會進行代碼審查時，與經驗豐富的人員進行配對會使任務變得容易得多。儘管最初的衆多代碼行毫無心義，但與時俱進使質量分析人員可以找到一種模式，而後他們逐漸習慣於代碼庫，最後只有經過查看應用程序的特定部分，他們纔有機會能夠清楚說明在該部分中實現了哪些業務邏輯。

此外，一旦開發團隊發現QA團隊正在關注代碼，他們將很樂意向他們解釋代碼的工做原理，從而提升質量分析人員的編程知識，並改善團隊之間的溝通。經過代碼審查的實踐，測試人員將知道在代碼的哪一個部分中定義了項目的哪些功能，從而提升了總體智慧和團隊合做精神。

最後，記住一件事。您無需成爲執行代碼審查會議的專家編碼人員。具備基本編碼知識的任何人均可以查看代碼。您只須要查看更改並詢問作什麼，爲何以及如何完成某件事。從較小的更改開始，並詳細瞭解它們以及任何有任何差別的地方，對其進行評論，並請編碼人員清除您的疑問。而且，若是您要管理整個項目，請確保將代碼審查和測試做爲必不可少的階段包括在任何軟件開發生命週期中都要執行。這將確保交付高質量的產品，並保持組織的聲譽。

執行代碼審查的方法

讓咱們開始閱讀代碼。根據您的應用程序的大小，您能夠執行兩種類型的代碼審查。

正式代碼審查：這是一個詳細的過程，須要您與多個參與者協做並在多個階段中工做。這是團隊參加會議並逐行檢查代碼的傳統過程，傳統上是使用打印副本。進行了完全檢查，發現該方法可有效發現缺陷。
輕量級代碼審查：此過程也很是有效，與正式代碼審查相比，所需工做更少。做爲正常開發程序的一部分，執行此審查有4種方法。

越過肩膀：在這裏，開發人員查看其餘人的代碼，然後者則瀏覽前者的代碼，並解釋其中的操做。
傳遞電子郵件：不管什麼時候簽到，管理源代碼的應用程序都會自動觸發一封郵件給審閱者。
結對編程：2個編碼器在同一工做站上開發代碼，同時不斷回顧彼此的工做。
工具輔助檢查：現在提供了專用的工具，用於代碼檢查和測試。對等方使用這些工具來檢查代碼並根據須要進行註釋。

Selenium自動化測試的代碼審查清單

儘管有一些最佳實踐，咱們將在後面進行討論，但這將致使完好陷的代碼審查，可是，若是您正在使用Selenium WebDriver進行自動化測試以對網站進行跨瀏覽器測試，則在審查代碼時須要檢查某些因素。

儘量使用CSS定位器代替Xpath。
必須將頁面對象用於全部用做選擇器的DOM對象。
避免使用複雜的數據管理結構。
爲了處理等待問題，測試應主要取決於框架。
對於數據搜索功能，使用最少的文本。
長元素定位器一般很脆弱。避免使用它們，由於綁定它們的佈局會發生變化。
頁面對象應該是惟一且健壯的。

代碼審查–遵循的最佳作法

就像編碼和測試同樣，您還須要牢記一些代碼審查最佳實踐。讓咱們詳細討論它們。

知道您要尋找的內容：在檢查以前設置目標。準備一個清單，其中可能包括編碼樣式，結構，邏輯的複雜性，可讀性。簡而言之，包括那些在自動化測試期間沒法檢查且須要人工干預的項目。提出諸如「我是否知道此代碼在作什麼？」或「此代碼是否符合客戶指定的編碼標準？」之類的問題，這被認爲是審查最佳實踐的最佳代碼，您能夠輕鬆地準備要檢查的項目。
在審閱以前進行構建和測試：在當前持續集成和持續交付的時代，理想的方法是在手動審閱代碼以前構建和測試代碼。這樣能夠確保代碼穩定並節省大量時間。成功構建以後，當代碼經過全部自動化測試時，最好的作法是進行代碼審查，並確保將無錯誤的代碼推送到開發人員的代碼行中。
不要花太長時間進行審閱：做爲代碼審閱最佳實踐的一部分，您須要確保您花費的時間不會超過平均時間。最好短暫休息一下代碼，以確保您的大腦得到所需的時間間隔，而且能夠從新開始，這會更好。常常檢查代碼也將幫助您考慮新場景並提升代碼質量。
您的評論毫不能傷害：在評論中要有建設性，而不是批評。提出問題而不是發表聲明。此外，還要稱讚開發人員的工做。您以正確的語氣提供的反饋意見必定不會傷害他們，而應該激勵他們改正錯誤，並確保再也不發生錯誤。
傳達指望和目標：明確審覈的目的和審覈者的指望。若是審閱者在您的指導下工做，那麼做爲代碼審閱最佳實踐的一部分，建議您爲他們提供一個清單，以幫助他們檢查強制性內容並確保以一致的方式審閱整個團隊的代碼。
包括您的整個團隊：不管您的程序員有多資深或經驗。每一個人都必須檢查代碼以及對其代碼進行檢查。當他們知道要檢查其代碼時，性能水平將相對提升。審查代碼時，請嘗試將架構師和開發人員包括在內。二者都將檢測到不一樣的問題，同時最終將影響整個應用程序的設計。
在任何須要的地方自動化：應該手動檢查代碼中的某些內容。還有其餘一些事情，可使用適當的工具進行檢查。在您不須要手動干預的地方實現自動化。諸如代碼分析器之類的工具會將代碼與編碼規則進行比較，並找出潛在的問題。
考慮代碼檢查以檢查跨瀏覽器的兼容性：咱們都知道，當特定的瀏覽器不支持特定的CSS樣式或JS功能時，就會發生Javascript，HTML / CSS的瀏覽器兼容性問題。
一旦咱們在某個應用程序上工做，該應用程序只能在Internet Explorer的較早版本中完美運行，所以某些樣式的使用受到了限制，該瀏覽器因與全部最新Web技術不兼容而給全世界的開發人員帶來了痛苦。
通過數週的編碼，進行了一次審查會議，結果發現，在編寫CSS時，在代碼的某些部分，咱們錯過了瀏覽器特定的供應商。當即進行更正，而後應用程序進入測試階段。不用說，它完美地經過了瀏覽器兼容性測試。若是不進行代碼審查，則可能會在跨瀏覽器測試期間發現缺陷，從而使開發人員急於找出致使問題的緣由。
培養積極的環境：從管理的角度來看，保持積極的工做文化很是重要，這是代碼審查最佳實踐的一部分。審查代碼時，積極的環境可能很是有幫助。誰引發了錯誤可有可無。重要的是已捕獲並修復了該錯誤。讚賞通信員，總的來講，這將有助於維持產品的質量。
依靠代碼查看工具：代替手動檢查和寫下問題，使用代碼查看工具能夠經過啓用內聯註釋和錯誤報告來節省工做量。

我但願您如今意識到SDLC中代碼審查的重要性，以及它與測試的區別。若是您是產品經理，那麼對於您而言，相當重要的是將代碼檢查過程歸入發佈週期，以防萬一，您能夠將其歸入其中。若是將其合併，則須要有效地組織帶寬和資源，並確保開發人員和測試人員都積極參與。若是您是一個QA，可是懼怕介入代碼審查，那麼您就須要改變見解，直接進入。最後，若是您是開發人員，則必須確保引入產品經理和軟件測試人員。代碼審查過程，以確保透明的透明度。審覈愉快！