前言

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

而即便你掌握了高超的技術(shù)，卻忽略了測試本質(zhì)，也很難讓你掌握的技術(shù)去服務(wù)于業(yè)務(wù)，服務(wù)于質(zhì)量。因此測試基本功對于測試人員的重要性不言而喻，所以在這里借花獻(xiàn)佛，在老師（狂師）指導(dǎo)下，對全棧測開訓(xùn)練營中前面針對測試人員基礎(chǔ)功修煉課程板塊中的一部分內(nèi)容做一個總結(jié)學(xué)習(xí)分享。

一、即便當(dāng)測試，也要當(dāng)優(yōu)秀的那位

測試作為項(xiàng)目最后一個環(huán)節(jié)，新的測試技術(shù)、手段、理念不斷出現(xiàn)，但是保證項(xiàng)目質(zhì)量的目標(biāo)沒有變。而深入到項(xiàng)目中，了解項(xiàng)目代碼、了解項(xiàng)目設(shè)計對于一個優(yōu)秀測試人員是必須具備的技能。

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

二、了解項(xiàng)目流程

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

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

三、關(guān)注架構(gòu)設(shè)計方案

關(guān)注項(xiàng)目的架構(gòu)設(shè)計，對測試人員有什么幫助？

1、能夠提前進(jìn)行測試工作，更早發(fā)現(xiàn)缺陷

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

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

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

測試人員該如何了解一個項(xiàng)目的架構(gòu)設(shè)計？

1. 從系統(tǒng)架構(gòu)圖入手

首先從系統(tǒng)架構(gòu)圖中，了解到有哪些服務(wù)，這些服務(wù)在每一層的分布情況；還有數(shù)據(jù)存儲、緩存，不同層之間進(jìn)行交互的協(xié)議。這樣能幫助我們快速對項(xiàng)目架構(gòu)有個大概的框架了解

2. 了解業(yè)務(wù)交互和數(shù)據(jù)流轉(zhuǎn)

接著可以通過閱讀流程圖、泳道圖、時序圖等，來幫助我們了解服務(wù)之間的業(yè)務(wù)交互關(guān)系，業(yè)務(wù)數(shù)據(jù)之間的流轉(zhuǎn)

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

• 技術(shù)架構(gòu)圖示例

圖片來源百度

多業(yè)務(wù)架構(gòu)圖示例

四、關(guān)注數(shù)據(jù)庫設(shè)計

從哪些方面去熟悉項(xiàng)目的數(shù)據(jù)庫情況:

1. 了解不同數(shù)據(jù)分別存儲在哪些數(shù)據(jù)庫中。因?yàn)橐恍?shù)據(jù)量大的項(xiàng)目，往往會根據(jù)業(yè)務(wù)實(shí)際情況，來把不同類型的數(shù)據(jù)存儲到不同的數(shù)據(jù)庫中。比如說經(jīng)常查詢的，會存在es/redis/clickhouse等數(shù)據(jù)庫；需要持久保留的數(shù)據(jù)，會存在mysql之類，等情況

2. 了解不同服務(wù)的數(shù)據(jù)存在哪個庫中，然后每個表都存哪些內(nèi)容，以及其中字段的意思和關(guān)聯(lián)（可以通過查詢數(shù)據(jù)庫設(shè)計文檔來了解）

3. 了解表之間的關(guān)聯(lián)性，比如說外鍵

4. 了解數(shù)據(jù)庫設(shè)計時的一些測試點(diǎn)（數(shù)據(jù)庫設(shè)計規(guī)則）

例如：

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

五、關(guān)注接口文檔

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

• 了解項(xiàng)目具體實(shí)現(xiàn)時
• 接口測試
• 性能測試

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

• 字段定義：字段類型、長度、是否是必填字段等字段屬性的定義
• 字段說明：每個字段是否都有字段的作用說明解釋，并且無歧義
• 請求示例：是否有正確和異常的請求內(nèi)容例子
• 請求規(guī)范：入?yún)L(fēng)格要統(tǒng)一，比如說日期格式如果是yyyy-mm-dd，那么所有接口都要這樣
• 響應(yīng)示例：是否有正確和異常的響應(yīng)示例
• 響應(yīng)規(guī)范：響應(yīng)內(nèi)容是否正確；響應(yīng)值是否有固定的格式規(guī)范，通常響應(yīng)結(jié)構(gòu)要規(guī)范統(tǒng)一，并且失敗情況要有字段說明失敗原因，以及統(tǒng)一的一套自定義狀態(tài)碼來對應(yīng)成功或各種失敗情況

六、關(guān)注服務(wù)的部署情況

如果項(xiàng)目有多個服務(wù)，并且是進(jìn)行分布式部署時，也需要了解這方面的情況。因?yàn)樵谶M(jìn)行性能測試在監(jiān)控和排查問題時，需要知道這些情況

七、閱讀開發(fā)代碼

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

• 結(jié)合代碼和需求，可以更加熟悉系統(tǒng)和業(yè)務(wù)
• 可以發(fā)現(xiàn)測試用例的遺漏點(diǎn)
• 結(jié)合代碼和需求，可以發(fā)現(xiàn)一些增量的bug（意思是本次的迭代會影響到哪些其它的功能模塊）

2. 如何review開發(fā)代碼？

• 和開發(fā)了解基本信息

首先和開發(fā)請教了解下代碼的結(jié)構(gòu)，比如哪些包對應(yīng)哪些服務(wù)的代碼，哪些是業(yè)務(wù)邏輯實(shí)現(xiàn)代碼，哪些是和數(shù)據(jù)庫進(jìn)行交互的，哪些是配置文件，哪些是接口定義文件等，這些有助于我們快速了解代碼結(jié)構(gòu)

• 針對增量代碼進(jìn)行review

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

• 帶著需求任務(wù)去看代碼

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

• review知識沉淀

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

八、熟悉項(xiàng)目配置文件

1. 在review配置文件內(nèi)容時，應(yīng)該關(guān)注的點(diǎn)：

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

九、總結(jié)

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