本章邰老師通過如下的測試模型開始了分享
關於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上過於關注需求細節，做剛剛好的資訊收集，有條理的收集，逐層細化
學習心得 python學習心得
自從來了深圳工作以後，尤其是屢屢面試碰壁以後。發現其實自己的知識面很窄，做筆試題的時候絞盡腦汁還是漏洞百出，並不是不會做，而是出現一大堆不該有的失誤。每次被問道，對資料庫了解嗎？說一大堆看起來很高階的東西 好啊，那我們寫幾個sql語句吧。馬上完蛋了，沒了手冊關鍵字都記不起。了解哪幾種指令碼語言，sh...
學習心得 我的學習心得
我是乙個已經步入中年的70後，離開校園已經20年了，因為當年的政策因素而未能圓我的大學夢，在20年的工作過程中總是因為缺少一張大學文憑而失去了很多機會，曾經也考慮過自考，但是乙個人去面對的時候總感覺心有餘而力不足。2018年3月份偶然讓我認識了尚德，原來自考還可以這樣學習。一直懷疑自己年紀大了記憶力...
Spring學習心得
不看不知道,一看便學到,會不會與您產生共鳴呢?喜歡再捧場拍磚 spring使用從一年前開始，邊學習邊開發。這裡講講我的學習心得。第一條 記住ioc就是spring的一切。而掌握ioc的唯一方法就是使用和思考。spring是ioc為核心的，所以第一步就是要深刻理解ioc，最好是能盡快把ioc作為教條式...