鑑定一下軟體測試熱門詞彙

測試奇譚發表於2021-09-22

鑑定一下軟體測試熱門詞彙。

(本期以一個簡單的電商平臺舉例,該平臺有商品管理、購物車管理、訂單管理、會員管理四個模組)

回滾

電商平臺釋出上線後,你熟悉的開啟商品頁面,進行線上驗證。

But,f**k,資料載入不出來!

image-20210921095726694

當開發大哥撓掉幾撮頭髮,依舊沒有找到問題原因時,只能眼神呆滯地望著你,丟了一句:我們回滾吧……

image-20210921095615038

於是,為了確保業務穩定,開發大哥將程式碼切換回到上一個正常的版本。這個切換操作就稱之為回滾——向前回到上一個穩定的版本。

髒資料

電商平臺釋出上線後,你熟悉的開啟頁面,進行線上驗證。

這次要驗證新增商品分類的功能,然而因為線上驗證流程的不規範,你在新增分類名時,將其打成“測試test”。

這樣的資料就叫髒資料——不符合環境規範的資料。

image-20210921100601549

如果使用者看不到這條資料,還可以刪資料挽回顏面;但如果看到了,並且產生了嚴重的影響,便會升級為線上事故,你得做好獎金被扣,亦或被辭退的準備。

空指標

你在電商平臺購買了一塊,卻發現包裹是空的——包裹裡沒有“物件”。

image-20210921101353943

你寫了兩行JAVA程式碼:

int[] array = null; 
System.out.println(array[0]);

執行時報了空指標錯誤java.lang.NullPointerException

image-20210922112704384

img

這是因為,array是null,不會建立新的物件(無記憶體地址),故在呼叫這個陣列時會產生空指標異常。

空指標——當呼叫的物件是空(一個指標不指向任何記憶體地址),而丟擲的異常。

微服務

在傳統的應用架構時,所有的系統都在一套程式碼上。

比如,開頭提到的簡單電商平臺,它有商品管理、購物車管理、訂單管理、會員管理四個模組。

試想,商品管理上新了一個功能,這套程式碼是不是要全量釋出?你得拉著負責購物車、訂單、會員管理的研發、測試一起加班上線,並且,一旦服務上線出現問題,其他服務也會跟著出問題。

微服務便可解決這類問題——將應用由原來的單體變成幾十上百個不同的應用,應用間通過介面、訊息等方式通訊。

image-20210921103849135

此外,微服務化後,不必每個系統都用同一種程式語言實現,比如商品系統,你可以用Java寫,購物車,你可以用Python寫……

分散式

有了微服務的概念後,便能很好理解分散式。

將不同的應用部署到不同的伺服器上,就叫分散式部署。比如,將商品系統部署到A伺服器上,將購物車系統部署到B伺服器上。

此外,將單個應用的各元件分開部署,也叫分散式部署。

比如,一個會員系統,它有資料庫(管理增刪改查會員資料),有前端頁面(展示會員資訊等樣式),有中介軟體(收發訊息,如訂單完成,會通知會員系統給該會員增加積分)等等。也可以採取分散式部署,將這些元件部署到不同的伺服器上。

image-20210921103726823

總的來說:

微服務是分散能力,即,可廣義理解為將一個應用拆分為多個應用,它是一種設計方法。

分散式是分散壓力,即,將服務部署到不同的伺服器上,解決高併發類問題,它是一種部署方式。

叢集

多臺伺服器部署同一個應用,便構成該應用的叢集。

比如,有十臺伺服器部署的會員服務,那就叫會員系統叢集。

image-20210921104002412

負載均衡

實現了分散式+叢集,就必須考慮負載均衡。

還是拿會員服務舉例。

假設一臺伺服器只能支援100個使用者同時檢視會員積分,但在雙11時,同時有1000人檢視會員積分,該怎麼辦?

image-20210921104214700

方法一:不增加伺服器,讓使用者排隊,先請求到的先查到,但是,你得處理10個批次,如果每個批次用時1s,那麼有的使用者可能會等待10s之久。

方法二:再增加9臺伺服器,支援1s內同時允許1000名使用者檢視會員積分。

一般來說,選擇方法一的都是傘兵。但是,方法二仍舊有問題,如果這1000個使用者,同時請求到一臺伺服器了,還不得回到原點?

這時,便需要負載均衡——你可以簡單理解為將這1000個查詢請求(將負載)平均(進行平衡)分到(分攤到)10臺伺服器(各個操作單元上)。

全鏈路

前面講到了微服務,將單個服務拆分成多個系統,每個系統即獨立執行,又相互關聯。

那麼,這些系統相互關聯形成的流程鏈條,就稱為全鏈路。

比如:登入會員—>查詢商品—>將商品加入到購物車—>下單成功—>會員記錄積分。

這樣一個完整的流程,就是一個加購下單全鏈路。

image-20210921104402732

最後

我們們懷著欣慰的心情,學學如何寫bug。

image-20210921142048454

image-20210921142938471

image-20210921143052620

image-20210921142644750

下回

攢夠一波,再跟大家鑑定一下軟體測試熱門詞彙。


測試奇譚,BUG不見。

大家好,我是譚叔。

節前,一位群友說她沒接觸過後端測試,不懂回滾、髒資料、空指標等詞彙。於是,我安排了這篇文章。

image-20210921143231596

image-20210921144312305

當然,為了方便大家快速理解,有的地方,我講得很淺、很片面,不過,你完全可以就著理解方向再去細化學習,以掌握到更多知識。

看到這裡,有的人可能會問:作為一枚測試,我幹嘛要關心這些詞彙?

道理很簡單:一名測試連待測系統“長”什麼樣子,都不知道,很不專業,會漏測很多東西。

比如,你測試的系統,線上環境資料庫是讀寫分離的,有一個主庫和多個從庫,而測試環境為了節省資源,只配置了一個主庫。那麼,一些由主從延遲引發的業務問題,你就無法覆蓋測試,或者說,你都不知道該怎麼測試。

so,要不要了解,要不要學習,看你自己~

最後,如果你還有弄不懂的詞彙,歡迎評論留言,下回攢夠一波,再跟大家鑑定軟體測試熱門詞彙。

image-20210921142522240

相關文章