回归测试与部署策略

框架背后的想法是,它应该是“缓慢运行的代码”。您不应该像它支持的应用程序那样频繁地更改框架。试着让框架处于一个较慢的开发周期:也许每三到六个月发布一次。

我的猜测是,您仍然在这个框架中制定一些架构决策。如果您认为框架的更改确实需要如此动态,那么请找出框架的哪些部分经常更改,并尝试将这些部分重构到需要它们的应用程序中。

敏捷并不一定意味着对每件事都有无限的改变。您的架构师可以为构成框架的内容设置边界,并防止人们为了可能的应用程序快捷方式而轻易地对其进行调整。它可能需要几次迭代才能稳定下来,但在那之后它应该更稳定。

除非有(单元)测试覆盖率,否则我不会称之为敏捷方法。敏捷的一个关键原则是拥有健壮的单元测试,为频繁的重构和新特性开发提供了一个安全网。你的情况有很大的风险。每月部署20到30个应用程序,其中1)大多数应用程序不会给用户带来任何新的业务价值;2)在我的书中,没有任何测试是不合格的。我坚信敏捷。但你不能只挑选其中方便的部分。

重构数据库 ,作者Scott Ambler。

另外,集成测试和单元测试之间有很大的区别。回归测试是集成测试。在这个层次上实现自动化是非常困难的。我认为在测试方面正在发生的突破都是关于编写高度可测试的代码,这使得单元测试越来越多的代码库成为可能。

以下是我能想到的一些技巧: 1.将框架分解为独立的部分,这样更改一个部分只需要运行一小部分测试用例。 3.减少更新框架的频率。如果应用程序不需要更改,则表示可以不更改它。所以我想这些应用程序可以使用旧版本的框架。你可以每3个月更新一次这些应用程序的框架。

回归测试是一种生活方式。您需要在每个应用程序发布之前对其进行回归测试。但是,由于时间和金钱通常不是无限的,所以您应该将测试的重点放在变化最大的领域。识别这些区域的一种快速而肮脏的方法是统计给定业务区域中更改的代码行;说“会计”或“用户管理”。这些应该首先得到最多的测试,以及您确定为任务关键型的任何领域。

现在我知道,代码行的变化不一定是衡量变化的最佳方式。如果您有定义良好的变更请求,那么实际上最好通过查看变更请求的数量和复杂性来评估这些热点。但不是每个人都有这种奢侈。

当您谈论对框架进行更改时,您可能不需要测试使用它的所有代码。如果你说的是像DAL这样的东西的变化,那基本上就是所有的东西。您只需要测试一个足够大的代码样本,以确保更改是可靠的。再次,从“任务关键”地区和受影响最严重的地区开始。

我发现将项目划分为3个不同的代码流是有帮助的;开发、质量保证和生产。开发对所有的更改都是开放的,QA是特性锁定的,而生产是代码锁定的(不管怎样,都是锁定的)。如果您以每月一次的周期发布到生产环境中,那么您可能希望在发布之前至少1个月从开发代码中分支一个QA构建。然后你花了一个月的时间来测试新的变化,回归测试你能做的一切。您可能需要在发布前一周左右完成对更改的测试,这样应用程序就可以登台运行,并且可以对安装进行几次干运行。你不可能对所有东西都进行回归测试,所以要准备好一个策略,以便将补丁发布到生产环境中。别忘了把这些补丁合并回QA和开发代码流中。

自动化回归测试将是一件非常棒的事情;理论上。实际上,更新测试代码的时间比手动运行测试脚本的时间要多。除此之外,你可以雇佣两三个测试猴子,价格相当于一个非常好的测试脚本开发人员。悲伤但真实。