跟他们一起做了才知道。。。中台业务偏技术，不懂的话基本没法测

用例是什么？测试过程中测试执行的依据，你的领域知识 + 测试思维的结合，是包含了需求，且不仅限于需求内容的。
目的是什么？让测试执行能证明哪些 OK，有哪些不 OK，最终帮助决策。
如何写好？想的比产品多和远，了解过开发的水平，熟悉用户的习惯，测试基础扎实，整个研发流程正规，不偷懒时间充足。用例想写不好都难。当然，再好的用例也要根据实际情况来，不适宜的好用例也谈不上多好。

感谢分享！先试用一下

关注一下。感谢分享！

1.年轻就是最大的资本。19 年毕业的有什么中年危机。。。。
2.测试要选对行业。成为行业的领域专家，搞不搞 IT 对你就没那么重要了。
3.你说的那些方向，基本都从选填变成必输了
4.持续学习，但是要紧跟潮流方向
5.在不年轻的时候有自己的核心竞争力

必须隔离

没接触过，学习了。

长度的话 缓冲区溢出？XSS？SQLinject？
web 类一般后两个吧，如果长度不严格 + 没有安全编码规范的话。安全漏洞很多的。
正确的做法是前端应该有清晰明确的提示，应用服务有规则验证，数据库层也要有判断。
如果自己用的内部系统，就不要纠结了，功能 ok 就行，管他提示呢。

个人经验：调 1-7 最靠谱，哪怕 1-7 逻辑变了，参数没变，你也就调个接口而已，不影响。我试过自己根据前置逻辑数据库直接生成数据，但是有时候更新不及时就一大堆错。

另外你 7 咋生成的前置数据。。。如果有线性关联的话，用 7 的前置 +7 不就生成了 8 的前置数据了么。。。

就方案一就行。
处理 1-7 的代码不是现成的么。。。你挨个调一下就行。而且接口层，怕什么代码多。。。
“逻辑分支多”——该覆盖的还不是要覆盖
“前置接口有出问题的风险”——我巴不得他出问题，出问题才是好事情啊。。。

你应该加上个限定词，你司的产品。。。
严谨一点。。。
你要是个名人，明天就因为这个言论上热搜了

厉害！好多地方值得学习！好多东西开了视野。。。。感谢分享！

有时候和公司谈个恋爱可以，结婚走到老还是比较难的。。。。哎，生活逼你当渣男

很棒！支持一下

arthas 用来排查问题非常好用！

频繁大改的。。接口？这显然是需求或者设计问题，建议在这个阶段就避免。
实在避免不了，调整下测试脚本的结构，让架构支持这种频繁的改动

达到或者超过开发水平吧，怼人会很有底气。很过瘾的

如果算法是黑盒的，感觉比较难，除非你自己写个算法来验证。。。

测试开发包含自动化测试，且不仅仅是自动化测试
他是面向测试的开发
是懂测试的开发
也是懂开发的测试

PS：知道一点不叫懂。。。

好久不见的乙醇大佬~
我焦虑的时候，会玩下游戏缓解下，挺减压的。
运动也是个减压的方式，可以和游戏结合着来。
有时候生活上的、工作上的压力，确实需要娱乐来排解，不要沉迷就行。

就怕那种没有一点个人生活的公司，再遇到一时的牛角尖或者抑郁了，周围有这样的同事，也帮一下吧，约着逛逛公园，打打 CSGO。

为啥不行，单独对前端表单展示做下验证就行，怎么好用怎么来，这种死逻辑最适合自动化验证了。
表单记得用 PO 形式分离。

好爽，拿钱给你们学习提升。。。弄好了还有奖励

工资对得起 996 或者某方面刚好满足你的需求就行，啥也没有的搞 996 就是耍流氓了

他就瞎说两个二八定律吧。。。

自学瓶颈了可以去霍格沃茨进修一波，看了下课程目录确实很好。
——非广告贴，我和他们没啥关系。。。