前言
大家好，我是林宗霖，是一位測試工程師，也是全棧測開訓練營中的一名學員。學習完全棧測開訓練營的課程，讓自己更加意識到：基礎不牢，地動山搖的道理。近兩年，行業的很多小夥伴都熱衷於自動化、測試開發等方面的技術，而忽略了測試基本功的修煉！
而即便你掌握了高超的技術，卻忽略了測試本質，也很難讓你掌握的技術去服務於業務，服務於質量。因此測試基本功對於測試人員的重要性不言而喻，所以在這裡借花獻佛，在得到老師許可下，對全棧測開訓練營中關於測試人員基礎功修煉課程中的一部分內容做一個總結學習分享。
一、即便是測試，也要當優秀的那位
測試作為專案最後一個環節，新的測試技術、手段、理念不斷出現，但是保證專案質量的目標沒有變。而深入到專案中，瞭解專案程式碼、瞭解專案設計對於一個優秀測試人員是必須具備的技能。
下面分別從如下幾個方面去介紹，測試人員，如何更為系統性的去深入瞭解一個專案。
二、瞭解專案流程
大部分專案，從需求確定到最後上線的大概流程：
測試人員從需求評審階段參與進來，在技術方案設計與評審時一定要參與，目的是要了解開發的設計實現思路，在過程中也可以找出思路的不足或漏洞。這階段參與進去，能幫助測試人員更好地設計測試方案（注意點是不要被開發的設計思路主導，這樣會影響用例設計的思路）
三、關注架構設計方案
關注專案的架構設計，對測試人員有什麼幫助？
1、能夠提前進行測試工作，更早發現缺陷
這一點和上面建議在技術方案設計和評審時，測試人員也參與進去的目的類似。只不過在架構設計階段，絕大部分測試人員是不具備“對架構設計評審發現問題”這一能力，但是參與進來了解，也可以逐步提升這方面的思維能力。
2、能夠幫助測試人員更全面、更有針對性地進行測試
- 瞭解架構設計，能夠讓測試人員瞭解到專案各個服務之間的關係，業務互動，資料儲存，資料流動等情況，從而能夠讓測試人員更有針對性地進行測試用例的設計
- 如果需要進行效能測試，甚至全鏈路壓測，更需要對架構非常熟悉以及開發框架的熟悉。否則如果不清楚整個系統的架構設計，可能設計出的壓測方案都有問題，更沒辦法對壓測結果進行分析和問題定位
測試人員該如何瞭解一個專案的架構設計？
1. 從系統架構圖入手
首先從系統架構圖中，瞭解到有哪些服務，這些服務在每一層的分佈情況；還有資料儲存、快取，不同層之間進行互動的協議。這樣能幫助我們快速對專案架構有個大概的框架了解
2. 瞭解業務互動和資料流轉
接著可以通過閱讀流程圖、泳道圖、時序圖等，來幫助我們瞭解服務之間的業務互動關係，業務資料之間的流轉
ps. 團隊中如果沒有這些，甚至開發人員沒時間寫，那麼測試人員可以通過詢問開發來自己完成這些
- 技術架構圖示例
圖片來源百度
多業務架構圖示例
四、關注資料庫設計
從哪些方面去熟悉專案的資料庫情況:
-
瞭解不同資料分別儲存在哪些資料庫中。因為一些資料量大的專案，往往會根據業務實際情況，來把不同型別的資料儲存到不同的資料庫中。比如說經常查詢的，會存在es/redis/clickhouse等資料庫；需要持久保留的資料，會存在mysql之類，等情況
-
瞭解不同服務的資料存在哪個庫中，然後每個表都存哪些內容，以及其中欄位的意思和關聯（可以通過查詢資料庫設計文件來了解）
-
瞭解表之間的關聯性，比如說外來鍵
-
瞭解資料庫設計時的一些測試點（資料庫設計規則）
例如：
- 欄位型別是否符合實際情況。比如說一些資料量大的整數型別設定成了int，其實使用bigint更加合理
- 欄位長度設定是否合理。比如說一些欄位在需求設計、前端、介面都進行了50長度限制，但是在資料庫中卻設計了1000的長度，明顯不合理
- 欄位是否為空的設定是否和實際情況相符。比如說需求和介面設計中，欄位A可以為空，但是表設計中卻設定了NOT NULL，這樣介面傳遞空資料到資料庫時，會報錯
- 是否需要進行分庫分表。在資料量激增時，是否需要進行分庫分表修改
- 是否存在冗餘欄位。一些用不上的欄位是否需要進行刪除
- 表之間的關聯是否合理
- 讀寫分離設計是否合理
- ...
五、關注介面文件
1. 大部分時候，哪些情況需要去關注介面文件
- 瞭解專案具體實現時
- 介面測試
- 效能測試
2. 在閱讀介面文件時，需要注意以下幾個方面（如果沒有，則可以推動改進）
- 欄位定義：欄位型別、長度、是否是必填欄位等欄位屬性的定義
- 欄位說明：每個欄位是否都有欄位的作用說明解釋，並且無歧義
- 請求示例：是否有正確和異常的請求內容例子
- 請求規範：入參風格要統一，比如說日期格式如果是yyyy-mm-dd，那麼所有介面都要這樣
- 響應示例：是否有正確和異常的響應示例
- 響應規範：響應內容是否正確；響應值是否有固定的格式規範，通常響應結構要規範統一，並且失敗情況要有欄位說明失敗原因，以及統一的一套自定義狀態碼來對應成功或各種失敗情況
六、關注服務的部署情況
如果專案有多個服務，並且是進行分散式部署時，也需要了解這方面的情況。因為在進行效能測試在監控和排查問題時，需要知道這些情況
七、閱讀開發程式碼
- 閱讀程式碼對測試人員的好處
- 結合程式碼和需求，可以更加熟悉系統和業務
- 可以發現測試用例的遺漏點
- 結合程式碼和需求，可以發現一些增量的bug（意思是本次的迭代會影響到哪些其它的功能模組）
- 如何review開發程式碼？
- 和開發瞭解基本資訊
首先和開發請教了解下程式碼的結構，比如哪些包對應哪些服務的程式碼，哪些是業務邏輯實現程式碼，哪些是和資料庫進行互動的，哪些是配置檔案，哪些是介面定義檔案等，這些有助於我們快速瞭解程式碼結構
- 針對增量程式碼進行review
大部分情況是沒有足夠的時間閱讀所有的程式碼。那麼我們可以選擇增量程式碼進行Review。檢查是否存在功能遺漏，邏輯錯誤，是否對原有的功能造成了影響之類
- 帶著需求任務去看程式碼
意思就是首先弄清楚本次迭代有哪些需求，熟悉了需求，編寫了測試用例後，帶著這些功能的實現是否存在問題的心理，去看開發程式碼。主要關注業務邏輯的實現以及介面引數定義的部分。不要關注配置以及其他和業務邏輯無關的地方，避免陷入到和業務邏輯實現無關的細節中。
- review知識沉澱
在review完成後，需要對發現的問題進行整理歸類。這樣既可以在後面的測試過程中做為測試用例的補充，也可以形成自己的一套知識沉澱。在review完成後，可以嘗試著去畫出服務的流程圖、專案架構圖，可以幫助自己對專案理解更深入
八、熟悉專案配置檔案
1. 在review配置檔案內容時，應該關注的點：
- 不同環境的配置檔案需要區分開，以防止將測試環境的配置同步到生產環境上
- 一些功能可以進行配置話，比如說灰度測試的流量限流，降級服務的開關，外部依賴的開關（比如說供應商的上下線）
- 業務引數的配置，一些業務引數可能需要靈活配置，比如說活動的規則、抽獎的概率、臨時的訊息通知等
- 中介軟體的配置，比如說
tomcat、redis、mq、mysql之類的配置，這些對環境、效能、任務排程等有關 - 資料庫需要注意時區的問題，如果es需注意時間欄位儲存的值型別和查詢語句對應的時間欄位值的型別需一致
九、總結
上面的這些注意事項，在實際工作中很少能一次性全部做得到的，這篇文章主要是希望能夠起到個指導方向的作用，拋磚引玉，如果有寫的不對的地方，或有不同的見解，歡迎指出來一起討論。