发凡测试种类四象限.PDF

CD CH4 發凡 1. 手動 VS 自動，如何取捨？如何權衡？太多測試依賴手動，本章會分享有效的自動化 測試策略以及操練 (practices) 2. Deming: 不要依賴大規模巡檢以成就品質，及早改善並且把品質建置進產品中。完整 的自動化測試將測試每個程式更動，種種的測試如單元 (unit)、元件 (component)、驗 收、手動、演示 (showcase)、可用性、探索性測試等等，都需要在專案中跟著開發持 續改善 3. TDD: 越早越好，完整的測試覆蓋就是好的回歸測試基礎 4. 非功能性測試 ：容量、安全性，如同其他測試做CI，可以及早發現那些更動會導致效 能問題或其他 5. 越早開始越好，專案中段才開始會有些慣性，不好追上，還是有些技巧可以讓舊有系 統上軌道 6. 測試是信心的基礎 ：臭蟲少、降低維運成本、維持好名聲。更鼓勵好的操練，並隨時 能提供最新文件以及技術規格 7. 只是九牛一毛，在此只舉梗概，更多細節請參考 Agile Testing, More Agile Testing 等 書 測試種類 ( 四象限) 業務面向並支持開發流程測試 1. 功能性或驗收測試，確保驗收標準都達成，最好自動化並在開發前就做。驗收測試主 要測試功能性、容量、可用性、安全性、可修改性、可用性等等，分為功能及非功能 性(第四象限) 2. 在敏捷環境中，驗收測試舉足輕重，告訴開發者什麼時候做好了，並告訴使用者想要 的功能已具備。Cucumber, JBehave, Concordian 與 Twist 等等的工具可以讓使用者 寫(驗收)測試腳本，讓開發者及測試人員實作系統面的測試 3. 應用程式中的單一標準路徑 ：快樂路徑 (happy path)。Given, when, then ：已知系統 測試起始時狀態，當使用者做某些操作，然後系統會進入新狀態。 4. 有時候起始狀態會有一些異同，操作及結束狀態也會有些差異，這就是替代路徑 (alternate path)。應該出錯的，就是悲傷路徑 (sad path)。需要一些經驗做些分析才能 分清這些路徑，並回饋做有效測試 5. 使用者驗收測試 (UAT)要在類上線環境中做，設置跟系統狀態都要盡量相同，外接服 務就用 mock，自動化驗收測試也是要在類上線環境做 自動化驗收測試的好處 ● 讓回饋迴路更快，開發者自己就可以知道東西壞掉沒，不需要找測試人員 ● 降低測試人員的負擔 ● 讓測試人員可以空出手腦來做探索性 (exploratory) 測試或是其他更高附加價值的活動 ● 驗收測試就是最好的回歸測試，對大規模協作及複雜依存系統很有幫助 ● BDD (behavior-driven development) 鼓勵分析師把需求寫成可執行的測試腳本，透過 Cucumber 或 Twist 做自動化，需求文件也可以一起進 CICD 探索性測試​ ：有經驗有頭腦的測試人員，會一邊熟悉系統一邊學習，一邊設計測試，一邊執行 測試，去探索自動化或舊測試未涉略之處女地，找到以前沒發現的 bug，補齊測試，或是發現 一些未知或意料之外的行為，跟著開發一起迭代，更進一步了解真實需求或確認需求真實，是 需要增減功能，這不是自動化能夠取代的測試，這需要創造性、洞察力及膽識，這不是black box testing，更不是ad-hoc testing，因為這一點都不sloppy，是很高技術含量的智慧行為，我 們要找的 QA 就要具備或培養這樣的能力 6. 回歸測試 (regresson) 是橫跨四象限的，所有的自動化測試就是回歸測試，幫助你做重 構 (refactoring/rearchitecting) 更有信心，確認系統行為沒破壞 7. 自動化測試維護起來可能昂貴，甚至有人反對大規模複雜的自動化測試，但依循一些 好方法及操練，是可以好好權衡，發揮自動化的效益 8. 自動化不是一體適用，有些如可用性、畫面版位、探索性測試就無法自動化。