发帖
雷达卡
在敏捷实践中，“测试”毫无疑问地是一个经常谈论的话题。然而，它也是经常被过分谈论的术语，所以，当我们想讨论“测试的种类”时，应该先了解一些细节。
在敏捷开发中，测试以很多不同的方法扮演着同样的角色，而且不同的测试种类扮演着不同的角色。为了说明这些角色，你需要敏捷开发中一些基本思想作为基础。
如果你需要更多敏捷开发的信息，你可以访问
为什么要测试？
测试是得到反馈的一个重要方法。测试对于确保代码做了它应该做的事是非常有用的，对于代码的修改反过来可以影响功能也是很有用的。测试也是开发人员知道什么时候算完成他所开发的一个特性。现在，我们有两个原则作为判断一个特性是否被描述的足够详细：
1、开发人员可以提供一个相当准确的估计
2、测试人员可以写出一个接受性测试
不但测试种类有所不同，产生测试的方法也不尽相同。
我们如何测试？
测试包括手工测试和自动化测试。关键要注意在开发过程中，每种技术所扮演的不同角色。尽管我们需要尽可能多地进行自动化测试，但并不意味着所有的手工测试就不再需要啦。因为即使软件通过了所有的自动化测试，它在用户刚开始使用时也可能出现错误。
根据敏捷原则（做聪明的事），要确保能用自动化测试的事情决不要用手工测试。同时要做到适合手工测试的内容决不要花高昂地成本做成自动化测试。另外，不要因为某方面不能自动化测试而不做测试。
你应该做哪些种类的测试？
我想，没有“放之四海皆准”的策略。象敏捷开发中的每个事情一样，测试也需要你用你的大脑！下面有一些测试的种类及它们在开发过程中扮演的角色，或者说是目的。
单元测试：一般是开发者在编写他们被分派的特性时建立的。目的是确保代码所完成的功能在任何变化时都是正确的。另外，单元测试的一个附加作用就是当作软件API的使用说明文档。
验收测试(或叫接受性测试)：用于确保具体的功能是否正常工作。特别地，验收测试是一个具体的客户场景，用于完成用户所期望的功能。
ＵＩ测试：一般包括一些页面流，提供已知输入并把得到的结果和期望的结果进行对照。有些ＵＩ测试是使用bitmap进行对比。
可用性测试：这可以说是另一个领域的测试，它常常需要人的参与！在这里不多陈述，但是可用性经常是做为“make-or-break”的验收条件。某些项目从自动化测试中得到了收益，这些自动化测试确保软件遵守了ＵＩ标准。
性能测试：对于很多应用来说，运行一套测试来确保多个非功能度量要求得到满足是非常关键的。如果你的应用需要很严格的性能度量要求，在初始的架构和设计阶段，你需要跟踪这些要求是否满足。在构建整个应用时，你要确保性能要求得到满足。通常，性能测试至少要在每个主构建时自动运行－也许你每星期五做一次或每次迭代做一次。
什么样的测试技术是有用的？
虽然自动化是一个关键，但它并不是唯一的一种测试！我更愿意使用手工与自动化相结合的测试。你可以自己定义自动化测试的频率的执行时间。 下面是几种不同类型的测试以及在敏捷项目中扮演的角色！
“Smoke” 测试：不可缺少的一小撮关键测试，用于确保基本的构建功能正常运行。其中一部分是自动化的，还有一些是手工的。运行“smoke”测试很容易的话，可以帮助开发团队了解每日构建是有用的。当需要一些手工测试时(一般来说成本比较昂贵)，应该把它放在主构建中，也就是有质量保证人员参与的较为正试的构建。要避免做代价很大而没有太多意义的“bad”构建。
Test Harness: 对于粗粒度的功能（特别是对于验收测试和主要的系统场景）进行制度化地测试来说，TestHarness常常是一个好方法。将一个TestHarness 作为新的功能加入到原有的测试套装中是很容易的。您可根据捕获的用户输入、正确的输出建立一个TestHarness并使其自动化。每个捕获的测试用例都被加入到测试数据库中，并与后面的回归测试相配合。
京公网安备 11010802022788号
