如果可以的话，尝试并推广使用持续集成的测试优先开发（又名 TDD、BDD、ATDD、示例规范）的想法（经常提交到诸如来自 Thoughtworks 的 Hudson 或 GO 之类的管道，该管道持续运行自动检查以查看是否在最近一次提交后，它们中的任何一个都已损坏）

在开发人员编写代码之前，他们编写了一个自动化测试（检查），由于没有执行代码而失败。然后他们编写代码以使自动检查通过。最后他们整理代码（重构）。

这将导致开发人员在编写代码时主要测试（检查）代码的功能/逻辑。作为我当前客户的测试人员，我与开发人员配对，以帮助确定我希望在编写任何代码之前看到的自动检查。

这些自动检查主要在单元、集成和容器（需要网络服务器）级别，因为这些是运行最快/最便宜的，但我们也有 GUI 级别的自动检查。

在将代码提交到管道之前，开发人员演示了代码以及测试人员和 BA，以确保它符合要求。然后，测试人员探索开发人员机器上的软件和代码，以练习边缘情况并查看是否存在任何问题。

如果确实出现任何问题，开发人员会编写一个失败的检查来重现问题，修复它并确保检查通过。

当测试人员满意时，开发人员将代码提交到管道，然后我们在集成环境中测试代码。

理想情况下，我们在集成环境中发现的唯一问题就是集成问题！

这节省了我们大量的时间，帮助我们完善客户和 BA 的要求，以确保我们正在构建正确的东西。

这是对我们在当前客户站点的运作方式的高度概括。这可能不是最好的过程，但它对我们有用。一些可能有帮助的链接：

Wikipedia
TDD 雅虎集团
Lisa Crispins 博客上的 TDD，带有指向她与珍妮特·格雷戈里（Janet Gregory）合着的书的链接，这是一个很好的资源！
软件测试俱乐部——另一个很好的提问和/或寻找答案
的资源我的一篇博客文章，其中包含一些关于测试如何改变 持续集成的重要资源

还有很多很多的资源——试试谷歌搜索“敏捷测试”。

希望这可以帮助，

邓克斯

我建议认真考虑构建一个具有绝对最少重复脚本代码的框架 - 这具有最小化更新工作的优势。同样，我会考虑具有面向对象框架的数据驱动脚本，您可以在其中构建事务对象以利用应用程序的功能。

这样，随着应用程序的增长和添加功能，您可以插入功能模块，而无需重写早期代码。

Web 对象到自动化对象的良好映射也是必不可少的 - 它需要多复杂取决于 Web 应用程序代码的性质，与开发人员合作以确保他们生成的 Web 对象有足够的钩子以允许您的脚本来访问它们（这可以像将项目 ID 放入 Web 对象的属性一样简单）

在每个开发阶段稳定之前，您可能希望避免功能和流程自动化。

在开发周期方面，老实说，我将自动化归类为它自己的开发周期，设计、构建、测试等都在它自己的周期中，并且依赖于一个稳定的应用程序来进行测试。

尽早开始，甚至在实际软件之前。这会给您带来很多好处 - 1. 您可以评估多个工具或自动化设计 2. 您的工具即使不完整，也可以帮助开发人员在早期阶段测试他们的代码。3. 您的最终产品（即自动化代码）将更适合实际产品 4. 提出您的自动化将作为一种探索性测试，恰好在需要时——在功能开发期间。

当接口固定并且实现可能发生变化时，自动化测试最有意义：接口固定是因为否则您会浪费时间追逐移动的目标，而实现可能会发生变化，否则将没有理由在第一次之后运行您的测试发布。（为了说明这个想法，自动化开发人员喜欢使用可预测元素 ID 的网站的一个原因是它们提供了一个比单纯的 DOM 层次结构更稳定（固定）的测试接口。）

那么，您的目标将是在开发周期中选择一个点，当您测试的接口足够稳定时，您将花费更多时间进行测试而不是赶上变化。做出这个选择没有一刀切的方法——毕竟，你是在试图预测未来——但你可以通过让你的开发人员知道你正在尝试做什么并监控你的开发人员的进度来提高你成功的机会.