我快坚持不住了

最新推荐文章于 2024-04-26 16:08:14 发布

isylan215

最新推荐文章于 2024-04-26 16:08:14 发布

阅读量362

点赞数 1

文章标签：人工智能 java python 编程语言软件测试

本文链接：https://blog.csdn.net/sylan15/article/details/120897979

版权

后台回复「15666」，加我私人微信

阅读本文大概需要 5 分钟。

你好，我是亦无。

围观我朋友圈的朋友都知道，我刚刚更新完第 250 条每日感悟。

噢，不对，其实是 500 条，因为我每次更新的是 2 条。

一条是关于软件测试的，一条是关于职场的。

话说昨天在一个群里和别人聊起这个事，其中一个同学竟然表示了不屑，原来他从 2018 年就开始每天记录自己的状态了，顺手还晒了下截图。

具体记录的内容不知道是啥，截图里能看到的有日期、天气、心情、睡眠记录和手账等信息，确实够细，确实够坚持，厉害了。

但是我认为记录什么内容，比坚持记录的时长更重要。

如果只是流水账，或者说每天的事项记录，我也可以呀。

我从 2019 年开始写日记，也是坚持到现在（噢，偶有断更），每天能写 1000 字呢（流水账，谁不会呀）。

可是我公众号依然断更断更断更了呀（揭短的事要说三遍，我是不是对自己太狠了）。

因为写原创公众号文章，真是太耗神了，我时间又不够（万金油一样的借口，噢，不对，万金油一样的理由），又不想降低质量（不知道你觉得质量如何，反正我是尽力了），只能减少数量了。

作为替代，我才坚持写每日感悟的。

这个东西吧，其实每次就几句话的事，但是搁不住每天都要写呀，稍微摸下鱼，脑袋就一片空白（知道了吧，我每天写，所以我从来不摸鱼）。

刚开始写的时候，感觉文思泉涌，干货取之不尽用之不竭，思绪如滔滔江水连绵不绝。

现在 250 天过去了，我快坚持不住了，感觉整个身体被掏空，噢，不对，是脑袋被掏空。

可是我看过的书，学（买）过的课都告诉我，现在是关键时刻，坚持就是胜利。

可我坚持的目的是什么呢？

我仔细认真的想了想，很简单，就是为了在达到一定数量时，可以理所当然的逼自己发公众号文章了。

为什么要坚持发文章呢？

很简单，就是想和，在亿万人中，关注了我的你聊聊，既然有缘，就续个长缘。

哎呦，有点煽情了，长话短说，直接上干货吧。

每日感悟-250：测试策略和测试方法这些测试基础的探讨越来越少，质量和效能的讨论越来越多，这是好事不？

每日感悟-249：之前我们说的测试，都是被动接收测试任务，做好质量的守门员；
现在说的质量保证，是要主动设计去保证产品质量，不仅仅要把好最后一道关，把把握每个过程的质量，做好质量的教练员。

每日感悟-248：微信在设计上的细节把控。

每日感悟-247：星球发帖，如果是「审核中」状态，帖子显示会错位，下拉刷新也不行，审核完就好了。
这应该算特殊场景的测试覆盖，可能因为「审核中」状态时间比较短，所以被忽略。

每日感悟-246：PC 端微信朋友圈的文字会错乱，这个问题隐藏的有点深，但是必现。

每日感悟-245：两个质量事故的启发：
1、人们对于隐私的重视程度已经逐渐提高（点评是一个，美团定位也算），对于隐私的测试要求，也要提高标准了；
2、涉及钱财和数据的，一定要尽可能多的覆盖各种异常，不仅仅是技术手段的保障，设计上也要考虑用户的心理预期；

每日感悟-244：首次登陆时，数据库字段为空，没有特殊处理（问题不大，但是处理下体验就更好了）。

每日感悟-243：这算是 bug 不，一会算与我关联的数据，一会不算？（我猜可能是数据里面有划分吧，但是作为用户，我的第一感觉就是 bug）

每日感悟-242：有道云笔记 IOS 版，登陆有效期过期后，打开 APP 时，自动登出了。
等我重新登陆进去后，才弹框提示我登陆信息过期了，需要重新登陆。
这就是用户场景的测试用例覆盖。

每日感悟-241：微信长按图片，会弹出菜单，如果图片上有文字，菜单会多出一个「提取文字」的选项，而且是放在菜单的底部。
如果响应比较快，没啥影响哈（感受不到会多出一个选项），但如果手机反应慢，经常在点击菜单的时候发现菜单点了，然后就点错了（比如保存图片点成了编辑）。
这就是用户场景的测试用例覆盖。

每日感悟-240：Boss 招聘出了桌面版，下载体验了一下。才安装完成，就提示错误了。
看起来是和使用环境有关系。
Windows 环境测试时，一定要注意区分内置 administrator 和普通管理员的区别，也要注意 UAC 开和关对程序的影响。
这就是用户场景的测试用例覆盖。

每日感悟-239：安全软件弹出一个病毒提醒框，你以为我会点阻止，或者点允许，其实我点了右上角的叉叉，因为我判断不了应该允许还是阻止。
这就是用户场景的测试用例覆盖。

每日感悟-238：中秋时，一个同事回家了，但是他家人不知道，然后把一箱水果给寄到公司了，然后就便宜我们这些坚持上班的人了。
这是典型的信息（需求）不同步，我们项目过程中，经常出现这种情况。
比如产品有需求变更，他以为已经同步给项目组同学了，可能并没有；
比如开发额外增加了一个修改点，他以为已经告知测试同学了，可能并没有；
比如测试同学发现了一个潜在质量风险，他以为项目组都意识到这个问题了，可能并没有。
所以重要的事情要反复确认，至少说三遍。

每日感悟-237：一个同学反馈我写的系统有 bug，是个页面展示的问题，页面上的一个图在她那，右侧没有展示全。
我打开她提供的 URL 看了下，没问题，显示的很正常。
正常的反应，我应该是告诉她我这没问题，是不是她自己操作的问题？
但是我又观察了一下，看起来是底部有滚动条，但是她没看到，所以直接告诉她拖动底部滚动条试试。
果然就是这个原因。
判断缺陷是否有效，也是质量保证人员必须具备的技能。

每日感悟-236：很多项目的潜藏风险，就像人行道上活动的地砖。
晴天时，踩上去会轻微的晃一下，没有质的影响，会被忽略。
雨天时，踩上去还是轻微的晃一下，踩上去的那只脚没事，另一只脚则会被溅上一脚水，甚至殃及旁人。

每日感悟-235：所谓的大项目，就是需要进行全面思考，避免只见局部不见整体。
比如时间都花在功能细节的测试上，忽略了整体连通测试，或者稳定性和兼容性的测试。

每日感悟-234：论坛关注的消息数太多，有 300 多条，需要翻 12 页，可我一次看不完，翻到 10 页就中断了。
下次登陆又新增了 50 条，这次翻 2 页就看完了，但一直显示未读 50 条（上次没看完的），可是我找不到这 50 条在哪了（需要翻页，又不知道需要翻多少页）。

每日感悟-233：以业务为主导的测试，业务目标是主要目标；
以质量为主导的测试，质量目标是主要目标；
业务和质量目标都达成是最好的，有冲突时就需要有取舍，悲剧的是，大部分时候都需要做这个取舍。

每日感悟-232：大家都知道为用户创造价值，是产品的核心竞争力，可是用户需要什么样的价值，很多人都理解不一致，最终意见也不一致，结果也就不一样。
这就是明白了很多道理，却仍然做不好产品。

每日感悟-231：测试右移固然是在一定程度上提效，但是一定要注意及时迭代优化，不然时间长了就成了狼来了的故事，再也没人相信了。

每日感悟-230：产品审别人需求时，吐槽文档不够详细，自己提需求时，文档是什么？
开发看别人代码时，吐槽别人不写注释，自己写代码时，没必要写注释。
测试看别人用例时，吐槽没有详细步骤，自己写用例时，没时间写步骤。

每日感悟-229：看个动画片都能发现个 Bug：
1、爱奇艺看片；
2、视频中截多张图图；
3、使用自带的拼图功能，选择「只保留台词部分」的选项；
4、查看拼图结果；
预期是可以成功拼图，结果是拼图的字幕都没了，我又多试了几下，如果背景图一样，字幕不同的时候，可以拼图成功，如果背景图和字幕一起变的话，拼图后的字幕就没了。

每日感悟-228：质量保证不仅仅要关注产品的技术质量，要关注的还有产品的诉求，质量再好的产品，如果没有用户，也体现不了高质量的价值，反而会增加成本。

每日感悟-227：质量保证是一个系统工程，不是说所有问题都需要全解决，而是在资源有限、成本有限的情况下，尽可能多的解决那些关键的、严重的问题。

每日感悟-226：道路设计的太平整，不利于排水；
道路设计的太斜，水流太集中，下水口排不急；
而且很多路的验收，并没有考虑雨天的情况，一下雨，各种情况都能看到；
这可以算是场景用例覆盖不到位。

每日感悟-225：目前设计用例的思路，大体有两种。
一个是从需求出发，对需求进行不同程度的拆分。
一个是从质量模型出发，从不同技术角度对实现进行覆盖。
随着现在用户体验的关注度提升，是时候增加一个新的角度了，就是「使用场景」。
通过对常见用户场景的覆盖，更好的从用户角度出发，发现那些场景化的问题（而不是掉到技术实现的坑里）。

每日感悟-224：有道云笔记有个特别好的功能，就是记录文档查看的位置，每次重新打开时，会自动跳到之前滚动条的位置。
按理说这是个很人性化的设计。
但是我管理的文档很多，偶尔打开一个之前的文档，就会跳到一个我根本记不住的位置，既然记不住，就是不需要的位置，这时候，这个优化的功能就成了冗余。关键是，还没地方去关闭这个「好意」。
时刻要警惕，我之蜜糖，很可能是彼之砒霜。
建议：1、加设置入口；2、只记录最近 5 条有操作记录的文档的位置信息。

每日感悟-223：做质量保证时间久了，就有点职业病。
比如沟通时，说完一句话，我立马就知道别人可能对这句话产生的不同理解，于是主动就进行了全方位的补充说明。
好处是沟通覆盖的角度很全，不足是重点不突出，太追求全面性了。
特别是这个过程会伴随着我自己的快速思考，经常会出现自言自语的情况。
嗯，任何事情都有两面性。

每日感悟-222：质量是个挺主观的词，如果没有衡量标准，质量就无从谈起。
所以谈质量，先设置好前提条件，比如三步以内的点击操作，不会出现明显的软件异常。

每日感悟-221：抛开业务本身谈技术，都是耍流氓，技术是为了支撑业务，测试技术也是一样。
不需要完美的质量，需要的是满足业务诉求的质量。

每日感悟-220：我记得之前的便利贴，都是贴纸顶部一小部分是粘胶，今天用的便利贴，竟然是反着的，只有顶部没有粘胶，其他位置都是粘胶，再也不用担心粘不牢了。
这也说明，那么我们认为本该如此的东西，也都有可以改进的空间。

每日感悟-219：今天玩星球，发现个很基础的 bug，一个常规操作流程中，弹框提示我选择了「取消」，然后 APP 就卡住了，没反应了，很明显就是业务逻辑没有处理这个场景。
操作步骤：
1、星球主题中打开另一个星球的链接；
2、新页面点击「查看更多内容」；
3、对话框点击「取消」；
预期是返回正常浏览，实际页面卡住完全无法操作了。

每日感悟-218：对产品的熟悉度，是测试的优势，他可以让我们更快的理解需求，从而推动工作的更快开展。
同时，它也可能成为劣势，因为熟悉会让我产生定势思维，从而发现不了问题，也就没法进行突破（创新）。

每日感悟-217：禁止需求变更，是不可能的，越是自己做过产品设计，越是能明白这一点。
那么作为测试，我们要做的，则是尽可能提前的完成需求变更，尽可能有效的识别有效变更。

每日感悟-216：用户只知道「可用」和「不可用」，没有「暂不可用」，也没有「自定义设置」，更没有「辅助功能」。

每日感悟-215：某个同学说他找 bug 的能力特别厉害，每天都能发现 5 个 bug，目前这个项目中已经发现了 100 多个 bug。
我算了下，这个项目已经 3 月了，每天 5 个就差不多有 300 个，根本不止 100 个呀。
看，我也发现个 bug（数据测试不能单纯看数据，要关注数据合理性）。

每日感悟-214：上次聊到食堂桌子的问题（199条），我只关注到了眼前短期的座位问题。
后来听「得到」里面提到，通过加长餐桌，增加团队成员一起吃饭、互相了解的机会，可以极大的增强团队沟通的效果，有利于团队发展。
从这个角度说，还是利大于弊的哈，果然是出发点不同，结论不同。
所以一个产品的价值主张尤为重要。

每日感悟-213：现在这站点的质量太差了，明明登陆了，结果提示用户信息错误。
我到用户中心去退出登陆，然后开始循环的退出然后自动登陆，然后又退出这么一直循环。
首页打开时，console 里面直接报 10 个 js 错误。

每日感悟-212：朝阳新换的这个公交牌，颜值确实是高了，但是从可扩展性来说，真是太差了。
比如要是新增或减少一趟车的话，目前的牌子都不能用了，因为每个牌子的框框已经固定了。

每日感悟-211：百度网盘这句柄数要逆天了。

每日感悟-210：更新了极客时间上面的昵称，部落里面展示正确了，但是点赞时，还是用的旧的昵称，下拉刷新后，可以更新为新的昵称了，但是继续点赞，仍然用的旧昵称。
猜测是前端做了用户信息的缓存，所以前端操作时就继续使用的缓存，刷新时会调用后台接口获取点赞数据，因为记录的用户 id，所以用户昵称可以更新过来，但是继续操作仍然走得缓存逻辑了。
其实合理的做法应该是，修改用户信息后，前端应该同时更新本地缓存信息。