话说作为一个测试人员，测试用例的设计与编写是一项必须掌握的能力，若想写出有效的测试用例则需要多方面的技术知识。平时工作遇到功能测试较多，但过多是敏捷型的，涉及少。我认为认真仔细的写好测试用例是有必要的。

　　就如何设计测试用例需从如下几个因素出发：

　　1、复用率，随产品不断升级，需要涉及更详细些，可一劳永逸；如仅使用一两次，没必要写的太仔细。

　　2、项目进度，时间允许可详尽，时间紧可执行即可。

　　3、使用对象，如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的更加详细些。

　　4、关注有效功能，大多数情况：我们不太可能在一个测试用例包含全部测试要求，因为众多的功能及不同的路径组合将使测试用例步骤繁多，操作复杂，或者完全不具可操作性。说这些并不是意味为需求中定义的每个功能和特性，编写一个或多个测试用例，只要把握好适度即可。

　　如何区分有效功能：

　　第一点，这个功能是可以还原到用户原始的手工业务流程中去的。

　　第二点，这个功能是否标志用户实际业务的一个阶段性结束，并且这项业务完成后，被完成的业务实体是否可以交付给其他用户或业务供完成下面的工作？

　　5、做好需求分析，这里的需求包含显示和隐式需求，根据需求文档将不同需求来源划分成一个个需求点，针对每小点进行测试分析，界定测试范围，并运用多种测试用例设计方法产生测试节点。

　　6、注重测试用例评审，评审会以检验功能是否覆盖完全，评审会成员有设计，开发，测试及专家成员。

　　如果测试用例编写不规范，后果不堪设想。

　　请参见：http://www.51testing.com/html/03/n-16903.html

　　啰嗦下：测试全面不等于全面测试，要结合实际进行覆盖而不是盲目的追求全面覆盖。有时候测试不全面但在不影响主流程的情况下，存在功能Bug也需要上线，这是测试人员无法掌控的。在成本面前测试人员总是无可奈何。。。

　　专家给的建议：在测试需求阶段进行测试需求分析（如果是已有的升级版本，可通过已确定的需求说明书及开发人员的功能描述，对过往的测试用例进行补足编写；如果是一个全新的需求可通过PRD，开发对产品的可实现功能描述及经验，相关业务知识进行用例设计），明确需求并找出隐式需求，随后制定测试策略。同时进行测试时间的估算和风险的预估，初步制定测试时间，测试工时，测试环境以及测试中可能需要的测试工具（如果有，可考虑）。