后台回复「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 分自动开奖。
感谢你的阅读、在看和转发,点我抽奖,祝你好运!
推荐阅读: