ibm测试_连续测试：IBM的观点

测试是昂贵的

软件开发和交付正在从复杂的，整体的应用程序（其许多依赖项在构建时已解决）发展到一种更加分布式的，以服务为中心的体系结构，其依赖项可以在运行时得到解决。 大多数企业应用程序是最初为云前环境设计的现有应用程序（也称为记录系统）与在云中开发的新的“参与系统”应用程序的组合。 由于它们的依赖性，它们的体系结构往往很复杂，并且它们使用API​​在现有的记录系统和新的参与系统之间架起桥梁。 他们利用API管理和云集成技术来实现集成，同时满足组织的安全要求。 他们的工作负载可以跨多个环境运行：本地，私有云，公共云-它们的组合是一种架构，也称为混合云。

“连续测试使项目团队可以在需要时（而不是在可能的情况下）执行测试。 ”

混合云架构正在成为支持云的应用程序和云原生应用程序的规范。 混合云为部署提供了灵活性，使组织能够选择合适的平台来运行其工作负载（ 混合云的DevOps：IBM的观点 ，2016年2月）。 IDC预测，到2017年，将有80％的企业IT公司致力于混合云架构（IDC FutureScape：2016年全球云预测- 掌握数字化转型的原始资料 ，2015年11月）。

IBM认为，测试改进可为公司节省大量资金，并具有竞争优势。 测试是一个可以改进流程的成熟领域-到2018年，质量保证的平均支出占IT总预算的百分比预计将上升到40％。许多组织的支出超过其三分之一，这一事实使成本增加测试环境的测试预算（ 《 2015-16年世界质量报告：凯捷，索吉提，惠普》 ）。

ADT最近进行的一项调查发现，到目前为止，测试是延迟部署到生产环境的第一原因（ ADT研究白皮书：组织越来越希望持续部署以进行恢复） 。 利用分析和测试见解，IBM专注于优化测试和相关的部署操作，以便有更多资源可用于创新。

为什么要争取连续测试？

为了使企业Swift向市场交付高质量的创新解决方案，整个交付团队需要鼓励和接受所有反馈。 这些反馈渠道不仅需要在开发和运营团队之间发生，而且需要贯穿整个交付生态系统（包括业务分析师，开发人员，设计师，架构师，测试人员，发布经理，第三方供应商等）以及业务利益相关者之间。 业务涉众要求测试人员验证定义的流程和交易将按预期进行。 测试人员正在寻找使测试活动的成本和影响最小化的方法。 持续的测试通过提供有关解决方案质量的即时反馈来赢得整个团队的信任。 对于业务利益相关者而言，连续测试增加了人们对可以依赖交付物以及对业务影响的风险最小的信心。 对于项目交付团队而言，连续的测试技术和工具可以最大程度地减少测试的影响，从而降低项目成本，加快解决方案的交付速度，最重要的是，确保交付高质量，可靠的解决方案。

对质量和速度的需求

业务涉众要求项目团队尽快交付新的应用程序，集成，迁移和更改。 反过来，项目团队要求测试人员验证以下内容：

• 技术环境按要求工作
• 业务流程和交易按预期运行
• 解决方案可扩展到预期的使用量
• 应用程序安全且用户数据受到保护

无论涉及的行业或技术如何，速度和质量之间都必须保持谨慎的平衡。 随着对云技术的日益接受，软件团队拥有比以往更多的工具，可以使他们的工作效率更高。 但是，尽管软件和系统开发人员会尽力避免出错，但人为错误是不可避免的，这就是我们进行测试的原因。 非测试产生的风险远远超过执行少量测试的成本。

随着敏捷和DevOps实践的日益普及，在每次迭代中重新执行手动测试已不再是可持续的模式。 只是时间不够，增加更多的人员来执行手动回归测试会导致收益递减。 更重要的是，反馈给开发人员的速度较慢，大大降低了生产率。 测试有效性是跟上快节奏的开发生命周期的关键方面。 通过运行最少数量的测试来发现最多数量的问题，从而对其进行优化。 即使是在更传统的开发生命周期中工作的团队（所有测试都在一个阶段中进行），他们也发现每次建立新版本时都无法跟上回归测试的步伐，包括缺陷修复，对现有功能的更改甚至是新的更改。功能全部捆绑到新版本中。 下图显示了仅几次迭代后，新功能的数量以及因此测试的数量已大大增加。

跟上所需的回归测试的唯一方法是自动化正确的测试集。 为了达到这种平衡，成熟的DevOps团队将测试自动化和手动探索性测试结合使用，二者均以连续模式运行。

找到正确的测试集

试图自动化所有测试是不可能的，而这样做的最终成本超过了收益。 对于任何相当复杂的应用程序，您无法测试通过系统的所有可能路径，因为即使应用程序中只有一个循环，可能路径的数量也变得无限。 如果随后添加测试数据排列，您将很快意识到尝试测试所有内容都是不可行的。 关键是要确定最重要的测试子集–您可以在其中进行的测试：

• 通常发现问题
• 看过回归
• 有客户投诉
• 知道故障的发生将是严重的甚至是灾难性的

新代码更改的影响分析是确定要运行哪些回归测试的关键方面。 但是，如果没有良好的变更集输入，则代码变更的数据和分析可能会产生误导。 对什么是正确的自动化测试进行分析应该涉及整个团队，从业务到开发，再到测试，再到运营和支持。 每个角色对事情在哪里和哪里出错都有不同的看法，因此让所有人参与进来很重要。

可以应用测试自动化的一些示例是：

• 数据驱动的测试，其中的数据集非常复杂并且涵盖了关键方面
• 业务逻辑验证，以确保获得正确的结果
• 与第三方系统集成，开发人员和测试人员可能无法完全访问该第三方系统
• 低强度性能测试。 跨版本运行小规模压力，负载，容量或内存泄漏检查，以便在进行正式负载测试之前及早发现性能下降
• 跨多个平台和操作系统安装和升级客户安装的软件，以购买商用软件
• 扫描安全漏洞，尤其是在财务或个人信息受到威胁时

测试自动化实施有各种形式和形式，一些关键示例如下：

• 单元测试
• 用户界面（UI）层上的功能测试
• 通过API进行功能测试
• 通过UI或API进行性能测试
• 安全测试

此外，手动进行的测试非常有价值。 与测试自动化并行地继续这些测试：

• 探索性测试。 非脚本测试，测试人员在没有规定最终结果的情况下分析系统的不同方面。 这有助于找到带有缺陷但尚未被自动化测试覆盖的新方案。
• 可用性测试。 要求最终用户测试系统的特定方面，并在其进行过程中提供口头反馈。 这使团队可以更好地了解用户在使用系统时的想法。

测试更智能，“左移”

您是否曾被告知过：“更聪明地测试，而不是更难！”？ 不幸的是，测试和开发经理经常将此消息发送给他们的团队。 但是，他们没有提供有关如何完成此更智能测试的指导。 团队忙于跟上他们现有的测试，以至于他们没有时间自己解决这个问题。

更加智能的测试的一个关键方面是在交付生命周期中进行更早，更频繁的测试 ，或者将测试左移 。 这样，团队可以尽早测试最危险的元素，然后可以连续重复使用这些测试。 直接向开发团队提供关于代码质量的早期迭代反馈，以确保在生命周期后期发现较少的问题，而这些问题的修复成本更高，是一种更明智的方法。

想象一下一个实时应用程序的质量低且评论不佳的情况。 这是一个场景，描述了项目团队如何在需要时（不仅是在可能的情况下）提高测试能力和执行测试自动化。

首先，所有利益相关者（业务，开发，测试，运营等）共同努力，以了解生产后缺陷的根本原因。 通过使用缺陷数据和分析，团队发现最重要的缺陷来自两个领域：

• 与其他系统集成
• 响应时间延迟

团队认为他们需要在开发过程的早期测试高风险的集成，而不是等到即将部署到生产之前，因此他们进行协作并捕获商定的接口和数据定义作为其系统体系结构的一部分。

他们还决定在构建可用后立即进行一些低强度性能测试，以便可以更早地发现并解决关键性能问题。 他们将跟踪每个构建的这些性能测试，以便他们可以立即查看性能是否下降。

基于这些接口，开发人员和测试人员可以共同为每个高风险接口创建虚拟服务或存根。 该接口存根模仿其他系统，并允许开发人员和测试人员在开发过程的早期阶段-编写和构建代码后就测试高风险区域。

然后，该团队将许多功能集成测试和关键响应时间测试自动化，因为这些是大多数重大生产缺陷的来源。

现在，无论何时进行新的构建，成功的构建过程都会触发如下所示的自动化活动：

1. 新的应用程序版本安装在自动配置的基于开发云的测试环境中。
2. 缺少相关服务的存根已启动。
3. 触发自动集成测试套件以执行，然后执行低强度性能测试。
4. 捕获测试结果，并向整个团队提供反馈。 团队将分析结果是否存在任何回归，尤其是在绩效方面。
5. 如果集成和性能测试通过，则将开发测试环境中应用程序的快照部署到系统测试环境。
6. 在系统测试环境中触发并执行基于自动用户界面的测试套件。
7. 再次，捕获测试结果，提供反馈，解决缺陷，并创建新的版本。

相关系统可用后，团队将针对实际系统再次运行这些相同的自动化集成和性能测试，以确认其应用程序仍能按预期运行。

这种情况可以应用于任何模式的缺陷。 它使整个团队可以一起工作，不仅可以在生命周期的早期开始测试，还可以首先自动执行最重要的测试，以便重复执行这些测试。 这样可以确保对应用程序中最危险的部分进行良好的测试覆盖。

实现持续测试

建立持续的测试文化需要人员，实践，工具和时间。 下图显示了创建连续测试过程中的典型做法。

当采用传统的测试方法时，缺陷是测试人员与开发人员之间的初始沟通渠道。 测试人员认为“我发现了一个错误！” 然后开发人员同意或不同意代码是否存在问题。 很多时候，缺陷不是代码本身的问题，而是需求，设计甚至测试的问题。 有时，问题出在应用程序本身之外–在测试环境，测试数据，测试脚本本身或这些东西的某种组合中。 在任何软件开发生命周期中，拥有一个用于记录和跟踪缺陷的协作环境至关重要，但是在采用正确的做法集时，跟踪缺陷只是冰山一角。

测试团队通常采用的下一种实践是测试管理–计划测试工作，确定所需测试，创建手动测试，收集现有测试，执行测试以及跟踪和报告测试进度。 这种测试管理实践可帮助团队和管理人员一目了然地了解测试是否通过，失败或被阻止。 它还回答了这个问题： 测试工作是按计划进行还是落后还是提前？

当团队发现手动运行所有测试效率低下，效率低下并且在许多情况下完全不可能时，通常会出现测试自动化实践。 如果不将其作为软件开发项目本身来进行，则成功创建健壮且可维护的测试自动化框架可能很困难。 在某些情况下，需要有一个共同的愿景，需求，体系结构，设计，甚至是编码，最后还要验证自动化是否可以实现预期目的。 没有这些方面，测试自动化框架往往会变得脆弱，脆弱，难以维护且重构成本高昂，并且经常被废弃。

除测试自动化外，测试分析和见解实践也开始增长，以回答诸如以下问题： 我们应该运行哪些测试，何时运行？ 我们为什么要运行它们？ 代码更改影响分析可能是一项艰巨的任务，尤其是在开发人员不严格且与其代码更改集保持一致的情况下。 了解上一次构建的更改对于选择要运行的正确测试集至关重要。 没有这种分析，过度测试–或重新测试所有内容都是诱人但代价高昂的答案。

测试的另一个关键方面是创建测试环境。 自动调配测试环境具有巨大的优势。 自动创建和配置测试环境可以将开始测试新版本所需的时间从数小时（甚至数天或数周）减少到几分钟。 这种自动化还减少了由于测试环境问题，错误安装的从属软件以及其他引入问题的手动过程导致的错误错误的数量。 在IBM DevOps的故事中，测试自动化与自动化部署密不可分。

结合测试执行和测试环境自动化，服务虚拟化或存根 ，可以大大提高测试工作的效率。 通过从已知的和公认的接口创建虚拟服务，开发人员和测试人员即使在不依赖该系统的情况下，也可以编写代码并针对同一接口进行测试。 针对这些已知接口执行测试可以使测试早得多地开始并且可以在每个构建上更频繁地运行。 服务虚拟化还允许测试可能无法通过实时系统进行测试的方案，例如：

• 异常与错误
• 缺失数据
• 延迟的响应时间
• 大量数据或用户

将服务虚拟化整合到整个测试工作中，团队可以首先构建并有效地测试系统中风险最高的部分，而不仅仅是构建和测试系统中易于测试的部分。 然后，当您针对系统中那些有风险的部分进行自动化测试并在每个构建中执行它们时，您会更好地覆盖这些部分。 这样可以确保在构建新版本时尽快识别出回归。

一个典型的场景可能是移动和Web开发团队在云应用程序上工作，大型机团队在本地工作。 通过服务虚拟化，IBM可以在这些混合云方案中消除环境依赖性。 然后，团队以自己的速度进行构建和测试，并采用适合其文化的正确DevOps方法。

提高测试有效性的测试的另一个方面是拥有正确的测试数据集。 使用尽可能像生产一样的测试数据可以在更多场景下提供更好的覆盖范围。 从生产环境中提取数据并出于安全目的对其进行屏蔽提供了一组真实的测试数据。 一组良好的测试数据还使团队能够创建异常或错误情况，否则可能很难进行测试。

一组有效的测试实践一起工作，可以使整个团队（而不仅仅是测试人员）提高质量并减少交付新功能所需的时间。 这些做法消除了依赖性和瓶颈，可以在生命周期的早期进行测试并实现连续测试-无需传统测试环境通常需要的大量投资。

结论

对于采用混合云战略的公司而言，对“快速质量”的渴望从未像现在这样，其中有些项目是在云中开发的，有些项目是在内部开发的，并且两者都需要在部署时无缝地协同工作。

我们将测试自动化和服务虚拟化的结合称为“连续测试”。 在生命周期中更早，更频繁地移动测试（“向左移动”）使团队可以持续构建，部署，测试和收集反馈。 直接向开发团队提供关于代码质量的早期迭代反馈，有助于确保减少在生命周期后期发现的问题，而这些问题的修复成本更高。 而且，如果在生产中发现问题，不仅解决问题的成本非常高，而且还会严重损害公司的声誉，甚至对客户忠诚度产生持久影响。 没有及时的测试和反馈，公司将无法真正快速交付质量。

其他贡献者：

• Glyn Rhodes，提供管理主管–连续测试
• James Hunter，行业解决方案和SAP主管
• 高级产品经理Roger LeBlanc –性能测试和UI自动化
• 产品经理Matt Tarnawsky – API测试和服务虚拟化

---

翻译自: https://www.ibm.com/developerworks/library/d-continuous-testing-shift-left-trs/index.html