在敏捷测试中如何设计用例

1.测试用例的粒度
测试用例能够写得很简单，也能够写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出须要测试产品的哪些要素、须要达到的质量目标、须要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工做指令卡同样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操做步骤，指定测试的方法和工具等等。
测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思惟。
测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并无进行“设计”，只是把须要测试的功能模块记录下来而已，它的做用仅仅是在测试过程当中做为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程当中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导未来的测试。
大多数测试团队编写的测试用例的粒度介于二者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。咱们应该根据项目的实际状况、测试资源状况来决定设计出怎样粒度的测试用例。
软件是开发人员须要去努力实现敏捷化的对象，而测试用例则是测试人员须要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工做的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工做的。

2。 基于需求的测试用例设计
基于需求的用例场景来设计测试用例是最直接有效的方法，由于它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin），由于需求是“活”的、善变的。所以在设计测试用例方面应该把敏捷的“及时响应变动比遵循计划更有价值”这一原则。
不要认为测试用例的设计是一个阶段，测试用例的设计也须要迭代，在软件开发的不一样的阶段都要回来从新审视和完善测试用例。

3。 测试用例的评审
测试用例设计出来了，质量如何，如何提升测试用例设计的质量？就像软件产品须要经过各类手段来保证质量同样，测试用例的质量保证也须要综合使用各类手段和方法。
测试用例的检查能够有多种方式，可是最敏捷的应当属临时的同行评审。我认为同行评审，尤为是临时的同行评审，应该演变成相似结对编程同样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，经过讨论、协做来完成测试用例的设计，缘由很简单，测试用例的目的是尽量全面地覆盖需求，而测试人员总会存在某方面的思惟缺陷，一我的的思惟老是存在局限性。所以须要一块儿设计测试用例。
除了同行评审，还应该尽可能引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协做比合同谈判更有价值”这一原则。这里顾客的含义比较普遍，关键在于你怎样定义测试，若是测试是对产品的批判，则顾客应该指最终用户或顾客表明（在内部能够是市场人员或领域专家）；若是测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。
所以，参与到测试用例设计和评审中来的人除了测试人员本身和管理层外，还应该包括最终用户或顾客表明，还有开发人员。

4。 测试用例数据生成的自动化
在测试用例设计方面最有但愿实现自动化的，要当属测试用例数据生成的自动化了。由于设计方面的自动化在可想象的未来估计都很难实现，可是数据则不一样，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工做。
不少时候，测试用例的输入参数有不一样的类型、有不一样的取值范围，咱们须要获得测试用例的输入参数的不一样组合，以便全面地覆盖各类可能的取值状况。可是全覆盖的值域可能会难以想象地普遍，咱们又须要科学地筛选出一些有表明性的数据，以便减轻测试的工做量。在这方面可利用正交表设计数据或成对组合法设计数据。
可利用一些工具，例如TConfig、PICT等来产生这些数据。
在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用工具生成。
工具未必能生成全部知足要求的数据，可是倒是最快速的，编程能生成全部须要的数据，可是多是最复杂、最慢的方式。因此应该尽可能考虑使用一些简单实用的工具，例如DataFactory等