description
Test Scenario Design Model

测试场景设计模型

测试最有效的是基于场景测试，由于场景测试需要功能齐备才能进行，这个模型有效的解决了场景测试需要等待到最后才能进行的问题；通过类似和开发一样的Story分析和提炼，得到与场景相关的各个小的场景，然后独立的对其进行测试；

但是这个方法只给出了模型，没有给出后面的测试用例具体如何展开，有点半拉子；

本质上和使用实例化需求分析中那种把大的Story拆分为小的Feature过程没有本质区别；

传统的测试不是以用户为中心；以往的测试设计方法，越来越不能满足当前敏捷开发的需要；

传统的以用户为中心的场景测试用例最大的毛病在于要等待系统开发完毕之后才能测试；

为了解决这个问题，他采用如下方法建立测试场景设计模型：

讲Story切分为Transaction，每个Transaction用Gherkin语言描述；
这个类似于把一个大的Use Case分成小的Use Case，一般涉及一个组件；
识别UI/UX，涉及Gherkin描述中的一些用户行为相关UI参数；
如，按钮，页面等；
识别Data，涉及Gherkin描述中的一些用户行为相关的数据，要记录数据的语法和语义；
所谓语法，就是数据的语法、结构；如，账号名的一些字符包含、长度要求等；
所谓语义，就是数据之间的关系；如，正确的账号和密码才能成功登录；
分析数据之间关系的时候，只需要分析数据有效、无效等价类之间的关系，不用过度展开；
识别Intergration，涉及哪些组件完成当前的Transaction，即识别上下游的依赖;
识别Risk，根据失效影响分析风险大小；

作者认为组合测试条件千千万，他并不尝试覆盖所有的测试参数组合，他只用有效和无效等价类对测试参数进行划分，然后通过列举一些、而不是全部的有效类、等价类进行测试用例设计；

因此，他设计测试用例时，更多的是导出Test Condition，并选取一些典型参数生成用例，而不是试图搞一个大而全的用例出来；

传统的设计方法，强调测试覆盖率，他的这个方法强调测试缺陷移除率和缺陷检测率；

Provide feedback