軟件測試業務梳理的實用技巧

Posted on by

測試業務梳理

在日常的測試工作中，不知道大傢是否會有梳理自己測試業務的習慣。我個人覺得這個事情是值得做的，最好還可以培養成一個習慣。

一、為什麼要梳理業務？

因為在業務測試中，作為測試人員，熟悉負責的業務是非常重要的，而通過階段性的梳理總結，可以讓你的業務知識系統化的沉淀下來。

當被問起這個業務系統的測試重點在哪裡？難點如何克服？為什麼要這樣設計等等問題，可以有條不紊的進行輸出。

又或者，當你任務需要交接，或者需要別人支援你的業務，你可以自信的把文檔丟過去，拍拍胸脯說：看一遍你就知道瞭。

同樣大傢平時都在做業務，同樣並沒有多少別的技術層的產出，這也是為什麼有人能拿A，有人卻隻能拿C的原因之一。

另外，當你有瞭多種業務的沉淀之後，你甚至可以提煉出很多通用性的東西，姑且稱為“方法論”吧。

二、梳理框架

優點這麼多，如何進行梳理呢？這裡我參照常規的服務系統，寫一些思路(框架)，僅供參考。

1. 測試場景

這部分可以整理出業務系統的測試場景。

可以重點貼出核心的測試場景，附帶上全量的測試用例。如果用例有後續迭代，也可以根據時間和內容進行分分類，放在這裡。

2. 業務

這裡就可以整理有關業務的更多細分領域。比如：

1)各種配置

業務涉及到的各種後臺配置、後臺地址、配置影響范圍、必須非必須配置、配置順序、特殊註意項等等。

2)前端

涉及到的產品前端功能是哪些、重要鏈接、主要的前端交互等等。

3)核心流程

梳理業務的核心流程，可以包含對用戶的操作流程，以及對應交互的接口。

另外，可以自己手動畫一畫核心業務流程圖，一般產品會給出，但是有時間自己畫一畫，腦海裡再過一過更加深刻，說不定還有意外發現來補充測試設計。

還有一個重點就是業務數據的處理過程，如果涉及到其他像kafka、es、緩存等中間件，數據處理的細節也可以整理出來。

4)問題排查

在測試工作中一定會遇到雜七雜八的問題，抽出一些典型問題，記錄下排查手段以及可能因素，方便自己以及其他人查看。

3. 系統

業務層梳理完，就應該關註應用服務層的瞭。

1)應用站點

可以從入口往下，整理出業務系統下各個站點，服務名稱、作用等信息。

2)接口與日志

這裡可以匯總下接口文檔，根據不同情況進行分類，反正目的就是為瞭高效查看對應文檔。

在測試過程中如何查看關鍵性的日志也很重要，對理解接口交互，排查問題都很有幫助。這裡可以記錄不同流程，涉及到的站點，如果過濾日志等信息。

3)MQ消息

記錄交互的 MQ 有哪些，topic、不同tag的作用是什麼、消息體等等。

4)異常機制

記錄下系統都有哪些異常的處理機制，常見的比如超時、重試、補償、兜底等等。

4. 數據

到瞭數據層瞭，自是來不開 mysql 、緩存、mongoDB等等。

梳理好各數據庫名，用來處理什麼，核心的表以及關鍵的字段，比如一些訂單類型、狀態等等。

redis這些nosql數據庫，梳理重要的 key、field、value等等。

5. 安全

比如接口的鑒權機制，一些涉及到更復雜加密處理的接口的細節。

還有一些並發操作類的控制也可以整理出來。

6. 性能

通常是單接口和鏈路場景的性能。

1)接口性能

比如：前端用戶體驗最直觀的接口、創單接口、詳情接口、預處理接口等等。

2)鏈路性能

最核心的鏈路場景，串起來進行壓測。

3)限流

如果涉及到限流的場景，可以進一步整理出考慮限流的因素，觸發的機制，處理的手段等。

7. 數據分析

數據是多樣的，比如日志數據、埋點數據、或者後臺看板大屏的數據，列出需要關心的點，以及數據的正常趨勢、不正常的趨勢。

8. 監控報警

通常就是測試右移後關註的點，可以監控線上運行的服務，對核心業務接口的一些常規指標進行監控。另外對日志系統不同類型的日志數量監控也有必要。

如果運維配套系統比較完備的話，我們測試自己就可以進行配置瞭，如果沒有的話，積極的參與其中吧。

9. 應急預案

一些核心業務系統，可能還會針對極端情況有應急預案。比如機房切換、災備預案等。

以上就是軟件測試業務梳理的實用技巧的詳細內容，更多關於軟件測試業務梳理的資料請關註WalkonNet其它相關文章！

推薦閱讀：