测试用例编写注意事项
测试用例设计的粒度需要考虑几方面的因素：1、复用率：如果随着产品不停得升级，需要设计的详细些，追求一劳永逸；仅使用一两次，则没有必要设计的过于详细；
2、项目进展：项目时间如果允许可以设计的详细些，反之则能执行即可；
3、使用对象：测试用例如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的详细些。
我们不太可能在一个测试用例包含全部测试需求，因为众多的功能以及不同的路径组合将使这样一个测试用例步骤繁多，操作复杂，完全不具有可操作性。
当然，这也并不是要您走向另一个极端，为需求中定义的每个特性或功能都提供一个甚至多个测试用例。这里的关键，是要寻找一个合适的度。推荐的方法是：关注有效功能。
区分有效功能的关键有2点：
1、这个功能是可以还原到用户原始的手工业务流程中去的。
2、这个功能是否可以标志着用户实际业务的一个阶段性结束？并且这项业务完成之后，被完成的业务实体是否可以交付给其他用户或业务以供完成下面的工作？
功能测试中要保证测试的覆盖率，首先要做好测试需求分析，测试需求获取方法包含了2种，显式需求及隐式需求。
做好需求分析，及时维护测试需求文档。将不同的需求来源划分成一个个需求点，针对每一点进行测试分析，界定测试范围，利用各种测试设计的方法产生功能测试节点。
用例设计阶段，首先要保证产品或项目在主要功能测试用例完全覆盖的情况下去对细节进行测试用例设计，可以运用多种测试用例设计方法来减少功能遗漏。
强化测试用例评审阶段的作用，以测试用例评审会议来检验功能是否覆盖完全，评审会成员需要有设计，开发，测试及专家组成员。
测试全面不等于全面测试，不要过分的追求高测试覆盖率，要结合实际情况去考虑，有些情况下，即使测试不全面，哪怕功能还有BUG也需要上线，这是测试人员也无可奈何的事情，因为毕竟要考虑到成本等一些其他的问题。
1、测试需求阶段是没有办法进行实质性的测试工作的，在测试需求阶段应该进行的测试需求分析。 明确测试需求，并分析出隐式需求，然后制定测试策略，初步制定测试时间，测试工时，测试环境，测试中是否需要使用工具（如果需要，就要确定选择哪款工具，或哪几款工具），并将可能会影响测试工作进行的风险进行预估，这些实际上就是测试计划的部分内容，而测试需求就是制定测试计划的基础和重点。
2、如果是一个已有产品的升级版本，那么可以通过已确定的需求说明书及开发人员对功能的描述，过往的测试用例来进行功能测试用例的编写；如果是一个全新的软件那么可以通过需求说明书，用户手册说明书，开发对产品的可实现功能描述及经验和业务知识来进行功能测试用例设计，但是在脱离了需求文档的情况下这些用例可用度非常低。 嗯，受教了 概念的，还是有些抽象 学习了
页:
[1]
