关于测试
问题表现：
配置化上线，风险怎么办？谁去保障你配的是对的呢？能不能基于配置去测试呢？
转化1：基于配置给我输出测试用例？这个是一个表面的转化，并没有解决根本的问题，也不是一个体系化的思维。或者可能是一个比较偏向表面的需求解读。
转化2：目的是为了验证业务的输入，是不是得到的结果，是我们想要的呢？所以这一层是偏全局的思维，也没有把需求解读全面。此时是： 你怎么样把业务要求的3分钟到达这个状态，给我反馈是对的呢？
发现矛盾点。但这个不是我解读的。
转化3：其实是基于配置出测试用例，认为这个是一个测试工具。
- 悖论是，如果你是自动化测试方案，你就是以状态机为入口，去测试状态机，这个没有什么意义。
- 答：其实我认为解读状态机的目的，也是为了动态化输出用例，或者输出条件，至于我们构建条件的过程，其实已经远离状态了，而是需要我们基于业务理解，去做不一样的排列组合。而以状态机去验证状态机，这个点，我不认同，首先我觉得读它是为了获取条件，那这个和你自己构造条件也是一样的，况且人工构造条件就能完结撇开状态机了吗？未必.比如你在非open API的时候，其实是需要把这带进去的，这个就需要你去读，既然都是读，和自动读，是没什么两样的。再者，我觉得验证的对象，也不是条件，条件拿到了，可执行性，这个点验证到了，但是真正去做执行的时候，重点是action啊，所以我这边是基于结果，做一个可视化的输出，这个可以和业务去比对的。
其实，即使是业务输入，也难得脱离的了状态机i，这个状态码也是一个啊。
转化4： 按照业务层输入，包含消息/timeout/TR等这几类，区分出不同的动作，由人员去做组合，同时输出可视化结果。
二 关于人工
明天又要去签单了啊，又有好几单了啊
回答：（你这个姓，哇塞，是人才辈出的姓啊）记住生活中的事件没记住名字，迟早会记住
点评：稍微清高了点。其实应该开开玩笑，当时直道是寻常啊老干妈
点评：太直接了，应该说句，不好意思总结： 永远不要忘了友好/ 积累生活中的笑点/ 夸奖他人/ 避免人性的弱点
