这是4年测试经验，自我总结出来的适用于所有产品编写测试用例的一个大致思路吧，仅供参考，有其他见解的可以一起讨论。个人看法是：在产品需求分析阶段，书写测试用例之前我们就应该想好以下问题，大致有个思路和规划，可以帮助我们更加清晰的梳理测试用例。
要写出一个逻辑清晰，条理清晰的测试用例步骤：
首先第一步：对产品要有大致的定位分析，了解产品开发使用到的技术和架构
只有了解了架构，才能知道底层逻辑的实现过程和原理，测试用例才会更具有全面性，健壮性和稳定性；目前常用的架构有分层架构、事件驱动架构、微服务架构等
第二步：分析产品业务及其需求
分析业务需求：产品用来干什么？为什么要做这个产品？客户是谁？业务功能帮助用户解决了什么问题？
分析用户需求：用户是谁？用户有哪些？（管理用户、普通用户），需要从不同用户的关注点去分析他们各自关注的需求；
分析功能需求：工作中大多数情况下都是在分析功能需求，但是一切功能需求都离不开业务需求和用户需求的背景；功能需求就思考该功能的数据来源？要实现哪些功能？核心功能是什么？显性功能和隐性功能都需要考虑以达到较高的用例覆盖率。好的测试人员就是要不断提高测试用例覆盖率，发现产品更多的隐形功能错误。
拿到一个功能后应该如何思考用例设计？（运用黑盒测试设计测试用例：等价类、边界值、因果图、判定表、正交试验、错误推测法、场景流程图法、自由测试法）
1. 首先应考虑当前的测试是单功能验证还是针对流程的测试。如果是针对流程，则直接使用场景法（流程分析法）来设计；
场景法需要画流程图，画出基本流、备选流和异常流，每一条可走的业务逻辑都要覆盖，每一条流的每一步又继续用等价类和边界值，判定表与因果图等方法进行分析；
2. 如果是单功能验证，则应首先判断页面的输入域与输出域之间是否有明显的约束关系或因果关系，有的话就使用因果图和判定表；如果没有则直接使用等价类划分法和边界值法设计测试用例。
3. 如果有约束关系或因果关系，再看这种关系是否复杂，一般比较简单的制约关系可以使用判定表来搞定，如果是复杂的制约关系则可能需要结合因果图来设计。
如果通过因果图或判定表得到的用例数过多，则再结合使用正交表来减少用例，如果不多的话，则不需要用到正交。
4. 因为所有非等价类和边界值的用例设计方法得到的都是用例设计规则，所以上一步的用例必须再结合等价类和边界值来得到最后的测试用例。
5. 设计完用例后，再使用一些其他的非 常规的用例设计方法来补充测试用例，如错误猜测法、输出域覆盖等，这样用例的设计就比较完整了。
第三步：画出逻辑思维导图，列出测试点，最后才编写测试用例
1.通过逻辑思维导图有层次的去分析测试点，按照一个清晰地层次流程进行梳理
2.测试点与测试点之间尽可能相互独立，一个测试点一条测试用例，避免交叉，作用是方便执行测试
3.用思维导图去列出测试点，可以方便记录和发散性的思维，不易错乱和遗忘测试点，也方便补充和改写
测试点列出来之后，开始执行测试用例的编写，编写时根据每个测试点需要思考：等价类划分法、边界值分析法、判定表、因果图、错误推测法、异常情况；从功能、性能、兼容、界面、安全、易用等多方面考虑；
标签：出牌,功能,测试点,套路,边界值,用例,测试用例,因果 From： https://blog.csdn.net/weixin_61837185/article/details/143511957