在目前最为正式且最早的笛卡尔 的方法论中，有着关于学习一套东西的四个注意点。
本文将联合我们测试领域的工作，去学习一下：
1.确保用来当作依据的事实是真实的
例子1: 小张准备开发一个非常难的自动化测试框架，整个实现过程很漫长，其中很多步骤的前提，都是某某条件达成，比如某某技术存在且可靠。在最理想甚至说是幻想的情况下，这个算法是可以完成的。结果小张开始了漫长的开发工作，可是好不容易进行了一大半的时候，才突然发现，其中一项很重要的技术元素自动定位技术 ，并没有开源，且无法改造，导致整个计划破产。小张欲哭无泪，他不知道怎么跟领导和同事交代，只好引咎辞职。这个事件告诉我们，在进行复杂的任务之前，一定要确保所有的依据/依赖都已经证明是真实可靠的，再开始。 例子2: 进行新项目的设计和推动，也叫做立项。 小明今天准备去晋升p7,在答辩时，他说想做一套全新的接口文档自测平台，可以有效的管理并统一接口文档的风格，提高接口文档的有效性，推动更新频率。 然后小明就开始对着台下的各位副总裁 总监 cto进行阐述，首先要介绍的就是项目背景。 1.公司内的接口文档混乱不堪，失效太多，测试同学怨声载道。 2.目前业界相关技术成熟，公众号：测试开发干货 上已更新可自动监控的接口文档平台 结果cto听的起劲的时候，旁边的一位中台总监不乐意了，他拆穿说：当前公司内的接口文档并没有混乱不堪，是可以正常使用的，并且公众号他刚刚关注了，并没有找到类似相关技术。所以最终小明的答辩失败告终。这里也劝诫大家不要把同事领导当傻子，拿一些不存在的东西当作依据。
2.困难的事要分成小部分一件一件来解决
小赵要做一件很困难的事，是什么呢？是一个超级ui自动化平台，她希望这个平台可以自行根据同事写的用例 直接就能让设备执行。这样看似魔法一样神奇的东西，真的可以实现么？实现的话，后续是不是维护起来很方便了呢？ 所以小赵把这件事开始进行分解： 1. 首先把用例分解成关键词 2.创造关键词匹配池系统 3.把提取的关键词智能分类成动作和断言等等 4.写一套元素库，存放页面的各种元素和其定位方式 5.写一个功能，可以自动录入元素，并且自动维护元素 6.写一套驱动系统，可以去自动驱动浏览器或手机设备 7.写一个动态脚本，让其可以去自动提取关键词来生成可执行脚本 8.写一个总控制平台，用来控制上述各个模块，并真实的执行脚本 9.开发报告系统/报警系统等等 ..... 就这样，小赵把这个事情分解成了40多个小模块之后，才认识到，其中的难度和风险等成本到底有多大，最终决定了放弃。转而选择去公众号：测试开发干货上直接下载现成的。
3.认识一个新事物要分步由浅入深，没有规则就自己创造规则去定义它
小王要创造一个新工具，叫元素自动定位工具，顾名思义，就是针对ui自动化不稳定的原因-元素频繁变更 进行自动维护，提高用例脚本的稳定性。 但是这个工具听起来就很困难，所以小王开始进行分解并定义它，在进行比对的时候，他给这个工具的一个自动定位的过程创造一套PTE理论，也就是PageThingElement。也就是说工具在自动维护元素的时候，先要分清这个要操作的元素是什么是一个页面，还是一个事件，还是一个控件标签。然后又创造了一套比对分数系统，根据控件的各种属性，比如id，长度，name，css，text ，位置等，对每个元素控件都设置了很多画像纬度，然后分别设置了比重，计算的最终得分来确定元素的真身，最终工具自然如愿以偿的创造出来了。
4.完成后要反复全局的去检测，以免自己以偏概全
接上面，小王创造出来这个工具后，在公司内进行多处应用来进行检测，发现这个计算最终得分的各种比重，在不同的项目中并不总是精准的。所以他设计了大数据智能推测比重的AI预测技术，但是因为其缺少大量数据和标注作为支撑，所以他决定把这个珍贵的技术进行开源和分享，让业界所有小伙伴都可以使用，然后汇总反馈，再集合起来喂给AI，让其更加智能。没错，它就是wqrfnium。
