关于敏捷开发中书写Story,AC,TC的一些见解

1、前言

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

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

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

2、Story

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

3、AC

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

4、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后跳转登录页
能够看到，好的测试用例必定是很是全面的，可以覆盖正常和异常的全部状况，经常使用的测试覆盖方法的覆盖率从弱到强依次有：语句覆盖，断定逻辑覆盖，条件逻辑覆盖，判断逻辑条件覆盖，条件组合覆盖，路径覆盖。