今天这篇文章，不聊纯技术，分享一些不一样的干货：技术背后的内驱力！
人之所以强大，在于（不安于现状的）人会不断的去学习，提升自己、突破自己。而保持多阅读是一种经久不衰且有效提升自我的学习途径！
如果把学习成长过程比喻成武功秘籍：
- 技术则是武功秘籍对应的招式修练，而想要练成绝世武功，光练招式还不够，还需要修炼对应的武功心法。
- 武功心法则对应的是我们的学习方法、学习思路或者说是学习背后的底层逻辑。
下面以软件测试&质量保障&质量建设几方面，给大家分享20条内功心法（行业金句），心法（金句）表面虽看似简单，但真正要做到并不容易，希望给大家在做质量改进工作时，多一些思考和启发！（也可以挑选一些作为你们公司或团队的文化建设标语）
软件测试：
- 任何软件的测试，都是可以基于
“输入-输出-行为”模型（又叫IBO模型）来做测试分析和设计。 - 当我们谈到“软件测试”时，是指软件测试的相关工作，如单元测试、集成测试、系统测试等，但不局限于动态测试，也可以包括静态测试——需求评审、设计评审、代码评审和借助工具进行代码静态分析。
- 测试是一个把质量意识输出到整个团队的人，是一个流程推动者，是一个需求挖掘者，是一个质量把关者，一方面我们确实通过自己的经验和技术手段去挖掘更多的Bug，另外一方面，通过传播质量意识尽可能的去从产品上游去避免Bug。
- 程序的测试可以证明程序有错，但永远无法证明程序无错。
- 一段程序，对于测试人员，bug永远是存在的，没有发现只是测试手段的不足。
- 测试做得再好，也只能是**减少 bug **的概率。
- QA和测试两者是有明显区别的，QA强调有好的研发过程产生好的产品，侧重过程定义、过程评审和过程改进，工作重心是预防缺陷，而测试属于质量控制，强调对软件阶段性产品和最终产品的质量检验，工作重心是发现缺陷。虽然测试是QA的重要手段之一，但不等同于QA。
- 研发偷偷上代码或者研发修改后给出的影响面不足导致出现线上问题的情况是非常比较常见的，尤其在小公司里面，常见的不得了；这个原因归根到底是，测试知道的或者能预防的太少了；
- 解释一下测试开发和开发工程师的区别，软件测试开发工程师（software engineer in test，后文简称SET）本质上也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。SET更加关注于质量提升和测试覆盖率的增加。他们这样做的目的是为质量服务，而SWE则更关注在客户使用功能开发的实现上。
- 很多人以需求规格为标准开展测试，所有的评判标准依据是“是否与需求文档一致”不一致就认为是Bug，这是很危险的做法，这只会拉低测试的高度，使其受限于需求规格的高度。
质量保障：
- 质量保障和测试的职责已从单纯的缺陷发现转变为客户满意度和业务成果的推动者了，这是个根本性的转变。
- 产品质量不仅仅是主管质量的部门和管理者的事情，而是所有员工的责任和义务。
- 产品质量或者工作中遇到问题不用慌，了解原因，制定方案，也许不能落地，但思考了，结果就是属于你的了；
- 测试或QA的职责是保证产品的质量，而bug过多则证明了产品质量差而不是产品质量好，bug多了证明团队当前是有问题的，证明QA在一定程度上没有做到位，证明当前的产品是有风险的。
质量建设：
- 质量体系的改进，不是一个一蹴而就的事情，它需要有耐心、有计划地进行。每一次过程改进都应该有要达到的目标，在目标没有达成之前就不应该轻易地进行下一次质量体系的改进。
- 每次引入新的质量理念也不是随意的进行。而是要看组织当前质量体系存在什么问题，希望怎样的体系改进能够解决这个问题。在考虑清楚这个问题之后，才去选择引入适合组织的新的质量管理理念。
- 以客户满意度为中心的质量体系建设。以客户为中心，从客户的角度看质量，所以满足客户需求的、用户期待的，都应该算做是质量，都是我们要持续改进的。
- 质量建设强调全员参与，全员参与有两个层面的问题要解决：一是意愿，二是能力。
- 很多团队在做质量建设时，一直都觉得资源不够，其实真不需要，富有富的打法，穷有穷的打法，关键要预判最大的难点，然后集中力量去攻克，集中力量打歼灭战，不要想那么多，初期就把核心点做好就行。
- 打造狼性团队，除了制度保证、考核到位以外，领导者的个人特质也是非常关键的。
- 好的质量的产品，不一定是完美的产品，不一定是没有缺陷的产品，而是为我们各种重要的用户提供相应价值的，并满足了他们对产品一定期望的产品。
看山是山，同一件事情在不同人眼中、甚至在不同阶段，都有不同的样子。一台电脑，可以用来吃鸡，可以用来看电影，也可以用来建模，还可以写论文，学渣与学霸都用一样的课本。
上面这些“内功心法”，不同人看到，可理解的程度也会不一样，是时候测试一下你是学霸 or 学渣？可以在留言区分享你对哪一条金句观点最为认同，或者分享一下对金句背后的理解。
