2022
-
亦起测-365
找个不合理的借口做推广，反而显得适得其反。
-
亦起测-364
确定哪些是真实存在的用户场景，是产品设计好坏的一个分水岭。
-
亦起测-363
有些人会绞尽脑汁的去想办法创新，其实很多创新都是在手头上的小事上。
-
亦起测-362
创新是觉察到用户自己都没觉察到的习惯，而不是无脑精简。
-
亦起测-361
任何东西都不一定完美，所谓的好，只是大多数情况下更好一点。
-
亦起测-360
改进不在大小，而在于实用。
-
亦起测-359
同理，一旦用户心智模式转变过来了，那就是绝对的忠实用户了，因为习惯是一种条件反射。
-
亦起测-358
作为质量保障人员来说，我们的主要目标是提高产品质量，但是到一定程度后，我们要做的其实也是提高容错性，在发生异常时尽可能的降低影响，而不是一味的追求没有任何的质量风险。
-
亦起测-357
田忌赛马的策略，在任何时候都适用。
-
亦起测-356
实践和真理的相互转化，是可以持续一生的课题。
-
亦起测-355
做事的目的一旦明确，剩下的就是方式的选择，如果把太多的精力放在方式上，可能会丢掉目标，如果优先关注目标，方式的选择就灵活的多。
-
亦起测-354
我以为我是用户，和我是真实用户之间，永远都有一道鸿沟，只有尽力缩小，无法填平。
-
亦起测-353
我之前说过测试的分层，最下面一层就是数据层，它到表示层还隔着逻辑层，哪些数据要展示，怎么展示，也是一个学问。
-
亦起测-352
愿意花精力去做想做的事情，效率和效果都会更好。
-
亦起测-351
市场不确定时，赢得确定性是第一优先级，赢得确定性之后，稳定性变成第一优先级。
-
亦起测-350
越是开始或者结束，越是要保持好平常心。
-
亦起测-349
我们的很多经验都是基于自身实践的总结，但是实践的范围有局限，因此得出的结论也有局限。
2021
-
亦起测-348
做事的方式，可以分两种，1 种是大力出奇迹，反正能做成，别管怎么做，1 种是对症下药，事半功倍。
-
亦起测-347
借助工具是人类的本能，并且可以让我们把事情做的更好。
-
亦起测-346
并不存在所谓的敌对关系，有的都是利益关系。
-
亦起测-345
提前准备，可以减少不确定性，增加确定性。
-
亦起测-344
取舍是一生的必修课，我们几乎每天都在做选择，选择就是取舍，如何能把握好平衡，也是一种能力。
-
亦起测-343
知道自己知道什么和不知道什么，就是对自己的认知和定位，越清楚自己的认知和定位，就越是可以更好的掌控自己的人生（做更多正确的选择）。
-
亦起测-342
隐私也是一种安全性需求，夹在中间明显没有在两边安全，虽然都是无意识的选择，但也说明安全性是潜意识的需求。
-
亦起测-341
每件事都有因果关系，有些是长期关系，比如饿了要吃饭，有些是临时关系，比如下班可以坐地铁，可以骑车，可以打车，搞清楚这个关系，可以对一件事的反应有更明确的对应关系，事半功倍。
-
亦起测-340
把时间用在让自己有收获的事情上，特别是有长期收益的事情上。
-
亦起测-339
2、大趋势虽然很确定，但那只是更高概率发生的事，在未发生前，还是会有各种各样的局部变量，可以随势而动。
-
亦起测-338
精力管理是比时间管理更关键的事。
-
亦起测-337
2、我是带空格 ~·！@#￥%…&*（）—+=-)(^$!~`{}[]【】、|\;':"：“；‘《》？<>/? 和中文的特殊字符集合
-
亦起测-336
很多既定的事情，稍微变通一下，可以起到意想不到的效果。
-
亦起测-335
比如 python 库安装，大部分都是 install 库名称，实在不行就去下载 whl 文件，很少想到还会有一些修改库可以直接用。
-
亦起测-334
那么在我们产品设计的时候，一旦我们搞错了谁是真实用户，设计结果可能就会谬之千里。
-
亦起测-333
越直白越易懂。
-
亦起测-332
点进去之后才发现，原来前面一个数竟然是已预约的人数，这体验太反人类了。
-
亦起测-331
看来我又经验主义了，这也算是一条特殊的测试用例吧，永远都不要低估用户使用产品的创意。
-
亦起测-330
蚂蚁森林种树时，之前看不到哪些自己种了，我每次都是去自己已种植的页面去看一眼，现在发现改版了，刚好解决了我说的这个痛点，看来这是一个接地气的产品经理。
-
亦起测-329
流调信息填报小程序做了更新，在流行病学史的众多单选题前面，增加了一个「全部为否」的一键填充按钮，真是太贴心了，为这个洞察点赞。
-
亦起测-328
改进：照 Google 抄一下就行了，Google 在 Hover 时连最后面的日期都不显示了，严格保证了体验的一致性，绝不给用户惊喜。
-
亦起测-327
实际结果：点赞失败，选不中点赞按钮，只能选中回复的内容，如果刷新或切换下页面后，才能成功点赞。
-
亦起测-326
真是应了那句话，你永远不知道用户会用什么方式来使用你的产品。
-
亦起测-325
接口的并发测试显然没做好。
-
亦起测-324
可测试性，也是软件质量的一个考核指标。
-
亦起测-323
浏览器的后退按钮，总是能发现惊喜。
-
亦起测-322
这是典型的举一反三，以此类推的例子，以后提交类似 Bug 时，都可以加一句「其他位置请一并处理」。
-
亦起测-321
这就是用户原始需求和产品需求的区别。
-
亦起测-320
测试技术能力的提升，最终都是要做业务支持中体现，而业务支持，也是为了更好的进行测试技术能力的提升，这应该是个相辅相成的过程，绝不是时间都被业务占有了，没有时间去提升。
-
亦起测-319
页面滚动异常
-
亦起测-318
Win10 的启动恢复做的并不好（完全还原重启前的进程状态），但是更新的频度竟然这么高，有这个自信，也是很厉害的了。
-
亦起测-317
传说中的用户体验性测试，你能看清这个写的是什么吗？
-
亦起测-316
实际：页面中所有的图标，都会展示一个「飞入」的特效。
-
亦起测-315
不考虑有效性的用例补充，都是耍流氓。
-
亦起测-314
很多伪需求（买个 4kw 插版）都是这么来的，看着以为解决了用户的问题（需要大功率插板），其实根本不是从原始诉求出发的（支持厨房电器使用，保证安全）。
-
亦起测-313
同理，我们测试角度有个叫用户体验测试，这个并不是说我假装自己是用户，就真的是用户了，而是有真的使用需求时，才是真用户。
-
亦起测-312
全回归是最无奈的测试方案。
-
亦起测-311
127.0.0.1 作为回传地址，默认和本机地址的效果是一样的，但是 windows 版 mongodb，默认绑定的是 127.0.0.1，如果要使用本机地址，还需要主动绑定一下。
-
亦起测-310
不管是扩大测试范围还是缩小测试范围，也都有更明确的原因。
-
亦起测-309
要解决的关键问题，就是信息同步。
-
亦起测-308
看起来是故意这样实现的，但确实有一些接口是必须实际进行了分享才可以，所以感觉很奇怪。
-
亦起测-307
有时候，越简单的事情越容易出错。
-
亦起测-306
现在我还想加一个「善于倾听」，如果你都没有耐心听完，如果你在听的时候一直在想着如何反驳，就不要说你理解了，因为你没有理解对方，你理解的是自己的想法而已。
-
亦起测-305
如果不去看数据，只是功能和逻辑层验证，根本没感知，但是去数据库看了数据，一眼就能看出差别来了。
-
亦起测-304
这就要求测试自己有主体责任的意识，如果质量需要开发协助，就要主动找开发，而不要等着开发意识到这是他的责任。
-
亦起测-303
这是上游决定下游的关系，也是全部都在推进测试左移期望要解决的问题吧。
-
亦起测-302
前提一致，结果才一致。
-
亦起测-301
这就好像我们的测试活动，其实很多风险，如果我们有足够的风险意识，是可以提前预防，提前准备的，一旦放松了警惕，风险必然会如期而至。
-
亦起测-300
比如很多操作方式都很奇葩，但大家的唯一要求都是别给我添乱。
-
亦起测-299
人工测试的优点则是发散，体验。
-
亦起测-298
下面这个选项前面应该是有个单选按钮的，最近突然就没了，但是这都过了好久，不知道为啥没有修复。
-
亦起测-297
你觉得呢？
-
亦起测-296
这就是产品经理的预期设计和真实用户的实际操作之间的鸿沟。
-
亦起测-295
小改动，大收益。
-
亦起测-294
ToC 不需要考虑本地化部署的测试，ToB 如果非 SaaS 模式，则是支持本地化部署，就一定要进行相应的测试覆盖。
-
亦起测-293
相对于 ToC 项目的小步快跑，ToB 项目更注重稳扎稳打。
-
亦起测-292
ToB 项目的稳定性和兼容性优先级最高，而不是 ToC 项目的功能性优先级最高。
-
亦起测-291
这对测试就提出新的要求，我们必须对整体项目实现都有足够的了解，才不至于出现盲人摸象的结果。
-
亦起测-290
现在到处都在开展政企项目的大环境下，是不是大家在研究互联网玩法的同时，也关注下 B 端测试经验的总结。
-
亦起测-289
一定不要用战术上的忙碌，掩盖战略上的懒惰。
-
亦起测-288
标记完成后，两端会同步，最终以手机端计时为准。
-
亦起测-287
如果必须要优化的话，显示出来[有人@我]，也许可以参考。
-
亦起测-286
公众号后台会展示用户的留言次数，以及留言的精选次数，可是会出现一个用户留言 1 次，但是精选了 2 次的情况，一直没搞明白咋算的？
-
亦起测-285
同事给推荐了一个神奇 notion，试用了一下，真香，感觉我要放弃有道云笔记了。
-
亦起测-284
这可以理解为理论和场景化的不一致，在产品设计和测试过程中同样需要关注这种情况，比如明明预期的操作步骤是123，实际客户就是213的操作，不可不防。
-
亦起测-283
这个计算的结果，我有点看不懂。
-
亦起测-282
自我改进的迭代能力，力大无穷。
-
亦起测-281
看，这就是我理解的用户的想法和用户真实想法的区别。
-
亦起测-280
在测试过程中尤其要注意这种经验主义，它会让我们降低对问题的敏感度。
-
亦起测-279
在我们推进质量改进的过程中，也要从关键数据着手，对症下药。
-
亦起测-278
但是直接显示日期，直观，明了，确定性，大爱这样细节的产品设计。
-
亦起测-277
原来如此，再好的事情，也需要好的策略配合，才能达成好的结果。
-
亦起测-276
技术影响力可以包括两方面，一方面是测试专业度，一方面是业务所在行业的专业度。
-
亦起测-275
这应该算兼容性测试没覆盖全。
-
亦起测-274
这应该算是对需求合理性评估太多后，留下的职业病吧。
-
亦起测-273
有意思的地方就在于，这个 Bug 出现的前置条件。
-
亦起测-272
是不是可以说明「不要相信开发的嘴」呢。
-
亦起测-271
这是一个特殊环境的 bug，在特定环境稳定重现，在其他环境就很难复现，这时候对 bug 的定位和分析就尤为关键。
-
亦起测-270
其实我们测试，也是在寻找产品质量的关键卡点，在格挡中，找到脆弱点，并尽早弥补。
-
亦起测-269
需求人员（包括但不限于产品经理）不使用自己设计的产品，是一个产品失败非常关键的原因。
-
亦起测-268
微信视频号的 Bug 一枚。
-
亦起测-267
阿里云盘对于上传和下载文件都有个数限制（我为啥知道？试出来的），但又不说限制多少个，就只是提示失败，愁死了。
-
亦起测-266
3、一些很明显看懂的话，错一两个字并不影响结果（目的最重要）；
-
亦起测-265
正应了那句「拷贝代码一时爽，维护代码火葬场」。
-
亦起测-264
当然，快捷的同时，带来的副作用就是误报，比如头带误报，比如有人低成本恶作剧（目前紧急电话都是免解锁）等等，但是呢，一个新东西出现，肯定有阵痛，也肯定可以妥善解决的吧。
-
亦起测-263
今天是最后还款日，又打了 4 个了，真是执着，不过都这个时候了，电话营销还是这么火么。
-
亦起测-262
二是要能甄别什么是真问题，每个人的理解不同，我们要避免「设计如此」的陷阱。
-
亦起测-261
最新版的微信已经改了展示了，不仅解决了问题，而且还扩展了选项，两全其美。
-
亦起测-260
也就是说，就算没有无限卡，也可以用这个方式无限的看。
-
亦起测-259
可能的问题原因：先用接口判断是否重名，如果重名则调用接口获取重名信息，这样就可能出现不一致，预期是判断是否重名的接口，应该直接把重名信息一起返回，保证一致性。
-
亦起测-258
微信「看一看」的数据真差呀。
-
亦起测-257
最近发现好几个 PC 客户端的 bug，这些问题在对应的 App 上都没事，看来大家是放松了对 PC 端的要求哈，PC 端的办公群体还是蛮多的，切不可掉以轻心哈。
-
亦起测-256
知微见著，很多产品的细节和灵感（很多缺陷的隐患），也是这么来的吧。
-
亦起测-255
两个截然相反的曲线，我能想到的一个结论是：建立链接是需要时间的，而断开链接只在一念之间。
-
亦起测-254
微信读书不是宽松社交么？为什么要这样调整？
-
亦起测-253
以此为戒。
-
亦起测-252
真给力。
-
亦起测-251
Windows PC 端微信更新为 3.4.0.38 版后，朋友圈和群聊里打开的图片，都是小图展示，故意设计成这样？从用户体感来说，明显是 Bug 呀。
-
亦起测-250
测试策略和测试方法这些测试基础的探讨越来越少，质量和效能的讨论越来越多，这是好事不？
-
亦起测-249
现在说的质量保证，是要主动设计去保证产品质量，不仅仅要把好最后一道关，把把握每个过程的质量，做好质量的教练员。
-
亦起测-248
微信在设计上的细节把控。
-
亦起测-247
这应该算特殊场景的测试覆盖，可能因为「审核中」状态时间比较短，所以被忽略。
-
亦起测-246
PC 端微信朋友圈的文字会错乱，这个问题隐藏的有点深，但是必现。
-
亦起测-245
涉及钱财和数据的，一定要尽可能多的覆盖各种异常，不仅仅是技术手段的保障，设计上也要考虑用户的心理预期；
-
亦起测-244
首次登录时，数据库字段为空，没有特殊处理（问题不大，但是处理下体验就更好了）。
-
亦起测-243
我猜可能是数据里面有划分吧，但是作为用户，我的第一感觉就是 bug
-
亦起测-242
这就是用户场景的测试用例覆盖。
-
亦起测-241
这就是用户场景的测试用例覆盖。
-
亦起测-240
这就是用户场景的测试用例覆盖。
-
亦起测-239
这就是用户场景的测试用例覆盖。
-
亦起测-238
所以重要的事情要反复确认，至少说三遍。
-
亦起测-237
判断缺陷是否有效，也是质量保证人员必须具备的技能。
-
亦起测-236
雨天时，踩上去还是轻微的晃一下，踩上去的那只脚没事，另一只脚则会被溅上一脚水，甚至殃及旁人。
-
亦起测-235
比如时间都花在功能细节的测试上，忽略了整体连通测试，或者稳定性和兼容性的测试。
-
亦起测-234
下次登陆又新增了 50 条，这次翻 2 页就看完了， 但一直显示未读 50 条（上次没看完的），可是我找不到这 50 条在哪了（需要翻页，又不知道需要翻多少页）。
-
亦起测-233
业务和质量目标都达成是最好的，有冲突时就需要有取舍，悲剧的是，大部分时候都需要做这个取舍。
-
亦起测-232
这就是明白了很多道理，却仍然做不好产品。
-
亦起测-231
测试右移固然是在一定程度上提效，但是一定要注意及时迭代优化，不然时间长了就成了狼来了的故事，再也没人相信了。
-
亦起测-230
测试看别人用例时，吐槽没有详细步骤，自己写用例时，没时间写步骤。
-
亦起测-229
爱奇艺的bug
-
亦起测-228
质量保证不仅仅要关注产品的技术质量，要关注的还有产品的诉求，质量再好的产品，如果没有用户，也体现不了高质量的价值，反而会增加成本。
-
亦起测-227
质量保证是一个系统工程，不是说所有问题都需要全解决，而是在资源有限、成本有限的情况下，尽可能多的解决那些关键的、严重的问题。
-
亦起测-226
这可以算是场景用例覆盖不到位。
-
亦起测-225
通过对常见用户场景的覆盖，更好的从用户角度出发，发现那些场景化的问题（而不是掉到技术实现的坑里）。
-
亦起测-224
建议：1、加设置入口；2、只记录最近 5 条有操作记录的文档的位置信息。
-
亦起测-223
嗯，任何事情都有两面性。
-
亦起测-222
所以谈质量，先设置好前提条件，比如三步以内的点击操作，不会出现明显的软件异常。
-
亦起测-221
不需要完美的质量，需要的是满足业务诉求的质量。
-
亦起测-220
这也说明，那么我们认为本该如此的东西，也都有可以改进的空间。
-
亦起测-219
预期是返回正常浏览，实际页面卡住完全无法操作了。
-
亦起测-218
同时，它也可能成为劣势，因为熟悉会让我产生定势思维，从而发现不了问题，也就没法进行突破（创新）。
-
亦起测-217
那么作为测试，我们要做的，则是尽可能提前的完成需求变更，尽可能有效的识别有效变更。
-
亦起测-216
用户只知道「可用」和「不可用」，没有「暂不可用」，也没有「自定义设置」，更没有「辅助功能」。
-
亦起测-215
看，我也发现个 bug（数据测试不能单纯看数据，要关注数据合理性）。
-
亦起测-214
所以一个产品的价值主张尤为重要。
-
亦起测-213
循环的退出然后自动登陆
-
亦起测-212
朝阳新换的这个公交牌可扩展性太差
-
亦起测-211
百度网盘这句柄数要逆天了
-
亦起测-210
修改用户信息后，前端应该同时更新本地缓存信息
-
亦起测-209
mongo 的数据查询和 SQL 的查询字段的处理上有很大的不同，比如字段写错了，sql 会报异常，mongo 就是返回一个空的结果，该夸它异常处理做的好呢，还是夸它可以完美掩盖问题呢。
-
亦起测-208
页面错误巨大
-
亦起测-207
实践是检验真理的唯一方法
-
亦起测-206
没有异常不代表没有问题，越是表面上一片平静的时候，越是要关注真正的问题是否被掩盖了（我系统自测时，没有任何错误，也没有任何数据，看起来像是数据的问题，但是数据构造后发现还是不正常，但是因为没有错误提示，定位非常棘手）。
-
亦起测-205
有道云笔记总是弹出这个提示
-
亦起测-204
2、闪断后，需要打开收听项目的详细播放页面点击开始，才会继续播放，如果不点进去点开始，就从头开始播放了；
-
亦起测-203
这个场景确实有点特殊，但也不是完全考虑不到
-
亦起测-202
目的不同，决策不同，结果也不同，比如红绿灯的设计，是以效率为主，还是以安全为主，决定了最后的通行效果。
-
亦起测-201
对于司机来说，右拐弯是最顺滑的，对于行人来说，右拐的车是最危险的，眼瞅着绿灯没了，右拐车流还是没完没了。
-
亦起测-200
点击同一张照片，会累计计数
-
亦起测-199
我的建议是，所有桌子都可以弄成单桌，就是面对面可以坐两人那种，然后根据不同的区域，可以适当的拼桌，但是更多的留单桌，这样可发挥的空间就大了哈，本来疫情期间也鼓励保持距离，一举两得。
-
亦起测-198
测试思维比测试技术本身要重要的多，就类似一个二分法，一个穷举法。
-
亦起测-197
测试不需要保证百分百没问题，但是百分百要知道，如果出问题，会造成什么样的影响。
-
亦起测-196
测试对业务理解透彻了，开发还会吐槽我们总问低级问题么？产品还会质疑我们搞不清优先级么？
-
亦起测-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
所以利他，就是最大的利己，因为利己是本色。
-
亦起测-184
最近一直在 boss 上收简历，发现如果我连续几天没时间上去沟通，就一个简历推动都木有，一旦活跃起来，就有简历过来了，这也是用了游戏化思维的及时反馈策略呀，同时也说明，如果发现了一个问题，先从自己身上找找原因。
-
亦起测-183
之前用不惯阿里云盘的照片同步，总感觉和之前的习惯不一致，很别扭，但是之前的方式用起来又确实不方便，现在多次尝试后，终于算是有点习惯了，这就是教育用户的效果么。
-
亦起测-182
很显然这个后退的场景考虑不足。
-
亦起测-181
这是一个神奇的 bug，或者说本来不应该出问题的 bug，但是出问题了，有时间我写个详细的复盘。
-
亦起测-180
很早前我在记一些数字时，经常用这个方法，现在在总结一些问题场景后，只要出现类似的逻辑实现，我就能快速回忆起上次补充完善的用例，感觉特别好。
-
亦起测-179
微信读书的书评提交后，是不能给自己点赞的，但是点开书评详情后，就可以给自己点赞了。
-
亦起测-178
和很多高手一直致力于对高精尖技术的追求不同，我一直想构建一套软件测试通用的基础知识体系，只有基础牢靠了，才能盖高楼，只有图纸清晰了，楼才不会盖歪。
-
亦起测-177
我一直想构建一个软件测试从入门到精通的体系，所以才有了软件测试经验图谱，但是现在看起来图谱更适合从熟悉到熟练这个过程，从入门到熟悉，以及从熟练到精通这两部分，还需要补充完善。
-
亦起测-176
虽然作为质量保证人员，发现问题是件很正常的事情，但是大部分人在发现问题的第一时间是怀疑自己是不是操作的有问题，当然，新手除外。
-
亦起测-175
当然，每个人对「高质量」的解读会存在差异。
-
亦起测-174
测试的目标是为了证明软件不可用，但是执行测试时，我们却总是希望别出现问题。
-
亦起测-173
质量保证的要求就是正确的事，具体的测试活动则是正确的做事。
-
亦起测-172
上游质量差，对质量的最大挑战是流程规范和信息同步；
-
亦起测-171
随着后面科技的发展，对计算机软件质量的依赖越来越高，质量的挑战也会越来越大。
-
亦起测-170
测试是个不确定的东西，不确定性就是它的特性，所以我们要你努力追求质量的可控性，就是最低的质量要求必须要得到保障。
-
亦起测-169
MySQL 查询语句不区分大小写，MongoDB 查询语句区分大小写。
-
亦起测-168
对于文本编辑器来说，支持的行数多少，和字数多少，是两个完全不同的测试点。
-
亦起测-167
我们至少要先保证「线」的层面全了，之后再去补充颗粒度更小的点。
-
亦起测-166
这就是我认为和事实上的区别，也是我们理解的用户角度和真实用户角度的区别。
-
亦起测-165
另一方面大家都不知道自己当前的位置，从而有一种无力感，不知道朝哪个方向努力。
-
亦起测-164
北京一卡通的登陆缓存，有个过期时间，但是一般都不会在意，也没地方设置，可是碰到上公交之后发现登陆过期，就很尴尬了，还需要重新登陆，关键时刻，手机号一键登录还经常失败，哎呀，愁死了。
-
亦起测-163
现实就是这样，总是和理想有出入，产品设计尤其要避免这种误区，总以为自己是从用户角度出发时，要考虑自己是不是真的用户。
-
亦起测-162
HTML 字符转义是前端最容易犯的问题，看起来很简单，技术实现也不难，但就是很多地方都会出。
-
亦起测-161
数据是效果的最好体现，哪怕仅仅使用拙劣的 Bug 数来体现，也是一种体现方式，当然，我们还是要追求更多角度，更准确的体现。
-
亦起测-160
测试对于业务的价值，可以分为两部分，一部分是某一个具体项目的质量保证，一部分是基于项目经验做出的对于同类项目更好的质量保证的体系建设。
-
亦起测-159
苹果的背部双击截图准确率太差了，经常乱截屏。
-
亦起测-158
所有的问题，最后都是选择的问题。
-
亦起测-157
我们一直说需求沟通要清晰合理，其实测试内部本身的沟通也是需要清晰合理，比如不同人对于测开角色的理解会有不同，比如我们说原始需求时，有些人就听不懂等等，任何专有名词，请保证理解的一致性后，再继续。
-
亦起测-156
所以不要止步于发现问题这个表象，而是要考虑如何解决根本的质量问题。
-
亦起测-155
当然，之所以叫优先级，就是说在后面的迭代中，我们还是要把欠的债给补上的。
-
亦起测-154
不过一直没忘记薅微信读书的羊毛。
-
亦起测-153
左移不应只是形式上的左移，要是具备左移能力的人在左移后发挥左移预期的效用，才是左移。
-
亦起测-152
测试保障和质量保障虽然只是名字的差异，但却是不同的概念，代表不同的意义，目前的话，大部分人都还停留在测试这个层面的理解，需要想办法贯彻对质量保障的理解。
-
亦起测-151
罗曼·罗兰也说过，「世界上只有一种真正的英雄主义，就是认清了生活的真相后还依然热爱它」
-
亦起测-150
被一个输入法的设置折腾的够呛，全部隐藏后找不到还原入口了，重装都没用，我也是醉了，不过看起来不是输入法的问题，而是系统没有提供对应的还原入口，倒是 Win10 系统自带输入法的默认设置是最符合「简单有效」设计原则的。
-
亦起测-149
今天弄了下小米手环的设置，「抬腕亮屏」竟然默认是关闭的，不管是手表（一直亮屏），还是手机（抬起亮屏），这都是默认选项，所以这算不算 Bug？
-
亦起测-148
给别人修电脑，发现他装了 2 块硬盘，其中的 SSD 竟然不是系统盘，这算不算 Bug？
-
亦起测-147
提示的错误信息明显是给开发看的，建议换成用户角度的错误信息
-
亦起测-146
按理说这也算 bug，不是程序实现 bug，是设计 bug。
-
亦起测-145
很多测试都觉得尴尬，主要是觉得测试没有技术含量，同时自己的技术又达不到开发的水平，所以只能委曲求全，终日惶惶。
-
亦起测-144
得到作为这么专业的音频应用，有非常严格的品控，但是依然没有解决学习计划连续播放时，不同栏目音频声量大小不一致的问题。
-
亦起测-143
阿里云盘使用完全不同的照片上传的策略（当然也是最先进的），我以为就我使用不习惯，一看网上很多人都不习惯，一个新习惯的培养，哪怕是先进的，也是需要时间的。
-
亦起测-142
本想给个好评，结果碰到个 Bug
-
亦起测-141
所谓的换位思考和感同身受，真的不是说起来那么简单，很多时候，也不是我们理解的那么轻松。
-
亦起测-140
果然是高手，成功利用了人们的惯性思维，肯定没人会来确认下地锁是不是好的。
-
亦起测-139
微软在 Win10 上对它的搜索、浏览器、输入法、OneDrive、WindowsDefender都做了很强的绑定，都是默认设置，并且默认启动，但是介入 Windows 的影响力，大家对这个都习以为常，并且作为是对我使用体验的改进了。
-
亦起测-138
但是反过来一想，这个广告的目的到底是什么，如果只是给已经熟知华与华的人来说，肯定是哇哦，华与华真牛，广告都做到这来了，如果是不熟悉的人来说，完全看不懂，看不懂「华与华」是啥，也看不懂啥叫「超级符号就是超级创意」，从这个角度来说，我觉得这个宣传又是很失败的。
-
亦起测-137
人脸识别手机解锁，我是戴着眼镜录的，然后不戴眼睛的话，就发现它识别不了，这算是 Bug 呢，还是设计如此呢？
-
亦起测-136
之前其实收到过短信提醒了，但是现在的短信全都被忽视了，产品经理么，这个场景要考虑不？
-
亦起测-135
可见早期介入测试的重要性，这里的早期测试，并不一定是测试同学来做，但是必须要做的。
-
亦起测-134
你能看出来这个「其它方式登录」是可以点击的么？
-
亦起测-133
想想这就和我们测试的系统一样，每个桥墩和桥面都是单元测试的一部分，桥墩和桥面开始组合，就需要集成测试，完整拼接后，就要进行系统测试了，不同时候的关注点也不同。
-
亦起测-132
并且，如果底子差，那么呈现同样的效果，反而还可以加分。
-
亦起测-131
如果说滴眼睛是一个 UI 操作，那么眼和鼻腔相连，鼻腔和口腔则是内部实现逻辑，如果只关注表面的操作，就意识不到内部的关联，更不会考虑到这个关联可能产生的额外测试点。
-
亦起测-130
这么说这个思路挺好的，但就是宣传上做的不够好，至少我没有一眼看出来是免费取纸，所以无形中减少了很多人尝试的动机。
-
亦起测-129
对于产品设计来说，这才是最大的困难，我们到底是要教育所有用户，还是要迎合部分用户。
-
亦起测-128
同样的产品实现也是一样，对目标客户就是好，非目标客户，一无是处。
-
亦起测-127
我看了下接口请求的情况，是 file create 接口pendding 了。
-
亦起测-126
这就是产品设计的两面性，有利有弊，就看弊大于利，还是利大于弊。
-
亦起测-125
5、2个文件移动就会显示有保险箱文件夹，1个文件移动就没有；
-
亦起测-124
这是一个和业务逻辑没关系的实现技术和测试点，懂不懂还是很明显的。
-
亦起测-123
如果从产品设计的角度考虑，这就是我们预置了一个理想的前提条件，出现意外的情况本来很小，但是一旦出现了，直接打回原形。
-
亦起测-122
这就是我们测试用例中的异常用例，有些我们很肯定不会出现的场景（厕所没纸？只收现金？指针为空？），其实总是有例外，所以一定要做异常处理，一定要做异常处理，一定要做异常处理。
-
亦起测-121
有道云笔记支持语音笔记，而且是实时转换为文字的，我试了下还蛮好用，但是感觉没有测试过语速特别快，并且持续时间特别长的场景，我试用的时候卡了好久都没翻译出来。
-
亦起测-120
我们做项目经常会碰到这种突发情况，第一反应应该是尽快的先解决问题，然后去复盘问题，找到问题的根本解决办法。
-
亦起测-119
一件事情是因为它的意义而存在的，比如梵高的画也是画，只是因为给赋予了梵高的意义，就变的不一样了，同样的，同样的反馈监控，崩溃监控，打点采集，赋予测试右移的意义，也不一样了。
-
亦起测-118
测试的价值，业务方最清楚，如果抛开业务方的角度去证明测试的价值，还是件蛮困难的事情。
-
亦起测-117
当所有人都接受一个好的体验作为现行标准时，才是真正好的体验，不然再好的体验也会变的格格不入，最后就是劣币驱逐良币。
-
亦起测-116
招商银行查看完整卡号后，复制的卡号是带空格的，可是很多地方输入带空格的卡号时都是识别错误，我记得招行自己 APP 的某些地方也是不识别，这就是用户体验，有时候我们以为的「改进」，其实也可能适得其反。
-
亦起测-115
那些我们以为很熟悉的经验，如果没有在最近验证过，就有小心掉到经验主义的陷阱了。
-
亦起测-114
今天玩手机游戏的时候，突然来了个电话，接了电话后游戏没有暂停，只是声没了，挂了电话，游戏继续，但是声没有回来，看来我又碰到特殊场景的用例没有覆盖到的情况了，所有带声的，一定记得跑这个用例。
-
亦起测-113
很多地方一直提倡用户视角去看待用户体验的问题，所以很多人就真的把自己当用户去评价一个产品，然后就发出「何不食肉糜」的感慨。
-
亦起测-112
一直说的测试左移，大家都知道是质量前置，但是落地的时候，会被人为的限定为自动化前置，其实需求评审时提出问题也是左移，而且是提效最明显的左移，只是没法量化。
-
亦起测-111
虽然我们都知道不能逆行，但实际上逆行的人很多，就像我们知道某些异常用例基本走不到，可是实际环境中肯定会被触发到一样现实。
-
亦起测-110
不要认为测试没问题就是真的没问题，可能只是没发现问题，测试的目的是证伪。
-
亦起测-109
线上回归环境的作用不是为了发现问题，而是为了避免问题出现在回归环境，所以每次在回归环境发现的问题都需要想办法在回归前规避。
-
亦起测-108
涉及数据库的项目测试，一定记得要测试数据库为空的场景。
-
亦起测-107
这个设计中有意思的地方是，不管有没有兜底方案，那个每天减少的免费时间，总是给人失落感，然后就会诱发大家去做各种活动。
-
亦起测-106
同样的，作为测试，我们对技术的追求，一定要记得目的是什么，是提效和更全面的保证产品质量，而不是技术本身（当然，如果能兼顾就完美了）。
-
亦起测-105
所以场景覆盖时，请多走一步，不要只停留在自己的想象中。
-
亦起测-104
对开发来说，如果明白这一点，知道在沟通时把黑话翻译成白话，能够瞬间提升测试同学的好感度。
-
亦起测-103
测试同学快吃吧，要注意原始需求的比例，需求变更前的比例，需求变更后的比例都是否符合预期，最终成品的口味是否符合预期。
-
亦起测-102
反过来想一想，当前的业务是否适合测试开发？我们到底期望测试开发带来什么样的改变？达成什么样的目标？也许会有新的收获。
-
亦起测-101
分层测试就是对测试目标进行归类，大类就是表示层、逻辑层、数据层，再细分可以有业务接口、通用接口，不同类别可以用不同的测试策略和测试方法，想清楚再动手，事半功倍。
-
亦起测-100
所以之前测试的面试题，都是必问「电脑突然上不了网了，可能是什么原因？」，借机温习了一下。
-
亦起测-99
这件事会给我的教训是，眼见不一定为实，经验主义害死人，这个情况在我们测试的时候很常见，比如一个功能曾经测试通过了，二次回归的时候就会有「 肯定不会有问题」的潜意识在作祟。
-
亦起测-98
建议修改的方案，搜索可以继续用缓存，但是我修改群名称，在更新数据库的同时也应该同步更新缓存。
-
亦起测-97
跟车距离真是考验人，跟的近了容易追尾，跟的远了被后面催还被前面加塞，其实我们选取测试颗粒度的时候也是这样，颗粒度太粗，可能覆盖率不够，颗粒度太细，可能会过度测试，这时候就是发挥我们测试经验的时候了。
-
亦起测-96
其实很多难以发现的 bug 都是这种连锁反应，如果只是盯着问题本身看，就是一个小问题，但是深究下，可能会有新发现。
-
亦起测-95
作为一个强度依赖导航的人来说，语音导航的描述真是让人捉急，明明我沿大路直行就可以了，非要告诉我说前面有个三岔路，请走最左侧岔路，吓的我看了半天哪有岔路，原来就是主路分出去的两条岔路，就是说用次要信息影响了我对主要信息的判断，增加我信息处理的负担，这种用户体验的测试，不过关。
-
亦起测-94
给我的启示是，实际场景的测试，比单纯的逻辑覆盖要重要的多。
-
亦起测-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
错把平台能力当作自己的能力很可怕，比如公司有现成的自动化用例管理系统，自己可以按模版添加用例，结果就变成自己熟练使用自动化，一定要区分哪些是我的能力，哪些是我们的能力。
2020
-
亦起测-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
质量和效率。
-
亦起测-07
测试的目标应该是在有限的时间内发现尽量多的问题，特别是严重问题，尽可能的降低线上风险，我们无法保证也做不到百分百无风险。
-
亦起测-06
测试经验的积累过程中，总结很重要，举个例子，每次发现问题，都应该想想「后期如何避免同类问题的发生？」，每次得出答案，每次就有新的收获。
-
亦起测-05
测试策略比测试执行重要的多，所以用例写的全之外，还需要用例优先级划分的好，但是很多人往往都花了很多时间在测试的全面性上，而忽略了针对性，结果的体现就是测试效率不高。
-
亦起测-04
如果一直局限在自己的角色上，根本做不到深入测试，既然是深入，就必须有全面的了解，知道逻辑细节和关联关系，知道如何去深入。
-
亦起测-03
测试目的永远比测试技术重要，不要为了追求完美而让我们忘记测试目的，比如在只有十人范围内使用的产品，就不要花费一周的时间去详细测试了。
-
亦起测-02
给闺女读了一篇课文《我要的是葫芦》，讲的是一个人种了葫芦，葫芦叶子长虫了，邻居好心提醒，他却说「叶子长虫了？我要的是葫芦」，作为测试人员，我们尤其要避免这种关系混淆问题，比如提测质量差，我们不能不管不顾，只想着我们要的是「测试质量」。
-
亦起测-01
做测试，最重要的还是思路，在那忙测点点点别以为就是探索性测试了，探索也是有法可依的。