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