前言

大家好，我是林宗霖，是一位測試工程師，也是全棧測開訓練營中的一名學員。學習完全棧測開訓練營的課程，讓自己更加意識到：基礎不牢，地動山搖的道理。近兩年，行業的很多小伙伴都熱衷于自動化、測試開發等方面的技術，而忽略了測試基本功的修煉！

而即便你掌握了高超的技術，卻忽略了測試本質，也很難讓你掌握的技術去服務于業務，服務于質量。因此測試基本功對于測試人員的重要性不言而喻，所以在這里借花獻佛，在得到老師許可下，對全棧測開訓練營中關于測試人員基礎功修煉課程中的一部分內容做一個總結學習分享。

一、即便是測試，也要當優秀的那位

測試作為項目最后一個環節，新的測試技術、手段、理念不斷出現，但是保證項目質量的目標沒有變。而深入到項目中，了解項目代碼、了解項目設計對于一個優秀測試人員是必須具備的技能。

下面分別從如下幾個方面去介紹，測試人員，如何更為系統性的去深入了解一個項目。

二、了解項目流程

大部分項目，從需求確定到最后上線的大概流程：

測試人員從需求評審階段參與進來，在技術方案設計與評審時一定要參與，目的是要了解開發的設計實現思路，在過程中也可以找出思路的不足或漏洞。這階段參與進去，能幫助測試人員更好地設計測試方案（注意點是不要被開發的設計思路主導，這樣會影響用例設計的思路）

三、關注架構設計方案

關注項目的架構設計，對測試人員有什么幫助？

1、能夠提前進行測試工作，更早發現缺陷

這一點和上面建議在技術方案設計和評審時，測試人員也參與進去的目的類似。只不過在架構設計階段，絕大部分測試人員是不具備“對架構設計評審發現問題”這一能力，但是參與進來了解，也可以逐步提升這方面的思維能力。

2、能夠幫助測試人員更全面、更有針對性地進行測試

• 了解架構設計，能夠讓測試人員了解到項目各個服務之間的關系，業務交互，數據存儲，數據流動等情況，從而能夠讓測試人員更有針對性地進行測試用例的設計
• 如果需要進行性能測試，甚至全鏈路壓測，更需要對架構非常熟悉以及開發框架的熟悉。否則如果不清楚整個系統的架構設計，可能設計出的壓測方案都有問題，更沒辦法對壓測結果進行分析和問題定位

測試人員該如何了解一個項目的架構設計？

1. 從系統架構圖入手

首先從系統架構圖中，了解到有哪些服務，這些服務在每一層的分布情況；還有數據存儲、緩存，不同層之間進行交互的協議。這樣能幫助我們快速對項目架構有個大概的框架了解

2. 了解業務交互和數據流轉

接著可以通過閱讀流程圖、泳道圖、時序圖等，來幫助我們了解服務之間的業務交互關系，業務數據之間的流轉

ps. 團隊中如果沒有這些，甚至開發人員沒時間寫，那么測試人員可以通過詢問開發來自己完成這些

• 技術架構圖示例

圖片來源百度

多業務架構圖示例

四、關注數據庫設計

從哪些方面去熟悉項目的數據庫情況:

1. 了解不同數據分別存儲在哪些數據庫中。因為一些數據量大的項目，往往會根據業務實際情況，來把不同類型的數據存儲到不同的數據庫中。比如說經常查詢的，會存在es/redis/clickhouse等數據庫；需要持久保留的數據，會存在mysql之類，等情況

2. 了解不同服務的數據存在哪個庫中，然后每個表都存哪些內容，以及其中字段的意思和關聯（可以通過查詢數據庫設計文檔來了解）

3. 了解表之間的關聯性，比如說外鍵

4. 了解數據庫設計時的一些測試點（數據庫設計規則）

例如：

• 字段類型是否符合實際情況。比如說一些數據量大的整數類型設置成了int，其實使用bigint更加合理
• 字段長度設置是否合理。比如說一些字段在需求設計、前端、接口都進行了50長度限制，但是在數據庫中卻設計了1000的長度，明顯不合理
• 字段是否為空的設置是否和實際情況相符。比如說需求和接口設計中，字段A可以為空，但是表設計中卻設置了NOT NULL，這樣接口傳遞空數據到數據庫時，會報錯
• 是否需要進行分庫分表。在數據量激增時，是否需要進行分庫分表修改
• 是否存在冗余字段。一些用不上的字段是否需要進行刪除
• 表之間的關聯是否合理
• 讀寫分離設計是否合理
• ...

五、關注接口文檔

1. 大部分時候，哪些情況需要去關注接口文檔

• 了解項目具體實現時
• 接口測試
• 性能測試

2. 在閱讀接口文檔時，需要注意以下幾個方面（如果沒有，則可以推動改進）

• 字段定義：字段類型、長度、是否是必填字段等字段屬性的定義
• 字段說明：每個字段是否都有字段的作用說明解釋，并且無歧義
• 請求示例：是否有正確和異常的請求內容例子
• 請求規范：入參風格要統一，比如說日期格式如果是yyyy-mm-dd，那么所有接口都要這樣
• 響應示例：是否有正確和異常的響應示例
• 響應規范：響應內容是否正確；響應值是否有固定的格式規范，通常響應結構要規范統一，并且失敗情況要有字段說明失敗原因，以及統一的一套自定義狀態碼來對應成功或各種失敗情況

六、關注服務的部署情況

如果項目有多個服務，并且是進行分布式部署時，也需要了解這方面的情況。因為在進行性能測試在監控和排查問題時，需要知道這些情況

七、閱讀開發代碼

1. 閱讀代碼對測試人員的好處

• 結合代碼和需求，可以更加熟悉系統和業務
• 可以發現測試用例的遺漏點
• 結合代碼和需求，可以發現一些增量的bug（意思是本次的迭代會影響到哪些其它的功能模塊）

2. 如何review開發代碼？

• 和開發了解基本信息

首先和開發請教了解下代碼的結構，比如哪些包對應哪些服務的代碼，哪些是業務邏輯實現代碼，哪些是和數據庫進行交互的，哪些是配置文件，哪些是接口定義文件等，這些有助于我們快速了解代碼結構

• 針對增量代碼進行review

大部分情況是沒有足夠的時間閱讀所有的代碼。那么我們可以選擇增量代碼進行Review。檢查是否存在功能遺漏，邏輯錯誤，是否對原有的功能造成了影響之類

• 帶著需求任務去看代碼

意思就是首先弄清楚本次迭代有哪些需求，熟悉了需求，編寫了測試用例后，帶著這些功能的實現是否存在問題的心理，去看開發代碼。主要關注業務邏輯的實現以及接口參數定義的部分。不要關注配置以及其他和業務邏輯無關的地方，避免陷入到和業務邏輯實現無關的細節中。

• review知識沉淀

在review完成后，需要對發現的問題進行整理歸類。這樣既可以在后面的測試過程中做為測試用例的補充，也可以形成自己的一套知識沉淀。在review完成后，可以嘗試著去畫出服務的流程圖、項目架構圖，可以幫助自己對項目理解更深入

八、熟悉項目配置文件

1. 在review配置文件內容時，應該關注的點：

• 不同環境的配置文件需要區分開，以防止將測試環境的配置同步到生產環境上
• 一些功能可以進行配置話，比如說灰度測試的流量限流，降級服務的開關，外部依賴的開關（比如說供應商的上下線）
• 業務參數的配置，一些業務參數可能需要靈活配置，比如說活動的規則、抽獎的概率、臨時的消息通知等
• 中間件的配置，比如說tomcat、redis、mq、mysql之類的配置，這些對環境、性能、任務調度等有關
• 數據庫需要注意時區的問題，如果es需注意時間字段存儲的值類型和查詢語句對應的時間字段值的類型需一致

九、總結

上面的這些注意事項，在實際工作中很少能一次性全部做得到的，這篇文章主要是希望能夠起到個指導方向的作用，拋磚引玉，如果有寫的不對的地方，或有不同的見解，歡迎指出來一起討論。