自动化测试必须能够快速反映实时项目状态.这个想法是:
在执行任何提交到存储库自动构建之后(尽可能快地完成).
如果构建成功,则启动自动化测试.一定要快.
这是我知道的最好的方法,以确定您的更改是否会破坏任何内容.
起初,似乎快速进行构建很难,但我们设法将它保持在100秒左右.105(!)项目的解决方案(MSVS 2008 C#).
测试似乎并不那么简单(我们使用NUnit FW).单元测试不是一个大问题.正是集成测试杀死了我们.而不是它们更慢的事实(关于如何使它们更快的任何想法都非常受欢迎)但事实上必须设置更慢(大约1000秒)的环境!
我们的集成测试使用需要重新部署的Web/win服务(目前为止19个),以反映最新的变化.这包括重新启动服务和大量HDD R/W活动.
任何人都可以分享环境和工作流程应该/可以组织/优化的经验,以加强自动化测试阶段.什么是"低级"瓶颈和解决方法.
PS书和广泛的文章是受欢迎的,但现实世界的工作解决方案更受欢迎.
您可以采取一些优化策略来提高测试的吞吐量,但是您需要问自己这个测试的目标是什么,以及为什么需要快速测试.
有些测试需要时间.这是生活中的事实.集成测试通常需要时间,您通常必须设置一个环境才能够执行它们.如果您设置了一个环境,您将希望拥有一个尽可能接近最终生产环境的环境.
你有两个选择:
优化测试或测试的部署.
不要经常这样做.
根据我的经验,最好是拥有一个正确的集成环境,并找到错误,并充分代表最终的生产环境.我通常选择选项2(1).
我们很有可能会说我们会一直测试所有东西,但实际上你需要一个策略.
(1)除非有大量错误只能在集成中找到,在这种情况下,忘记我说的一切:-)