在大型公司，企业中进行测试通常是一项复杂而费力的工作。 业务部门与IT之间的差距非常大：当开发人员在代码级别上具有远见，而验证在单元测试级别上，并且客户认为即使不使用服务，也可以使用或超过整个开发流程，而整个流程却超出了一个开发团队，甚至是整个团队，部门\公司。 并且他要求组织业务测试或端到端测试，或者基于从头到尾（端到端2端）的方案进行测试。
让我们从头开始-从臭名昭著的“端到端业务测试”来自两个支柱，即测试金字塔和ISO9000标准。
测试金字塔
测试金字塔可能是任何精通其专业知识并在与相关单位进行沟通时积累了颠簸的测试人员所熟悉的。 特别是经常有必要在证实测试自动化时呼吁它。 哪些测试更便宜且更重要？ 快跑
测试金字塔的本质并不棘手：测试应基于编写和执行中最简单，最快的测试-单元测试。 当然，检查类和函数的接口几乎是无法展示给客户的，但是如果没有这种强大，整体的，无故障的基础，几乎不可能构建更高的东西。 通常，几十个函数，方法和类为客户实现某种功能，实际上，可以将十几个单元测试简化为某些顶级测试。 客户已经需要一间带装饰的漂亮公寓，但是当公寓中倾斜的窗户停止打开并且地板和天花板因第一次吹拂而破裂时，客户不太可能会满意。 但是，客户自己进入公寓检查其质量可能不是最好的主意。 同意，用户很难检查地基中混凝土的质量，并重现所有天气条件。 因此，在测试中，当然需要顶层测试，只有在我们制定出单元测试后，才需要高层测试。
开发更高难度的测试和执行更高级别的测试（集成测试）的难度更大，集成测试可验证整个团队同时工作的模块的正确操作，并发布其产品（系统）。 即，在不考虑与外部系统交互的情况下，检查代码的集成，测试系统。 这样的测试已经暗示了高级检查，很可能是通过系统API甚至是GUI（前端）对系统的调用。 使用这种类型的测试更加困难-为了覆盖代码的所有分支和细微差别，您很可能需要对各种测试数据使用大量强烈重叠的检查，并且在自动化过程中通常会在脚本中开发大量条件和分支。 也就是说，一方面，我们已经接近用户，这使生活变得困难，但另一方面，我们很难找到一种通用语言，这使我们付出了更多代价，并且支票的质量仍然不够。 也就是说，我们可以将客户推出新公寓，他可以检查所有内容，但无需考虑与其他居民的互动，天气条件和公用事业。 同意，通常，在现实生活中对理想世界，模型的感觉并不多。
如果添加这些条件，我们将看到我们的系统如何与外部系统（供应商和消费者）以及我们的环境进行交互，即我们进行系统测试，那么我们很容易看到测试的复杂性也会增加。 我们将需要实现所有交互系统的同时可操作性，尽管其中没有专家的参与。 目前，仅接受供应商提供的一些数据并将数据传输给我们的消费者就足够了。 以正确的顺序和格式。 数据的进一步命运并不困扰我们。 最主要的是我们的系统可以在正确的环境中正常工作。 而且这里一切都很好-对于我们的客户，我们已经可以进行全面的演示，但仅在现实生活中，并不是我们开发的所有成功标准。 客户将他的公寓放在一所坚固的房子里当然是很好的，但是如果您需要从那儿买东西，爬过铁丝网，然后沿着鳄鱼湖划独木舟进入到处是蛇的小屋，那也许我们是不对的在那里吗？
因此，这里进行端到端测试的第一个想法是不仅要检查我们的环境，还要检查系统所接收或发送的数据通过的所有互连系统。 反过来，这意味着我们将不得不将这些“测试金字塔”中的几个相互结合。 脆弱的桥梁的构建，我们将通过手柄保存对用户有价值的数据。
唯一的问题是如何执行此操作？ 谁应该这样做？ 如何放在一起？
ISO9000
一系列描述质量管理体系的标准，包括对组织中任何过程都应进行描述和记录的事实，即使这是在秋季向看门人发布佣金的过程。 如果是这样，则不能描述在组织中使用和开发的软件内部发生的单个过程。 问题是如何做到这一点？ 当然，从BDD的角度来看，最好的描述是通过测试进行的行为描述，测试金字塔将位于该行为下。 但是，我们将立即回到困境，将多座金字塔与从顶部到顶部的细绳相结合，沿着这条绳索的助行器及其使用者将无需保险即可行走。
流程方法是一种管理策略，要求组织管理其流程及其之间的交互。 因此，您需要考虑公司的每个主要流程及其支持流程。
因此，最简单的方法是使用抽象-创建至少一个流程图，并指示其输入和输出，使流程可控且可衡量，确保与父子流程的互连（按照ISO9000的要求）
所有过程都具有：
•输入；
•输出；
•操作控制；
•适当的测量和监控。
每个流程都将具有支持流程，这些支持流程将使流程得以实现
业务图最适合此目的，并且最常使用UML，BPMN，ARIS等标准，并且流程本身成为带有“多维数据集”的流程图。 在“多维数据集”之间存在交互，在BPMN标准中，它是动作流和消息流。 这正是我们所需要的！
任何想要获得证书并遵循ISO9000标准的公司都很可能已经获得了这样的计划，并且它们是最高要求的组成部分。 如果公司拥有出色的分析师，那么很可能与计划中针对单个操作的需求的链接就会降到低层次的需求。 我们需要他们。
实际上，在图上我们可以看到整个过程，并了解我们需要构建哪种方案，以及在什么时候使用哪些数据运行哪个系统/团队。
我并没有低估那些编写能在软件和硬件系统的不同部分之间发送消息的能干代码的开发人员的工作，但是要牢记一切。 而且，当该流程用于许多其他流程时，最好随身携带这样的“卡片”以进行有效的测试，甚至更适合构建测试模型。
在实践中
因此，我们有两个介绍性的内容-每个团队\系统应准备好一系列的测试-从最小的单元测试到复杂的系统测试，以及组织内部必须以业务形式描述需求的事实-过程。 这一事实将使我们能够快速向客户回答其业务流程的运作方式以及在什么时候中断，并且我们自己在收到来自工业运营的缺陷时，可以快速进行根本原因分析（对缺陷的根本原因进行分析）。 从理论上讲。
但是实际上，一切再次落到了测试人员身上-如何从一堆测试（尤其是外国测试）中选择正确的测试，将它们构建成一个链，再到每个系统的输入以提交必要的数据并与正确确定的预期结果进行比较？
最简单的选择是首先根据业务模型开发测试，然后将团队划分为实施特定业务流程的项目。 为此，在某些测试管理工具中，已经可以加载BPMN方案（例如，对于HPE ALM-支持XPDL格式的加载）。 HP ALM本身会将方案分解为一组需求（操作），并在需要时创建需求层次结构（模块“需求”->“业务模型”）。 接下来，我们的业务是通过测试覆盖需求，然后构建需求，从而将测试链条覆盖到我们的业务流程中。 HPE ALM中的这些链称为“路径”，可让您查看序列的所有组合。 如果需要，可以立即将链转换为测试。
但是，即使您不使用测试工具，也仍然必须从业务流程中建立链。 特别是考虑到工具的不完善（并非一切都如此乐观），以及测试模型很可能需要在事后组装，并由不依赖新项目的“普通团队”以回归的形式执行，这一事实很重要。
松鼠可以通过几种方式达到颠簸？在这种情况下，我们将需要打开每个团队的测试，找到与业务模型中出现的需求相关的测试，并从中构建链，将其保存在“公共空间”中。 创建公共空间是一种替代，但是无论如何都应该如此，即使是以谷仓书，excel或测试管理工具中的项目区域的形式。 如果我们再次谈论HPE ALM，则BPT（业务流程测试）模块将负责此功能，该模块同时使您可以将一项测试的结果转换为另一项测试的参数。 但是，如果您希望在HPE ALM上辛勤工作，则可以通过在执行流程（执行流程）中重建测试集（Test set）来实现此目的。 然后，在启动完整集时，将依次调用负责传递端到端脚本的每个组件的测试人员。
而且，仅凭测试是不够的。 根据我的实践，几乎所有工具都有一些致命的缺陷，因此，如果您进入业务流程中测试自动化的阶段，那么您将开始创建一个脚本，该脚本将按正确的顺序进行测试。
结果，可以得出两个结论：
1）对于端到端方案，很可能以前开发的测试用于业务流程链（方案）中的每个系统
可以以稀疏矩阵的形式展示公司的所有完整测试套件，其中每个系统的测试都以列的形式分布（为简化起见，系统测试），而业务流程则以行的形式分布。 也就是说，对于某些业务流程，您需要选择\创建覆盖业务流程的测试，建立关系。 如果没有覆盖，这是一个填补测试模型中空白的机会，或者是确保通过其他级别的测试（集成测试，单元测试，代码审查以及通过分析器运行）来确保质量。
2）需要一个工具来监视，跟踪和更新业务流程，以便与测试模型同步。
而且，如果测试工具或多或少可以忍受创建测试模型的能力，那么更新确实很糟糕，与试图查看流程和测试模型的更改相比，重新创建模型通常会容易得多。 实际团队的经验表明，创建架构的实时可视化效果更好。 最简单的方法是在公共区域中使用简单的标记板和贴纸。 然后，参与业务流程的团队可以清楚地看到流程的修改方式（删除和添加连接，删除和添加操作）。 最主要的是每个人都可以访问董事会。 另外，请注意，如果该过程涉及系统之间的消息，那么通常，每个系统至少应进行两次测试-用于发送和接收数据。 但是，您可以使用整个乐高城市（从大型街区开始）来代替贴纸，或者使用更具创意的东西。 这里最主要的是一种语言和一种信息空间，这在企业中是非常缺乏的。
总结
组织视觉和适当的业务流程测试是一件复杂且非常昂贵的事情。 请注意，端到端测试不仅仅是接受测试，而是客户将要进行的用户测试，它正在建立桥梁，同时考虑到客户将遵循并带领用户步入正轨的所有可能情况。
再一次-E2E-这不是在拉达卡利纳（Lada Kalina）上过桥散步，甚至不是两个kamaz通道。 这是一项复杂的工程工作，用传感器称重桥梁并执行所有可能的检查和情况-至少对这些情况进行了描述。
您的公司是否需要如此理想的整理工作完全取决于您的目标和需求。 通常，与任何测试一样，您应该在此阶段评估由于遗漏缺陷而带来的潜在风险，以及准备成本和进行端到端测试的成本。 要评估会从中花费更多的钱，然后采取行动。 但请注意，在业务流程的端到端测试中，没有坚实的基础（例如100％通过率的单元测试（约90-100％的覆盖率），没有集成测试（约60-80％的覆盖率，90- 100％的通过率），无需进行系统测试（20-40％的覆盖率，80-100％的通过率）。 建立成功的标准（质量门）不仅仅是产品质量的要求，这里要记住的主要事情是E2E测试的数量仅仅是金字塔的顶端（覆盖率1-2％，合格率约99％），不应大于其基础，而不是同时是前面步骤中的漏洞。 这是对先验被认为在先前阶段已关闭的补充。
此类测试的组织主要是准备和同步测试用例和数据（测试分析）的工作，以及一组组织措施，在可行的测试站点上同时在同一地点同步团队。 请牢记这一点，不要试图提前向客户展示“端到端测试”，以免浪费大量时间而没有将所有工作组件组装在一起的人。
PS描述了工具和实践-仅以举例来说，作者并没有为自己设定广告产品的目标，也没有宣布这种端到端测试的唯一方法。