在敏捷项目的快速迭代中，QA要负责和推动多个质量保障活动比如需求分析、过程改进、风险管理、自动化测试开发维护和故事卡验收测试等，其中留给故事卡验收测试的时间是有限甚至是紧迫的，但是质量要求却一点也不能放松。那么如何在敏捷快速迭代交付压力下快速地进行故事卡验收测试呢？由于故事卡验收测试中的测试设计是最花精力和时间的，所以这个问题又可以进一步分解为下面两个子问题：
1.如何快速的进行测试设计？
2.如何设计出覆盖率高的测试用例？
1.在分析解答这两个问题之前，要强调一下进行测试设计的前提：
对产品(待测系统)业务逻辑的充分了解 - 可以帮助QA从用户角度进行场景设计以及避免遗漏任何改动相关的功能
●产品功能
●产品平台
●产品接口
●产品数据流
●产品操作
●产品用户体验
2.对产品(待测系统)实现技术的充分了解 - 可以帮助QA了解实现细节来减少测试范围
●产品类型
WEB
Mobile
桌面软件
●产品技术架构
●产品技术栈
如果上面的前提都不满足的话，是很难设计出好的测试用例的。
现在我们来仔细分析上面提出的两个问题
问题1： 如何快速的进行测试设计？
舍弃传统测试设计方法，避免过渡设计，采用思维导图等方式进行粗粒度的快速设计
在传统的测试设计方法中，QA需要依据需求文档，对照着功能描述，进行详细的用例设计和数据设计，然后把测试用例录入到电子表格或是一些测试用例管理工具中比如Testlink，QC等。类似这样的工具都要求测试用例具有非常详细的信息比如测试环境、测试步骤、测试数据测试期待结果，于是QA会花大量的时间在测试用例的设计和编写录入上。
在敏捷项目中，我们提倡采用探索式测试来进行手工验收测试。探索式测试是一种基于反馈的，边设计边执行的测试风格，不会要求详细的脚本化的测试用例，只需要选定某种特殊的测试方法在产品上进行深入的探索。所以QA们不会使用具体的测试用例管理工具去编写详细的测试用例，而是使用简单的工具(例如思维导图)记录简单的测试想法/测试功能点，在实际的测试执行过程中，会针对某一个测试想法进行探索式测试。 这些测试想法/测试功能点只需要描述清楚测试的功能点是什么，基本的用户场景和数据是什么即可，通常来说一句话就能覆盖。此外，使用Gherkin语言描述（前提条件"GIVEN",发生什么操作"WHEN"和结果"THEN"）也是一种方法。
比如对于To Do List这样的一个应用，QA不需要去设计编写繁琐的test cases/steps,只需要写出类似下面的测试想法
●测试想法1： 加入一个task，然后完成这个task
●测试想法2： 加入多个tasks，然后一次性清空全部tasks
●测试想法3： 加入多个tasks，然后删除某几个tasks
●测试想法4： 使用filter过滤tasks list
在实际测试执行过程中在使用探索式测试(漫游测试)，比如拿上面的测试想法来举例
●测试想法1
超模漫游： 测试系统界面
反叛漫游： 系统会不会接受错误的task描述，比如为空的task，全是空格的task
沙发土豆漫游： 有没有默认值？placeholder？
●测试想法2
找茬漫游： 能不能清空后再次在无task状态下清空
●测试想法3
快递漫游： 删除后tasks只是从前端删除还是从后端删除？涉及数据库不？task描述长度最长是多少？
●测试想法4
反叛漫游： 当没有适合条件的task的时候，filter之后的结果是什么，界面如何显示
可见采用测试想法思维导图和探索式测试将会有效的减少测试设计和执行时间。当然测试想法的记录形式不局限于思维导图，使用简单的word文档进行文本描述，使用excel文档进行表格描述都是可行的，只要符合"KISS"原则即可。具体怎么设计测试想法和应用探索式测试，会在稍后提到。
"Shoulder Check"可以帮助QA确认代码改动影响范围从而变动测试范围
在敏捷项目中，当故事卡需要从开发状态转入测试状态时，开发和测试会在一起进行"Shoulder Check"。这个活动会让开发和测试一起“玩”一下刚开发完的新功能(或是bug fix)。开发会给QA展示这个故事卡所有的代码改动和通过验收条件来展示最终效果，与此同时QA也会提出自己的任何疑问。通过回顾代码改动，QA可以评估和与开发确认代码的影响范围从而变动测试的范围，一般来讲，基本都能够减少测试范围从而避免没必要的手工回归测试。
问题2： 如何设计出覆盖率高的测试用例？
由于现在产品业务逻辑日益复杂，迭代交付速度日益加快，按照规格需求来写详细的测试用例，并加以等价类、边界值、因果图和判定表等测试用例设计方法已经不能满足当前对测试“快又准”要求。快速地进行粗粒度的测试设计并不等于忽略掉很多测试场景和数据，QA需要的是一种测试设计思路来指导具有高覆盖率的测试用例设计。
下面主要介绍我在日常工作中如何进行故事卡验收测试的设计和执行。在故事卡已经满足提测标准的前提下，整个测试设计和执行一共分为五轮：
1.使用RST(Rapid Software Testing)进行基于风险或缺陷模型的测试，目的是快速发现一些典型缺陷
2.使用HTSM中的Test Techniques和软件属性分类创建测试，目的是归纳出适用于故事卡的测试维度和覆盖到最基本的测试点
3.使用测试建模方法创建指导测试设计的模型，目的是通过建立好的产品模型给每个测试维度加上更多丰富的测试想法和测试数据
4.使用探索式测试之漫游测试来扩展每个测试想法，目的是通过不同的漫游测试方法给每个测试维度加上更多丰富的测试想法和测试数据，也有可能会增加新的测试维度
5.使用探索式测试执行各个测试想法，目的是在执行测试的同时扩展思路，创造更多的测试路径，也会基于系统执行结果的反馈，不断优化测试想法和测试数据
接下来我们深入的探讨下每轮测试实现的方式
第一轮： 基于RST的测试设计和执行
快速测试RST(Rapid Software Testing)是技能和思维模式，通过一种快速，低投入，可行和可靠的方式来做更加有效的测试。具体做法是针对某些常见的风险或缺陷模型进行专项深度测试。RST能够帮助QA在短时间内发现一些特定类型的缺陷，这些错误可以是需求设计上的业务逻辑错误，也可以是平时测试中经常遇到的缺陷。这一轮也类似于传统测试用例方法中的“错误推测”方法，只不过不是基于经验和直觉，而是依靠的总结归纳的“缺陷模型”。
因为RST只是针对一些特定的软件缺陷进行，所以这一轮测试不会进行太多的测试设计也不要求QA具备丰富的产品知识。
典型的测试方法有
QA在这一轮中通过已有的产品缺陷模型和寻找故事卡改动可能会引起的缺陷来进行测试，这样会快速的找到一些典型的缺陷。如果还没有产品缺陷模型，那就赶快归纳总结出产品发生过的缺陷和发现手段。
第二轮： 基于HTSM和软件属性分类的测试设计
HTSM中提供了九种测试技术，这些测试技术用来启发创建测试，我们就会使用这九种测试技术作为故事卡验收测试的基本测试维度。“通用的测试技术”是指技术是简单明了的且可以脱离复杂的上下文普遍适用的，很多特殊的技术都可以基于下面九种测试技术中一种或是多种，通过组合通用技术和本模型中其他的元素，我们能够得到很多特殊的测试技术。下面列出了这九种通用的测试技术：
●功能测试 Function Testing
描述：测试软件的能力
典型思路
●辨识产品能做的事情
●决定你怎么知道产品能工作
●一次只测试一个功能
●测试每个功能只做了它应该做的事情而没有做它不应该做的事情
域测试 Domain Testing
描述： 专注于测试软件所处理的数据
典型思路
●找到产品处理的所有数据。看输出也看输入
●决定哪些特殊的数据需要测试。考虑边界值、典型值、无效值和最佳代表数据
●考虑数据的组合
数据初始化
数据默认值
数据完整性，在不同模块之间的赋值和调用
●压力测试 Stress Testing
描述：用极限行为和数据压迫软件
典型思路
●寻找极易遭受挑战性数据和被限制的资源破坏的子系统或是功能
●选择或创建有挑战性的数据或者资源限制条件进行测试。比如庞大或是复杂的数据结构，高负荷，持久测试，大规模测试用例和低内存条件
●流测试 Flow Testing
描述： 测试软件的操作顺序
典型思路
●测试多个活动串联以后端到端的流程。比如在状态模型中开展漫游测试
●不要在活动中重设系统
●改变时间线和顺序，试试并发
●情景测试 Scenario Testing
描述： 用有说服力的场景来测试软件
典型思路
●开始时思考关于产品的一切
●设计测试来覆盖与产品有意义的和复杂的互动
●一个好的场景测试是一个引人注目的故事，这个故事涉及谁做了什么影响产品的事情
●声明测试 Claims Testing
描述： 测试所有产品资料 Challenge every claim
典型思路
●调查所有的声明，澄清所有的声明
●鉴别所有关于产品的参考资料
●测试关于产品声明的精准性
●用户测试 User Testing
描述：从用户角度测试 Involve the users
典型思路
●识别用户的角色分类
●识别每一类的用户分别会做什么事情，怎么做以及带来的用户价值是什么
●获取真实的用户数据来进行测试
●否则，系统性地模拟一个用户(这里有一个坑，就是你很容易自以为你就是真实的用户，而不是你并不是)
●强有力的用户测试通常都会涉及多个不同类别的用户和不同的角色，并不是某一个
●风险测试 Risk Testing
描述：猜想一个问题，然后去尝试发现它 Imagine a problem, then look for it
典型思路
●这个产品可能会有什么样的问题
●哪些问题最有严重或是最有可能性发生？先聚焦在这些问题
●如果这些问题有可能发生，应该怎么去发现他们？
●列出一个包含一些有趣问题的列表，然后设计测试去揭露他们
●这个测试能帮助咨询专家，设计文档，历史缺陷报告或者启发风险
●自动化检查 Automatic Checking
描述：自动检测大量不同的结果 Check a million different facts
典型思路
●寻求或开发工具来做大量操作和检查大量结果
●考虑能部分自动化测试覆盖率的工具
●考虑能部分自动化测试先知的工具
●考虑能够自动化感知变更的检测器
●考虑能够自动化产生数据的创造器
●考虑能够帮助人工测试的工具
此外我们也可以从下面软件属性分类来思考我们的测试用例设计，这些属性分类也会启发测试维度的思考：
●结构 --> 自动化检查 Automatic Checking
代码路径
●功能 --> 功能测试 Function Testing
产品功能正常
产品异常处理
产品符合需求
后台功能正常
●业务价值 --> 情景测试 Scenario Testing, 用户测试 User Testing
给客户带来的价值
依赖方
影响其他系统
●平台 - 执行环境
测试产品依赖的环境
OS
不同配置项
网络
硬件资源使用情况
●数据 --> 域测试 Domain Testing
测试不同的数据类型
有效无效
大规模
输入输出
●接口 --> 情景测试 Scenario Testing, 用户测试 User Testing
交互方式
人工界面
自动程序
●状态 --> 流测试 Flow Testing
不同状态
持久
一致
可见HTSM还是覆盖了大部分上面的软件属性，需要注意的是"平台"所对应的兼容性测试并没有在HTSM中列出来，而QA需要测试软件在不同执行环境下的表现。
QA在这一轮需要探索和决定上面测试技术中哪些适用于当前的故事卡(产品功能)，把适合的测试技术与故事卡的变动联系起来，确定了针对本次改动的大致测试范围和基本测试点。比如说"Domain Testing"域测试是专注于测试数据的测试技术，基本适用于每一个故事卡，针对域测试，QA会产生类似下面的测试想法：
●该变动影响和涉及的测试数据有哪些
数据作为输入变量
数据作为输出变量
●测试数据有什么类型
有哪些无效的数据？如何被系统识别和处理
有哪些有效的数据？不同的有效数据类型如何被系统接收和处理
最重要的测试数据是哪些？考虑边界值、典型值、无效值和最佳代表数据
●测试数据如何产生
用户产生数据的方式有哪些
●测试数据如何被系统处理
大规模的数据处理
同一数据在不同模块之间的处理
●测试数据会在哪些地方以什么方式呈现给用户
上面提到这九种技术是非常通用的，如果发现故事卡有需求变动不能被这九种技术覆盖掉，那么QA需要考虑自己“创造”一种测试技术来覆盖需求。此轮测试相比于RST，这一轮测试会涉及更多业务领域知识，最基本的业务功能都会在此轮测试中被覆盖到。
基于测试建模的测试设计
测试建模是以指导测试设计为目的建立产品模型，此产品模型就是测试建模的产出。这个产品模型包含着大量测试需要关注的信息。
QA常使用的测试建模手段有哪些呢？
1.组合测试
组合测试(combinatorial testing)是一种测试用例生成方法。测试人员将被测试对象抽象成一个受到多个变量影响的系统，其中每个变量的取值是离散且有限的。
两因素组合测试生成的测试集可以覆盖任意两个变量的所有取值组合。在理论上，该测试用例集可以暴露所有的两个变量共同作用而引发的缺陷
多因素组合测试生成的测试集可以覆盖任意n个变量的所有取值组合。在理论上，该测试用例集可以发现所有由n个因素共同作用引发的缺陷
常用工具：PICT生成满足特定组合覆盖标准的组合测试用例集
更多工具集
2.输入输出模型/IO模型
输入输出模型是最基本的测试模型，这个模型列举了被测对象所有的输入变量和输出变量，然后定义了输入输出的关系。这个模型经常被用来设计数据和流程相关的测试。
3.状态机模型
分析识别出被测对象所有的状态以及状态之间进行变迁的触发事件，这样我们可以得到一个状态图
通过分析状态图，QA可以设计测试用例覆盖所有状态、所有状态变迁和所有触发事件
也可以把状态图转变为状态表
4.功能列表
用列表的方式列出产品的主要功能和子功能
QA在这一轮测试中需要观察上轮中得到的测试想法可否使用测试建模技术来细化；如果可以细化，那QA可以得到更多的测试想法和更加精确的测试数据。
基于探索式测试之漫游测试的测试设计
探索式测试可以用于帮我们在测试设计中开发出测试用例，它也可以帮助我们发现在规范说明书中可能漏掉的用户场景，还可以组织测试人员的测试思路.探索式测试之漫游测试是在特定主题指导下对产品进行探索的一组测试方法，这里列出一些最常见的方法。因为这一轮测试是基于上几轮测试的结果，所以我们使用HTSM的九种技术来展示漫游测试方法可以发挥巨大作用的地方。
功能测试 Function Testing
卖点漫游：测试人员测试软件的重点功能
配角漫游： 测试人员重点测试软件的非主要功能
超模漫游： 测试人员重点测试软件界面的美观和易用
破坏者漫游：测试人员实施破坏性的测试，测试软件失败处理能力和失败恢复能力
域测试 Domain Testing
快递漫游：测试人员跟随一组数据走遍软件的功能
沙发土豆漫游：测试人员测试数据默认值和空值
收藏家漫游： 测试人员通过测试尽可能多的去收集软件的输出，通过输出变量的多样性来推断输入变量的多样性以及触发该输出的路径
流测试 Flow Testing
地标漫游： 测试人员选择一组相关的功能，依次测试，直到测试了所有功能
出租车漫游： 测试人员发现并测试触发某一功能的所有途径，或完成某项任务的所有方式
歧路漫游：测试人员以错误的方式或顺序来操作软件
情景测试 Scenario Testing
傲慢美佬漫游：测试人员用一些不合“正常”逻辑的情景来测试软件
混票漫游：测试人员跟随一个测试情景访问某个功能，然后再利用另一个测试情景去测试其他功能
用户测试 User Testing
知识分子漫游： 测试人员运用业务和技术知识向软件提出极具挑战的问题
风险测试 Risk Testing
找茬漫游： 测试人员在测试软件时，以找茬的心态去挑战软件。他提出各种问题去质疑软件
极限值漫游：测试人员输入极限值或制造软件的极限状态来发现软件的错误
QA在这一轮测试中需要利用漫游测试方法带来的启发在每个测试分类中创建更多的测试点和测试数据, 这一轮测试设计中，更多的异常测试用例会被挖掘，测试设计也基本完成了。
基于探索式测试的测试执行
接下来我们需要“按部就班”的执行设计好的测试点，不会像执行固定的脚本一样去执行测试用例，而是还会在执行的过程加入一些变化。
在执行某个测试点时，我们可以
根据实时测试结果反馈
发现是否遗漏了一些需求
挖掘新的测试数据
决定是否创建新的测试点或是删除无效测试点
变动某个测试步骤来增加场景的多样性
在遇到有业务逻辑分歧的时候，可以尝试先往不同路径测试，最终再回到主路径
所以整个测试执行是基于测试结果反馈的，QA既测试了之前设计好的用例，又在测试扩展测试了其它没有提前设计的用例。
总结
通过改变测试设计方法和精准定位代码变动影响范围，QA可以减少大量测试设计和执行时间。通过五轮不同目的的测试，QA考虑到了一次故事卡变动影响的方方面面，每一轮测试有其独特的使命，提高了测试用例覆盖率，避免了测试冗余。只有把所有可行的测试方法都组合起来使用，才能设计出高覆盖率的测试用例。
