后台回复「MTSC」，领取大会 PPT

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

“二麻子，听说你被催更了？”

“必须的呀，我这么有影响力的大佬（浑身发热），停更了快五个月，怎么也得有个人催催才有动力更新呀。”

“真的假的？现在已经不流行你这种土包子基础知识了，大家都在谈敏捷测试、大数据测试、AI 测试了，谁会催你？”

“那是因为我实在，所以我只写接地气的干货，当然受欢迎了（说的我自己都要害臊了），来来来，有图有真相。”

“真不赖，竟然真有好几个催更，不过话说回来，人家都催了这么多次，你干嘛还不更？”

“那可不，咱也是有铁粉的人，不过说来惭愧，年前有几个系统着急做，又没有人手，所以业余时间全去救火了，谁知这一救就一发不可收拾，一下搞完三个系统，顺便把 HTML、CSS、JQuery、Tornado 全给熟悉了一遍。”

“这都是些基础技术嘛，竟然搞了这么久？”

“嗯，之前一直搞客户端的产品，确实对 Web 接触不多，所以多花了点时间，不过经过几个版本的迭代，现在公用模版和框架都稳定了，再新加系统就是分分钟的事。”

“那花了这么长时间，都有啥收获可以分享的不？”

“当然有了，不然哪敢轻易更新，好不容易涨起来的粉，我可珍惜了。”

“别废话，直接上干货。”

“千万别着急，路要一步步走，饭要一口口的吃，我今天先简单说一下，更详细的后面会陆续更新哈。”

“还卖关子呢？爷不伺候了。”

“看看看，刚说了猴急吃不了臭豆腐，你就急了，慢慢更才是为了让干货更实在呀。”

“行吧，先把今天的干货甩出来，不干我拿鞋底子抽你，要是我觉得还行，就帮你疯狂转发。”

“得，你说话可的算数：

1、纯粹的前后端分离架构时，一定关注 URL 带不同参数时获取页面数据的正确性；

2、如果使用了部分查询（limit）来优化展示速度时，一定要验证翻页后数据的正确性；

3、前台提交数据时，一定要关注是提交完整页面数据（这种需要验证并行操作的场景），还是只提交变更数据到后台；

4、如果是使用的 MySQL 数据库，并且支持多条件自定义搜索时，一定要增加用例覆盖关键词是 or 和 and 的情况；

5、如果使用的 MySQL 数据库，并支持模糊匹配，一定要增加用例覆盖关键词带 % 的情况；

6、如果有前端显示的逻辑，一定要看是否处理了 HTML 转义字符等；

7、所有的硬编码逻辑，都是万年深坑，要么避免，要么提前考虑好维护方案；

8、出现超过一次的常量就提取到配置文件，使用超过一次的函数就提取到公共模版；

9、优化（重构）代码比写新代码更可怕，因为谁都给不出准确的影响范围；

10、MongoDB 搜索匹配时区分大小写，MySQL 搜索匹配时不区分大小写；

11、MongoDB 搜索匹配时区分数据类型，MySQL 搜索匹配时不严格区分；

12、如果可以的话，测试过程中时刻关注数据库的实际数据，而不仅仅是看前端的展示；

13、尽量让前端开发一开始就把每个控件带上唯一的 id 属性，可以极大的方便后续进行自动化测试；

14、请关注用户体验测试，一个好的前端，可以让产品逼格提高 N 倍；

15、当开发说「我的修改很简单」，完全不等同于「这个修改影响的范围很小」。”

“果然干货不少呀，不过有些听的似懂非懂。”

“所以说让你慢慢来，有些是必须有实际的案例才能体会的更深刻，才能记得更牢，才能在自己以后的项目中发挥作用。”

“行行行，你说啥都对，我这就给你点赞转发能行不？”

“是老铁的必须点赞转发一条龙支持，更多干货即将袭来，给公号加星标可以第一时间看到更新噢。”

以上，虽然停更了几个月，但是期间我一刻也没停止学习，希望这几个月的积累，能给大家带来些许新的收获，2020，我们继续一起努力。

当然，如果你认同我的观点，记得分享文章到朋友圈 + 点个「在看」让更多人看到，谢谢。

为了感谢大家的支持，我准备了一个抽奖，在 3 月 3 号上午 8 点 15 分自动开奖。

感谢你的阅读、在看和转发，点我抽奖，祝你好运！

推荐阅读：

二麻子，你准备好开学礼了嘛

二麻子，你们测试用例跑出来的 Bug 占比是多少？

二麻子，听说你们公司的用例是写给领导看的？

软件测试经验图谱硬技能之积累和应用

测试前移之需求合理性验证