如果你点开了链接，看到了本文章，我想你一定被文章的标题吸引了进来，或许你们会说又是标题党。标题党就标题党吧，你们肯定会看完的
刚开始接触测试的朋友，对测试用例（case)一定不陌生，它是测试的基本功。或许你已经被他磨平了棱角. 可能在几年之前，测试用例的编写和执行是许多IT公司招聘的必备条件之一, 可能不少朋友经常使用Excel编写case 殊不知，随着项目和时间的推移，Excel的文件大小会越来越大，打开速度也越来越慢。加上项目迭达速度的加快，Excel的效率已经明显不够。而且阅读起来也相对比较吃力，下文我将提到敏捷模式下的测试该如何进行。
一、开发和测试通性困扰？
面对复杂性（需求）：不断地修改计计划、不断地增加预算、低劣的产品质量……
面对复杂性（项目组成员）：经常加班到深夜、提交的产品不合格……
二、敏捷开发中的敏捷目的
敏捷宣言
个体和交互比过程和工具更有价值；能的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。
其核心是:以人为本,发挥人的主观能动性.
.
三、传统测试和敏捷测试区分：
3.1 传统的测试
1.守门员:质量保证者，阻止那些不可靠的、无效的、充满BUG的版本发布。
2.信息提供者:提供大量积极的、关于项目开发的状态的信息。告诉大家哪些功能正常工作、哪些功能不能正常工作、哪些BUG必须处理。
3.2、某大厂敏捷测试
测试和开发的角色界线变得模糊。有些人主要做测试工作，有些人主要做开发工作，但是在快速推进的过程中，所有人都会被号召起来测试或支持测试的工作。
更多职责:帮助开发人员理解需求,尽早确定测试规范。
四、敏捷测试用例的设计和评审要素
4.1、基于需求的用例场景来设计测试用例
1.基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
2.把测试用例当成"活"的文档,因为需求是"活"的、善变的。因此在设计测试用例方面应该符合敏捷的"及时响应变更比遵循计划更有价值"这一原则。
3.测试用例的设计不是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。
**4.2、敏捷测试用例设计原则
通常我们所看到的测试用例的设计是其中一项。
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像银行取款机系统中工作指令系统界面一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。
测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行"设计"，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，方便辅导后面的测试。
请看如下一个例子：
现在有一个 PC 客户端的命令行工具，这个工具可以接收三个命令行参数，其中，前两个是数字，最后一个是运算符，运算符只支持加减乘除四种，工具的功能就是把前两个数字使用运算符做下运算，然后输出运算结果。
我们来看下面的用例：
第一种风格，完全是遵循脑图的本来用法，属于层级递进式，前面层级都是后面层级的前置条件，需要把每一个分支的所有层级全部组合到一起，才是一条完整的用例
第二种风格，是按照要素归类的方式，每一层都是同一要素的不同类别，细化到的最后一级就是一条完整用例，前面的层级只是为了让分类清晰，为了把后面一大坨的最终用例更有条理的进行展示。
二种风格的用例各有优点
第一种风格适合做需求分析，通过思维的逻辑发散，把不同的路径通过脑图进行展现，从而激发更多的灵感。
但是测试用例是针对已经固定的需求和实现来做覆盖，它的前提是固定的，我们用脑图需要做得，就是把已有的需求和实现，转换为用例后，再通过合理的方式进行呈现。
我们需要的，一方面是合理的拆分，比如第二种格式里的第一层，我们按照输入、输入顺序和输出分成三块，后续继续按第一个参数、第二个参数和第三个参数这种方式进行更细的划分，所以条理性还是蛮清晰的。
这种格式的用例，在做用例评审时，可以很方便的和需求进行一一对应，能够很快的确认需求覆盖率。
另一方面，这种格式的用例，对于用例执行者也是比较友好的，执行者可以只关注用例的最后一个节点，按照指定策略执行就行了，在这种情况下第二种用例会比第一种用例效果更好，如果是第一种格式，需要每次都从头看到尾，很容易出错。不过笔者相对来说喜欢第一种，通过不同路径脑图进行展现，激发更多的灵感。
本文部分内容来自 51testing