在敏捷开发中，测试是在整个生命周期中集成的；在整个开发过程中不断测试软件。
敏捷 development 没有单独的测试阶段。开发人员更多地参与测试，编写自动化的可重复单元测试以验证其代码。
除了面向质量更高的软件，这对于支持以下原则也很重要： 小型，迭代，增量版本.
使用自动可重复单元测试，可以将测试作为构建的一部分进行，以确保每次生成构建时所有功能均正常工作。而且构建应该定期（至少每天），因此集成也随您而行。
这些原则的目的是在整个开发过程中将软件保持在可发布的状态，以便可以在任何时候将其发布’s appropriate.
XP（极端编程）敏捷方法学走得更远。 XP推荐 测试驱动开发，在编写软件之前编写测试。
但是测试不应该’只能由开发人员在整个开发过程中完成。众所周知，专业测试人员仍然扮演着非常重要的角色 “developers can’t test for toffee!” 🙂
在敏捷开发中，测试人员的角色可能会发生很大变化，从而变得比单纯的测试更类似于质量保证。具有相当大的优势 从一开始就涉及测试人员.
这进一步加剧了 轻量级的需求方法 在敏捷开发中，与传统的规范和文档方法相比，强调对话和协作来澄清需求更为重要。
尽管可以在敏捷开发中更详细地阐明需求（只要它们是及时完成的，而不是全部在前期完成），但这很有可能导致一些歧义和/或某些情况下，并非全部团队成员对需求有相同的了解。
那么这对于敏捷测试人员意味着什么呢？测试人员转向敏捷开发方法的共同关注点–特别是那些来自更加正式的环境的人– is that they don’确切地知道他们’重新测试。他们不’没有详细的规范可以测试，那么他们如何进行测试呢？
即使在更传统的开发环境中，我也一直认为测试人员可以测试软件是否符合规格，但是产品的质量仍然可能很差，这可能是因为要求的说明不明确或者因为要求的要求写得很清楚，但并不是很好首先的想法！规格并不一定会使产品变好！
在敏捷开发中，’相信有时– maybe even often –仅当可以看到该软件正在运行时，这些情况才真正明显。通过交付 小增量发布 并且仅通过运行的软件来测量进度，酸测试就可以看到该软件，然后您才能真正判断出是否’s good quality.
敏捷 testing therefore calls for more judgement from a tester, the application of more expertise about what’s good and what’并非如此，因为您对商品的外观有所了解，因此变得更加灵活，并有信心做更多的工作。它’当然，不仅仅是遵循测试脚本的情况，还需要确保软件能够按照规范进行操作。
由于这些原因，敏捷测试不适合虚拟对象！
凯莉
有关敏捷原则的更多信息，请参见 10 Key Principles of 敏捷 Software Development.
