這是一份機票預訂系統的軟體測試報告，老師評分98分，希望能幫助各位園友。
一、 測試任務、目標
本次課程設計將對航班訂票系統進行系統測試，驗證系統是否滿足登入註冊以及訂票退票等功能要求，同時測試系統的效能是否達標。
二、 進行測試工作量估計
根據機票預定系統的需求規格說明書，可以看出這是一個規模比較小的系統，可以採用手工測試和自動化測試相結合的方式進行測試。可以採用場景法、成效價類劃分法、邊界類法和常見錯誤法來編寫測試用例。本系統有8個功能點要測試，比較複雜的功能點是新增訂票、查詢訂票和修改訂票三個功能點，每個功能點大約需求10個測試用例，其它均為2-5個測試用例，初步估計有50個測試用例，約有3人/天的工作量，執行測試則有6人/天的工作量。
三、 人員資源和資源分配
人員資源分配：
小組成員每人各負責一部分進行開發測試：
測試員（一人）
軟體工程需求分析（一人）
系統設計員（一人）
專案經理（一人）
架構師（一人）
資源分配：
初級設計不需要用到過多資金，只需保證人手一臺電腦裝置，以供成員使用即可。
四、明確任務的時間和進度安排
機票預訂系統設計週期預計為一個月，一個月內完成模型的初步設計。其中具體時間安排如下：
其中設計進度為期一個月，其中為確保工期按時完成，每個星期都會有一次階段性驗收。
五、風險估計和應急計劃；
風險估計：
1.系統可側性差
2.測試環境不符合測試要求
3.測試人手不夠，時間不足
4.測試所需硬體、軟體需求不滿足
應急計劃：
1.加強測試環境的管理和改進
2.在專案前期加強對人員的管理和培訓，測試人員要儘早熟悉產品，做好人員分配工作。
3.測試前做好測試所需硬體配置，軟體安裝更新等工作。
六、測試失敗/透過的標準
在功能測試中，系統中各功能能正常執行；在效能測試中，各類測試指標包括測試中應該達到的某些效能指標，這些效能指標均是來自應用系統設計開發時遵循的業務需求，當某個測試的某一類指標已經超出了業務需求的要求範圍，則測試已經達到目的，即可終止壓力測試。
應用軟體級別的測試指標：
測試用例執行透過率,透過的測試用例個數/測例總數。該值>=95,
(1) 事務的執行情況
事務的平均響應時間（期望值：<15s）
事務的最大響應時間（期望值：<30s）
平均每秒處理數量（分別記錄單位時間內成功、失敗和停止的數量）
不同併發使用者數的狀況下的上述記錄值
(2）測試結果分析情況
測試指標：
吞吐量：單位時間內網路傳輸資料量
七、測試範圍
1.功能測試
註冊和登入使用者資訊
訂票辦理
退票辦理
查詢購票資訊
- 效能測試
本次測試是針對系統的效能特徵和系統的效能調優而進行的，主要需要獲得如下的效能測試指標。
1、系統的響應能力：即在各種負載壓力情況下，系統的響應時間，也就是從客戶端交易發起，到伺服器端交易應答返回所需要的時間，包括網路傳輸時間和伺服器處理時間。
2、應用系統的吞吐率：即應用系統在單位時間內完成的交易量，也就是在單位時間內，應用系統針對不同的負載壓力，所能完成的交易數量。
3、應用系統的負載能力：即系統所能容忍的最大使用者數量，也就是在正常的響應時間中，系統能夠支援的最多的客戶端的數量。
3.UI介面測試
1、導航、連結、 Cookie 、頁面結構包括選單、背景、顏色、字型、按鈕名稱、 TITLE 、提示資訊的一致性等。
2、友好性、可操作性（易用性）
4.安全性測試
1、程式安全性
2、網路安全性
- 資料庫測試
① 系統資料機密性
② 系統資料的完整性;
③ 系統資料可管理性;
④ 系統資料的獨立性;
⑤ 系統資料可備份和恢復能力
八、測試策略
1.單元測試
人工靜態檢查：
主要是保證程式碼邏輯的正確性。包括檢查機票預定系統中演算法的邏輯正確性、模組介面的正確性、檢查輸入引數有沒有作正確性檢查、呼叫其他方介面的正確性、異常錯誤處理、保證表示式、SQL語句的正確性、檢查常量或全域性變數使用的正確性、程式風格的一致性、規範性、檢查程式碼註釋是否完整。
動態執行跟蹤：
檢查實際的執行結果和預期結果是否一致。保證機票預定系統的程式碼覆蓋率，儘量做到程式碼的全覆蓋。常見單元測試覆蓋標準：語句覆蓋、分支覆蓋、條件覆蓋、分支-條件覆蓋、條件組合覆蓋、路徑覆蓋。
2.整合測試
機票預定系統經過單元測試的模組一個接一個地組合，然後測試組合單元的功能。通常，整合測試是在單元測試之後進行的。一旦建立並測試了所有單個單元，我們便開始組合那些經過測試的模組並開始執行整合測試。這裡的主要目標是測試單元/模組之間的介面。以下是一些進行整合測試的簡單步驟：準備測試整合計劃、確定整合測試方法的型別、相應地設計測試用例，測試場景和測試指令碼、一起部署所選模組並執行整合測試、跟蹤缺陷並記錄測試結果、重複上述步驟，直到測試完成整個系統。
3.系統測試
機票預定系統的系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。系統測試發現問題之後要經過除錯找出錯誤原因和位置，然後進行改正，是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。物件不僅僅包括需測試的軟體，還要包含軟體所依賴的硬體、外設甚至包括某些資料、某些支援軟體及其介面等。
4.驗收測試
在此階段下，機票預定系統已透過三個測試級別(單元測試，整合測試，系統測試)但仍可能有一些小錯誤，當終端使用者在實際場景中使用系統時，可以識別這些錯誤。驗收測試是對先前完成的所有測試過程的擠壓。需求分析：測試團隊分析需求文件以找出所開發軟體的目標。透過使用需求文件，流程圖，系統需求規範，業務用例，業務需求文件和專案章程完成測試計劃。測試計劃建立：概述測試過程的整個策略。測試用例設計：能夠涵蓋大多數驗收測試場景。測試用例執行：包括使用適當的輸入值執行測試用例。測試團隊從終端使用者收集輸入值，然後測試用例和終端使用者執行所有測試用例，以確保軟體在實際場景中正常工作。確認目標：成功完成所有測試過程後，測試團隊確認軟體應用程式沒有錯誤，可以將其交付給客戶端。
九、測試用例的設計與規劃
| 所屬產品 | 所屬模組 | 相關需求 | 用例標題 | 前置條件 | 步驟 | 預期 | 用例型別 | 用例狀態 |
|---|---|---|---|---|---|---|---|---|
| 機票預定系統 | 登入 | 正確登入 | 登入 | 無 | 使用已經註冊的賬號和密碼 | 登入成功 | 功能測試 | 正常 |
| 機票預定系統 | 登入 | 賬號不存在，無法登入 | 無法登入1 | 無 | 沒有註冊的使用者名稱進行登入 | 登入失敗，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 登入 | 密碼不正確，登入失敗 | 無法登入2 | 無 | 輸入錯誤的密碼進行登入 | 登入失敗，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 查詢機票 | 輸入不存在的地點進行查詢 | 查詢航班1 | 已經登入 | 輸入不存在的地點，點選查詢 | 查詢失敗，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 查詢機票 | 輸入正確的地點進行查詢 | 查詢航班2 | 已經登入 | 輸入正確的地點，點選查詢 | 查詢成功，顯示航班資訊 | 功能測試 | 正常 |
| 機票預定系統 | 訂票 | 選擇已經售完的機票，給出提示資訊 | 訂票失敗1 | 已經登入，查詢到對應的機票 | 點選已經售完的機票 | 無法訂票，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 訂票 | 選擇有餘票的機票，沒有選擇支付方式 | 訂票失敗2 | 已經登入，查詢到對應的機票資訊 | 點選未售完的機票，點選支付按鈕 | 提示選擇支付方式 | 功能測試 | 正常 |
| 機票預定系統 | 訂票 | 選擇有餘票的機票，選擇支付方式，但是餘額不足 | 訂票失敗3 | 已經登入，查詢到對應的機票資訊 | 點選未售完的機票，選擇支付方式，點選支付按鈕 | 支付失敗，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 訂票 | 選擇有餘票的機票，選擇支付方式，餘額充足 | 訂票成功 | 已經登入，查詢到對應的機票資訊 | 點選未售完的機票，選擇支付方式，點選支付按鈕 | 支付成功 | 功能測試 | 正常 |
| 機票預定系統 | 退票 | 退票時間在航班規定退票時間點之後，退票失敗 | 退票失敗 | 已經登入，購買相應的機票 | 選擇購買的機票，點選退票按鈕 | 退票失敗，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 退票 | 退票時間在航班規定退票時間點之前，退票成功 | 退票成功 | 已經登入，購買相應的機票 | 選擇購買的機票，點選退票按鈕 | 退票成功，機票的金額返還給使用者 | 功能測試 | 正常 |
| 機票預定系統 | 使用者充值 | 使用者往系統充值一定數量的金額，沒有選擇支付方式 | 充值失敗1 | 已經登入 | 進入個人中心，點選充值按鈕，直接點選支付 | 充值失敗，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 使用者充值 | 使用者往系統充值一定數量的金額，選擇支付方式，但是金額不足 | 充值失敗2 | 已經登入 | 進入個人中心，點選充值按鈕，選擇支付方式，點選支付 | 充值失敗，給出提示資訊 | 功能測試 | 正常 |
| 機票預定系統 | 使用者充值 | 使用者往系統充值一定數量的金額，選擇支付方式，金額充足 | 充值成功 | 已經登入 | 進入個人中心，點選充值按鈕，選擇支付方式，點選支付 | 充值成功 | 功能測試 | 正常 |
| 機票預定系統 | 使用者投訴 | 使用者點選投訴按鈕，投訴理由不合理 | 投訴失敗 | 已經登入 | 點選投訴按鈕，填寫投訴理由，點選提交按鈕 | 投訴失敗 | 功能測試 | 正常 |
| 機票預定系統 | 使用者投訴 | 使用者點選投訴按鈕，投訴理由合理 | 投訴成功 | 已經登入 | 點選投訴按鈕，填寫投訴理由，點選提交按鈕 | 投訴成功 | 功能測試 | 正常 |
| 機票預定系統 | 機票資訊 | 從航空公司的資料庫獲取機票資訊，顯示在系統裡 | 顯示機票資訊 | 無 | 1. 建立GET請求 2. 設定請求Param 3. 設定斷言 4. 執行請求 | 顯示成功 | 介面測試 | 正常 |
| 機票預定系統 | 購買的機票資訊 | 從資料庫獲取使用者已經購買的機票，顯示在系統裡 | 顯示購買機票資訊 | 已經登入和購買機票 | 1. 建立GET請求 2. 設定請求Param 3. 設定斷言 4. 執行請求 | 顯示成功 | 介面測試 | 正常 |
十、測試環境和測試條件的規劃
作業系統：window10
資料庫：mySQL8.0
伺服器：tomcat1.0
CPU：8核
記憶體：16G
硬碟：1T
網路：百兆寬頻
測試前置條件：將網站進行本地搭建，資料完整，功能正常
十一、 測試工具的設計和選擇
Jmeter：不依賴於介面，如果服務正常啟動，傳遞引數明確就可以新增測試用例，執行測試。
測試指令碼不需要程式設計，熟悉http請求，熟悉業務流程，就可以根據頁面中input物件來編寫測試用例。
測試指令碼維護方便，可以將測試指令碼複製，並且可以將某一部分單獨儲存。
可以跳過頁面限制，向後臺程式新增非法資料，這樣可以測試後臺程式的健壯性。
利用badboy錄製測試指令碼，可以快速的形成測試指令碼。
Jmeter斷言可以驗證程式碼中是否有需要得到的值。
使用引數化以及Jmeter提供的函式功能，可以快速完成測試資料的新增修改等。
selenium：Selenium是一個用於Web應用程式自動化測試工具。Selenium測試直接執行在瀏覽器中，就像真正的使用者在操作一樣。而且它開源、多瀏覽器、多平臺、api齊全（自帶很多方法）、瀏覽器內執行
loadrunner：LoadRunner 是一種預測系統行為和效能的工業標準級負載測試工具。透過以模擬上千萬使用者實施併發負載及實時效能監測的方式來確認和查詢問題，LoadRunner 能夠對整個企業架構進行測試。透過使用LoadRunner ， 企業能最大限度地縮短測試時間， 最佳化效能和加速應用系統的釋出週期。目前企業的網路應用環境都必須支援大量使用者，網路體系架構中含各類應用環境且由不同供應商提供軟體和硬體產品。難以預知的使用者負載和愈來愈複雜的應用環境使公司時時擔心會發生使用者響應速度過慢， 系統崩潰等問題。這些都不可避免地導致公司收益的損失。