一、前言

在如今的一些中大型软件项目中，许多开发团队都有自己的一套需求分析及测试步骤与方案。而在敏捷开发中也有相应的需求分析及测试方法与过程。比如：Story（用户故事）,AC（验收标准）,TC（测试案例） 这些就是在敏捷开发中常用的一些概念。

在敏捷开发团队中，他们的需求及测试文档大概会是下面这样：

正如上图所示：一个 Feature（功能）会由几个Story组成。若Story过大，还可能会拆分成子Story。若Story描述的比较具体，则可以直接拆分出几个AC。每个AC又可以拆分出几个TC来作为实际编码与测试的准则。不论是Story,AC还是TC，都应尽可能满足这些特点：完整性，正确性，可行性，可验证性，无歧义性，一致性，必要性，划分优先级。

二、Story

作为用户故事：其描述的是用户的需求，是功能的简短描述，细节应该在客户团队和开发团队的讨论中产出。也就是说，用户故事不是确定不变的详细设计说明书。
坏例子：
Story:当用户进入首页，他应该看到推荐职位，以便他快速找到想要的工作。
好例子：
Story:作为一名首次使用求职软件用户，我想要在明显的地方看到推荐职位，来帮助我快速找到合适的工作。
像这样站在需求者的角度来思考问题，才能够挖掘出真正有价值的需求。以便设计开发出符合需求的功能。

三、AC

作为验收标准：不是大而全的详细设计，AC只是故事完成的必要的条件。AC的内容也只是关于关键或重要事情的简短描述，是客户或PO验收功能的主要依据。
坏例子：
given:用户已挂机
when:用户再次登录
then:提示“您的账号已被封停”
好例子：
given:用户挂机超过5分钟
when:用户再次登录该账号
then:在登录界面弹出“您的账号已被封停，15天后解封”提示弹窗
AC应当具有完整性（完整列出Story的验收标准），正确性（应符合自然逻辑），可验证性（可以很方便的进行验证），无歧义性（所使用的描述语言应尽量严谨，规范，通用，标准，专业），一致性（AC或Story之间不能有逻辑冲突）。

四、TC

作为测试案例：也是User story的一个重要补充，是AC的具体实现。TC应该比AC更加详细，不止包括AC的所有内容，还应包括很多异常测试用例，以确保系统对异常能正确的处理。
例如： 注册账号时密码应该由6到18位数字和字母组成。
坏例子：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："abc123"
then:弹出“注册成功”提示框，并在3S后跳转登陆页
好例子：
测试用例01（长度和组合条件都不满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："12345"
then:弹出“密码必须由6-18位字母和数字组成”提示框
测试用例02（长度和组合条件都不满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："abcde"
then:弹出“密码必须由6-18位字母和数字组成”提示框
测试用例03（长度不满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："123ab"
then:弹出“密码必须由6-18位字母和数字组成”提示框
测试用例04（长度不满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："123456789abcdefghij"
then:弹出“密码必须由6-18位字母和数字组成”提示框
测试用例05（组合条件不满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："123456"
then:弹出“密码必须由6-18位字母和数字组成”提示框
测试用例06（组合条件不满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："abcdef"
then:弹出“密码必须由6-18位字母和数字组成”提示框
测试用例07（都满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："abc123"
then:弹出“注册成功”提示框，并在3S后跳转登陆页
测试用例08（都满足）：
given:用户已在账号输入框输入账号："test123"
when:用户在密码输入框输入："abc1234"
then:弹出“注册成功”提示框，并在3S后跳转登陆页
可以看到，好的测试用例一定是非常全面的，能够覆盖正常和异常的所有情况，常用的测试覆盖方法的覆盖率从弱到强依次有：语句覆盖，判定逻辑覆盖，条件逻辑覆盖，判断逻辑条件覆盖，条件组合覆盖，路径覆盖。