敏捷、开发&测试

Continuous Testing ## Agile ## Devops
你曾经看过厨师准备一道菜吗?你可能已经注意到，在他们工作的时候，他们会仔细检查原料——品尝、嗅觉、感觉、观察，甚至倾听。他们的刀总是随时准备行动，异常锋利。在准备食物的每一个阶段，他们都会品尝食物，尽管食物的外观、味道和感觉都很不一样。如果有什么不太对的地方，他们会立即停下来，然后解决问题。他们绝不可能为顾客提供不符合他们要求标准的食物。
**这种形式的持续品尝被软件行业以持续测试的形式模仿，**它已经存在了很长一段时间，但是作为极限编程(XP)的一部分开始流行起来，XP是在20世纪90年代由Kent Beck正式提出的。XP的一个原则是，如果少量的测试可以消除一些缺陷，那么大量的测试可以消除更多的缺陷。
**开发人员编写单元测试来验证一小段代码，然后测试人员编写并运行验收测试，以确保需求被正确地实现。**随着敏捷开发在21世纪初变得越来越流行，测试人员和开发人员被鼓励作为同一个团队的一部分一起工作。他们将与产品负责人合作，定义一个特性的功能，并以增量的方式交付软件。测试不是等待开发人员完成编码阶段，而是与开发并行进行，以便在sprint结束时交付可工作的软件。
如今，**DevOps将开发团队和运营团队集合在一起，在不牺牲质量的前提下快速交付软件。这只能通过在引入问题时立即检测问题，从而使源代码不存在缺陷来实现，以便在它们接近客户之前将其清除。不管你是使用瀑布、敏捷还是DevOps方法，持续的测试都可以帮助你交付更好的软件。**这篇白皮书解释了持续测试的概念，它涉及到什么，并描述了Micro Focus如何在整个开发过程中采用持续测试，从而实现更快的交付和更高水平的质量。
Waterfall
瀑布式开发方法包括作为软件开发生命周期一部分的定义良好的测试阶段。它在开发阶段之后，通常在功能完成里程碑处。缺陷将在测试阶段被发现并记录下来。当测试完成时，开发人员将修复缺陷，测试人员将在代码完成里程碑处获得另一个构建来测试。这个模型可以工作，但它远非完美:
Agile
许多组织已经采用了一种不同的、响应更快的过程，即敏捷开发。创建敏捷开发实践是为了响应遗留瀑布式开发中典型的僵化、官僚和线性方法。敏捷强调尽可能快地交付可工作的软件，以实现客户反馈和交互。
DevOps
今天，越来越多地组织采用DevOps方法，通过将开发团队和运营团队紧密地联系在一起来构建可以在任何时候发布到生产中的高质量软件。DevOps试图消除交付软件的人为障碍，并授权交付团队对他们构建和交付的软件负责。为了降低开发和生产之间的检查点，有几个关键的考虑:
DevOps团队依赖于强大的沟通和协作来避免引入技术债务。
手动步骤的自动化是必不可少的。通常，交付软件的手工步骤经常会引入缺陷、延迟和返工。从编译和构建代码更改，到部署和配置软件，再到测试软件，所有事情的自动化都是必不可少的。
需要在每个阶段提供反馈并根据反馈采取行动。
DevOps团队获得了很多好处，包括:
1.上市时间缩短了。DevOps鼓励团队尽早向最终用户展示软件，以获得反馈;
2.他们生产正确的产品。因为最终用户从早期阶段就开始体验软件，所以DevOps团队可以立即纠正他们的做法。
3.发布版本更可靠。DevOps团队必须能够在任何时候发布软件。通过投资自动化部署，在部署到生产环境时就不会有太多的意外。
4.产品质量比较好。对于能够随时发布的强调意味着DevOps团队必须确保始终如一的高质量。就像厨师在准备食物的每个阶段都用他们所有的感官检查食物一样，现在的软件开发团队在开发过程的每个阶段都测试软件。这就是所谓的连续测试。
就像厨师在准备食物的每个阶段都要用他们所有的感官检查食物一样，今天的软件开发团队在开发过程的每个阶段都要测试软件。这就是所谓的连续测试。
Confidence through Continuous Testing
今天的软件开发团队经常把软件当作一种实验，他们依靠反馈来证明他们的假设。开发团队努力尽快向客户发布软件更新，以便他们能够迭代和改进。为了实现这一点，他们采用了一种机制，使新功能能够尽可能快地从开发人员的键盘流到最终用户的屏幕上。从开发人员到最终用户的这条路径通常被称为管道，在理想的形式中，它是一个完全自动化的过程，包括CI和代码构建、测试、部署和生产环境中的系统监视。CI服务器，如Jenkins、Bamboo、TeamCity、CircleCI，以及交付自动化平台，如Chef、Puppet、Ansible、Codar，通常实现管道。
管道的目标是快速有效地向系统交付变更，然后通过测试验证系统是否按预期工作。完整的管道从开发人员工作站通过QA环境一直到生产环境移动并验证变更。任何阻碍快速交付目标的东西都必须移除。进入管道的任何代码都经过严格测试，以避免通过缺陷或不稳定性给产品带来技术债务。
代码应该平稳地通过管道，并且任何阻碍该流程的瓶颈都应该被修复。如果在代码中发现了缺陷，则该代码的流程将被停止，并且必须修复缺陷，以便继续它的旅程。许多组织采用一种称为门控签入的流程，它对签入到源代码存储库中的任何代码执行快速签入。如果代码不能编译，或者没有通过一组基本的测试，代码更改将被拒绝，并且不会添加到源代码控制中。因此，代码不允许进入管道。当然，这并不能保证代码不存在缺陷，但它确实有助于确保管道中始终有可编译并满足进入管道的最低基本标准的代码。
系统将阻止您签入不能编译的代码，或者拒绝在管道的每个阶段没有通过测试的代码，这样的认识给了开发人员信心。现在，他们可以频繁地检入代码，而不是破坏构建并阻止其他人检入他们的工作的人。
触发构建与计划构建
连续测试意味着在管道中的每个阶段运行测试，这些阶段由代码签入等事件自动触发。但是，在这些阶段中的每个阶段，您还可以将测试配置为定期运行，即使没有引入已知的更改。这种类型的计划测试提醒您可能无意中引入的更改。无意更改的一个示例可能是绕过自动部署机制对配置进行的手动更改。持续测试的目的是让团队尽快发现问题，一直运行测试是确保及时反馈的另一种机制。