QA测试用例规范

• 按版本大小灵活的设置用例

  目前针对测试用例，有不同的呈现方式，在网易使用最多的可能有以下2种：

  Xmind脑图的形式和TC形式；
• 大版本用例（业务逻辑复杂，测试点多）
  一般针对大型版本，比如校招专场重构等比较复杂的版本，我们建议2种结合着看，先用Xmind把所有的逻辑和测试点罗列，然后在tc上编写具体的用例，明确冒烟的范围等，但是该种方式有一个缺点是耗时较长，建议预留一定的编写用例的时间；一般我们在用例评审的时候更关注的是测试点的罗列；
• 中小版本用例（业务逻辑相对简单，测试点明朗）
  如果是中小型版本，建议可以采用TC或者Xmind的单独走的形式。
  特别是小版本迭代，可以直接用Xmind罗列所有的测试点，Xmind可以非常清晰的罗列出整个迭代产品逻辑，快速的产出；但是需要针对逻辑或者操作不太复杂的版本，如果开发在冒烟上仍然有困难，可以单独罗列冒烟用例，或者跟开发达成冒烟共识；
  还有一种是直接用TC，如果版本逻辑不复杂，写用例时间相对充裕，可以直接用该种方法，TC用例的产出需要对用例的完整性和可读性有较高的要求，形式上来说对开发冒烟和用例的执行是友好的，但是需要遵守一定规则。

 

• TC用例编写原则

  编写tc用例需要遵守如下原则：

• 系统性

  在写用例的时候，需要系统的考虑整个测试点的输出。无论从测试类型上以及业务功能输出上，都需要完整的考虑；参考系统测试设计思维建议

• 规范性

  tc测试用例包含有几个重要字段，比如用例的等级，标题，前置条件，操作步骤和预期结果，在写用例的时候，很多时候我们可能忽略了重要字段的填写，这样在给开发以及产品在用例的执行和参考上可能会带来一些困惑；针对重要字段，在tc上需要填写完整，确保用例的规范性；

• 可读性

  用例的可读性体现在文字输出上也体现在整个用例的设计结构上；举个例子，比如我们拿到一个迭代，如何非常清晰的合理的去对功能进行分层，可能直接影响到了用例整体结构的可读性上，所以前期拿到整体产品结构的时候，不要急于下笔，而要学会给用例或者脑图进行合理的分层；再比如说，在文字描述上，尽可能的要少出现一些模棱两可的语句，引起不必要的理解错误；我们写用例的话有两个重要的目的：

  1.梳理产品逻辑以及查看是否有需求漏洞
  2.要将产品逻辑和需求正确的输出给开发，达成三方共识。
  以上两点对用例的可读性提出了重要的要求。

• 可操作性

  举个例子，比如有个需求是登录失败，提示“登录失败”。那我们写用例的时候，是需要细化登录失败的场景（比如离职员工登录失败，用户密码错误等等），将每个用例细化成一个可以操作的指南，而不是在操作步骤上很笼统的概括“登录失败”。

以上是我们需要共同遵守和维护的用例规范，后续大家有好的建议可以继续补充~