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

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

「得到」APP

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

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

是滴是滴

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

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

嗯嗯，同感

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

这个，偶也不知道……

共勉!
谢谢大家点赞