這次我們說下第3大塊的流程,那就是Test Procedure,這里面有5大任務:
(1) 確定產品的目的
(2) 確定產品功能
(3) 確定潛在不穩定的地方
(4) 測試每個功能且記錄問題
(5) 設計和記錄一個持續性的驗證測試
產出 |
退出標準 |
目的陳述功能列表潛在的不穩定和有挑戰性數據的列表產品錯誤和注意點
持續性驗證測試 |
每個任務都完成了每個問題或疑惑都被測試經理解決了或接受了每個人員的產出都被測試經理接受了有足夠的信息可證明這個產品在功能性和穩定性上通過驗收 |
1.1 Identify the purpose of the product
評審這個產品并確定這個產品需要提供的基本服務,如果可以的話,定義這個產品的使用者。寫一段話簡單說明下這個產品的目的和目標用戶。
一些在目的陳述中用到的潛在的目的動詞
創建,編輯
查看,分析,報告
打印
解決,計算
管理,控制
通信,交互
提供數據,提供介入,搜索
支持,保護,維護
清除,解決,使其完善
讀,過濾,轉移,轉變
一些在目的陳述中對用戶的能力的討論
特殊技能,知識,能力,或無能
解決問題的能力
期望或需要
限制 (誰不會是這個產品的使用者)
產出 |
退出標準 |
目的陳述問題/爭論點 | 像上述那樣完成任務這個”目的陳述”必須都是經過需求方的確認從這個產品的目的中選擇對于用戶來說的最重要的方面 |
常見的問題:
為啥這個任務很重要?
如果沒有對這個產品的目的有所了解,就不能很好的區分主要的和貢獻性的功能。由于測試的大部分精力用在主要的功能上,所以這些區別是非常關鍵的。而我們不需要長篇大論,只要這個目的陳述里包含足夠的信息來讓我們跟蹤重要的可作為主要的功能就可以了。
該怎樣來寫這個目的陳述呢?
如果需求方提供了這個產品說明包含了用戶的調研,那我們可以從這個開始先過一遍,寫這個過程中,可以使用動詞+名稱的形式,比如’編輯簡單文本文件’ 或 ‘一個用戶無合法性的授權產生合法性的文檔’。而且如果這個產品有些目的需要一些特殊的屬性(相對于一般用戶),一定要在目的陳述中寫清楚。而這些目的動詞可以從之前說過的目的動詞庫中取(也可以豐富動詞庫),這也可以幫助我們注意到一些容易忘記的一些產品目的。
怎樣區別目的和功能呢?
目的是和用戶的需求相關的。功能是和這個產品所提供或產生的一些具體的東西相關的。
有時候一個功能的目的和這個功能的名稱是一樣的,比如’打印’:打印就是這個打印功能的目的。大多數時候,一個功能都提供了一個可以確定的更通用的目標。比如:一個文字處理器的目的就不是查找和替代文本;其實查找和替代就是編輯文本的一部分而已。編輯才是真正的目的。另外一方面,如果一個產品具有’ 超級搜索和替代’,那搜索和替代功能就可以是這個產品的目的。
1.2 Identify functions
首先走遍整個產品并發現產品在做什么。
對于所有的主要的功能做一個概要。
記錄一些有趣的或次要的貢獻性的功能。
對于我們不知道怎么去分類的或者覺得自己不能測試的任何功能,把它告訴測試經理。
一些查找出功能的途徑:
查看下在線幫助
查看下需求方的調查問卷
查看組成這個產品的所有程序
查看產品所有菜單
查看所有的窗口
查看工具欄
查看所有對話框和小工具
右擊查看所有數據對象,接口定義,窗口方框
雙擊查看所有數據對象,接口定義,窗口方框
查看產品所有為功能狀態轉換的選項設置
查看只有特殊的輸入才能觸發的功能
查看浸透在其他功能中的錯誤處理和恢復功能
功能分類:
主要的功能
貢獻性的功能
產出 |
退出標準 |
功能列表問題/爭論點 | 像上述那樣完成任務每個定義的主要的功能對于產品目的完成都是必須的已經合理的包含了貢獻性的功能 |
常見的問題
1. 為啥這個任務重要呢?
對這些功能的羅列,我們可以對將要測試的功能做一個概要。當完成測試的時候,這個概要可以作為我們理解這個產品和測試范圍的一個標記。這個功能概要對于測試經理或需求方來說都是一個很重要的記錄,并且可以作為參考,防止他們(包括將來被其他的測試人員咨詢)問我們做了什么,沒有做什么。
原文轉自:http://www.anti-gravitydesign.com