软件敏捷测试是否写测试用例(2)

　　软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

　　基于需求的测试用例设计

　　基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。

　　要把测试用例当成“活”的文档(Effective Software Testing ： 50 Specific Ways to Improve Your Testing – Elfriede Dustin)，因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

　　不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。

　　测试用例的评价

　　测试用例设计出来了，质量如何，如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

　　测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

　　除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。

　　因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。

　　测试用例数据生成的自动化

　　在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

　　很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

　　可利用一些工具，例如TConfig、PICT等来产生这些数据。

　　在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成(基于数据库的数据)、利用工具生成。

　　工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。

　　seanhe ： 先抛观点：需要写测试用例

　　先看测试用例是什么，也就是我们打算进行的测试执行的具体内容

　　测试用例可以分级别：如大纲型、方案型、具体操作数据型，但是根本一点就是要使测试过程有序的进行，尽量少做无必要的重复。

　　敏捷宣言是什么?拥抱变化

　　拥抱变化不代表着杂乱无章，代码即文档，不代表着代码没有注释，所有人都靠代码去看逻辑。

　　敏捷下测试是需要规划的，用例是需要书写的，但是书写的用例并不应该是我们通常意义上非常详尽的测试用例，而可能演变成单元测试框架或者功能自动测试框架，或者测试大纲。

　　总之，测试过程是需要规划的，在有效规划的前提下，尽量少的做无用工作

原文转自：http://www.uml.org.cn/Test/20112235.asp