1 軟體研發的風險本質
軟體研發過程是個集體性的活動， 團隊工作在一起的目標就是在規定的時間內完成原計劃的特性並交付上線， 而其過程中不免有多種風險因素的存在。 作為一名QA， 我時常在思考， 軟體研發過程中的風險究竟是怎樣引入的， 其本質因素又是什麼。 我們先暫時放下這個問題， 來看一下QA的角色價值。
交付上線後的軟體版本作為整個反覆運算完成後最重要的輸出物， 其實也是我們在反覆運算內所有工作圍繞的核心所在。 我們大體上都會有這樣的一種共識， 反覆運算結束後，
說到這裡， 上面提到的風險引入的本質因素貌似有了答案：是新的需求引入了風險， 這貌似是教科書上的經典答案。 我們可以再深入思考一下：需求會是團隊反覆運算結束後的最終交付物嗎？顯然不是。 所有需求最終都會轉化為軟體實際的功能、性能等方面的實現。 而軟體功能、性能的實現本質上是由一行行代碼組成的， 因此我們覺得軟體研發過程中風險的本質因素是代碼發生了變化。
2 QA判斷測試範圍與重點的常見痛點
開發作為軟體代碼的實際生產者， 在提測的時候， 往往會被QA要求告知本次提測功能變更的實際區域， 因為QA需要通過開發傳遞的這些資訊輸出來判斷接下來的測試範圍和測試重點。 開發傳遞這些資訊的方式大體有郵件描述、口頭溝通等， 但這些方式往往會存在如下兩個痛點：
開發告知的變更是基於其自身的主觀判斷， 有時可能會存在遺漏和遺忘。
語言和文字在資訊傳遞的過程中， 往往會存在不同人對其理解有一定差異性的情況。
由於上述兩點痛點問題， QA在判斷測試範圍和測試重點時可能會存在一定程度上的非客觀性，
3 代碼變更風險分析平臺與服務化
在代碼變更風險分析的平臺化實踐上， 為了綜合判斷代碼的品質風險， 我們整合了多維度的分析資料和資訊， 其中包括實際的代碼diff， 新增/刪除代碼行數， 子類數， 類的扇入（有多少其它類會調用）、扇出（會調用多少其它類）， 極高/高/中圈複雜度（複雜度越高的方法和類越容易產生bug）等。 下面採用問題驅動的方式， 分三個維度來講講平臺的具體思考與實現。
3.1 誰會使用該平臺服務
平臺最開始的用戶群定位在QA群體，
3.2 他們會怎樣使用該平臺服務
在時間比較緊張的情況， 使用者可能想利用非常短的時間， 快速地瞭解整體的風險資訊。 對此平臺採用了視覺化的手段將風險資訊聚合在了一張圖上， 從而幫助使用者快速的掌握整體風險資訊。
上面的這張圖是某專案的整個工程的拓撲圖。 每個圓圈代表的是一個類檔；類與類之間的連線代表了他們之間關聯關係（子類、扇入、扇出）， 越是中間區域的類表示被依賴的越多， 也越是底層；圓圈的直徑大小代表了檔代碼行的變動量， 越大表示變動越大；顏色色系的深淺代表了複雜度的大小， 越深複雜度越高。
如果一次代碼變動導致某些中間區域的、深色的圓圈直徑變得很大， 這代表著這次的代碼變更風險會比較大， 這應該引起QA的高度重視， 應考慮增加相應的測試力度。 在時間比較寬裕，同時對整個專案代碼結構有大致瞭解的前提下，使用者可能想更詳細的瞭解一下具體的變更資訊。對此平臺採用了表格矩陣的方式展示每個類檔的多維度資訊，從而説明使用者更細細微性的掌握風險資訊。如下圖：
在時間比較寬裕，同時對整個項目代碼又非常瞭解的前提下，使用者可能想在平臺上直接能看到具體的代碼diff。對此平臺採用了類似gitlab等代碼倉庫管理平臺，用頁面的方式，展示具體代碼diff，從而幫助使用者最細力度的掌握風險資訊。如下圖：
3.3 他們會在哪些場景下觸發使用該平臺服務
在代碼的開發過程中，使用者可能期望在開發分支上通過對比不同revision，來及時瞭解和掌握代碼變更的綜合資訊。
在提測的時候，使用者可能期望將提測分支與線上分支進行對比，來瞭解和掌握這個版本所有代碼變更的綜合資訊。
在回歸測試中，開發修復bug後會要求QA重新基於修復版本進行測試，使用者可能期望在提測分支上通過對比修復bug前後的不同revision，來瞭解和掌握針對這些bug修復所做出的代碼變更的綜合資訊。
上線後，對於hotfix，使用者可能期望在hotfix分支上通過對比hotfix前後不同revision，來瞭解和掌握代碼變更的綜合資訊。
上述四種使用場景基本覆蓋了QA活動過程中最常見的一些類型，對此平臺通過實現不同分支之間的對比、分支內不同revision之間的對比兩種方式實現了上述四種使用場景的全覆蓋。
網易企業服務-企業資訊化服務提供者
湖南領先網路科技有限公司 hnling.com
在時間比較寬裕，同時對整個專案代碼結構有大致瞭解的前提下，使用者可能想更詳細的瞭解一下具體的變更資訊。對此平臺採用了表格矩陣的方式展示每個類檔的多維度資訊，從而説明使用者更細細微性的掌握風險資訊。如下圖：
在時間比較寬裕，同時對整個項目代碼又非常瞭解的前提下，使用者可能想在平臺上直接能看到具體的代碼diff。對此平臺採用了類似gitlab等代碼倉庫管理平臺，用頁面的方式，展示具體代碼diff，從而幫助使用者最細力度的掌握風險資訊。如下圖：
3.3 他們會在哪些場景下觸發使用該平臺服務
在代碼的開發過程中，使用者可能期望在開發分支上通過對比不同revision，來及時瞭解和掌握代碼變更的綜合資訊。
在提測的時候，使用者可能期望將提測分支與線上分支進行對比，來瞭解和掌握這個版本所有代碼變更的綜合資訊。
在回歸測試中，開發修復bug後會要求QA重新基於修復版本進行測試，使用者可能期望在提測分支上通過對比修復bug前後的不同revision，來瞭解和掌握針對這些bug修復所做出的代碼變更的綜合資訊。
上線後，對於hotfix，使用者可能期望在hotfix分支上通過對比hotfix前後不同revision，來瞭解和掌握代碼變更的綜合資訊。
上述四種使用場景基本覆蓋了QA活動過程中最常見的一些類型，對此平臺通過實現不同分支之間的對比、分支內不同revision之間的對比兩種方式實現了上述四種使用場景的全覆蓋。
網易企業服務-企業資訊化服務提供者
湖南領先網路科技有限公司 hnling.com