本章邰老師通過如下的測試模型開始了分享
關於Risk感悟：
在這個模型中，針對一個被測系統我們可以問無數的問題，也可以進行無窮盡的測試的測試。做剛剛好的測試時要基於Risk(風險)的，做基於項目上下文的測試,把這些識別出來的風險作爲測試“啓發”
Risk包含兩個屬性 L：Likelihood(可能性) I :Impact(影響)
識別風險主要通過如下幾個方面：
1>基於整個研發流程的信息掌控。
2>用戶(用戶的痛點是什麼？用戶關注什麼？)
風險不是一層不變的，需要根據項目的進程持續迭代和更新。
關於Idea的感悟：
只要是做過一段測試的人，都會都熟悉的被測系統有自己的Test Idea，我們可以認爲這也是一種“啓發”，但很遺憾這種Idea往往是非常零散的、不夠完備的，有些可能不具備價值。我們需要將這些零散的Idea進行結構化、讓它便於交流，讓它能夠在交流的過程中更完備，並剔除不具備價值的內容。
Test Oracle:
Test Oracle就是你的 knowledge base,作爲一個測試人員在代碼的實現層面你可以不如DEV，但是對於需求瞭解、對於需求的領域知識（協議、業務流程、場景….）的瞭解不應該遜色與其他人。當然從廣義上來說，knowledge base不應該僅僅侷限測試這一個領域，你所掌握的所有技能和知識都是你的綜合能力。
Answer:
關於Answer 0,1,N的解釋。
有的人會認爲設計和測試執行會認爲一個測試用例或一次測試執行必須要有一個明確的測試預期結果。測試的過程應該是follow測試步驟並check測試結果。但Cem Kaner和邰曉梅等測試大牛認爲測試也可以看做是一種調查、探索和不斷學習被測對象的過程。在做探索之前結果是未知的（0）也就是沒有明確的測試結論，測試的作用可能不僅僅是發現Bug。N是指測試需要各種各樣的視角，每個測試人員的知識背景不同可能存在不同的測試設計，可能得到不同的測試設計結果，不用排斥而應該是學習和借鑑各種視角。
KYM:
KYM就是一種系統的收集和整理測試啓發的框架。
KYM 的價值在於促使項目干係人更頻繁的交流，及時獲取信息，提前發現風險。
在做一件事情的時候一定要遵循 why->how->what的思路進行，避免直接上來就進行what,就像做測試設計不能上來就寫用例，要提前做問題收集和風險識別，
KYM的引導詞：
CIDTESTED,從如下幾個方向考慮，收集信息（包括但不僅限於如下信息）：
Customer
Info
Dev relations
Test Item
Test Team
Schedule
Deliverable
Equipment & Tools
參考Page 52
需要注意的：
1>KYM重要的是你所做的溝通和交流，並不是花哨的呈現形式。無法從腦圖的炫酷程度來判斷KYM的好壞，要從任務上下文信息收集的好壞來評判。一切源於“用戶、項目、任務”
2>不要在KYM上過於關注需求細節，做剛剛好的信息收集，有條理的收集，逐層細化