測試技術好多種RRR
根本就像用了魔法卡繁殖的小精靈
來源:http://immortalnova.hatenablog.com/entry/2016/06/17/181726
我覺得單一個測試技術就像一個小精靈
一個小精靈一點都沒有威脅性，但是當他搭配了魔法卡「繁殖」之後多了好多個小精靈，根本厲害啊，打也打不完
這也代表著多個測試技術組合起來的測試方法會更能夠掌握目前產品的風險
這一篇的心得來自於 微軟測試之鑰 微軟一線測試專家技術精華 這一本書的第5章第1節，以下簡稱為此書
如果說測試是為了發現錯誤而執行程式的過程，那麼測試技術就是執行程式並判斷其對錯的具體方法
節錄自此書第 5-2 頁
我覺得，測試就好像在開車，而測試技術就像停車技巧、打檔、踩油門、轉方向盤等等的各種具體開車行為。
在此書的這一個章節中引用了 Cem Kaner 教授建立的測試技術分類系統來撰寫
Cem Karner教授的相關資料 https://en.wikipedia.org/wiki/Cem_Kaner
測試技術會從 7 個方面對測試過程進行指導
-
範圍 => 被測對象
-
覆蓋 => 測試深度與廣度
-
測試者 => 測試者
-
風險 => 需要被發現的潛在問題
-
活動 => 如何執行測試
-
評估和測試先知 => 對測試結果進行評估
-
結果導向 => 測試的目標
Cem Karner 建立了六要素測試分類系統，以下是測試分類系統的六大分之
-
基於涵蓋的測試技術，關注測試的範圍和涵蓋
-
基於測試者的測試技術，關注誰來執行測試
-
基於風險的測試技術，關注潛在問題
-
基於活動的測試技術，關注如何執行測試
-
基於評估的測試技術，關注如何判斷測試通過
-
結果導向的測試技術，關注於特定目標或檔案
關於這六大分之作者也有對其中相關的測試技術進行列舉
1. 基於涵蓋的測試技術，關注測試的範圍和涵蓋
這個是典型的測試技術，其包含了
- 功能測試
- 功能或特性的整合測試
- 邊界測試
- 最佳代表測試
作者提出了不只這 4 個名詞其主要要表達的是基於涵蓋的測試技術所關注的都是被測對象的功能和功能之間的互動性是否符合預期
這邊特別可以說的是最佳代表測試
最佳代表測試 : 要求從眾多測試範例中選擇最有代表性的測試範例，常見的例子包含使用者最可能使用的資料、給產品最大挑戰的資料、最能暴露風險的資料等
節錄自此書第 5-3 頁
我想，最佳代表測試，就是拿來自動化測試跑的一種測試範例吧，畢竟他風險最大、最容易暴露風險。
當然，並不是只有最佳代表測試才能被自動化執行。
2. 基於測試者的測試技術，關注誰來執行測試
其實這一個基於測試者的測試技術十分常見，在遊戲業界中就會常常聽到要封測，就算是一種用戶的 Beta Test
這一種測試技術其實也很常見，以下是作者列舉的測試技術的其中幾種
- 缺陷大掃除 (Bug Bash)
- 結對測試 (Pair Testing)
- 內部試用
缺陷大掃除可以參考我之前在自己團隊所執行的結果與經驗(趁機打廣告XD
Test - 我舉辦了一場 Bug Bash－大家都進來測試吧!!
結對測試就跟結對編程很像
由另一個人來觀察、指導與紀錄測試過程，在這一個執行的過程之中就可以獲得對於產品不同角度的Feedback
內部試用這點可以參考這一篇 wiki
主要的目的就是讓自己可以在日常中使用自己的產品，讓自己對於產品更有自信心，也可以在日常的開發週期中發現一些實際使用者會遇到的問題。
3. 基於風險的測試技術，關注潛在問題
以風險作為角度的測試，就是用來避免非常態的使用情境來發現問題，以下是作者列出的其中幾種測試技術
- 邊界測試
- 壓力測試
- 負載測試
- 可用性測試
- 基於歷史的測試
這幾點可以看得出來都是以非常態的使用狀態來進行測試，這些基於風險的測試，通常都會使用工具來輔助測試人員來進行測試。
常見的壓力測試及負載測試的工具用google就可以找到很多了~ EX: jmeter、apache bench等等之類的
甚至有些已經發展成一種服務囉~
4. 基於活動的測試技術，關注如何執行測試
以下是作者列出的其中幾種測試技術
- 隨機測試
- 猴子測試
- 情境測試
- 回歸測試
其實猴子測試也可以算是基於風險的測試技術，但作者將其歸類於基於活動的測試技術。
不過我覺得不管測試技術被分類於哪一種分類底下，只要他能夠達成想要達成的測試目的，就可以了。
這邊可以特別說的是回歸測試，回歸測試的目的就是為了避免產品的程式碼在進行變更之後而產生問題的一種測試技術，但他有一個很大的成本
其成本就是時間
時間越長的回歸測試，能涵蓋及避免的問題就越廣，即時間越短的回歸測試，能涵蓋及避免的問題就越狹隘。
5. 基於評估的測試技術，關注如何判斷測試通過。
我認為，基於評估的測試技術，主要是根據用戶的需求，或是訂製出來的規範而進行的一種測試技術。
不過有趣的是，訂定出來的規範以及用戶需求，都不是測試人員自己所決定的，常常是需要第三方的人、事、物來一同決定其測試是否通過。
所謂人，就是團隊或客戶
所謂事、物，就是「討論」、「執行」之後所產出的「文件」
以下是作者提到諸多的基於評估測試技術的其中兩種測試技術
- 比較規格說明或其他權威檔案
- 基於診斷的測試
第 1 個就是依據文件來執行的測試技術，比對文件內容與軟體執行結果是否符合來評估目前測試是否通過
第 2 個就是依據工具來執行的測試技術，使用工具來進行對於產品的測試，其結果通常會有報告，然後再依據報告結果進行評估目前測試是否通過。
6. 結果導向的測試技術，關注於特定目標或檔案
結果導向的測試技術，就是所謂的「以終為始」，以最終最能夠解決客戶需求的功能，來進行測試，這樣的測試通常是最簡單但很重要的測試。
有些軟體也會要求須要符合某些認證標準才能夠Release。
以下測試技術是作者列出的其中 2 種測試技術
- 用戶接受測試
- 認證測試
結語
在學習測試技術時，測試人員可以快速定位它在分類系統中的位置。
在選擇測試技術時，他可以同時運用來自不同分支的測試技術，以實施多樣化的測試。
節錄自此書第 5-8 頁
在最後此書也有提到由 Lisa Chrispin 和 Janet Gregory 提出的測試象限的概念，如下圖，該圖拍攝於此書的 5-9 頁
在此圖可以清楚看到它的架構分類四大象限，相較於 Cem Kaner所提出的六大分支來得易於理解許多。
不過這邊特別要說的是作者不同意 Lisa Chrispin 和 Janet Gregory將探索式測試置於第三象限，原因是因為
探索式測試是一種並行地實施測試學習、測試設計、測試執行呵結果評估的測試風格，作為一種測試思維方法，它可以指導測試象限的任何一種測試技術的使用
節錄自此書第 5-9 頁
我覺得...
探索式測試其實就是一種Interface，而其他執行測試的過程與技術，就是實作這個探索式測試的各種方法
以上是跟大家分享 微軟測試之鑰 微軟一線測試專家技術精華 5-1 的內容
最後想問大家一個問題
不知道大家對於探索式測試的看法及作法是甚麼?
感謝各位大大觀看 <(_ _)>
周記碎碎念
連續好幾周沒有寫了..要轉動齒輪真的需要比較大的力氣，希望自己可以再持續下去，我想一定是動力還不構，看來要弄個連續寫三周就吃大餐的 Bonus (誤