本章邰老师通过如下的测试模型开始了分享
关于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上过于关注需求细节，做刚刚好的信息收集，有条理的收集，逐层细化