不定期更新，但是总可以在公众号后台回复「图谱」获取最新完整版

谢谢大佬带上分

多谢消灭 0 回复

嗯嗯，各取所需

已经修复了

请多指教

链接加上了，多谢提醒

知道的，但是作为面向用户的产品，用户体验应该是要优先考虑的，至于原生是什么逻辑，其实没多少人在意。

比如 TesterHome 的 markdown 就没有这个问题，就没人去质疑说不该和原生逻辑不一致。

「得到」APP

这个说的是黑盒系统测试的测试用例编写方法。

模块测试可以算集成测试了吧，其实也是适用的，可以从代码实现和调用者需求两个层面进行考虑

是滴是滴

从另一个角度看：
如果是 UI 测试，写详细测试用例太繁琐，写测试点更清晰明了；
如果是逻辑测试，写测试点可能过于简单，需要测试用例或者带测试步骤的测试点辅助完善。

我们目前只写测试点，没有写详细用例了，如果测试点写的不够明确，就要求在备注中补上详细操作步骤，这样不需要维护两份文档

嗯嗯，同感

我们用思维导图，其实写的主要是测试点，而不是按照 excel 的格式放到思维导图而已，那种只是工具的变化，貌似意义不大。
关于思维导图写测试点更详细的说明，可以继续关注我后续同步的文章。
当然，这只是我们团队的做法，仅供参考。

这个，偶也不知道……

共勉!
谢谢大家点赞

我印象比较深的点：
1.他们目标很清晰，对于「质量是所有人的责任」的执着和推进；
2.各种自动化实现的程度，真的体现了工具为我所用的感觉；
3.明确所有角色都是为了业务服务，而不是仅仅局限在「测试」的角色中；

如果觉得可以拿这个来吹牛逼，说明还是有价值的，哈哈