这玩出花儿了，厉害

1.接口测试测完能证明你跑的那些 case 是没问题的。当然前提是你自己的测试代码没 bug 哈
2.覆盖率 100% 也不能说明质量越高

return a/(b+c)

以上代码 a=1,b=1,c=1 就 100% 代码覆盖和函数覆盖了。但是 b+c=0 时呢？
3.覆盖率是在业务场景覆盖完之后，帮你做漏测分析的，不要把覆盖率单独拿出来说事儿，覆盖率越高也不一定代表质量越好。另外覆盖率用来做用例质量分析，用来做精准测试，他不香么。

终极目的是为了偷懒，少点烦我的事

只有 json 的话，就可以调用接口录制了啊，你到时候检查下录制的结果不就行了。当然，这个肯定是开发完之后了。
如果开发之前调整用例做 TDD，写代码批量修改 json 或者 yaml 我觉得也比改 excel 舒服（可能有我 excel 完全不会啥酷炫功能的原因）。

直接用 json 不行么

感谢分享

感谢分享！

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

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

感谢分享！先试用一下

关注一下。感谢分享！

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

必须隔离

没接触过，学习了。

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

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

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

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

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

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

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

很棒！支持一下

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

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

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

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