一、測試工具背景

當測試環境搭建完成后，測試人員將在自己搭建的環境上執行測試用例，開展測試工作。測試人員在執行測試用例的過程中，如發現實際結果與預期結果不一致， 則意味著出現Bug (缺陷、錯誤、問題)。當測試人員發現了Bug之后，就需要把Bug提交給開發人員進行修復。那測試人員應如何記錄一個Bug呢?測試人員通過什么工具把Bug轉發給開發人員的呢?測試人員提交完Bug后又如何做回歸測試呢?本章將對提交Bug所涉及的各種問題進行詳細介紹。提交Bug不僅僅是測試人員價值的體現，也是測試人員迓開發人員溝通的重要橋梁，Bug 的數量和質量將會對軟件質量的改善起到重要的推動作用。

二、測試管理工具

測試管理工具是指在軟件開發過程中，對測試需求、計劃、用例和實施過程進行管理、對軟件缺陷進行跟蹤處理的工具。通過使用測試管理工具，測試人員或開發人員可以更方便地記錄和監控每個測試活動、階段的結果，找出軟件的缺陷和錯誤，記錄測試活動中發現的缺陷和改進建議。通過使用測試管理工具，測試用例可以被多個測試活動或階段復用，可以輸出測試分析報告和統計報表。有些測試管理工具可以更好地支持協同操作，共享中央數據庫，支持并行測試和記錄，從而大大提高測試效率。

三、測試工具介紹

目前市場上主流的軟件測試管理工具有：TestCenter（澤眾軟件出品）、TestDirector（MI公司TD，8.0后改成QC），TestManager（IBM），QADirector（Compuware），TestLink（開源組織），QATraq（開源組織），oKit (統御至誠)，Jira 管理工具，禪道。

測試管理包含的內容有：測試框架、測試計劃與組織、測試過程管理、測試分析與缺陷管理。

四、禪道介紹

禪道簡介

禪道由青島易軟天創網絡科技有限公司開發，國產開源項目管理軟件。它集產品管理、項目管理、質量管理、文檔管理、組織管理和事務管理于一體，是一款專業的研發項目管理軟件，完整覆蓋了研發項目管理的核心流程。

禪道官方網站：http://www.zentao.net/

官網使用步驟詳解：http://www.zentao.net/book/zentaopmshelp/38.html

禪道項目管理系統的特點

第一款完整涵蓋產品管理、任務管理、測試管理的開源管理軟件，使用一個軟件解決項目管理核心問題。

基于國際流行的敏捷管理方式scrum。

B/S Broswer/Server C/S Client/Server 架構，方便部署、使用。

概念簡單，容易上手。

開源的項目管理軟件，可自由進行定制，修改。

免費的項目管理軟件，降低企業的投入成本。

自主的開發框架，預留擴展機制，通過第三方的插件擴展獲得更多的功能。

禪道系統的功能列表

產品管理：包括產品、需求、計劃、發布、路線圖等功能。

項目管理：包括項目、任務、團隊、版本、燃盡圖等功能。

質量管理：包括bug、測試用例、測試任務、測試結果等功能。

文檔管理：包括產品文檔庫、項目文檔庫、自定義文檔庫等功能。

事務管理：包括todo管理，我的任務、我的Bug、我的需求、我的項目等個人事務管理功能。

組織管理：包括部門、用戶、分組、權限等功能。

統計功能：豐富的統計表。

搜索功能：強大的搜索，幫助您找到相應的數據。

擴展機制，幾乎可以對禪道的任何地方進行擴展。

api機制，所見皆API，方便與其他系統集成。

用戶角色

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

5.禪道的安裝

5.1.雙擊文件，安裝(解壓)

注意：必須安裝在 英文目錄下。

5.2.查看目錄

點擊服務：apche可以選擇80或88端口，mysql可以選擇3306或3308端口

點擊訪問禪道，頁面會自動跳轉到禪道的頁面。

也可以直接訪問http://localhost/zentao/ 管理用戶：admin，密碼 123456

備注：如果你啟動的是88端口，請使用http://localhost:88/zentao來訪問。

5.3. 登錄

5.4.登錄成功

第一次登錄成功自動跳轉修改密碼界面。

五、禪道操作

人員管理

權限分配

產品控制

項目控制

編寫用例

提交缺陷(bug)

人員管理

使用 管理員（admin）登錄后將出現的頁面

1.1.添加部門

進入“組織” → “部門” 的頁面，新建三個部門并保存

1.2.添加用戶

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

1.3.添加產品經理

1.4.添加開發人員

1.5.添加測試人員

賬號：hgx hgx123457

mayan mayan123457

wangqing wangqing123457

1.6 添加成功展示效果

創建產品

在禪道中，產品是一切的核心，所有的東西基本上都是圍繞產品展開。那么如何創建第一個產品呢？

產品經理登錄禪道，進入“產品” → “+添加產品”的鏈接頁面，新建產品并保存。

在這個頁面中，產品名稱和產品代號是必填的。比如，我們創建一個“測試產品”，代號為test。點擊保存。

3.添加需求

添加了產品之后，需要創建一個需求。

所謂需求，就是來描述一件事情，如模板：作為一名<某種類型的用戶>，我希望<達成某些目的>，這樣可以<開發的價值>。這樣的需求，有用戶角色，有行為，也有目的和價值所在，非常方便與團隊成員進行溝通。

創建需求的步驟如下：

1.產品經理登錄禪道。

2.進入產品視圖。

3.在頁面右側，有“新增需求”菜單，點擊菜單，出現新增需求的頁面。

4.需求的創建頁面，預計工時和需求名稱都為必填項。預計工時，也就是你估計完成這個需求大約多少個小時。

注意：由誰評審，選擇不需要評審，這樣新創建的需求狀態是激活狀態。只有激活狀態的需求才能關聯到項目中，進行開發。

4.創建項目

創建了產品和需求以后，需要創建一個項目，來完成這個需求。在實際的情況中，肯定會有多個需求。那么如何確定一個項目中該做哪些需求呢？應該對需求進行優先級的排列，并根據項目的周期和參與的人手來決定。

4.1 項目經理登錄禪道，點擊“添加項目”

4.2 點擊創建項目中的“保存”，系統將自動跳轉到下圖：

4.3 點擊“設置團隊”鏈接進入“團隊成員”頁面，如下圖：

image.png

4.4 點擊“團隊管理”鏈接進入“團隊管理”頁面，添加團隊成員并保存，如下圖：

4.5 進入“項目” → “需求” → “+關聯需求”的鏈接頁面來關聯該項目的需求并保存，如下圖：

關聯需求.png

單擊保存.png

4.6單擊圖中的“保存”按鈕后看到積云商城第一期項目所關聯的需求，如圖：

保存.png

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

關聯需求成功.png

批量創建任務.png

開發人員領取任務，并提交測試版本

5.1. 查看任務

開發人員登錄禪道系統，進入“我的地盤” → “任務” →的鏈接頁面就可以查看項目經理分配的任務

查看任務.png

5.2. 完成任務

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

完成任務.png

5.3. 創建版本

當開發人員全部完成任務時，便可提交相應的測試版本，進入“項目” → “版本”的鏈接頁面進行版本的創建，如下圖：

創建版本.png

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

創建測試版本.png

通過禪道系統來追蹤Bug

在上一節中開發人員已經通過禪道系統提交了可測試的版本，接下就由測試人員來執行測試，并提交Bug。

6.1. 查看任務

測試人員登錄禪道系統，進入“項目” → “任務” → 的鏈接頁面，此時就可以查看項目經理分配給測試人員的 任務，如下圖：

查看任務.png

6.6.2. 提交bug

假設測試人員已經完成測試用例設計并測試用例執行完畢，并且在測試中發現了問題，那么測試人員就要通過禪道提交Bug給開發人員。

測試人員，進入 “測試” → “Bug” 的鏈接頁面，如下圖：

提交bug.png

6.3. bug提交

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

Bug提交.png

6.4. 查看bug

開發人員登錄禪道系統，進入 “測試” → “Bug”的鏈接頁面，此時就可以看到測試人員提交的bug，如下圖：

6.5. 完成解決

開發人員修復好該bug之后，就會單擊“解決”按鈕，在彈出對話框中設置解決信息并保存，那么此時Bug就已經解決完成，如下圖：

6.6. 關閉Bug

測試人員登錄禪道系統，并驗證所提Bug是否被開發人員修復好，如經驗證，此Bug已被解決，將會彈出“關閉”按鈕，并備注相關信息，如下圖：

點擊“保存”后，“解決”按鈕變為灰色，點擊“關閉”，彈出如下圖：

6.7. 查看狀態

當測試人員再次查看此Bug時，此Bug為關閉狀態，如圖所示：

6.8. 如果沒有解決

如果測試 人員驗證此bug發現并沒有解決，就會再次編輯此bug，并將bug的狀態設置為激活狀態并重新指派給開發人員。

至此，bug的基本流程已經完成。

創建發布

當某一期的項目結束后，如果這一期的版本可以對外發布，此時產品經理的一個職責就是創建一個發布。創建發布的意義在于告知相關部門人員，有新產品上線，可以讓相關人員繼續開展工作。

創建發布的步驟：

1.產品經理進入產品視圖，選擇“發布列表”。

2.點擊【創建發布】，進入創建發布頁面。

3.填寫必填項：發布名稱、Build和發布日期。

注意：發布的前提是要創建一個Build。

測試團隊

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? Xeon? CPU 2GHz

內存：4G

CPU：雙核1.8G主頻bIntel? Xeon? CPU 2GHz

內存：4G

CPU：1CPU（雙核），Intel? Pentium? 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、缺陷級別分析

解析：嚴重缺陷、一般缺陷、輕微缺陷各占總缺陷的5%，輕微缺陷占85%。

2、缺陷模塊分析

解析：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加密的原因。

那么如何配置FIddler來解析這些加密的請求呢？

方法一：是查官網的安裝文檔，

方法二：看提示，軟件公司還是很人性化的在返回內容里面提示了需要在哪里設置，就是第二行那一句：enable the Tools > Options > HTTPS > Decrypt HTTPS traffic option.

我們按照提示來進行設置，先在左上角的工具欄里面找到Tools，然后依次選擇Options、HTTPS ，然后勾選Decrypt HTTPS traffic選項，勾選后安裝證書。

安裝證書兩種方法：

勾選后點擊右邊的Actions按鈕選擇“Trust Root Certificate”選項，然后全部選擇是就行了。

勾選后點擊右邊的Actions按鈕選擇第二個選項將證書導出到桌面，然后再在對應的瀏覽器里面添加即可。

然后我們再打開一個新的網頁(例如百度)，查看請求

至此，已經可以監聽PC端瀏覽器的請求了。

14.10 移動端抓包

首先你的Fiddler所在的電腦和手機必須處在同一個局域網內(即連著同一個路由器)。

查看你的本機IP地址，在Fiddler的右上角有一個Online按鈕，點擊一下會顯示你的IP信息

配置連接信息：Tools > Options >Connections

端口默認是8888，你可以進行修改。

勾選Allow remote computers to connect選項，然后重啟Fiddler，再次打開時會彈出一個信息，選擇ok即可。

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

最后安裝手機證書，在手機瀏覽器一欄輸入電腦的IP地址和端口號

這里我是192.168.1.157:8888

進入一個網頁，點擊最下面那個FiddlerRoot certificate下載證書，下載成功后在設置里面安裝，安裝步驟：打開高級設置->安全->從SD卡安裝證書->找到證書文件->點擊后為證書命名點擊確定即可安裝成功

測試一下，比如在手機上打開抖音app，找到評論的那一個請求。

在這里還是要推薦下我自己建的Python自動化學習群: 902061117 ，群里都是學Python自動化測試的，如果你正在學習Python ，小編歡迎你加入，大家都是測試開發黨，不定期分享干貨（只有Python軟件測試相關的），包括我自己整理的一份2021最新的Python自動化資料。

這些資料，對于【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你

關注我的微信公眾號【傷心的辣條】自行獲取~

如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！

推薦閱讀：

什么樣的人適合從事軟件測試工作？

談談從小公司進入大廠，我都做對了哪些事？

想轉行做軟件測試？快來看看你適不適合

軟件測試從自學到工作，軟件測試學習到底要怎樣進行？

軟件測試工程師簡歷項目經驗怎么寫?–1000個已成功入職的軟件測試工程師簡歷范文模板（真實簡歷）

總結

以上是生活随笔為你收集整理的禅道/缺陷报告/测试报告/接口测试及用例/Fildder的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。