距离上次推送,已然过去了 4 个月,让大家久等了。

虽然 4 个月没有推送,但是这个号的关注者一直在增加,不管是新朋友还是老朋友,感谢你的坚守。

写文章,特别是写原创干货,还是要接地气的干货,耗时又耗力。

为了保证推送质量,我一直比较谨慎,宁愿少一点,也不愿为了推送而推送,我相信你也是为了看干货而关注的我,所以我们的目标是一致的,感谢你的理解和支持。

上次我推送的 100 条每日感悟,没想到特别受待见,目前阅读量已经 1000+,点赞 32,在看 20,赞赏 2,再次感谢你的支持。

被认可,是我坚持下去的唯一动力。

这次我带来的是上次的后续,请尽情享用。

每日感悟-200:碰到个 Bug,一个 App 选择从相册添加照片时,一次可以添加 9 张,但如果性能不好,点击同一张照片,会累计计数,如图。

每日感悟-199:我们食堂都是4人长条桌,有部分是单独摆放,另一部分是并一起拼成 8 人桌。
我吃饭算比较晚的,一般是 2 个人一起,但是经常找不到位置,也不是没有位置,而是找不到合适位置。
因为大部分的 8 人桌,都坐了 2 个人,有的是顶头坐 2 人,我们插中间好像很奇怪,有的是顶头一个,另一个坐中间,这样就更不好插入了,反正就是人不多,座位很尴尬,应该是可以改进的。
我的建议是,所有桌子都可以弄成单桌,就是面对面可以坐两人那种,然后根据不同的区域,可以适当的拼桌,但是更多的留单桌,这样可发挥的空间就大了哈,本来疫情期间也鼓励保持距离,一举两得。

每日感悟-198:测试思维比测试技术本身要重要的多,就类似一个二分法,一个穷举法。

每日感悟-197:测试不需要保证百分百没问题,但是百分百要知道,如果出问题,会造成什么样的影响。

每日感悟-196:产品、开发、测试就是一个稳定的铁三角,抛开任何一方来谈责任,都是在甩锅。
产品需求考虑的合理还完善,开发会实现错误么?测试会质疑需求质量么?
开发提测质量好了,测试会把时间都花费在写 bug 上么?产品会再三确认要按照需求来实现么?
测试对业务理解透彻了,开发还会吐槽我们总问低级问题么?产品还会质疑我们搞不清优先级么?

每日感悟-195:抛开 bug 质量提 bug 数都是耍流氓。

每日感悟-194:软件测试经验图谱中我把知识性内容说成「硬技能」,有人告诉我这不对,知识不属于技能。今天有个同学问题「业务逻辑」该如何解释。
作为粘合剂的测试人,用词要慎重。

每日感悟-193:六一儿童节有个 bug,就是孩子有活动或者放假,可是家长没放假,却需要陪同。

每日感悟-192:前端文本显示自测时,我最常有的特殊字符集合:~!@#$%^&*()_+{}|:"<>?/.,';\[]=-

每日感悟-191:SQL 语句格式化的时候,有两种方式,其中一种是 format,这时候我们测试数据的构造一定要覆盖带路径反斜杠的情况。

每日感悟-190:是不是可以这么说,不看 js 实现的前端测试,都是在盲测。

每日感悟-189:看似简单的翻页测试,却极容易藏 bug,比如每页显示 15 条数据,当前第 2 页,然后我删除了一条记录,继续翻到第 3 页,那么第 3 页展示的是 31-45 的记录呢,还是 32-46 的记录呢?

每日感悟-188:对于 Web 测试,发现一个问题时,能明确定位出是前端的问题,还是服务端的问题,已经比仅仅描述问题的现象要厉害的多了。

每日感悟-187:如果业务用的类 SQL 数据库,在构造测试数据时,一定记得构造一条带有「&」符号的字符串作为查询条件。

每日感悟-186:这个测试用例也不错。

每日感悟-185:周末偷懒 2 天都木有更新,每次我都成功的使用自我安慰的技能骗过了自己,所以我是相信心理作用是可以对物理世界造成影响的,也相信除了人性最深处的底色外,我们根本就不懂任何人。
所以利他,就是最大的利己,因为利己是本色。

每日感悟-184:最近一直在 boss 上收简历,发现如果我连续几天没时间上去沟通,就一个简历推动都木有,一旦活跃起来,就有简历过来了,这也是用了游戏化思维的及时反馈策略呀,同时也说明,如果发现了一个问题,先从自己身上找找原因。

每日感悟-183:之前用不惯阿里云盘的照片同步,总感觉和之前的习惯不一致,很别扭,但是之前的方式用起来又确实不方便,现在多次尝试后,终于算是有点习惯了,这就是教育用户的效果么。

每日感悟-182:极客时间支付成功后,如果选择不分享,进入的是个空白页面,返回后,进入的是个不可支付的支付页面。很显然这个后退的场景考虑不足。

每日感悟-181:数据测试时,大家考虑过整数,浮点数,正数,负数等等,有人考虑过这种数不?00.1
这是一个神奇的 bug,或者说本来不应该出问题的 bug,但是出问题了,有时间我写个详细的复盘。

每日感悟-180:之前周一上班时,偶尔会因为疏忽,忘带工卡了。
后来我想到了一个办法,然后就一次也没忘记过了。
办法就是把工卡固定放到裤子的右边兜里面,而且只放工卡。
我理解这种叫做场景记忆法,任何时候我一摸裤兜,就会有一个明确的心理预期,自动出现关联记忆。
很早前我在记一些数字时,经常用这个方法,现在在总结一些问题场景后,只要出现类似的逻辑实现,我就能快速回忆起上次补充完善的用例,感觉特别好。

每日感悟-179:微信读书的书评提交后,是不能给自己点赞的,但是点开书评详情后,就可以给自己点赞了。

每日感悟-178:和很多高手一直致力于对高精尖技术的追求不同,我一直想构建一套软件测试通用的基础知识体系,只有基础牢靠了,才能盖高楼,只有图纸清晰了,楼才不会盖歪。

每日感悟-177:我一直想构建一个软件测试从入门到精通的体系,所以才有了软件测试经验图谱,但是现在看起来图谱更适合从熟悉到熟练这个过程,从入门到熟悉,以及从熟练到精通这两部分,还需要补充完善。

每日感悟-176:虽然作为质量保证人员,发现问题是件很正常的事情,但是大部分人在发现问题的第一时间是怀疑自己是不是操作的有问题,当然,新手除外。

每日感悟-175:那些对 bug 敏感的同学,在没有发现 bug 时就会很沮丧,其实一个高质量的 bug 带来的成就感要胜过众多显式 bug 的成就感。
当然,每个人对「高质量」的解读会存在差异。

每日感悟-174:测试的目标是为了证明软件不可用,但是执行测试时,我们却总是希望别出现问题。

每日感悟-173:做正确的事,优先于正确的做事。
质量保证的要求就是正确的事,具体的测试活动则是正确的做事。

每日感悟-172:上游质量好,对质量的最大挑战是效率和深入度;
上游质量差,对质量的最大挑战是流程规范和信息同步;

每日感悟-171:特斯拉最近的质量风波再次提醒我们,涉及到生命、财产安全的产品,质量保证是头等大事,不能容忍半点质量风险。
随着后面科技的发展,对计算机软件质量的依赖越来越高,质量的挑战也会越来越大。

每日感悟-170:测试是个不确定的东西,不确定性就是它的特性,所以我们要你努力追求质量的可控性,就是最低的质量要求必须要得到保障。

每日感悟-169:MySQL 查询语句不区分大小写,MongoDB 查询语句区分大小写。

每日感悟-168:对于文本编辑器来说,支持的行数多少,和字数多少,是两个完全不同的测试点。

每日感悟-167:有人理解用例覆盖全,就是把所有的组合条件都列全,这是限于「点」的层面。
我们至少要先保证「线」的层面全了,之后再去补充颗粒度更小的点。

每日感悟-166:我学自行车的时候,还是带横梁的,但是没有特别的摔过,就学会了,想起来学的应该还算简单,但是我知道有很多人不会骑自行车。
学过自行车,电动车基本上骑上就会了,但是我才知道有人会自行车,但是不会电动车。
这就是我认为和事实上的区别,也是我们理解的用户角度和真实用户角度的区别。

每日感悟-165:测试人员一直对自己的发展感到迷茫,是因为我们没有一个清晰的成长地图,没有地图就会出现两个问题。一方面会造成大家不知道自己要去的方向,所以存在深深的不安全感。
另一方面大家都不知道自己当前的位置,从而有一种无力感,不知道朝哪个方向努力。

每日感悟-164:北京一卡通的登陆缓存,有个过期时间,但是一般都不会在意,也没地方设置,可是碰到上公交之后发现登陆过期,就很尴尬了,还需要重新登陆,关键时刻,手机号一键登录还经常失败,哎呀,愁死了。

每日感悟-163:驾校学开车时,有个老师告诉我们说,右脚一般都是放在油门上,因为大部分时间都是正常行驶,另一个老师则告诉说,右脚一般都是放在刹车上,因为危险无处不在,而且谨防误踩。
开车时,我一直都在纠结这个问题,然后知道他们都错了,开车的时候右脚一直都在动,并没有固定的必须放在哪的规则。
现实就是这样,总是和理想有出入,产品设计尤其要避免这种误区,总以为自己是从用户角度出发时,要考虑自己是不是真的用户。

每日感悟-162:HTML 字符转义是前端最容易犯的问题,看起来很简单,技术实现也不难,但就是很多地方都会出。

每日感悟-161:数据是效果的最好体现,哪怕仅仅使用拙劣的 Bug 数来体现,也是一种体现方式,当然,我们还是要追求更多角度,更准确的体现。

每日感悟-160:测试对于业务的价值,可以分为两部分,一部分是某一个具体项目的质量保证,一部分是基于项目经验做出的对于同类项目更好的质量保证的体系建设。

每日感悟-159:苹果的背部双击截图准确率太差了,经常乱截屏。

每日感悟-158:昨天去儿研所看急诊,排队一个小时才看上,排上就是开个手指血的单子,等结果出来后再去开药,排队一小时,看病十分钟。
刚好看到另一个更惨的,带了大便样本,但是排队时间太长,超过样本检测要求的时限了,需要重新采集,但是孩子也不是说便就便的。
我一直在想这个流程为啥不优化,然后听到护士说,只有医生才能开检查单。
突然明白了,这是效率和安全性的权衡,两害相较取其轻。
所有的问题,最后都是选择的问题。

每日感悟-157:我们一直说需求沟通要清晰合理,其实测试内部本身的沟通也是需要清晰合理,比如不同人对于测开角色的理解会有不同,比如我们说原始需求时,有些人就听不懂等等,任何专有名词,请保证理解的一致性后,再继续。

每日感悟-156:测试的目的不是发现问题,而是解决问题。
所以不要止步于发现问题这个表象,而是要考虑如何解决根本的质量问题。

每日感悟-155:测试目的指导着我们所有的测试活动。
比如驱动测试就要求万无一失,那么测试考虑的全面性优先级最高,当然耗时也比较久。
比如 MVP 产品就要快速试错,那么主要功能实现是第一优先级,其次是不要出现明显的异常即可。
比如稳定性大于一切的时候,那么平台兼容性和产品自身稳定性的优先级最高,功能实现的优先级反而降低了。
当然,之所以叫优先级,就是说在后面的迭代中,我们还是要把欠的债给补上的。

每日感悟-154:去年的 Flag 是把测试相关的书都看一遍,现在是该买的都买了,只等看了。
今天是 423 读书日,是时候把 Flag 捡起来了。
不过一直没忘记薅微信读书的羊毛。

每日感悟-153:测试左移到需求阶段,理论上对质量保证是最高效的。
但是由于需求阶段需要沟通讨论的细节非常多,相应的占用时间也非常多,如果这时候测试参与其中,但是没有发挥到应有的质量风险预警的效果,那么就是适得其反。
左移不应只是形式上的左移,要是具备左移能力的人在左移后发挥左移预期的效用,才是左移。

每日感悟-152:测试保障和质量保障虽然只是名字的差异,但却是不同的概念,代表不同的意义,目前的话,大部分人都还停留在测试这个层面的理解,需要想办法贯彻对质量保障的理解。

每日感悟-151:今天看几个大佬又聊到测试角色定位的问题,总结一句话还是,目标很明确,方法也都有,就是走起来步步维艰,朱老师总结到,难,就是挑战,才有意义。
罗曼·罗兰也说过,「世界上只有一种真正的英雄主义,就是认清了生活的真相后还依然热爱它」

每日感悟-150:被一个输入法的设置折腾的够呛,全部隐藏后找不到还原入口了,重装都没用,我也是醉了,不过看起来不是输入法的问题,而是系统没有提供对应的还原入口,倒是 Win10 系统自带输入法的默认设置是最符合「简单有效」设计原则的。

每日感悟-149:今天弄了下小米手环的设置,「抬腕亮屏」竟然默认是关闭的,不管是手表(一直亮屏),还是手机(抬起亮屏),这都是默认选项,所以这算不算 Bug?

每日感悟-148:给别人修电脑,发现他装了 2 块硬盘,其中的 SSD 竟然不是系统盘,这算不算 Bug?

每日感悟-147:星球昨天出现一个很有意思的 Bug,就是保存分享卡片到本地时报错了。
刚开始碰到这个情况,我还是蛮诧异的,图片已经生成,为啥还会保存失败呢?
所以我去清了一些照片,看看是不是空间导致的,结果并不是。
我又试了一下直接分享照片到微信,同时保存照片到本地,结果成功了。
那就更奇怪了,这 2 个保存图片到本地的操作难道不是同一个接口在 2 个地方的应用么?
因为不知道具体实现逻辑,就报给吴老板了,确认就是 Bug,好吧。
不过还有个小建议,提示的错误信息明显是给开发看的,建议换成用户角度的错误信息。

每日感悟-146:很多应用程序都有交互弹框,之前很多交互框是模态的,但是用户体验不好,现在很多就都做成非模态的了,但也造成一个问题,比如有些弹框忘记屏蔽右上角的最小化按钮了,如果用户把这个框最小化,就找不到打开入口了。
按理说这也算 bug,不是程序实现 bug,是设计 bug。

每日感悟-145:很多测试都觉得尴尬,主要是觉得测试没有技术含量,同时自己的技术又达不到开发的水平,所以只能委曲求全,终日惶惶。

每日感悟-144:得到作为这么专业的音频应用,有非常严格的品控,但是依然没有解决学习计划连续播放时,不同栏目音频声量大小不一致的问题。

每日感悟-143:阿里云盘使用完全不同的照片上传的策略(当然也是最先进的),我以为就我使用不习惯,一看网上很多人都不习惯,一个新习惯的培养,哪怕是先进的,也是需要时间的。

每日感悟-142:本想给个好评,结果碰到个 Bug。

每日感悟-141:十几年前,一个要好的朋友给我说,他自己剪不到自己的脚指甲。
我当时听了觉得特别不可思议,因为我很轻易的看到自己的脚指甲,并且可以把臭脚掰到自己眼前。
这么多年过去了,我一直都记得这个事,特别是最近一次剪指甲,突然发现我也很难看见自己的脚指甲后,才终于明白他说的那种感受。
所谓的换位思考和感同身受,真的不是说起来那么简单,很多时候,也不是我们理解的那么轻松。

每日感悟-140:我住的是一个老小区,没有规划停车位,一些住户为了不在自己很晚下班后找不到车位,就会找合适的地方装地锁。
但是小区又不让装,所以就出现装了拆,拆了装的情况,到现在就没剩下多少了。
我经常路过的地方就有一个地锁,我早上路过时,地锁已经锁上了,晚上回家时,一直是同一辆车停那,我就想这个地锁还挺坚挺。
有天不注意,我绊了下,才发现这地锁是坏的,根本没锁上,只是竖着装个样子。
果然是高手,成功利用了人们的惯性思维,肯定没人会来确认下地锁是不是好的。

每日感悟-139:微软在 Win10 上对它的搜索、浏览器、输入法、OneDrive、WindowsDefender都做了很强的绑定,都是默认设置,并且默认启动,但是介入 Windows 的影响力,大家对这个都习以为常,并且作为是对我使用体验的改进了。

每日感悟-138:路过机场时,看到机场黄金广告牌上的宣传语「华与华,超级符号就是超级创意」,我是在得到里面听过「华与华」,知道它牛逼的名声,但是对于后面的「超级符号就是超级创意」确实没听过,所以感觉一懵,回来查了下,原来是华与华出过的一本书,也是他们最响亮的名号。
但是反过来一想,这个广告的目的到底是什么,如果只是给已经熟知华与华的人来说,肯定是哇哦,华与华真牛,广告都做到这来了,如果是不熟悉的人来说,完全看不懂,看不懂「华与华」是啥,也看不懂啥叫「超级符号就是超级创意」,从这个角度来说,我觉得这个宣传又是很失败的。

每日感悟-137:人脸识别手机解锁,我是戴着眼镜录的,然后不戴眼睛的话,就发现它识别不了,这算是 Bug 呢,还是设计如此呢?

每日感悟-136:半路上收到短信说我欠费停机了,没有 4G,也没法给自己充值,一时半会找不到可用 Wifi,之前那种可以充值的电话亭当然也木有,好尴尬。
之前其实收到过短信提醒了,但是现在的短信全都被忽视了,产品经理么,这个场景要考虑不?

每日感悟-135:这是我见过通用性和合理性最好的设计。
但是完全没法向下兼容,因为顶层设计就不同了。
可见早期介入测试的重要性,这里的早期测试,并不一定是测试同学来做,但是必须要做的。

每日感悟-134:你能看出来这个「其它方式登录」是可以点击的么?

每日感悟-133:公司门口的天桥修缮,把一边的楼梯拆了,竖了两个桥墩子。
一天吃完饭,和同事聊天,我就问他们能不能看出来后面桥面的走势。
其实我自己也没看出来,因为桥墩的高矮比率比较奇怪。
晚上路过的时候我又瞅了下,发现了第一个桥面的布置,终于看明白是咋回事了。
想想这就和我们测试的系统一样,每个桥墩和桥面都是单元测试的一部分,桥墩和桥面开始组合,就需要集成测试,完整拼接后,就要进行系统测试了,不同时候的关注点也不同。

每日感悟-132:前天去复查眼睛,谭教授的助理给我登记信息,看我纠正视力 1.0,就问我近视多少度。
我说 1000 多点吧。
她感慨到,那挺不错呀,能纠正的这么好。
好吧,我接受这个夸奖。
这个事可以看出来,一个产品底子好不好不重要,最终呈现的效果好最重要。
并且,如果底子差,那么呈现同样的效果,反而还可以加分。

每日感悟-131:昨天拿了 4 个药,都是滴眼睛的。
可能是一下滴的太多,间隔太短,过了一会药水竟然流到嘴里了。
如果说滴眼睛是一个 UI 操作,那么眼和鼻腔相连,鼻腔和口腔则是内部实现逻辑,如果只关注表面的操作,就意识不到内部的关联,更不会考虑到这个关联可能产生的额外测试点。

每日感悟-130:今天去医院又没有带纸,去医院厕所看了看也没纸,但是门口有个取纸机。
本来以为收费的呢,扫码后发现是免费的,或者准确的说是地推吧,因为需要关注公众号才出纸。
这么说这个思路挺好的,但就是宣传上做的不够好,至少我没有一眼看出来是免费取纸,所以无形中减少了很多人尝试的动机。

每日感悟-129:昨天给闺女放电视看,让她自己选节目,她来指挥,我来操作。
她说,向上。
我立马按向上键,同时画面是向下滚动的。
她着急的说,向上向上。
我说,这不就是向上么?
她解释说,我说的是向上翻,我要看下面的内容。
好吧,我已经被教育成了 Windows 思维,而闺女还是 Mac 思维。
对于产品设计来说,这才是最大的困难,我们到底是要教育所有用户,还是要迎合部分用户。

每日感悟-128:周末去挖了一大盆地菜,晚上包饺子。
同样是地菜,对不喜欢的人来说,就是草,对喜欢吃的人来说,就是宝。
同样的产品实现也是一样,对目标客户就是好,非目标客户,一无是处。

每日感悟-127:我用阿里云盘页面版一次性传了 7137 个文件,然后页面就卡死在那了,一动不动,啥也点不了。
我看了下接口请求的情况,是 file create 接口pendding 了。

每日感悟-126:一直不理解为啥北京很多路口的红绿灯都没有倒计时,感觉有倒计时我可以更好的规划启动和闯关时机。
今天查了下,原来是因为和红绿灯的自适应系统没法完美兼容,同时也是为了避免抢灯闯关。
这就是产品设计的两面性,有利有弊,就看弊大于利,还是利大于弊。

每日感悟-125:阿里云盘试用体验:
1、新建文件夹后建议直接进入文件夹,大部分的操作都是新建文件夹->传照片到这个文件夹;
2、默认排序建议使用创建时间/修改时间,按名称排序有个问题,就是文件/文件夹比较多的时候,突然找不到了;
3、不管是什么排序,新建的文件夹都是放到最后,我要在这个文件夹传文件,体验就很不好;
4、上传的照片名称都是原始文件名,我更希望是使用日期格式的文件名;
5、2个文件移动就会显示有保险箱文件夹,1个文件移动就没有;
6、如果全屏查看图片时,建议不要显示 查看原图 按钮了;

每日感悟-124:为什么代码对测试很重要?因为没写过代码,根本想不到某些测试点。
比如一个很简单的 web 页面,展示数据库的信息,不清楚实现的,就是简单的点点点看看有没有展示问题,但是知道实现逻辑的人,就知道有个分页查询的逻辑,就是每次展示时,只查询当前页面的数据,加快展示速度,当然开发也可以直接全表查询,那么在数据很少的时候,看不出来区别,数据量大了区别就来了。
这是一个和业务逻辑没关系的实现技术和测试点,懂不懂还是很明显的。

每日感悟-123:本来面部识别解锁是比指纹更方便的,但是因为突发的疫情,戴上口罩后,面部识别基本就废了,然后每次打开手机都得输入密码,反而没有指纹方便了。
如果从产品设计的角度考虑,这就是我们预置了一个理想的前提条件,出现意外的情况本来很小,但是一旦出现了,直接打回原形。

每日感悟-122:昨天带闺女去医院复查,等抽血结果的时候突然肚子疼,跑到卫生间一看,没纸,急急慌慌跑门口买纸再跑回医院,幸亏没耽搁正事。
蹲着的时候我就又起了上次也是去医院,付钱的时候突然发现他们只收现金,可是我好久都没装过现金了,找了一圈人才换到 10 块钱,10 块钱难死个人。
这就是我们测试用例中的异常用例,有些我们很肯定不会出现的场景(厕所没纸?只收现金?指针为空?),其实总是有例外,所以一定要做异常处理,一定要做异常处理,一定要做异常处理。

每日感悟-121:有道云笔记支持语音笔记,而且是实时转换为文字的,我试了下还蛮好用,但是感觉没有测试过语速特别快,并且持续时间特别长的场景,我试用的时候卡了好久都没翻译出来。

每日感悟-120:今天陪闺女去上培训班,姐姐去上课,妹妹和我在外边玩,过了一会发现妹妹眼睛肿了,赶紧去找清水冲洗了一下,过一会好转了,才去看看到底什么引起的。
我们做项目经常会碰到这种突发情况,第一反应应该是尽快的先解决问题,然后去复盘问题,找到问题的根本解决办法。

每日感悟-119:一件事情是因为它的意义而存在的,比如梵高的画也是画,只是因为给赋予了梵高的意义,就变的不一样了,同样的,同样的反馈监控,崩溃监控,打点采集,赋予测试右移的意义,也不一样了。

每日感悟-118:测试的价值,业务方最清楚,如果抛开业务方的角度去证明测试的价值,还是件蛮困难的事情。

每日感悟-117:当所有人都接受一个好的体验作为现行标准时,才是真正好的体验,不然再好的体验也会变的格格不入,最后就是劣币驱逐良币。

每日感悟-116:招商银行查看完整卡号后,复制的卡号是带空格的,可是很多地方输入带空格的卡号时都是识别错误,我记得招行自己 APP 的某些地方也是不识别,这就是用户体验,有时候我们以为的「改进」,其实也可能适得其反。

每日感悟-115:昨天闺女生病了,打车去儿研所,我记得上次去的时候东门在装修,所以直接跑到北门了,下车了才发现北门关了,东门重新开了。
看完病,继续打车,上车点就设置成东门了,结果搞好了要出门才发现,东门不让出,要走西门,晕,幸好西门出,最后也是绕到了东门马路上。
那些我们以为很熟悉的经验,如果没有在最近验证过,就有小心掉到经验主义的陷阱了。

每日感悟-114:今天玩手机游戏的时候,突然来了个电话,接了电话后游戏没有暂停,只是声没了,挂了电话,游戏继续,但是声没有回来,看来我又碰到特殊场景的用例没有覆盖到的情况了,所有带声的,一定记得跑这个用例。

每日感悟-113:很多地方一直提倡用户视角去看待用户体验的问题,所以很多人就真的把自己当用户去评价一个产品,然后就发出「何不食肉糜」的感慨。

每日感悟-112:一直说的测试左移,大家都知道是质量前置,但是落地的时候,会被人为的限定为自动化前置,其实需求评审时提出问题也是左移,而且是提效最明显的左移,只是没法量化。

每日感悟-111:从马路对面到我们公司,要经过一个天桥,上桥前要走过一条辅路,之前经过辅路时,我一定会小心翼翼的盯着车行的方向看看有没有车,一直这样安全的度过了很多天。
有一天我仍然按照习惯,一边看着车行的方向是不是有车,一边赶紧往前走,突然一股妖风从我耳边呼啸而过,原来是有人骑车逆行,吓死宝宝了。
虽然我们都知道不能逆行,但实际上逆行的人很多,就像我们知道某些异常用例基本走不到,可是实际环境中肯定会被触发到一样现实。

每日感悟-110:我们公司对面有个天桥,天桥走到对面下去右拐是辅路,但是栏杆上面有挡板,如果不注意,看不到辅路上面的车。
之前没有关注时,下了楼梯就右拐,这条正常用例执行的一直很稳定。
直到有一次,刚下去就有一辆车窜出来,差一点被撞到,之后就学乖了,每次都要伸头看看有没有车,这是实际场景中肯定会出现的异常用例。
不要认为测试没问题就是真的没问题,可能只是没发现问题,测试的目的是证伪。

每日感悟-109:线上回归环境的作用不是为了发现问题,而是为了避免问题出现在回归环境,所以每次在回归环境发现的问题都需要想办法在回归前规避。

每日感悟-108:涉及数据库的项目测试,一定记得要测试数据库为空的场景。

每日感悟-107:微信读书的免费读书卡,设计的很有意思。
看着每天减少的免费读书时间,贪便宜的我,总会花时间去做各种活动,增加自己的免费时长。
其实他这个免费卡,还有一个机制,就是当完全用完的时候,再分享一次,就可以送 10 天时间,所以看起来基本上不用担心免费时间会用完(经历过2次,但是没反复验证确认)。
这个设计中有意思的地方是,不管有没有兜底方案,那个每天减少的免费时间,总是给人失落感,然后就会诱发大家去做各种活动。

每日感悟-106:周末开车去奥森,本来想去之前停过的一个地面停车场,但是好久没去过,有点记不清,结果在记得的位置转了三圈都没有找到,最后不得已停在一个地下停车场,整整耗时 30 分钟。
这个事本身没啥问题,但是我能感受到经验主义对自己的影响,特别是经历过一个好的体验的经验后,就会念念不忘,甚至对这个事情的念想,超过这个事情本身的目的。
比如去奥森本来是陪孩子玩,结果在已经有地方停车的情况下,还是在车上浪费了半小时,顾此失彼。
同样的,作为测试,我们对技术的追求,一定要记得目的是什么,是提效和更全面的保证产品质量,而不是技术本身(当然,如果能兼顾就完美了)。

每日感悟-105:前几天风大,从公司南出口出来就感觉到一股凉意,不过还好,在承受范围内。
拉上大衣的拉链就赶紧往西走,刚走出大楼的墙角,一股妖风袭来,差点把头发都吹没了。
其实这股风一直都在,只不过在大楼门口时,都被大楼给挡住了。
走出来没有大楼遮挡时,才感受到风真正的威力。
其实我们测试过程中,经常碰到类似的场景。
比如我们会测试进楼、出楼、还在楼门口反复溜达了,但就是没有走出大楼的范围,这都是常规用例。
再多走一步,跨过大楼的范围(边界值),就是异常用例,也是真实的用户场景。
所以场景覆盖时,请多走一步,不要只停留在自己的想象中。

每日感悟-104:对等沟通的前提是要有对等的基础知识储备,但是开发和测试是技能树的两个分支,所以才会出现经典的开发和测试的沟通问题(bug不认同=理解不一致=描述角度不同),才会出现测试必须懂代码的要求,说到底是为了打通沟通的基础。
从这个角度看,对测试来说,写代码并不是主要的,懂才是,特别是要懂那些专业黑话,比如注入啦、公共函数啦、空指针啦、初始化啦等等;
对开发来说,如果明白这一点,知道在沟通时把黑话翻译成白话,能够瞬间提升测试同学的好感度。

每日感悟-103:今天准备吃麻辣烫,我说给我来份不带辣椒的。
回复说,没有了,就剩下目前的 4 份带辣椒的了。
本来想将就一下算了,大厨又善意的说他帮我把辣椒处理下。
等他把辣椒都铲掉后,又加了一句,我再加点酱,给辣味中和下。
晕,还有这操作呢。
其实我们测试的产品,就像这碗麻辣烫。
需求提出时,原材料还没有混合在一起,但是比例基本固定了。
开发提测时,已经是加工后的了,也按比例混合在一起,如果是多人开发的,有可能已经搅拌多次了。
需求变更就是铲掉碗里的辣椒。
再加点芝麻酱就是打补丁。
测试同学快吃吧,要注意原始需求的比例,需求变更前的比例,需求变更后的比例都是否符合预期,最终成品的口味是否符合预期。

每日感悟-102:脱离了业务的测试开发,会抱怨自己开发的东西没人用,深入业务的测试开发,会抱怨自己没时间写代码,这是一个长期的未调和的矛盾。
如果一定盯着问题看,这个基本就无解了。
反过来想一想,当前的业务是否适合测试开发?我们到底期望测试开发带来什么样的改变?达成什么样的目标?也许会有新的收获。

每日感悟-101:分层测试就是对测试目标进行归类,大类就是表示层、逻辑层、数据层,再细分可以有业务接口、通用接口,不同类别可以用不同的测试策略和测试方法,想清楚再动手,事半功倍。

说实话,相对上次的 100 条,我自我感觉本次质量是有下降的。

之前我总是感觉有源源不断的内容可以总结,可一旦开始总结,还是会有被掏空的感觉。

当然,这也告诉我不能松懈,要持续不断的输入,才能保证持续不断的输出,进而形成输入输出的正循环。

这个正循环,我相信是和你的目标是一致的,很高兴可以和你一起去挑战这个目标。

最后,

如果本次的 100 条中,哪怕有 1 条,你觉得有收获,请留言告诉我,这是我继续产出的动力。

如果你不想每次都等这么久才看到这个总结,可以后台回复「15666」加我微信(坑位有限,先到先得),围观我的朋友圈。

以上,谢谢你认真的看完了。

- END -

点个“在看”,传播一份价值

越测越开心

欢迎"留言"

你的观点,碰撞我的,就是知识的火花

这件小事,我坚持了 200 天相关推荐

  1. 这件小事,我坚持了 300 天

    后台回复「15666」,加我私人微信 阅读本文大概需要 17 分钟. 大家好,我是亦无. 前几天我做了个梦. 梦见我最新推送的一篇文章,阅读量竟然达到了 1500+,在梦中,我的下巴都惊掉了,还反复确 ...

  2. 过年啦,说三件小事!

    2020这魔幻的一年,即将结束,忙忙碌碌一整年,终于可以放假休闲了.今年因为疫情原因,很多同学都选择在原地过年. 往年一到大年二十九,三十,熙熙攘攘的城里会空很多,公交地铁都跟包场似的,空荡荡的.今年 ...

  3. 情侣必做的100件小事,提升幸福感,快收藏

    情侣必做的100件小事,极大提升幸福感: 1.一起散步2.一起看电影3.一起过生日4.一起旅行5.一起看日出6.一起看日落7.一起爬山8.一起看海9.一起游泳10.一起跨年11.一起拍照12.一起滑冰 ...

  4. K8s 从懵圈到熟练 – 镜像拉取这件小事

    作者 | 声东 阿里云售后技术专家 导读:相比 K8s 集群的其他功能,私有镜像的自动拉取,看起来可能是比较简单的.而镜像拉取失败,大多数情况下都和权限有关.所以,在处理相关问题的时候,我们往往会轻松 ...

  5. 手机蓝牙连不上jimu机器人_蓝牙连接出现问题到解决问题,一件小事,感慨实时逆向思维的重要...

    有一个古老的哲学难题:"如果森林里的一棵树倒了,但没人听见,那么它发出声音了吗?如何回答这个问题和看待它的角度有关.然而,如果观察者和被观察者的关系是必不可少的基本关系,那么就不可能有树倒下 ...

  6. 如何拉取k8s镜像_K8s 从懵圈到熟练 – 镜像拉取这件小事

    导读:相比 K8s 集群的其他功能,私有镜像的自动拉取,看起来可能是比较简单的.而镜像拉取失败,大多数情况下都和权限有关.所以,在处理相关问题的时候,我们往往会轻松的说:这问题很简单,肯定是权限问题. ...

  7. 哈佛大学推荐:让自己变幸福的20件小事(值得收藏)

    幸福是什么? 关于这个问题,或许每个人心中的答案都不同.我们的生活经历不同,对于幸福的诠释,也就各有不同. 但无论哪一种幸福的复述,都是源自一个人内心最温情的认知,和最丰裕的感受. 幸福不是脸上的虚荣 ...

  8. 鲁迅先生的《一件小事》

    一件小事⑴ 我从乡下跑到京城里,一转眼已经六年了.其间耳闻目睹的所谓国家大事,算起来也很不少:但在我心里,都不留什么痕迹,倘要我寻出这些事的影响来说,便只是增长了我的坏脾气,--老实说,便是教我一天比 ...

  9. 《一件小事.呐喊》--鲁迅 词语解释

    <一件小事> -出自鲁迅小说集<呐喊>. 伊:彼,他,她. 装腔作势:故意装出一种腔调,做出一种姿势,用来比喻故意做作. 威压:表现出使人敬畏的气魄.威:表现出来使人敬畏的气魄 ...

  10. 跟领导关系再好,也别做3件小事,嘴欠手贱,煮熟鸭子会飞

    职场人最喜欢传播的小道消息,就是人事变动的风吹草动.开大会,往往研究小事:开小会,才是研究大事.热门人选,结局未必是他.沉得住气的,往往杀出黑马.有城府的领导要提拔你,运作成熟后才会私下暗示你.天下没 ...

最新文章

  1. weblogic项目java.sql.SQLException: ORA-01861: 文字与格式字符串不匹配 at oracle.jdbc.....错误解决
  2. Google要推输入法 是战略布局还是战术需要?
  3. 数据结构和算法学习一,开篇
  4. vue 部门tree样式_vue+Element实现tree树形数据展示
  5. [SCOI 2010]传送带
  6. Jira Concept- Issues
  7. [python opencv 计算机视觉零基础到实战] 十一找到图片中指定内容
  8. Jmeter笔记(Ⅱ)使用Jmeter实现轻量级的接口自动化测试
  9. 程序员面试-并发大数据分布式
  10. java 易错题_java错题集(1-3)
  11. python小白逆袭大佬_Python小白逆袭大神心得
  12. 拉丁正方形 java_LeetCode 221. Maximal Square 最大正方形(C++/Java)
  13. Intellij IDEA打开Java项目并启动
  14. 电线电缆行业MES解决方案
  15. 家具从设计到生产一步完成 有屋拆单 SU草图拆单 全屋定制拆单 衣柜橱柜拆单 办公家具设计拆单 展柜定制拆单 宠物家具定制设计拆单软件 有屋软件
  16. 国密SM2椭圆曲线密码算法
  17. TeX系列: dot2tex 和 dot2texi 配置步骤
  18. 海思方案技术研发交流群/海思方案供需交流群
  19. 人口统计、红利、康波
  20. 概率统计·参数估计【矩估计、极大似然估计、无偏性、有效性、相合性】

热门文章

  1. Python代码制作“恐龙跳一跳“小游戏
  2. WinDynamicDesktop下载慢解决方法
  3. Element 表格序号问题
  4. 如何打开电脑并打开浏览器
  5. Falcon(一)——数据集管理和数据处理平台
  6. 求一个向量变换为另一个向量的矩阵_机器学习数学-矩阵
  7. 【随笔】Linux drop_caches
  8. 编制职工档案管理程序C语言,职工档案管理系统
  9. 云盘行业的“冰与火”
  10. 阿里一面:SQL 优化有哪些技巧?