感谢分享！

公司需要你学哪个，你就学哪个。

感谢分享~
不过 “不会写代码的测试不能保证软件质量”，有失偏颇。代码也只是工具之一而已。

感谢分享

持续关注，感谢分享

点赞

最好每个用例独立开，便于维护，也没有什么隐含的先后顺序的问题。以后也方便根据某些规则进行用例抽取。
“避免每次都回到起始页，然后再进去 A 页面”，这个我也不是很理解，为啥要避免，节约时间么？

用例之间还有关联性？

很不错，赞一个。

自己开发个网站，或者去弄个开源的，自己写自动化测试

我靠 神器啊 橙色的那种

感谢分享，我主要是对实时质量的有效性理解有点疑惑。
假设一种极端情况，我们就用实时质量来评估是否具备上线条件，不做任何其他测试。
如果运行一段时间没有问题，那么我们什么时候能得到可以上线的结论呢？
感觉实时质量是测试的补充，采集到一些正向的常见的用户行为，并能把海量的业务数据当用例库积累，但是还得解决如何反馈更深层次或者更恶意的行为带来的问题

通篇出现 “老婆” 23 次

比较好奇运行含测试，实时可反馈，啥时能解决？比如金融口

这玩出花儿了，厉害

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，最终帮助决策。
如何写好？想的比产品多和远，了解过开发的水平，熟悉用户的习惯，测试基础扎实，整个研发流程正规，不偷懒时间充足。用例想写不好都难。当然，再好的用例也要根据实际情况来，不适宜的好用例也谈不上多好。

感谢分享！先试用一下

关注一下。感谢分享！