测试用例的设计是整个测试工作中最重要的一环，也是整个测试流程中难度最大的部分。测试用例是指导整个app的测试工作的灵魂，以下则简单的介绍测试用例在项目过程中的几个比较典型的作用。
1.便于理清测试思路，确保需覆盖测试的功能点无遗漏
测试一个app所涉及的功能测试点视功能的复杂程度而定，功能越多、功能模块间的交互越复杂， 则相应的测试点越多，若没有根据测试用例单凭记忆来执行测试工作，想到什么功能点就测什么功能点则很容易出现漏测的情况。
2.便于测试工作量的评估
测试工作量的评估其中的一个重要的参考依据就是测试用例的数量。如果在评估工作量时没有任何依据就拍拍脑袋给出大概工作量，不仅会让项目组成员的存疑还可能会被自己带坑。一般而言，一人一天可执行大约100条测试用例，根据测试用例的数量便可大致评估出所需的测试执行时间，这样评估出来的工作量准确性高且有理有据，也比较能让项目组的人接受。
3.便于提前准备测试数据
在设计测试用例时便能提前了解到需要用到哪些测试数据，相关的测试数据就可以在测试任务执行之前先准备好，测试环境因数据问题无法验证到的功能也可以被提早发现，有风险也可以提早暴露提早规避。在准备好测试数据后，到提测之时便可以有条不紊的开始测试实施。
4.便于把控测试工作进度
由于测试用例是基于产品功能设计出来的，故测试用例的执行率可以大致的表示当前进度对需求的覆盖率，在每天统计测试进度时可以根据测试用例的执行率来评估测试进度是否正常，是否有由于环境问题或者bug未修复而受阻无法执行的用例，如果有的话可以根据受阻用例的占比情况评估是否会对项目的进展有影响，并根据实际情况确定是否需要通报风险。
5.便于回归测试
回归测试通常指在RD修复bug之后，QA对bug修复情况进行验证，同时测试是否有引入新的bug。回归测试除了验证原来的bug已修复之外，还需要验证RD在修改老代码后有没引入其他新的问题，这时候回归全部用例的话显然工程量大，效率低，绝对不是一个行之有效的方法。这种情况下就得先和RD确认沟通清楚代码改动后涉及到的的影响面，据此确定回归范围，筛选出相关的用例作为回归用例进行回归测试。
6.把握app迭代过程中的测试侧重点
当今互联网行业，敏捷开发已被广为推崇，而敏捷其中的一个特点就是快速迭代快速交付，因此QA也需要把握好测试的侧重点，必能实现敏捷要求“更快更好”。如何实现“更快更好”呢？首先必须维护好设计测试用例，在版本迭代过程中迭代用例，标明各个用例所隶属的需求版本，在测试执行过程中着重执行新需求相关的用例，回归原功能中的重要功能和原来容易出错的功能，分清主次执行测试任务，才能实现测试的“更快更好”。
7.便于测试工作的组织，提高测试效率，较低测试交接成本
通常由于种种原因，最初参与需求评审的测试人员可能最终不是真正的测试任务执行者，测试执行者可以通过PRD文档和交互文档了解需求，另外如果测试用例写得足够清晰明了，足够全面详实，测试执行者一定程度上也可以通过测试用例来了解功能需求，能更快上手执行测试任务。
由此可见，测试用例在测试过程中占据的地位是多么不容小觑，故要做好测试工作的前提，还是要踏踏实实的把测试用例设计这一环做好。