您好,登錄后才能下訂單哦!
這篇文章主要介紹了軟件測試業務梳理的實用技巧有哪些的相關知識,內容詳細易懂,操作簡單快捷,具有一定借鑒價值,相信大家閱讀完這篇軟件測試業務梳理的實用技巧有哪些文章都會有所收獲,下面我們一起來看看吧。
因為在業務測試中,作為測試人員,熟悉負責的業務是非常重要的,而通過階段性的梳理總結,可以讓你的業務知識系統化的沉淀下來。
當被問起這個業務系統的測試重點在哪里?難點如何克服?為什么要這樣設計等等問題,可以有條不紊的進行輸出。
又或者,當你任務需要交接,或者需要別人支援你的業務,你可以自信的把文檔丟過去,拍拍胸脯說:看一遍你就知道了。
同樣大家平時都在做業務,同樣并沒有多少別的技術層的產出,這也是為什么有人能拿A,有人卻只能拿C的原因之一。
另外,當你有了多種業務的沉淀之后,你甚至可以提煉出很多通用性的東西,姑且稱為“方法論”吧。
優點這么多,如何進行梳理呢?這里我參照常規的服務系統,寫一些思路(框架),僅供參考。
這部分可以整理出業務系統的測試場景。
可以重點貼出核心的測試場景,附帶上全量的測試用例。如果用例有后續迭代,也可以根據時間和內容進行分分類,放在這里。
這里就可以整理有關業務的更多細分領域。比如:
1)各種配置
業務涉及到的各種后臺配置、后臺地址、配置影響范圍、必須非必須配置、配置順序、特殊注意項等等。
2)前端
涉及到的產品前端功能是哪些、重要鏈接、主要的前端交互等等。
3)核心流程
梳理業務的核心流程,可以包含對用戶的操作流程,以及對應交互的接口。
另外,可以自己手動畫一畫核心業務流程圖,一般產品會給出,但是有時間自己畫一畫,腦海里再過一過更加深刻,說不定還有意外發現來補充測試設計。
還有一個重點就是業務數據的處理過程,如果涉及到其他像kafka、es、緩存等中間件,數據處理的細節也可以整理出來。
4)問題排查
在測試工作中一定會遇到雜七雜八的問題,抽出一些典型問題,記錄下排查手段以及可能因素,方便自己以及其他人查看。
業務層梳理完,就應該關注應用服務層的了。
1)應用站點
可以從入口往下,整理出業務系統下各個站點,服務名稱、作用等信息。
2)接口與日志
這里可以匯總下接口文檔,根據不同情況進行分類,反正目的就是為了高效查看對應文檔。
在測試過程中如何查看關鍵性的日志也很重要,對理解接口交互,排查問題都很有幫助。這里可以記錄不同流程,涉及到的站點,如果過濾日志等信息。
3)MQ消息
記錄交互的 MQ 有哪些,topic、不同tag的作用是什么、消息體等等。
4)異常機制
記錄下系統都有哪些異常的處理機制,常見的比如超時、重試、補償、兜底等等。
到了數據層了,自是來不開 mysql 、緩存、mongoDB等等。
梳理好各數據庫名,用來處理什么,核心的表以及關鍵的字段,比如一些訂單類型、狀態等等。
redis這些nosql數據庫,梳理重要的 key、field、value等等。
比如接口的鑒權機制,一些涉及到更復雜加密處理的接口的細節。
還有一些并發操作類的控制也可以整理出來。
通常是單接口和鏈路場景的性能。
1)接口性能
比如:前端用戶體驗最直觀的接口、創單接口、詳情接口、預處理接口等等。
2)鏈路性能
最核心的鏈路場景,串起來進行壓測。
3)限流
如果涉及到限流的場景,可以進一步整理出考慮限流的因素,觸發的機制,處理的手段等。
數據是多樣的,比如日志數據、埋點數據、或者后臺看板大屏的數據,列出需要關心的點,以及數據的正常趨勢、不正常的趨勢。
通常就是測試右移后關注的點,可以監控線上運行的服務,對核心業務接口的一些常規指標進行監控。另外對日志系統不同類型的日志數量監控也有必要。
如果運維配套系統比較完備的話,我們測試自己就可以進行配置了,如果沒有的話,積極的參與其中吧。
一些核心業務系統,可能還會針對極端情況有應急預案。比如機房切換、災備預案等。
關于“軟件測試業務梳理的實用技巧有哪些”這篇文章的內容就介紹到這里,感謝各位的閱讀!相信大家對“軟件測試業務梳理的實用技巧有哪些”知識都有一定的了解,大家如果還想學習更多知識,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。