这件小事，我坚持了 100 天

我一直相信自己是个长期主义者，但是这几次公众号的断更，还是对我打击挺大。

一方面肯定和自己缺乏行动力有关。

另一方面是因为自己对公众号文章的要求太高，尽量追求完美，所以压力就会比较大，总不敢下笔。

去年底我就想了另一个输出方式，写每日感悟。

主要写的是测试相关的经验总结，开始写的都是一句话浓缩的精华，后来因为很多人问，所以又做了扩展描述。

但不管哪一种，都是很简短的，所以写起来很快，然后就日更了，这才刚刚满 100 天。

早点让你加我微信好友没有加，这回亏大了吧。

不过也没事，我抽时间把这 100 天的输出给做了汇总，请查收：

每日感悟-100：家里用了几年的网突然不行了，本来准备打电话报修的，然后我问了下情况。 

有路由器这个屋没问题，另一个卧室的网不行了。

我试了下另一个屋的信号不大好，没隔多远，信号竟然一直都不是满格。 

但是之前一直挺好的来着，看来不是网的问题，是我们家墙的问题。

噢，不对，墙也没动过，应该是路由器的问题。 

果断把之前一个淘汰的，只有两根天线的路由器拿出来换上，问题搞定。 

在诸多问题定位中，网络问题的定位一直都比较麻烦。 

所以之前测试的面试题，都是必问「电脑突然上不了网了，可能是什么原因？」，借机温习了一下。

每日感悟-99：我住的小区，是一个开放式小区，但是在疫情紧张的时候，也会做封闭式的管理。 

因为不是常态，所以偶尔会被别人问到小区的管理情况。 

我记得我经常回答，现在管理的不严，随便进出。 

有一天早上，我走的晚了，才发现，原来不是我之前看到的那样，每个没有出入证的人进来，都需要登记。 

得出之前的结论，是因为我总是早出晚归，完美的避过了查岗期。 

这件事会给我的教训是，眼见不一定为实，经验主义害死人，这个情况在我们测试的时候很常见，比如一个功能曾经测试通过了，二次回归的时候就会有「 肯定不会有问题」的潜意识在作祟。

每日感悟-98：一个 IM 的群聊，我修改了群聊的名称，再搜索的时候，用新的名称竟然搜不到，用老的名称才能搜到，过了几天再试，才可以用用新改的名称。 

猜测是搜索的时候，为了提高效率，先走的本地缓存，但是修改群名称的时候只更新了数据库信息，没有同步更新缓存信息。 

建议修改的方案，搜索可以继续用缓存，但是我修改群名称，在更新数据库的同时也应该同步更新缓存。

每日感悟-97：跟车距离真是考验人，跟的近了容易追尾，跟的远了被后面催还被前面加塞，其实我们选取测试颗粒度的时候也是这样，颗粒度太粗，可能覆盖率不够，颗粒度太细，可能会过度测试，这时候就是发挥我们测试经验的时候了。

每日感悟-96：因为戴口罩，所以出气时眼镜会上雾，因为眼镜上雾看不清路，所以我刻意调整呼吸，因为调整呼吸导致鼻子不通气，因为鼻子不通气导致说话不顺畅，因为说话不顺畅又去调整呼吸，最后都有点呼吸紊乱了。 

其实很多难以发现的 bug 都是这种连锁反应，如果只是盯着问题本身看，就是一个小问题，但是深究下，可能会有新发现。

每日感悟-95：作为一个强度依赖导航的人来说，语音导航的描述真是让人捉急，明明我沿大路直行就可以了，非要告诉我说前面有个三岔路，请走最左侧岔路，吓的我看了半天哪有岔路，原来就是主路分出去的两条岔路，就是说用次要信息影响了我对主要信息的判断，增加我信息处理的负担，这种用户体验的测试，不过关。

每日感悟-94：我们家燃气卡，好久之前冲了 300 块，然后一直用到现在，去银行充钱，回复说钱还有剩下的，不用冲，搞的我们用着也不放心，但是也没人找上门。 

前几天宝妈主动给燃气公司打电话问啥情况，燃气公司给查了一下最后一次缴费时候的气数，和目前的气数，说是表可能坏了，自己去银行补一下钱就行，然后让我们自己联系师傅免费换表。 

钱是补上了，然后给师傅打电话换表，结果师傅说表没坏，按他说的步骤，一同操作下来，再去插卡，好了。

问他是为啥，说是电池完全没电的时候，我们刚好还在用气，然后就会不读卡了，哪怕换了电池也不行。 原来是一个混合条件的边界值测试用例没有覆盖到。 

但是想想，这个场景在实际生活中应该还是蛮常见的。给我的启示是，实际场景的测试，比单纯的逻辑覆盖要重要的多。

每日感悟-93：很多人对不确定性存在恐惧，所以尽可能的让质量确定，然后就会人为的给质量加一些标准，随着标准的增多，最后的结果就是会出现过度测试。

每日感悟-92：质量是一个相对词，而不是一个绝对词，并不是没有 bug 就是好的质量，也不是有 bug 就是质量不好，关键是在不应该有 bug 的地方别出 bug。

每日感悟-91：不考虑可维护性的测试方案都是短期思维，长期思维的话，可维护性是首先要考虑的事情，相对来说，也是一个特别大的难点。

每日感悟-90：测试是一个过程，不是目的，不管是左移还是右移，都是在把风险分摊到过程的不同阶段，如果我们能够承担风险带来的后果，完全可以不测试。

每日感悟-89：中台的目标是技术通用化和模块化，业务的诉求是质效优先，所以录属中台的业务测试既要保证业务目标的绝对达成，也要保证部门目标的绝对达成。

每日感悟-88：工具化和模版化的好处是快，但是坏处是让用的人不再去想这背后到底都做了啥，最后就变成了对工具的依赖，一旦工具出现一点问题，流程可能就会被卡住，所以在一些关键流程的地方，慢也是快。

每日感悟-87：对于需求合理性，任何的建议都好像是在质疑，虽然也确实需要质疑，但是谁都不爱自己被否定，所以需求合理性要基于事实来讨论，而不是基于观点。

每日感悟-86：测试对问题的全面性的考虑有利有弊，利的一面就是真的在特殊情况发生时有心理准备，甚至有提前的应对方案，弊的一面就是如果没有发生特殊情况的话，前期的考虑就是多余了，所以这是个选择，选择的依据是我们能否承担考虑不足所造成的后果。

每日感悟-85：「先入为主」是人类的天性，因为我们大部分的认知都是基于自己的实践得来的，所以当出现一个问题时，首先是从自己的实践经验中搜寻解决方法，作为测试，我们要对抗这种天性，我们要从用户角度设计用例场景，自己只是用户群体中的一个点。

每日感悟-84：全流程质量改进，一定是全流程各角色都参与的，而让全流程角色配合才是最难的，毕竟在没有收获前，增加的是他们的工作量。

每日感悟-83：测试右移确实一定程度上节省了测试过程的用时，但也要考虑右移后发现问题的处理时间，如果处理成本较高，还会带来连锁反应，就要斟酌右移的适用性，还是那句话，效果说明一切，而不是技术说明一切。

每日感悟-82：ToC 和 ToB 的主要区别我理解是服务的群体不同，C 端服务的是用户，B 端服务的是客户，用户是爷爷，客户是爸爸，爷爷说话你可以不听，爸爸说话你敢不听？

每日感悟-81：大家都知道测试左移对质量提升有帮助，但是移不好就是甩锅给产品和研发了，所以它不仅仅是测试的事，是全流程的一个配合。

每日感悟-80：发现 Bug，并不等于指出 bug 的现象，而是指出 bug 产生的原因，有些是直接原因，有些是间接原因，对原因分析的程度就等于我们对逻辑理解的深度。

每日感悟-79：测试工程师和心理咨询师的目的都一样，我们不是为了发现 Bug，只是为了解决 Bug 后，让产品更完美。

每日感悟-78：测试工程师和心理咨询师都是有强大内心的人，每天都在应对各种带着负面情绪的 Bug，却依然热爱自己的工作。

每日感悟-77：对于内部系统而言，前端实现的模版化也是提效，而且是极大的提效，每个系统都做个完全不同的酷炫前端就是耍流氓。

每日感悟-76：提效工具的易用性是相对而言的，如果只是内部使用，而且投入较大的话，实用性永远是第一优先级。

每日感悟-75：所谓提效，不一定是系统化，大部分时候工具化就可以搞定了，判断的标准就是投入最小化，产出最大化。

每日感悟-74：每个人都会习惯的从自己的经验出发去做判断，比如没测过客户端软件的同学，我给出一个用例题，绝大部分会把 web 测试的用例点也写上了。

每日感悟-73：如果微信公众号只是推送了一个链接，在电脑客户端版本上将显示如下的 bug，这是 bug 么？如果是，为啥至今都没有修复？如果不是，这也太奇怪了吧？当然，虽然长得难看，功能是正常的。

每日感悟-72：报了一个 bug，最怕前端说是客户端的问题，客户端说是服务端的问题，服务端说是前端的问题，关键是谁也不愿实际调试看一下，所以提醒小伙伴要有准确区分 bug 范围的能力。

每日感悟-71：海底捞悄悄的更新了自己的水果夹，之前的夹子总是打滑，新夹子手感特别好，这么小的细节竟然都能被发现并改进，还有什么理由做不好？

每日感悟-70：数据是个好东西，但是不同人角度不同，同样是低迷的数据，有人看到了机会，有人看到了失望，一定要获取尽量多维的数据，做出全面的判断。

每日感悟-69：精通业务并且能在业务测试中发现可以提效的需求，进行快速迭代实现后立马有明显的提效效果，我理解这才是测开，脱离了测试本身的，都只是开发。

每日感悟-68：自行车更新迭代了这么多年，都没有迭代出自行车把托，现在共享单车有了，而且全有了，但是我去看售卖的单车还是没有，这就是截然不同的产品思维。

每日感悟-67：视频号我刷出来很多 bug，但是并没有影响大家的正常使用，充分说明问题处理的优先级，比问题本身更重要。

每日感悟-66：质量度量不应该是一个固定的公式，而是随着当前项目的需要，动态调整的，也就是说，度量是为了质量服务的。

每日感悟-65：循环必须设定跳出条件，测试要求原则之一。

每日感悟-64：对测试来说，通过技术解决问题并不是最关键的，通过资源解决问题才是关键，我们需要协调上下游，以及全流程的资源来达成质量目标。

每日感悟-63：只是发现问题，不给解决问题建议的测试，不是好测试。

每日感悟-62：如果只看到实现的表示层，你得用 100 条用例覆盖，也还可以没测到关键点，如果看到逻辑层，可能 10 条用例就足够覆盖了，比如自定义搜索框框的条件组合。

每日感悟-61：环境搭建和环境兼容性，特别是客户端还涉及不同软件的兼容，是测试中特别耗时间的一块，还不得不做，所以对底层实现原理的挖掘和了解是必须的，可以让我们兼容测试的针对性更强。

每日感悟-60：只看现象不看错误码的 bug，全是耍流氓，只提示错误，但是不告诉错误码或原因的提示框，也是耍流氓。

每日感悟-59：对于快速迭代的版本，注定没法一次完美，所以每次在上次的基础上有改进，只好不差就是标准。

每日感悟-58：为了赶工期，开发迭代提测，测试迭代跟进，多么美好的规划，灾难就在发生在第二次迭代提测时，因为改了一个问题，引发了更多的问题，所以说，合适的流程工具要用在合适的人身上才行。

每日感悟-57：开发人员提测质量的好坏，对口的测试可以清楚的感知到，但是其他人不知道，所以我们需要有合理的质量度量标准来量化这个事情，大家都知道这个理，也明白这个需要，但就是对具体标准没法达成一致。

每日感悟-56：测试人员每天面对那么多问题，如果经验不做沉淀和积累，只会越来越忙，所以我们要学会框架性思维，就是碰到问题时，使用框架性思维来考虑解决一类的问题，这样让功力与日俱增。

每日感悟-55：分析问题时需要很强的逻辑思维能力，哪怕使用排除法，也是逻辑思维的体现，我最常用的例子就是杨辉三角编程实现。

每日感悟-54：作为每天都和问题打交道的测试，解决问题的能力非常重要，它又包括发现问题、分析问题和解决问题，目前基础测试人员都停留在发现问题的阶段，根据对问题分析的深入度可以界定中高段位，明确定位出问题的根本原因并提出合理解决方案的，无疑都是高手了。

每日感悟-53：不设定前提的情况下，妄下结论的，都是耍流氓，比如为什么这样的 bug 都可以漏出？其实产品根本没有提这个实现的需求。

每日感悟-52：如果一个产品的研发需求比较多，说明处于维护期，如果一个产品的产品需求比较多，说明产品经理脑洞比较大，如果一个产品的用户需求比较多，说明产品正蒸蒸日上。

每日感悟-51：一个优秀的测试，对于知识的广度和深度都有要求，同时，还需要具备整合这些知识的能力，特别是知识的可迁移能力，最大程度的避免知识的一次性效果。

每日感悟-50：测试作为流程的下游，有时候很难保证做的都是正确的事，但是我们可以坚持努力把事情做正确。

每日感悟-49：一个靠谱的上游，和一个不靠谱的上游，差距十万八千里，这就是为啥要大力推进测试左移的原因吧，可越是靠谱的越是支持流程正规化，不靠谱的一个劲反对说被限制了自由。

每日感悟-48：做测试，一个很重要的能力就是质量风险评估，这个可以当作核心竞争力来进行培养，评估的依据全部都是基于项目实践经验而来，不可复制，也不可能短时间内速成。

每日感悟-47：作为测试，产品出现任何质量问题，我们都跑不了，哪怕发版之前负责人拍着胸脯说「出事算我的」，那我们的责任也是「为啥不拦着」。

每日感悟-46：需求评审时，首先要确认的是「原始需求」，原始需求不是产品经理加工过的需求，而且产品需求要解决的具体的用户问题，只有针对这个第一手问题进行评审，才能保证需求的正确性和合理性。

每日感悟-45：不同岗位技术要求不同，但是大家的目的是相同的，所以通识要求也应该是相同的，比如测试、开发、产品的目标都应该是业务优先，并且在不同的时候分别优先关注稳定性、合理性和正确性，然后才是不同角色使用不同的技术角度通过分工来共同达成目的。

每日感悟-44：测试用例执行并不是简单的点点点，哪些用例可以一起跑，哪些用例可以优先跑，哪些用例工具跑，哪些用例可以深入跑，哪些用例可以扩展跑，这些都是能力，是那张无形的手。

每日感悟-43：对于大部分人追求高精尖的技术，我觉得方向是对的，但是从实用性来看，我们更应该花时间先把手头的事情搞好，比如在花时间搞 web 自动化之前，至少要知道出问题了先按 F12 看 Console 输出信息的吧。

每日感悟-42：错把平台能力当作自己的能力很可怕，比如公司有现成的自动化用例管理系统，自己可以按模版添加用例，结果就变成自己熟练使用自动化，一定要区分哪些是我的能力，哪些是我们的能力。

每日感悟-41：金字塔模型在哪都适用，很多人都愿意讨论塔尖上的东西，比如 AI 自动化、去测试化等等，其实大部分人缺少是金字塔底向上跃升的东西，比如测试用例深入度、全面性等等。

每日感悟-40：没出问题时，一起都是效率优先，一旦出了问题，复盘的结果就是流程更重要，如此反复。

每日感悟-39：自动化流程的好处是效率，坏处就是太快了，可能会加速问题的发生，毕竟人在操作过程中，是可以由主观能动性来发现一些意外情况，所以从质量角度来说，流程并不是越快越好，该快的应该快，不该快的就需要悠着点。

每日感悟-38：每个业务都希望测试能多快好省，而且永无止境，所以我们要用数据来证明，我们真的一直都很快好省，这就是数据度量的价值吧。

每日感悟-37：在基础质量得到保障后，易用性已经超过了之前要求的性能。

每日感悟-36：随着生活节奏的变快，变化的常态化，大家对质量的期望是有明显下降的，不管是实物的质量，还是软件质量，所以我们要在这中间找一个合适的平衡，保证投入产出比的合理性。

每日感悟-35：测试实际上只是质量保证兜底的方案，而做不到 100% 的质量保证，只有基础质量得到了保证，测试才可以做更深入的测试，如果一直徘徊在基本功能保证边缘，也就很难深入了。

每日感悟-34：不敢做决定的测试不是好测试，作为用户的代言人，除了要保证产品功能正确性，还有保证产品易用性、可靠性、效率、维护性、可移植性，简称软件质量模型。

每日感悟-33：测试除了要保证产品的功能正确性之外，一定要关注功能的合理性，我宁愿一个功能不生效，也不希望一个功能让用户感觉反人性。

每日感悟-32：测试作为技术岗，既要考虑到技术的实用性，也有关注到技术的趋势，实用性技术稳扎稳打，趋势性的技术紧跟不舍，并可以趁机突破。

每日感悟-31：如果把任何质量的问题，都归结为测试，一方面测试承担不起，另一方面也是承受不起，产品质量应该是整个团队的事。

每日感悟-30：测试执行时的优先级设置比测试用例的覆盖率更重要。

每日感悟-29：一个靠谱的产品，加上靠谱的开发，基本上可以保证 80% 的质量，只有这样才能体现测试的价值，反之亦然。

每日感悟-28：流程上的质量保证，比测试环节的质量保证要重要也高效的多，但是实施难度也大的多。

每日感悟-27：测试经验的积累有点像内功修为，一朝一夕是看不到进展的，需要日积月累，而且需要配合一定的招式才能得到很好的体现。

每日感悟-26：功能测试要怎么入门？先把测试流程和测试用例设计方法理论搞通透了，然后把登录框的用例自己写完整了，基本就入门了。

每日感悟-25：先胜而后求战，这句话其实比较适合测试，如果把所有质量的责任都放到测试身上，最后就是看运气，只有全局考虑流程、上下游等各个环节，全流程进行质量保证，才能做到真正的保证质量。

每日感悟-24：对于业务测试，如果搞不清楚测试范围，再多的测试也不能保证效果，所以我们会在测试范围的确认上花费很多时间，越是黑盒花的时间就越多，但目前还没有特别有效的解决方案。

每日感悟-23：如果不是头部，不必强求去追求那些先进的技术，比如 AI 测试，每个技术都需要一个普适性的过程，这个过程是需要资源投入的，我们可以关注，然后在恰当的时机去引入，最重要的还是要能带来实际生产力的提升。

每日感悟-22：所有的工具都是人（手）的延伸，这也是「工具」这个词的含义，所以不要为了工具而去做工具，而是先想想有没有现成的/开源的工具可以用，只有在不得已的情况下才去创造工具。

每日感悟-21：项目流程的意义在于可以帮我们查缺补漏，保证基础质量，如果一个事情完全由一个人独立完成，可以不设置这些繁琐的规定，但是如果是多人协作，一定想着去建立和优化流程，而不是忽略流程的重要性。

每日感悟-20：那些可能存在风险的地方，最后一定会发生风险，所以在发现风险时，要么修复它，要么规避它，千万不要无视它。

每日感悟-19：测试过程中，最忌讳的就是经验主义，特别是同一个功能点反复回归测试时，最容易出现我上次看过了，这地方没问题，然后就会掉以轻心的情况，我也一直在和这个毛病抗争中。

每日感悟-18：业务逻辑对测试来说是必须熟悉了解的，同时业务逻辑对测试来说也是最不重要的，我们要把更多的精力放到对底层实现逻辑的了解上，只有了解了原理，才能一通百通，才能把握质量的关键。

每日感悟-17：作为最简单最实用使用最广泛的测试用例设计方法，等价类和边界值，相对于知道它名字的人，能够熟练使用的人真是少数，其实越是简单的招数，它蕴含的力量越强大。

每日感悟-16：测试理论的知识，其实内容并不多，但就是这么固定的内容，有很多人有选择无视，有些经验确实大部分人实践中都可以悟到，但是相对于通过实践趟坑来总结已有的理论来说，想办法把理论应用于实践效率更高。

每日感悟-15：需求讨论时，问题考虑的越复杂，后续出问题的概率越小，因为前面都考虑过了，问题考虑的越简单，后续出问题的概率越大，因为会发现坑越来越多，填坑都停不下来。

每日感悟-14：每发现一个问题，就是一次进步的机会，每一次问题修复，就是一次用例完善的经验，不断反思复盘，才能在发现的问题越多的情况下，避免更多问题的发生。

每日感悟-13：相对于测试保证质量，一个靠谱的开发其实更重要，所以我们测试还有一个角色就是辅助开发做好代码管理，让他们只专心写代码就好了。

每日感悟-12：作为测试，我们要尽可能的模拟用户的真实环境进行验证，可是大部分用户的环境都是复杂且不可控的，所以我们一方面要想办法让我们的产品做好环境兼容，特别是异常处理，然后才是保证功能的正常可用。

每日感悟-11：测试岗位存在了这么久，甚至有地方都在讨论「去测试化」了，但是很多业务人员对于「测试」的理解，仍然很是局限，这让大家的沟通又增加了一层障碍。

每日感悟-10：几年前的面试，大部分人的职业规划都是性能测试，现在风气变了，全部变成了自动化测试，或者叫测开，但其实很多人对测开岗位的理解并不完全一致，你理解的测开是干嘛的？

每日感悟-09：第一次剥虾，竟然把肚子下的黑线当作虾线了，宝妈纠正后又把之前的虾重新弄了一次，这就是需求不明确前白忙活的测试活动，作为下游的测试，一定要想尽一切办法让上游的信息通畅明朗。

每日感悟-08：测试作为流程的下游，能做的事情其实很有限，所以现在到处推行测试左移、测试右移、全流程测试以及 DevOPS，但是万变不离其宗，业务方的诉求永远只有两点：质量和效率。

每日感悟-07：测试的目标应该是在有限的时间内发现尽量多的问题，特别是严重问题，尽可能的降低线上风险，我们无法保证也做不到百分百无风险。

每日感悟-06：测试经验的积累过程中，总结很重要，举个例子，每次发现问题，都应该想想「后期如何避免同类问题的发生？」，每次得出答案，每次就有新的收获。

每日感悟-05：测试策略比测试执行重要的多，所以用例写的全之外，还需要用例优先级划分的好，但是很多人往往都花了很多时间在测试的全面性上，而忽略了针对性，结果的体现就是测试效率不高。

每日感悟-04：如果一直局限在自己的角色上，根本做不到深入测试，既然是深入，就必须有全面的了解，知道逻辑细节和关联关系，知道如何去深入。

每日感悟-03：测试目的永远比测试技术重要，不要为了追求完美而让我们忘记测试目的，比如在只有十人范围内使用的产品，就不要花费一周的时间去详细测试了。

每日感悟-02：老大给读了一篇课文《我要的是葫芦》，讲的是一个人种了葫芦，葫芦叶子长虫了，邻居好心提醒，他却说「叶子长虫了？我要的是葫芦」，作为测试人员，我们尤其要避免这种关系混淆问题，比如提测质量差，我们不能不管不顾，只想着我们要的是「测试质量」。

每日感悟-01：做测试，最重要的还是思路，在那忙测点点点别以为就是探索性测试了，探索也是有法可依的。

请原谅我这篇文章偷懒了，不过我相信这 100 天的总结里，总有几条对你有帮助，拿走，不用谢。

借此机会，再次感谢停更期间一直催我更新的朋友，我就不贴图了。

当然也感谢那些给我说，想催更但是又不好意思催的朋友，谢谢你的记挂和坚守。

这个日更经验总结的事，我还会坚持下去，如果希望第一时间获取这个信息的话，请关注公众号后，后台回复「15666」加我私人微信。

再次感谢大家的支持，别走开，一大波干货即将袭来。

 

- END -

标签：感悟,小事,每日,问题,质量,测试,100,流程,这件
来源： https://blog.51cto.com/sylan215/2919630