目錄
一、禪道
一、測驗工具背景
二、測驗管理工具
三、測驗工具介紹
四、禪道介紹
五、禪道操作
7. 創建發布
8. 測驗團隊
二、缺陷報告
三、測驗報告
一、概要
二、測驗程序
三、缺陷分析
四、測驗總結
四、介面測驗以及用例撰寫
五、Fiddler
好文推薦
一、禪道
一、測驗工具背景
當測驗環境搭建完成后,測驗人員將在自己搭建的環境上執行測驗用例,開展測驗作業,測驗人員在執行測驗用例的程序中,如發現實際結果與預期結果不一致, 則意味著出現Bug (缺陷、錯誤、問題),當測驗人員發現了Bug之后,就需要把Bug提交給開發人員進行修復,那測驗人員應如何記錄一個Bug呢?測驗人員通過什么工具把Bug轉發給開發人員的呢?測驗人員提交完Bug后又如何做回歸測驗呢?本章將對提交Bug所涉及的各種問題進行詳細介紹,提交Bug不僅僅是測驗人員價值的體現,也是測驗人員迓開發人員溝通的重要橋梁,Bug 的數量和質量將會對軟體質量的改善起到重要的推動作用,
二、測驗管理工具
測驗管理工具是指在軟體開發程序中,對測驗需求、計劃、用例和實施程序進行管理、對軟體缺陷進行跟蹤處理的工具,通過使用測驗管理工具,測驗人員或開發人員可以更方便地記錄和監控每個測驗活動、階段的結果,找出軟體的缺陷和錯誤,記錄測驗活動中發現的缺陷和改進建議,通過使用測驗管理工具,測驗用例可以被多個測驗活動或階段復用,可以輸出測驗分析報告和統計報表,有些測驗管理工具可以更好地支持協同操作,共享中央資料庫,支持并行測驗和記錄,從而大大提高測驗效率,
三、測驗工具介紹
目前市場上主流的軟體測驗管理工具有:TestCenter(澤眾軟體出品)、TestDirector(MI公司TD,8.0后改成QC),TestManager(IBM),QADirector(Compuware),TestLink(開源組織),QATraq(開源組織),oKit (統御至誠),Jira 管理工具,禪道,
測驗管理包含的內容有:測驗框架、測驗計劃與組織、測驗程序管理、測驗分析與缺陷管理,
四、禪道介紹
1. 禪道簡介
禪道由青島易軟天創網路科技有限公司開發,國產開源專案管理軟體,它集產品管理、專案管理、質量管理、檔案管理、組織管理和事務管理于一體,是一款專業的研發專案管理軟體,完整覆寫了研發專案管理的核心流程,
禪道官方網站:http://www.zentao.net/
官網使用步驟詳解:http://www.zentao.net/book/zentaopmshelp/38.html
2. 禪道專案管理系統的特點
第一款完整涵蓋產品管理、任務管理、測驗管理的開源管理軟體,使用一個軟體解決專案管理核心問題,
基于國際流行的敏捷管理方式scrum,
B/S Broswer/Server C/S Client/Server 架構,方便部署、使用,
概念簡單,容易上手,
開源的專案管理軟體,可自由進行定制,修改,
免費的專案管理軟體,降低企業的投入成本,
自主的開發框架,預留擴展機制,通過第三方的插件擴展獲得更多的功能,
3. 禪道系統的功能串列
產品管理:包括產品、需求、計劃、發布、路線圖等功能,
專案管理:包括專案、任務、團隊、版本、燃盡圖等功能,
質量管理:包括bug、測驗用例、測驗任務、測驗結果等功能,
檔案管理:包括產品檔案庫、專案檔案庫、自定義檔案庫等功能,
事務管理:包括todo管理,我的任務、我的Bug、我的需求、我的專案等個人事務管理功能,
組織管理:包括部門、用戶、分組、權限等功能,
統計功能:豐富的統計表,
搜索功能:強大的搜索,幫助您找到相應的資料,
擴展機制,幾乎可以對禪道的任何地方進行擴展,
api機制,所見皆API,方便與其他系統集成,
4. 用戶角色

image.png
禪道管理軟體中,核心的三種角色:產品經理、研發團隊和測驗團隊,這三者之間通過需求進行協作,實作了研發管理中的三權分立,其中產品經理整理需求,研發團隊實作任務,測驗團隊則保障質量,其三者的關系如下圖:

image.png
5.禪道的安裝
5.1.雙擊檔案,安裝(解壓)

image.png
注意:必須安裝在 英文目錄下,
5.2.查看目錄

image.png

image.png

image.png

image.png
點擊服務:apche可以選擇80或88埠,mysql可以選擇3306或3308埠
點擊訪問禪道,頁面會自動跳轉到禪道的頁面,
也可以直接訪問http://localhost/zentao/ 管理用戶:admin,密碼 123456
備注:如果你啟動的是88埠,請使用http://localhost:88/zentao來訪問,

image.png
5.3. 登錄

image.png
5.4.登錄成功
第一次登錄成功自動跳轉修改密碼界面,

image.png
五、禪道操作
人員管理
權限分配
產品控制
專案控制
撰寫用例
提交缺陷(bug)
1. 人員管理
使用 管理員(admin)登錄后將出現的頁面

image.png
1.1.添加部門
進入“組織” → “部門” 的頁面,新建三個部門并保存

image.png
1.2.添加用戶
進入“組織” → “用戶” → “+添加用戶”的鏈接頁面,添加“專案經理”賬戶并保存,郵箱和源代碼賬號可以為空,其中“您的系統登錄密碼”我管理員admin的密碼,

image.png

image.png
1.3.添加產品經理

image.png
1.4.添加開發人員

image.png
1.5.添加測驗人員

image.png
賬號:hgx hgx123457
mayan mayan123457
wangqing wangqing123457
1.6 添加成功展示效果

image.png
2. 創建產品
在禪道中,產品是一切的核心,所有的東西基本上都是圍繞產品展開,那么如何創建第一個產品呢?
產品經理登錄禪道,進入“產品” → “+添加產品”的鏈接頁面,新建產品并保存,

image.png

image.png
在這個頁面中,產品名稱和產品代號是必填的,比如,我們創建一個“測驗產品”,代號為test,點擊保存,
3.添加需求
添加了產品之后,需要創建一個需求,
所謂需求,就是來描述一件事情,如模板:作為一名<某種型別的用戶>,我希望<達成某些目的>,這樣可以<開發的價值>,這樣的需求,有用戶角色,有行為,也有目的和價值所在,非常方便與團隊成員進行溝通,
創建需求的步驟如下:
1.產品經理登錄禪道,
2.進入產品視圖,
3.在頁面右側,有“新增需求”選單,點擊選單,出現新增需求的頁面,
4.需求的創建頁面,預計工時和需求名稱都為必填項,預計工時,也就是你估計完成這個需求大約多少個小時,

image.png

image.png
注意:由誰評審,選擇不需要評審,這樣新創建的需求狀態是激活狀態,只有激活狀態的需求才能關聯到專案中,進行開發,
4.創建專案
創建了產品和需求以后,需要創建一個專案,來完成這個需求,在實際的情況中,肯定會有多個需求,那么如何確定一個專案中該做哪些需求呢?應該對需求進行優先級的排列,并根據專案的周期和參與的人手來決定,
4.1 專案經理登錄禪道,點擊“添加專案”

image.png

image.png
4.2 點擊創建專案中的“保存”,系統將自動跳轉到下圖:

image.png
4.3 點擊“設定團隊”鏈接進入“團隊成員”頁面,如下圖:

image.png
4.4 點擊“團隊管理”鏈接進入“團隊管理”頁面,添加團隊成員并保存,如下圖:

image.png
4.5 進入“專案” → “需求” → “+關聯需求”的鏈接頁面來關聯該專案的需求并保存,如下圖:

關聯需求.png

單擊保存.png
4.6單擊圖中的“保存”按鈕后看到積云商城第一期專案所關聯的需求,如圖:

保存.png
4.7單擊上圖中的“批量分解”的鏈接按鈕進入“批量創建”頁面,并進行任務指派、保存,如下圖:

關聯需求成功.png

批量創建任務.png
5. 開發人員領取任務,并提交測驗版本
5.1. 查看任務
開發人員登錄禪道系統,進入“我的地盤” → “任務” →的鏈接頁面就可以查看專案經理分配的任務

查看任務.png
5.2. 完成任務
當開發人員完成某一項任務時,可以單擊右側完成按鈕,在彈出的對話框中設定消耗的事假并保存即代表改任務完成,如下圖:

完成任務.png
5.3. 創建版本
當開發人員全部完成任務時,便可提交相應的測驗版本,進入“專案” → “版本”的鏈接頁面進行版本的創建,如下圖:

創建版本.png
5.4. 點擊“+創建版本”鏈接進行版本創建,并保存,如下圖:

創建測驗版本.png
6. 通過禪道系統來追蹤Bug
在上一節中開發人員已經通過禪道系統提交了可測驗的版本,接下就由測驗人員來執行測驗,并提交Bug,
6.1. 查看任務
測驗人員登錄禪道系統,進入“專案” → “任務” → 的鏈接頁面,此時就可以查看專案經理分配給測驗人員的 任務,如下圖:

查看任務.png
6.6.2. 提交bug
假設測驗人員已經完成測驗用例設計并測驗用例執行完畢,并且在測驗中發現了問題,那么測驗人員就要通過禪道提交Bug給開發人員,
測驗人員,進入 “測驗” → “Bug” 的鏈接頁面,如下圖:

提交bug.png
6.3. bug提交
單擊“提交bug”鏈接進入到提交Bug的頁面,此時可以提交Bug并進行相應保存,如下圖:

Bug提交.png

image.png
6.4. 查看bug
開發人員登錄禪道系統,進入 “測驗” → “Bug”的鏈接頁面,此時就可以看到測驗人員提交的bug,如下圖:

image.png
6.5. 完成解決
開發人員修復好該bug之后,就會單擊“解決”按鈕,在彈出對話框中設定解決資訊并保存,那么此時Bug就已經解決完成,如下圖:

image.png
6.6. 關閉Bug
測驗人員登錄禪道系統,并驗證所提Bug是否被開發人員修復好,如經驗證,此Bug已被解決,將會彈出“關閉”按鈕,并備注相關資訊,如下圖:

image.png

image.png
點擊“保存”后,“解決”按鈕變為灰色,點擊“關閉”,彈出如下圖:

image.png
6.7. 查看狀態
當測驗人員再次查看此Bug時,此Bug為關閉狀態,如圖所示:

image.png
6.8. 如果沒有解決
如果測驗 人員驗證此bug發現并沒有解決,就會再次編輯此bug,并將bug的狀態設定為激活狀態并重新指派給開發人員,
至此,bug的基本流程已經完成,
7. 創建發布
當某一期的專案結束后,如果這一期的版本可以對外發布,此時產品經理的一個職責就是創建一個發布,創建發布的意義在于告知相關部門人員,有新產品上線,可以讓相關人員繼續開展作業,
創建發布的步驟:
1.產品經理進入產品視圖,選擇“發布串列”,
2.點擊【創建發布】,進入創建發布頁面,
3.填寫必填項:發布名稱、Build和發布日期,
注意:發布的前提是要創建一個Build,

image.png

image.png
8. 測驗團隊
8.1.Bug處理
測驗 → bug → 提bug → 生成bug串列
8.2.測驗用例操作
1.1.4.修改用例
用例操作
1.1.5.執行測驗用例
1.1.6.設定第三個測驗用例執行失敗
1.1.7.可以直接將執行失敗的用例轉成bug
六、禪道使用流程總結
人員管理(admin):添加部門 → 添加用戶
創建產品(產品經理):產品 → 添加產品
添加需求(產品經理):產品 → 需求 → 提需求
創建專案(專案經理):專案 → 添加專案 → 自動跳轉(選擇設定團隊)→ 團隊管理 → 給團隊配人
關聯需求(專案經理):專案 → 需求 → 關聯需求 → 勾選任務
批量分解(專案經理):在任務右側 → 選擇批量分解 → 批量分解
查看任務(開發人員):我的地盤 → 首頁查看任務 → 點擊任務數量進入任務串列 → 選擇完成任務
創建版本(開發人員):專案 → 版本 → 創建版本
測驗Bug(測驗人員):測驗 → bug → 提bug
解決bug(開發):測驗 → bug → 確認 → 完成
再次測驗(測驗人員):測驗 → 再次測驗 → 如果解決的,點擊關閉,否則重新編輯
創建版本(產品經理):產品 → 發布 → 創建發布 → 完成
七、案例 練習
要求:
公司名稱:1802C科技有限公司,
部門:開發,測驗,產品,
用戶:后臺開發2個人,產品2個人,測驗1個人,前端1個 移動端1個 運維1個
產品:社區商圈專案
Web端一級功能,二級功能
App端一級,二級
二、缺陷報告
8.1 定義
概述:標識并描述發現的缺陷,具有清晰、完整和可重現問題所需的資訊的檔案,
理解:測驗人員發現缺陷,將缺陷記錄在《缺陷報告》中,通過缺陷報告將缺陷告知給開發人員,并對缺陷進行跟蹤和管理,缺陷報告是測驗人員與開發人員之間重要的溝通方式,
8.2 什么是缺陷
軟體缺陷就是通常說的Bug,它是指在軟體中(包括檔案和程式)存在的影響軟體正常運行的問題,
軟體未達到產品說明書標明的功能,如一個即時通訊App不能聊天,
軟體出現了產品說明書指明不會出現的錯誤,如高考不帶身份證,
軟體功能超出產品說明書指明的范圍,如即時通訊App做了一個地圖功能,
軟體未達到產品說明書雖未指出但應該達到的目標,如一個賬號的密碼是明文,
軟體難以理解、不易使用、運行速度緩慢或者從測驗人員的角度看最終用戶認為不好,如一個即時通訊App無法找不到聊天界面,
8.3 軟體缺陷產生的原因
需求不明確和變更
軟體需求不清晰或者開發人員對需求理解偏差,導致軟體設計時偏離用戶的需求目標,造成軟體功能或特征上的缺陷,此外,開發程序中客戶頻繁更新需求也會影響軟體最終的質量,
軟體結構復雜
編碼問題
專案期限短
使用新技術
8.4 導致軟體缺陷的典型錯誤
錯誤軟體缺陷
客戶與軟體開發人員之間交流困難缺少預期的軟體功能
開發人員未注意到代碼中的邏輯錯誤單擊按鈕沒有進行任何操作
開發人員忘記了對檔案復制代碼進行錯誤檢查復制了一份被破壞的檔案,導致軟體崩潰
開發人員沒有理解客戶的情況軟體不能滿足客戶的要求
8.5 軟體缺陷分類

軟體缺陷分類.png
8.6 缺陷報告的核心要素
八項:缺陷編號、缺陷狀態、缺陷標題、重現步驟、嚴重程度、優先級、缺陷型別、測驗環境,
缺陷編號
缺陷的唯一識別符號
缺陷狀態
缺陷跟蹤程序的進展情況

缺陷處理流程.png

缺陷狀態.png
新建:剛發現的缺陷
已指派:已經由測驗人員將缺陷指派給開發人員進行處理
已打開:開發人員正在修復缺陷
已修復:開發人員完成缺陷修復,還未進行回歸測驗
已拒絕:發開人員拒絕修復
已延期:對缺陷進行延緩處理
已關閉:由測驗人員回歸測驗后,缺陷不存在了
重新打開:由測驗人員回歸測驗后,發現缺陷任然存在,
缺陷標題
缺陷的概述,描述問題本質
重現步驟
①一步一步描述再現缺陷的操作步驟
②預期結果
③實際結果
嚴重程度
缺陷對軟體系統的影響程度
優先級
修復缺陷的重要性或緊迫性
缺陷型別
根據缺陷產生的來源和根源劃分出的缺陷種類
功能、配置、安裝、性能缺陷
測驗環境
測驗環境配置,包括軟體環境和硬體環境
8.7 缺陷報告撰寫技巧
1、對錯誤的描述要做到簡潔、準確、完整,揭示錯誤實質2、盡量使用短語和短句,避免復雜句型句式3、每個軟體問題報告只書寫一個缺陷或錯誤4、明確指明錯誤型別和嚴重程度5、每一個步驟盡量只記錄一個完整操作6、復現的操作步驟要完整,準確,簡短7、可以附加必要的錯誤特征影像8、可以附加必要的測驗用例
8.8 缺陷報告模板

報告缺陷模板.png
三、測驗報告
9.1 引入
回歸測驗作業完成后,就代表著產品即將上線,此時每個測驗人員都需要針對自己所測驗的模塊出具一份測驗報告,以此來總結測驗結果,測驗報告可以說是軟體測驗人員在測驗階段的最后一份輸出檔案,那么初級軟體測驗工程師應該如何撰寫測驗報告呢?
9.2 定義
記錄測驗的程序和結果,對發現的問題和缺陷進行分析的檔案
9.3 測驗報告分類
階段測驗報告
整體測驗報告
9.4 報告內容
9.4.1 概要
撰寫目的
①對測驗報告進行相應的解釋
②對專案進行簡介
③對于測驗任務進行簡單描述,要測驗哪些內容
測驗人員
類似于測驗計劃中的人員分工,簡單描述日期等
測驗環境
軟體和硬體環境
9.4.2 測驗程序
階段測驗報告:
1、測驗進度情況
2、用例執行情況
3、缺陷統計
總體測驗報告
1、各版本的測驗情況
2、各版本的缺陷統計
9.4.3 缺陷分析
1、按照缺陷級別
2、按照功能模塊
3、按照輪次
4、缺陷總數
5、缺陷型別
6、缺陷趨勢
9.4.4 測驗總結
1、測驗結論
通過/不通過;
需求覆寫率100%,測驗用例執行過率100%;
缺陷:致命=0,嚴重=0,一般=0,提示≤10%
2、風險分析
測驗進度、人員安排導致的風險;
測驗內容考慮范圍之外導致的風險;
測驗環境不全面導致的風險,
3、遺留問題
遺留問題描述、等級、處理方法,
9.5 測驗報告模板
一、概要
1、撰寫目的
背景
本報告為積云商城1.0版本的測驗報告,用于記錄測驗程序,總結測驗情況,分析測驗資料,歸納測驗作業程序中的問題與遺留的風險,給出相應的測驗建議供后續參考,
積云商城是Android平臺的電商應用,1.0版本是首次發布版本,包含登陸/注冊、商品展示/搜索、購物車、訂單管理、支付等功能,
測驗內容
對積云商城1.0版本進行了功能、性能、易用性、兼容性測驗,功能測驗覆寫以上所有功能;對登陸和訂單管理功能進行了性能測驗;兼容性測驗覆寫了Android 6,7,8,9版本,華為、小米等主流廠家機型,
2、測驗人員
測驗作業6月1日開始,6月15日測驗完成,測驗組4人,總作業量60人天,人員分工如下表:
姓名角色職責
測驗經理測驗負責人制定測驗策略,撰寫測驗計劃,設計測驗用例,撰寫測驗報告
工程師A測驗工程師制定性能測驗方案,進行性能測驗,撰寫性能測驗報告
工程師B測驗工程師設計測驗用例,測驗執行
3、測驗環境
配置應用服務器資料庫服務器測驗機
硬體配置CPU:雙核1.8G主頻 Intel(R) Xeon(R) CPU 2GHz
記憶體:4G
CPU:雙核1.8G主頻bIntel(R) Xeon(R) CPU 2GHz
記憶體:4G
CPU:1CPU(雙核),Intel(R) Pentium(R) CPU E2180 2.0GHz
記憶體: 8G
軟體配置Windows2008 server
Tomcat 6.0 (功能測驗)
Websphere 7.0(功能、性能測驗)
CentOS7、Oracle 11g R2Windows7+IE11,性能測驗工具:Loadrunner11
二、測驗程序
1、測驗進度
測驗任務責任人啟動時間計劃完成時間完成時間備注
測驗計劃/評審測驗經理2019.5.272019.5.272019.5.27
需求分析測驗工程師2019.5.282019.5.282019.5.28
測驗用例設計/評審測驗工程師2019.5.292019.6.42019.6.6需求變動,用例設計延遲2天完成,
2、用例執行情況
模塊用例總數執行用例數通過用例數未通過用例數阻塞用例數
登錄/注冊50504820
購物車75737032
支付75707005
合計20019318857
執行率=執行用例數/用例總數
通過率=通過用例數/執行總數
3、缺陷統計
1.0版本共發現缺陷21條,新增bug10個,修復bug17個,遺留bug4個,
模塊名稱bug總數新增bug數修復bug數遺留bug數
登錄/注冊177143
商品4331
合計2110174
修復率=bug修復/bug總數
三、缺陷分析
1、缺陷級別分析

缺陷級別.png
決議:嚴重缺陷、一般缺陷、輕微缺陷各占總缺陷的5%,輕微缺陷占85%,
2、缺陷模塊分析

image.png
決議:bug共21條,其中17條存在于登錄/注冊模塊,開發人員需要著重對于該模塊進行自測,
3、缺陷型別分析
按照版本統計
按照趨勢統計
四、測驗總結
1、測驗結論
內容:通過/不通過,執行率、通過率、修復率、遺留問題的級別以及數量,
示例:積云商城1.1測驗通過,可以上線,測驗用例執行率100%,測驗用例通過率95%,未通過的測驗用例不影響業務運行,嚴重缺陷為0,一般缺陷為0,輕微缺陷小于10%,
2、 風險分析
編號風險描述規避方法及建議
3、 遺留問題
編號缺陷描述缺陷等級處理方法
四、介面測驗以及用例撰寫
11.1 介面
11.1.1 介面概述
定義:介面就是API(Application Programming Interface,應用程式介面),是一個軟體或服務對外提供的介面,別人只要呼叫這介面,而內部如何實作,不需要關心,你只要按照要求進行介面呼叫即可,
外部系統與系統之間以及內部各子系統之間的互動點,包括外部介面、內部介面,
舉例:
假設物流中“貨物”是資料,存放貨物的“總倉庫”是資料庫,“店鋪”是我們的網站、App,頁面上顯示的內容、數字,以及用戶的操作請求和結果都是需要不停搬運的“貨物”——資料,則負責調配分配打包的中轉站就是API,快遞小哥直接從中轉站取貨就好,
作用:對于軟體提供商來說,留出API,讓別的應用程式來呼叫,軟體才能發揮最大的價值,才能更有生命力,(同時別人也看不見代碼,不傷害商業機密,)
對于應用開發者來說,有了開放的API,就可以直接呼叫多家公司做好的功能來做自己的應用,不需要所有的事情都自己操刀,節省精力,
11.1.2 介面的表現形式
客戶端要先操作服務端資源,首先要找到服務端提供的介面,然后才能向服務端發送資源請求,那么何為服務端介面呢?其實就是一個地址(URL),比如:
http://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1

1615302590(1).png
采用的協議(http:):一般來講網址中第一個“:”前面的就是該網址所采用的協議,這里的HTTP就是個協議 ,HTTPS是HTTP的安全版本,HTTPS在HTTP的基礎對傳輸的資料進行了加密和簽名,以保證資料傳輸的安全性,我們平常打開兩頁的時候會看到網址前面都有一個HTTP或HTTPS,這就是告訴你,你在向服務器發送此請求的程序中要遵循的協議是HTTP或HTTPS (也就是規則),
服務器地址(//www.qubaobei.com):以雙斜杠“//”開頭,后面跟的就是這個服務器的地址,專業術語叫域名,
請求資源路徑(/ios/cf/dish_list.php) :表示你要請求的資源在該服務器下/ios/cf/dish_list.php的路徑下,
引數(?stage_id=1&limit=20&page=1):引數可以找到具體內容,和路徑之間使用“?”隔開,引數之間使用“&”隔開,引數是以鍵值對的形式表現出來的,
把此URLhttp://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1稱為食品模塊個介面, 也稱為介面地址,
11.2 介面檔案
介面檔案展示
11.2.1 封皮
封面最好是本公司規定的封面,有logo,內容標題,版本號,公司名稱,檔案產生
日期,(錯誤地方在于,檔案的標題要和頁眉中的標題一致)
11.2.2 修訂歷史
表格形式較好些,包括:
版本,修訂說明,修訂日期,修訂人,審核時間,審核人,
11.2.3 介面資訊
介面呼叫方式,是post方式還是get方式,介面地址,別人需要線上的哪個地址就寫哪個,(自己提前測驗好線上的這個介面,是否有其他問題,千萬別犯低級的錯誤,尤其是某個字母寫錯)
11.2.4 功能描述
一定要清晰的描述介面功能,(不要遺漏一些細節,比如介面獲取的資訊不包括哪些,哪些要寫明白)
11.2.5 介面引數說明
每個引數都要和實際中呼叫的一樣,包括大小寫;引數的含義言簡意賅的說明;格式是string 還是int 還是long等格式(例如引數為@RequestParam("appKey") StringappKey, @RequestParam("randomId") Integer randomId);說明部分,說明引數值是需要哪個公司提供,并詳細說明引數怎么生成的,例如時間戳,是哪個時間段的;引數是否必填,一些引數是必須要有的,有些是可選引數,一定要注意寫清晰,
11.2.6 回傳值說明
1、有一個模板回傳值,并說明每個回傳引數的意義,
2、提供一個真實的呼叫介面,真實的回傳值,
注:現實作業中,對介面有疑問要及時跟同事交流,
11.3 介面測驗的概念
11.3.1 概念
測驗系統組件間介面的一種測驗,介面測驗主要用于檢測外部系統與系統之間以及內部各個子系統之間的互動點,
11.3.2 介面測驗本質
實質就是資料的傳輸和接受,傳輸的是介面地址中的引數,接受的是文本字串,然后對比文本字串是否正確,
11.4 介面測驗的目的和原理
11.4.1 目的
測驗介面的正確性和穩定性,
11.4.2 原理
介面測驗的原理是通過測驗程式模擬客戶端向服務器發送請求報文,服務器接收請求報文后對相應的報文做出處理然后再把應答報文發送給客戶端,客戶端接收應答報文這一個程序,
11.5 常用介面測驗工具
11.5.1 典型商業工具:
LoadRunner(LR):一款商業性能測驗工具,用來做介面測驗,很好很強大 ,但是配置比較麻煩,
SoapUI:開源測驗工具,通過soap/http來檢查、呼叫、實作Web Service的功能/負載/符合性測驗;該工具既可作為一個單獨的介面測驗工具使用,也可利用插件集成到Eclipse,maven2.X,Netbeans 和intellij中使用, 了解就可以了,基本已經不用了,
11.5.2 典型開源工具
Jmeter :一款開源的介面測驗工具,操作簡單,方便,既有jdbc request操作資料庫資料,也有http request和soap request應對測驗
13.5.3 擴展插件
postman:谷歌瀏覽器的擴展工具,主要用來做介面測驗,谷歌商店中選中安裝,界面同poster差別不大,界面簡潔,
13.6 介面測驗應該測什么
13.6.1 單一介面
單一介面功能的測驗主要測驗回傳的資料結構是否和介面檔案給出的一致,介面的正常功能是否完成,介面的引數檢查測驗,介面的例外測驗,
13.6.2 組合介面
定義:組合介面測驗主要是通過組合多個單一介面,來測驗一個業務場景
案例:測驗購物網站的一個下單的功能,那么因為在下單之前還有一些流程,所以要測驗一個場景,
測驗:搜索商品 --> 選中商品 --> 添加進購物車 --> 提交訂單 -->支付
(提交訂單時還涉及到地址的選取等)
注:涉及到如果使用從cookie或者session在本例中的區別:如果使用cookie加入購物車,那么換一臺電腦購物車里的商品就不存在了,但如果使用的是session,購物車里面的東西就一直存在,即:cookie是本機作用的,session不止于本機作用,
13.6.3 結構檢查
(1)檢查回傳值的結構是否正確,如是json型別還是xml型別的資料
(2)欄位名稱是否正確等
XML和JSON都使用結構化方法來標記資料
13.7 介面測驗內容
13.7.1 功能邏輯
通過查資料庫或快取等驗證資料是否處理正確,
通過其他輔助途徑進行驗證
13.7.2 例外測驗
介面測驗中主要測驗介面正常邏輯,但僅邏輯測驗不能保證資料的安全及程式介面在例外情況下的邏輯處理的正確性,
13.7.3 路徑測驗
當被測介面的實作方法中,判斷邏輯復雜分支多,且判斷中又呼叫了其他的介面,此時必須要進行路徑覆寫測驗,
13.7.4 其他例外場景
研發的專案,有些專案是底層使用的系統,根據專案特點,可能會存在特殊的例外場景,
例如: 支付的異步操作,支付訊息重試等
11.8 測驗案例
11.8.1 get請求
11.8.2 post請求
Postman使用
13.9 介面測驗用例模板

介面測驗用例模板.png
五、Fiddler
14.1 Fiddler簡介
14.1.1 簡介
Fiddler是位于客戶端和服務器端之間的代理,也是目前最常用的抓包工具之一 ,它能夠記錄客戶端和服務器之間的所有請求,可以針對特定的請求,分析請求資料、設定斷點、除錯web應用、修改請求的資料,甚至可以修改服務器回傳的資料,功能非常強大,是web除錯的利器,
14.1.2 功能
1、能夠監聽http/httpS的流量,可以截獲從瀏覽器或者客戶端軟體向服務器發送的http/https請求;
2、對截獲之后的請求,我們還能夠查看請求中的內容;
3、偽造請求,不僅可以偽造客戶端的請求,還能夠偽造服務器的回應,——該功能能夠方便我們進行前后端的調式,
4、測驗網站的性能;
5、解密https的外部會話,因為https本身是一種加密的協議,通過fiddle我們可以進行解密操作;
6、提供第三方擴展插件,滿足更多需求,
14.1.3 Fiddler作業原理

fiddler原理.png
14.2 Fiddler下載安裝
下載:打開官網
安裝:
漢化:
14.3 Fiddler界面介紹

fiddler界面.jpg
Fiddler界面從上到下分為:選單欄、工具列、回話串列、功能頁簽、命令列,狀態欄六大板塊
file capturing = F12 = 左下角capturing
14.4 選單欄
14.4.1File選單
1、Capture Traffic:可以控制是否把Fiddler注冊為系統代理,
2、New Viewer:打開一個新的fiddler視窗
3、Load Archive:用于重新加載之前捕獲的以SAZ檔案格式保存的資料包,
4、Save:支持以多種方式把資料包保存到檔案中,
5、Import Sessions...:支持匯入從其他工具捕獲的資料包,也支持匯入以其他格式存盤的資料包,
6、Export Sessions...:把Fiddler捕捉到的回話以多種檔案格式保存,
7、Exit:取消把Fiddler注冊為系統代理,并關閉Fiddler
14.4.2 Edit選單
1、Copy:復制會話,
2、Remove:洗掉會話,
3、Select All:選擇所有會話,
4、Undelete:撤銷洗掉會話,
5、Paste as Session把剪貼板上的內容粘貼成一個或多個模擬的會話,
6、Mark:選擇一種顏色標記選中會話,
7、Unlock for Editing 解鎖會話,
8、Find Session...打開Find Session視窗,搜索捕獲到的資料包,
14.4.3 Rules選單
1、Hide Image Request:隱藏圖片回話,
2、Hide CONNECTS:隱藏連接通道回話,
3、Automatic Breakpoints:自動在[請求前]或[回應后]設定斷點,Ignore Image觸發器控制這些斷點是否作用于圖片請求,
4、Customize Rules...:打開Fiddler腳本編輯視窗,
5、Require Proxy Authentication:,要求客戶端安裝證書,該規則可以用于測驗HTTP客戶端,確保所有未提交Proxy-Authorization請求頭的請求會回傳HTTP/407回應碼,
6、Apply GZIP Encoding:只要請求包含具有gzip標識的Accept-Encoding請求頭,就會對所有回應使用GZIP HTTP進行壓縮(圖片請求除外),
7、Remove All Encoding:洗掉所有請求和回應的HTTP內容編碼和傳輸編碼
8、Hide 304s:隱藏回應為HTTP/304 Not Modified狀態的所有回話,
9、Request Japanese Content:選項會把所有請求的Accept-Encoding請求頭設定或替換為ja標識,表示客戶端希望回應以日語形式發送,
10、User-Agents:把所有請求的User-Agent請求頭設定或替換成指定值,
11、performance:模擬弱網測驗速度,
14.4.4 Tools選單
1、Options...:打開Fiddler選項視窗,
2、WinINET Options...打開IE的Internet屬性視窗
3、Clear WinINET Cache:清空IE和其他應用中所使用的WinINET快取中的所有檔案,
4、Clear WinINET Cookies:清空IE和其他應用中所發送的WinINET Cookie
5、TextWizard...:選項會啟動TextWizard視窗,對文本進行編碼和解碼,
6、Compare Session:比較回話,
7、Reset Script:重置Fiddler腳本,
8、Sandbox:打開http://webdbg.com/sandbox/
9、View IE Cache:打開IE快取視窗,
14.4.5 View選單
1、Show Toolbar:控制Fiddler工具列是否可見2、DefaultLayout、Stacked Layout、Wide Layout三種界面布局3、Minimize to Tray:最小化Fiddler到系統托盤(快捷鍵:CTRL+M)4、Squish SessionList:控制回話串列是否水平收縮,5、AutoScroll Sessionlist:添加新的回話時,自動滾動到回話串列底部
14.5 工具列

fiddler工具列.png
1.備注功能
2.重新發送請求,快捷鍵:R鍵,
3.洗掉請求
4.當有請求前斷點時,點擊去發送請求,
5.流模式,(默認是緩沖模式)
6.解碼
7.保持回話的數量,
8.選擇你想要抓包或者監聽的程式
9.查找
10.保存所有會話,檔案名以.saz為擴展名
11.截圖
12.計時器
13.快捷的打開IE瀏覽器

fiddler工具列1.png
14.清除IE快取
15.文本的編碼解碼工具
16.分離面板
17.MSDN查詢
18.本機的資訊
14.6 會話串列

fiddler繪畫串列.png
1.請求的ID編號
2.http回應狀態碼
3.會話使用的協議
4.請求發送到的服務器主機名
5.資料包在服務器中的路徑和檔案
6.回應body的位元組數
7.回應頭資訊Cache-Control的值
8、回應頭資訊Content-Type的值
9.發起請求的本地windows行程
10.注釋
11.自定義備注
14.7 功能頁簽
14.7.1 Statistics頁簽
通過該頁簽,用戶可以通過選擇多個會話來得到這幾個會話的總的資訊統計,比如多個請求傳輸的位元組數,訪問頁面時選擇第一個請求和最后一個請求,可獲得整個頁面加載所消耗的總體時間,從條形圖表中還可以分別出哪些請求耗時最多,從而對頁面的訪問進行速度性能優化,
14.7.2 inspectors頁簽(常用頁簽)
它提供headers、textview、hexview,Raw等多種方式查看一條http請求的請求和回應,它分為上下兩部分:上部分為請求展示,下部分為回應展示,
14.7.3 AutoResponse頁簽(常用頁簽)
它可以抓取在線頁面保存到本地進行除錯,大大減少了在線除錯的困難,可以讓我們修改服務器端回傳的資料,例如讓回傳都是404的數據包讀取本地檔案作為回傳內容,
14.7.4 composer頁簽常用頁簽)
支持手動構建和發送HTTP,HTTPS和FTP請求,我們還可以從回話串列中拖曳回話,把它放到composer選項卡中,當我們點擊Execute按鈕時則把請求發送到服務器端,
14.7.5 FiddlerScripts頁簽
打開Fiddler腳本編輯,
log頁簽:
列印日志
14.7.6 Filters頁簽(常用頁簽)
過濾器可以對左側的資料流串列進行過濾,我們可以標記、修改或隱藏某些特征的資料流,
14.7.7 Timeline頁簽
時間軸,也稱為Fiddler的瀑布圖,展示網路請求時間的功能,每個網路請求都會經歷域名決議、建立連接、發送請求、接受資料等階段,把多個請求以時間作為X軸,用圖表的形式展現出來,就形成了瀑布圖,在左側會話視窗點擊一個或多個回話,Timeline 便會顯示指定內容從服務端傳輸到客戶端的時間,
14.7.8 命令列
help 打開官方的使用頁面介紹,所有的命令都會列出來,
cls 清屏 (Ctrl+x 也可以清屏)
select 選擇所有相應型別的回話(如select image或select css),
?sometext 查找字串并高亮顯示查找到的會話,
size 選擇請求回應大小小于size位元組的會話,
=status/=method/@host 查找狀態、方法、主機相對應的會話
1uit 退出fiddler
bpafter xxx 中斷URL包含指定字符的全部回話回應
bps xxx 中斷HTTP回應狀態為指定字符的全部回話回應,
bpv xxx 中斷指定請求方式的全部回話回應
bpm xxx 中斷指定請求方式的全部回話回應,等同于bpv xxx
bpu xxx: 與bpafter類似,
14.8 狀態欄

fiddler狀態欄.png
1、顯示的Fiddler是否處于捕捉狀態(開啟/關閉狀態),可以點擊該區域切換
2、顯示當前捕捉哪些行程,
All Processes 捕獲所有行程的請求
Web Browsers 捕獲 Web 瀏覽器的請求,應該特指 IE
Non-Browser 捕獲非 Web 瀏覽器的請求
Hide All 隱藏所有請求
3、顯示當前斷點設定狀態,通過滑鼠點擊切換,有三種:
不設定斷點
所有請求在斷點處被暫停
所有回應在斷點處被暫停
4,顯示當前共捕獲了多少回話(如:300,表示共捕獲了300個會話,如:10/300,表示當前選擇10個會話,共捕獲300個會話),
5,第五區塊,描述當前狀態,
如果是剛打開Fiddler,會顯示什么時間加載了CustomRules.js;如果選擇了一個會話,會顯示該會話的URL;如果在命令列輸入一個命令,就會顯示命令相關資訊,
14.9 web抓包
我們雙擊打開軟體,進入到如下的一個界面,然后點擊某一個請求,你會發現請求的內容是一堆明顯不對的文字,然后該請求的左邊是一個鎖的樣式,聯想到https加密,你會發現原因可能是沒有配置Fiddler,然后解釋一下右邊的默認回傳內容,第一句是“這是一個CONNECT隧道,加密的HTTPS流量通過該隧道流動,”,就證實了我們的猜測,果然是因為https加密的原因,

image.png
那么如何配置FIddler來決議這些加密的請求呢?
方法一:是查官網的安裝檔案,
方法二:看提示,軟體公司還是很人性化的在回傳內容里面提示了需要在哪里設定,就是第二行那一句:enable the Tools > Options > HTTPS > Decrypt HTTPS traffic option.
我們按照提示來進行設定,先在左上角的工具列里面找到Tools,然后依次選擇Options、HTTPS ,然后勾選Decrypt HTTPS traffic選項,勾選后安裝證書,

image.png
安裝證書兩種方法:
勾選后點擊右邊的Actions按鈕選擇“Trust Root Certificate”選項,然后全部選擇是就行了,
勾選后點擊右邊的Actions按鈕選擇第二個選項將證書匯出到桌面,然后再在對應的瀏覽器里面添加即可,
然后我們再打開一個新的網頁(例如百度),查看請求
至此,已經可以監聽PC端瀏覽器的請求了,
14.10 移動端抓包
首先你的Fiddler所在的電腦和手機必須處在同一個局域網內(即連著同一個路由器),
查看你的本機IP地址,在Fiddler的右上角有一個Online按鈕,點擊一下會顯示你的IP資訊
配置連接資訊:Tools > Options >Connections
埠默認是8888,你可以進行修改,
勾選Allow remote computers to connect選項,然后重啟Fiddler,再次打開時會彈出一個資訊,選擇ok即可,

image.png
打開你的手機,找到你所連接的WIFI,長按選擇修改網路,輸入密碼后往下拖動,然后勾選顯示高級選項,然后在代理一欄選擇手動,再將你先前查看的IP地址和埠號輸入進去,然后保存,

image.png
最后安裝手機證書,在手機瀏覽器一欄輸入電腦的IP地址和埠號
這里我是192.168.1.157:8888
進入一個網頁,點擊最下面那個FiddlerRoot certificate下載證書,下載成功后在設定里面安裝,安裝步驟:打開高級設定->安全->從SD卡安裝證書->找到證書檔案->點擊后為證書命名點擊確定即可安裝成功
測驗一下,比如在手機上打開抖音app,找到評論的那一個請求,

最后感謝每一個認真閱讀我文章的人,看著粉絲一路的上漲和關注,禮尚往來總是要有的,雖然不是什么很值錢的東西,如果你用得到的話可以直接拿走:

這些資料,對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫,這個倉庫也陪伴上萬個測驗工程師們走過最艱難的路程,希望也能幫助到你!
在我的QQ技術交流群里(技術交流和資源共享,廣告勿擾)
可以自助拿走,群號:310357728 群里的免費資料都是筆者十多年測驗生涯的精華,還有同行大神一起交流技術哦
如果對你有一點點幫助,各位的「點贊」就是小編創作的最大動力,我們下篇文章見!
好文推薦
在小公司“混”了2年,我只認真做了5件事,如今順利拿到位元組 Offe
去了位元組跳動,才知道年薪 30w 的測驗工程師有這么多?
北京35歲程式員失業,感嘆:編程估計沒戲了,想去賣點煎餅果子養家~
29歲轉行軟體測驗靠譜嗎?一個過來人的心路歷程送給迷茫的你
同樣是IT行業,測驗和開發薪資真就差這么大嗎?
?
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/296512.html
標籤:其他
