软件测试最全浅谈测试用例设计，2024年最新国内一线互联网公司面试题汇总

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

最近干的最多的事情就是设计测试用例、评审测试用例了，于是我不禁又想到了一个经典的问题：如何设计出优秀的测试用例？

可能有些童鞋看到这个问题会有些不以为然，这有什么好想的？干个测试谁还不会设计测试用例？

但是以我个人经历，以及一些接触来说，这个测试基本功确实不是那么容易做好的。可能很多人都觉得这个太基础了，往往就越容易忽略，而喜欢趋之若鹜的追求各种开发语言、自动化测试、测试平台这种上层建筑。

在我看来，业务测试是基础，其他的各种技术栈都是用来提效的手段，主次是分明的。另一方面来说，只有深入透彻得理解业务，才能更好的挖掘可以提效的点。

ok，言归正传，下面以我个人理解来浅谈如何设计测试用例，欢迎交流。

如何设计测试用例

一、研究需求文档

通常来说，正确的测试流程应该是：需求评审->测试用例设计->测试方案设计->测试环境\数据准备->提测后执行用例进行测试&查漏补缺，所以仔细的研究需求文档是重中之重。

一般来说需求文档里会定义产品的功能点，我们可以先通篇阅读对整个产品功能有个整体的印象，然后再开始从多个角度去深入产品细节中去，挖掘有价值的东西：

• 产品显性功能点：这个很简单，就是产品里明确定义出来的内容。
• 产品隐性功能点：产品没明确定义，但是会涉及到的功能点。
• 疑问点：需求定义不清楚的地方，或者涉及到一些测试范围的确认等等。

在需求文档输出之后，一般相关部门也会跟着输出其他辅助文档，比如：UE交互文档，UI设计页面，这些可以更好地帮助我们形象化产品，更好的去设计测试用例。

二、知晓开发设计

需求确定后，开发一般也会开始进行开发设计。通常会有一些架构设计、流程图、时序图、接口文档等内容输出，千万不要忽略这些文档，我觉得是非常有价值的。

记住：就算是做黑盒测试，也不要把被测系统真正的当做一个大黑盒。

必须对内部的架构有清楚的认识，数据背后传输的链路、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等。

拿最近在忙的车控业务来说吧，当你在手机APP上点击开车门后，这个指令如何达到车端，车端又是如何返回结果的。整个链路经过了哪些服务，中间件等你都要清楚才行，否则你就不能说是真正地熟悉这个业务。不是真正的熟悉业务，那么又如何真正设计出一份优秀的测试用例呢？

单单根据测试需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就很可能出现缺陷遗漏。

另外，我们可以去了解开发的实现思路，有能力的童鞋或许可以直接去看开发代码。看不了的也可以通过跟开发沟通了解实现过程，这些对我们都有很大的帮助。

有时候开发在给你讲述实现过程的时候，甚至就能自觉地发现一些问题。

但是，我们也不要完全根据开发的代码实现为依据去设计测试用例，还是根据原始需求来设计。

三、用例设计方法

了解的足够多了，开始要去设计测试用例了。我们是先写脑图，记录出思路和问题点，最后我们才会编写Excel版的测试用例。一般传统互联网可能也不要求写Excel了，这个看不同公司规定。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**