這邊我使用 NotebookLM 來嘗試建立測試計劃
需求來源
https://www.thsrc.com.tw/ArticleContent/58764cad-504a-486c-b1dc-f42aaa4f3552
(A) 直接開立測試計劃
a. prompt
假設你是資深有經驗的測試人員
請根據 IEEE 829 Test Plan 格式, 撰寫一份測試計劃, 請用中文撰寫
b. 產出
提供的資源中沒有關於 IEEE 829 測試計劃格式的資訊，因此無法根據該格式撰寫測試計劃
資源中僅提供關於台灣高鐵 T-EX 應用程式功能的說明，包括訂票、付款、取票、分票、智慧語音訂票和手機票證過閘等功能的詳細步驟和注意事項。3456…。
若要根據 IEEE 829 測試計劃格式撰寫測試計劃，你需要提供更多關於 IEEE 829 標準的資訊，以及要測試的特定軟體或系統的功能需求和設計規格。
c. 個人感想
結果發現 Notebook 說不知道什麼是 IEEE 829. 幸好它沒有自己瞎掰騙我
我記得在 ChatGPT 中它毫不猶豫就產生出測試計劃出來
因此, 我只好網路上再找份 IEEE 829 Test Plan 輸入到 NotebookLM中
然後再請它產生測試計劃
d. 產出
台灣高鐵 T-EX 應用程式 測試計劃
1. 測試計劃識別碼: THSR-T-EX-TP-001
2. 參考資料:
●”T-EX App 訂/付/取票/分票說明 – 台灣高鐵”
3. 簡介:
本測試計劃旨在概述針對台灣高鐵 T-EX 應用程式的測試策略和方法。 該應用程式為旅客提供便捷的購票、付款、取票和管理車票等功能。 本計劃將涵蓋應用程式主要功能的測試，包括訂票、付款、取票、分票、智慧語音訂票和手機票證過閘等。
4. 測試項目:
●T-EX 應用程式 (iOS 和 Android 版本)
●智慧語音訂票服務
●手機票證過閘功能
●分票服務
●「今日自由座」專區
●智慧型手錶整合 (iOS 和 Android 版本)
5. 軟體風險議題:
●應用程式安全性: 保護使用者敏感信息 (例如信用卡資訊和個人資料) 的安全性至關重要。
●系統整合: 應用程式與後端系統 (例如購票系統和支付平台) 的整合需要進行徹底測試，以確保順暢的交易流程。
●使用者體驗: 應用程式必須提供直觀且易於使用的介面，以滿足各種旅客的需求。
●效能: 應用程式應在不同網路環境和設備上保持快速響應和穩定性。
6. 待測功能:
●訂票
○搜尋和選擇車次
○選擇座位偏好
○輸入旅客資訊
○使用電子優惠券
○預訂輪椅座位和乘車導引服務
●付款:
○使用信用卡付款
○使用行動支付 (例如 Apple Pay 和 Google Pay)
○使用便利商店付款
●取票:
○手機取票
○分票給同行者
○便利商店取票
●分票:
○透過即時通訊軟體、簡訊或電子郵件分享車票
●智慧語音訂票
○使用語音或文字輸入訂票資訊
○查詢時刻表和票價
●手機票證過閘:
○使用手機上的 QR 碼過閘
●「今日自由座」專區:
○購買當日自由座車票
○僅限購票手機過閘
●智慧型手錶整合:
○查看今日車票
○查詢高鐵時刻表
7. 不進行測試的功能:
●與外部系統 (例如銀行和第三方支付平台) 的整合將不包含在本測試計劃中。
●應用程式中與高鐵行程無關的功能 (例如新聞和娛樂) 將不進行測試。
8. 測試方法:
本測試將採用黑盒測試方法，重點關注應用程式的功能和使用者體驗。 測試將涵蓋以下方面:
●功能測試: 驗證應用程式是否按照預期執行其功能。
●使用者介面測試: 確保應用程式介面直觀且易於使用。
●相容性測試: 測試應用程式在不同設備和作業系統上的相容性。
●效能測試: 評估應用程式的響應時間、穩定性和資源使用情況。
●安全性測試: 驗證應用程式是否安全地處理使用者資訊。
9. 測試通過/失敗標準:
●功能測試: 所有測試用例必須成功執行，並且應用程式行為應符合預期。
●使用者介面測試: 應用程式介面應符合設計規範，並且易於使用。
●相容性測試: 應用程式應在所有目標設備和作業系統上正常運行。
●效能測試: 應用程式應滿足預定的效能指標。
●安全性測試: 不應發現任何重大安全漏洞。
10. 暫停準則和恢復需求:
●如果發現阻礙進一步測試的重大缺陷，測試將暫停。
●在開發團隊修復缺陷並發布新版本應用程式後，測試將恢復。
11. 測試交付物:
●測試計劃文件
●測試用例
●測試報告
●缺陷報告
12. 剩餘測試任務:
●制定詳細的測試用例。
●準備測試數據和環境。
●培訓測試人員。
13. 環境需求:
●具有不同作業系統和螢幕尺寸的行動設備。
●穩定的網路連接。
●測試帳戶和數據。
14. 人員和培訓需求:
●具備行動應用程式測試經驗的測試人員。
●熟悉 T-EX 應用程式的測試負責人。
15. 責任:
●測試負責人: 制定和執行測試計劃，管理測試團隊。
●測試人員: 執行測試用例，報告缺陷。
●開發團隊: 修復缺陷，發布新版本應用程式。
16. 時間表:
●測試計劃審查: [日期]
●測試用例開發: [日期]
●測試執行: [日期]
●測試報告: [日期]
17. 風險和應急計劃:
●風險: 測試時間表可能會受到開發延誤的影響。
●應急計劃: 如果發生開發延誤，將調整測試時間表。
18. 批准:
●[測試負責人姓名]
●[專案經理姓名]
19. 詞彙表:
●T-EX: 台灣高鐵行動購票應用程式。
●QR 碼: 快速響應碼。
備註:
●本測試計劃將根據測試進度和需求進行更新。
●所有測試相關文件將存儲在指定的共享位置。
額外說明:
由於資源中沒有詳細說明 T-EX 應用程式的設計規格，本測試計劃僅能提供一個概要性的測試策略。 在實際測試過程中，需要根據更詳細的應用程式規格和需求制定更具體的測試用例和測試步驟。
e. 個人感想
產生出來的計劃有點樣子, 但是廢話不少
有些東西需要我們提供給他, 例如: 人力資源, 測試環境, 測試時間等等
或者說大多數的東西都是我們要提供
NotebookLM只能在某些部分提供建議而已
(B) 提供了一部分背景資訊
a. Prompte
假設你是資深有經驗的測試人員
請根據 IEEE 829 Test Plan 格式, 撰寫一份測試計劃, 請用中文撰寫
請參考下面的背景資訊來撰寫測試計劃
(1) 測試時間: 3 週
(2) 測試人員: 4 位, 其中 2 位會做測試自動化, 擅長 python
(3) 測試環境: 目前只測試 app
(4) 測試風險
a. 沒有足夠 app 去測試 android
b. 測試人員經驗不到一年
c. 沒有開發的設計文件
b. 產出
台灣高鐵 T-EX 應用程式 測試計劃
1. 測試計劃識別碼: THSR-T-EX-TP-002
2. 參考資料:
●”T-EX App 訂/付/取票/分票說明 – 台灣高鐵”
3. 簡介:
本測試計劃旨在概述針對台灣高鐵 T-EX 應用程式進行為期三週的測試策略和方法。 該應用程式為旅客提供便捷的購票、付款、取票和管理車票等功能。本計劃將涵蓋應用程式主要功能的測試，包括訂票、付款、取票、分票、智慧語音訂票和手機票證過閘等。
4. 測試項目:
●T-EX 應用程式 (iOS 和 Android 版本)
5. 軟體風險議題:
●設備不足: 沒有足夠的 Android 設備進行測試。[c]
●測試人員經驗不足: 測試團隊成員經驗不到一年。[c]
●缺乏設計文件: 開發團隊沒有提供設計文件。[c]
6. 待測功能:
●訂票:
○搜尋和選擇車次
○選擇座位偏好
○輸入旅客資訊
○使用電子優惠券
○預訂輪椅座位和乘車導引服務
●付款:
○使用信用卡付款
○使用行動支付 (例如 Apple Pay 和 Google Pay)
○使用便利商店付款
●取票:
○手機取票
○分票給同行者
○便利商店取票
●分票:
○透過即時通訊軟體、簡訊或電子郵件分享車票
●智慧語音訂票:
○使用語音或文字輸入訂票資訊
○查詢時刻表和票價
●手機票證過閘:
○使用手機上的 QR 碼過閘
●「今日自由座」專區:
○購買當日自由座車票
○僅限購票手機過閘
7. 不進行測試的功能:
●因時間限制，智慧型手錶整合功能將不包含在本輪測試中。
8. 測試方法:
本測試將採用黑盒測試方法，重點關注應用程式的功能和使用者體驗。 測試將涵蓋以下方面:
●功能測試: 驗證應用程式是否按照預期執行其功能。
●使用者介面測試: 確保應用程式介面直觀且易於使用。
●相容性測試: 測試應用程式在不同設備和作業系統上的相容性。
●安全性測試: 驗證應用程式是否安全地處理使用者資訊。
●自動化測試: 兩位擅長 Python 的測試人員將針對核心功能 (例如訂票、付款和取票流程) 開發自動化測試腳本，以提高測試效率和覆蓋率。 [c]
9. 測試通過/失敗標準:
●所有測試用例必須成功執行，並且應用程式行為應符合預期。
●不應發現任何阻礙主要功能使用的嚴重缺陷。
●所有中級和低級缺陷應在發佈前修復或記錄。
10. 暫停準則和恢復需求:
●如果發現阻礙進一步測試的重大缺陷，測試將暫停。
●在開發團隊修復缺陷並發布新版本應用程式後，測試將恢復。
11. 測試交付物:
●測試計劃文件
●測試用例
●測試報告
●缺陷報告
●自動化測試腳本
12. 剩餘測試任務:
●制定詳細的測試用例。
●準備測試數據和環境。
●培訓測試人員，特別是針對 T-EX 應用程式和自動化測試工具的使用。
13. 環境需求:
●多台 iOS 設備。 [c]
●盡可能多地準備 Android 設備，以減輕設備不足的風險。 [c]
●穩定的網路連接。
●測試帳戶和數據。
14. 人員和培訓需求:
●四位測試人員，其中兩位具備 Python 自動化測試經驗。 [c]
●熟悉 T-EX 應用程式的測試負責人。
15. 責任:
●測試負責人: 制定和執行測試計劃，管理測試團隊，協調與開發團隊的溝通，並向專案經理報告測試進度和結果。
●自動化測試人員: 開發和維護自動化測試腳本，執行自動化測試，分析測試結果並報告缺陷。
●手動測試人員: 執行手動測試用例，探索性測試，報告缺陷，並提供使用者體驗方面的回饋。
●開發團隊: 修復缺陷，發布新版本應用程式，並提供必要的技術支援。
16. 時間表:
●第一週:
○測試計劃審查和最終確定
○測試用例設計和審查
○測試環境設置和數據準備
○測試人員培訓
●第二週:
○執行核心功能的手動測試
○開發和調試自動化測試腳本
○開始執行自動化測試
○缺陷報告和追踪
●第三週:
○完成所有功能的測試，包括邊緣案例和異常情況
○進行迴歸測試，確保已修復的缺陷沒有再次出現
○完成測試報告，總結測試結果、缺陷分析和建議
●備註: 此時間表僅為初步規劃，實際執行過程中可能需要根據測試進度和發現的缺陷進行調整。
17. 風險和應急計劃:
●風險一：Android 設備不足
○應急計劃:
■優先測試 iOS 版本，並盡可能調用更多 Android 設備。
■使用模擬器進行部分測試，但需注意模擬器可能無法完全模擬真實設備的行為。
■與開發團隊協商，延長測試時間或減少測試範圍。
●風險二：測試人員經驗不足
○應急計劃:
■加強測試人員培訓，特別是針對 T-EX 應用程式和測試方法的培訓。
■安排資深測試人員指導新進人員，進行結對測試和代碼審查。
■制定詳細的測試用例，盡可能涵蓋各種場景和邊界條件。
●風險三：缺乏設計文件
○應急計劃:
■與開發團隊溝通，盡可能收集相關的設計資訊，例如 API 文檔、資料庫結構等。
■透過探索性測試，更深入地了解應用程式的功能和行為。
■將測試過程中發現的設計缺陷和疑問反饋給開發團隊，協助完善設計文件。
18. 批准:
●[測試負責人姓名]
●[專案經理姓名]
19. 詞彙表:
●T-EX: 台灣高鐵行動購票應用程式。
●QR 碼: 快速響應碼。
備註:
●本測試計劃將根據測試進度和需求進行更新。
●所有測試相關文件將存儲在指定的共享位置。
額外說明:
由於資源中沒有詳細說明 T-EX 應用程式的設計規格，本測試計劃僅能提供一個概要性的測試策略。 在實際測試過程中，需要根據更詳細的應用程式規格和需求制定更具體的測試用例和測試步驟。
c. 個人感想
第二次後, 測試計劃的內容有比較詳盡
會根據我提供的背景資訊, 加以展開處理. 因此重點是要提供背景資訊
(C) 只針對測試計劃中某個章節展開
a. Prompt
假設你是資深有經驗的測試人員
需要撰寫測試計劃
請針對測試的進行策略部分, 撰寫 10 點事項, 請用中文撰寫
撰寫時請參考下面的背景資訊
(1) 測試時間: 3 週
(2) 測試人員: 4 位, 其中 2 位會做測試自動化, 擅長 python
(3) 測試環境: 目前只測試 app
(4) 測試風險
a. 沒有足夠 app 去測試 android
b. 測試人員經驗不到一年
c. 沒有開發的設計文件
b. 產出
測試進行策略
1.優先測試核心功能：
由於測試時間有限 (三週)，應優先測試應用程式最關鍵的功能，例如訂票、付款和取票流程。[c] 確保這些功能在各種情況下都能正常運作。[c]
2.分階段測試：
將測試分為多個階段，例如冒煙測試、功能測試、回歸測試和效能測試。 每一階段都有明確的目標和通過/失敗標準。[c]
3.利用自動化測試：
充分利用兩位擅長 Python 的測試人員，針對核心功能開發自動化測試腳本，以提高測試效率和覆蓋率。[c] 自動化測試可以重複執行，節省時間並減少人為錯誤。[c]
4.集中測試 iOS 版本：
鑑於 Android 設備不足，優先集中測試 iOS 版本，以確保在有限資源下獲得最大測試覆蓋率。[c]
5.模擬器輔助測試：
在 Android 設備不足的情況下，可以使用模擬器進行部分測試，但需注意模擬器可能無法完全模擬真實設備的行為，因此應盡可能使用真實設備進行測試。[c]
6.加強測試人員培訓：
由於測試團隊成員經驗不足，需加強培訓，包括 T-EX 應用程式功能、測試方法、缺陷報告流程和測試工具使用等。[c] 資深測試人員可以指導新進人員，進行結對測試和代碼審查，以提升團隊整體測試能力。[c]
7.探索性測試：
由於缺乏設計文件，鼓勵測試人員進行探索性測試，以更深入地了解應用程式功能和行為，並找出隱藏的缺陷和設計問題。[c] 探索性測試可以彌補缺乏文件所帶來的資訊不足。[c]
8.積極與開發團隊溝通：
積極與開發團隊溝通，盡可能收集相關設計資訊，例如 API 文件、資料庫結構等。[c] 測試過程中發現的設計缺陷和疑問應及時反饋給開發團隊，協助完善設計文件，並確保測試用例設計的準確性。[c]
9.建立詳細的測試用例：
儘管缺乏設計文件，仍需盡可能建立詳細的測試用例，涵蓋各種場景和邊界條件，以確保測試的完整性和覆蓋率。[c] 測試用例應包含預期結果，以便於驗證應用程式行為是否符合預期。[c]
10.持續回歸測試：
每當修復缺陷或發佈新版本應用程式後，都應進行回歸測試，確保已修復的缺陷沒有再次出現，並且新功能的加入沒有影響現有功能的正常運作。[c]
c. 個人感想
如果採用將大問題拆解成小問題,NotebookLM 表現很好
可以把它列得很詳盡很具體
(D) 針對要測試的功能做展開
a. Prompt
假設你是資深有經驗的測試人員
需要撰寫測試計劃
請針對需要測試的功能部分, 撰寫 15 點事項, 依風險優先順序排列, 請用中文撰寫
b. 產出
測試功能清單 (依風險優先順序排列)
由於缺乏詳細的設計文件，以下功能清單僅基於應用程式的一般功能和過往經驗，並結合目前已知的風險進行排序。在獲得更詳細的設計文件後，需要重新評估和調整測試功能的優先級別和範圍。 [c]
高風險功能:
1.訂票流程: [1, 3, c]
○輸入不同起訖站、日期、時間和車次 combinations 的訂票測試。[1, 3, c]
○驗證票種選擇功能，包括全票、早鳥優惠、大學生優惠、定期票等。 [1, 3, c]
○測試座位偏好功能，確認系統能否按照旅客需求分配座位。
○驗證訂票數量限制，單筆交易最多 10 張，去回票最多各 5 張。
○測試訂票時間限制，確認旅客能否在允許的時間範圍內訂票。
2.付款流程: [3, c]
○測試各種付款方式，包括信用卡 (VISA, MasterCard, JCB)、Apple Pay 和 Google Pay。
○驗證付款資訊的安全性，確保敏感資料得到妥善保護。[c]
○測試付款成功和失敗的處理流程，包括錯誤提示和訂單狀態更新。[c]
○驗證與第三方支付平台的整合，確保交易流程順暢。[c]
3.取票流程: [3, c]
○測試在 App 中取票的功能，確認票券資訊正確顯示。[3, c]
○測試分票功能，驗證分票流程和同行旅客取票的便捷性。
○測試「今日自由座」功能，確認購票、付款和取票流程的順暢性。
○測試智慧型手錶取票功能，驗證手錶與手機 App 的同步和資訊顯示。
○測試使用手機票證過閘門的功能，確保掃描 QR Code 可以順利進站。
4.修改/退票流程: [3, c]
○測試修改訂票的功能，包括日期、時間和人數的變更。[3, c]
○測試退票功能，驗證退票流程和退款處理的準確性。[3, c]
○測試不同情況下的退票規則，包括去回程票的處理和手續費的計算。
5.智慧語音訂票功能: [8, 14, c]
○測試語音辨識的準確性，確認系統能夠正確理解旅客的語音指令。 [8, 14, c]
○測試訂票流程的順暢性，驗證語音互動的便捷性和易用性。[8, 14, c]
○測試不同語音指令和查詢功能，確保功能的完整性和覆蓋率。[8, 14, c]
中風險功能:
6.帳戶管理: [c]
○測試註冊、登錄和密碼管理功能，確保帳戶安全性和易用性。[c]
○測試個人資料管理功能，包括修改、更新和驗證資訊。[c]
7.常用乘客名單: [8, c]
○測試新增、刪除和修改常用乘客資訊的功能，驗證資訊的準確性和完整性。[8, c]
○測試在訂票過程中使用常用乘客名單的便捷性。[8, c]
低風險功能:
8.時刻表和票價查詢: [1, 5, c]
○測試查詢不同起訖站、日期和時間的時刻表功能，確認資訊的準確性和即時性。[1, 5, c]
○測試查詢不同票種和區間的票價功能，驗證資訊的正確性。[1, 5, c]
9.高鐵訊息: [6, c]
○測試高鐵活動訊息、列車運行狀況和系統維護等資訊的顯示和更新。[6, c]
○驗證資訊的準確性和即時性，確保旅客能夠獲得最新的資訊。[c]
10.電子優惠券: [6, c]
○測試儲存、管理和使用電子優惠券的功能，驗證其便捷性和有效性。[6, c]
11.交易歷史紀錄: [6, c]
○測試查詢和管理過往交易紀錄的功能，確認資訊的完整性和準確性。[6, c]
12.提醒設定: [6, c]
○測試設定訂票、付款/乘車和到站提醒的功能，驗證提醒的準確性和即時性。[6, c]
13.無障礙服務: [5, c]
○測試預訂輪椅座位和申請乘車導引的功能，確保服務的可用性和便捷性。[5, c]
14.Siri 捷徑: [6, c]
○測試使用 Siri 捷徑進行訂票的功能，驗證其便捷性和易用性。[6, c]
15.其他功能: [c]
○測試「關於高鐵」、「聯絡我們」等功能的可用性和資訊的準確性。[c]
在測試過程中，需要根據實際情況調整測試的優先級別和範圍，並記錄所有測試結果和發現的缺陷，以便及時修正和完善應用程式。
c. 個人感想
對於需求的部分, 原先就有給他系統的說明, 所以它可以展開列得十分詳細
所以應該是要先檢視 test plan 的內容, 確認每一項目是否有給相關背景資訊, 如果有 NotebookLM 才可能給建議
所以你也不能不懂 test plan 原先要寫什麼. 不懂就無法給背景資訊
發表迴響