👆🏻 👍 ⌨️ 我们为什么以及如何测试更新 🤓 🧜🏿 🐍

在本文中，我将解释为什么重要的是不要忘记测试产品更新以及该过程在我们公司中的工作方式。更新稳定性取决于产品声誉和用户对您的创新的信心。根据我自己的经验，我可以说有时候在开始更新之前，例如在电话上，我宁愿至少等待一天并阅读注释（它们始终仅与最新版本相关）。如果评论是侮辱性的，那么我决定更新的可能性往往为零。由于负面评论而导致的应用程序评级下降，并且还原它并不容易，因为您需要使用户对安装新更新感兴趣，而他现在会担心。

用户通常不满意什么？

该应用程序在更新后根本无法运行。例如，它根本不知道如何处理旧格式的数据。
奖金，折扣，用户储蓄（游戏，商店，咖啡馆）丢失；
宣布更新的新功能不起作用；
一项新功能有效，但其中一些旧功能掉线了；

所有这些问题都与移动应用程序以及我们在家测试的DLP系统有关。关于我们正在处理的内容。

我们发布什么以及需要更新什么

我们公司为客户提供防止企业信息泄漏的解决方案，并能够根据需要为每个组织分别进行配置。系统的主要元素是其设置（将以何种标准搜索入侵者）和事件（已记录的事件）。

该产品由几个部分组成，在本文中，我们将考虑InfoWatch Traffic Monitor事件分析和存储服务器。该产品在Linux系列OS上运行，具有自己的数据库。安全员使用Web控制台进行工作。当前支持两种不同的Linux发行版和两个数据库。该系统可以通过多种方式安装：多合一，所有组件都安装在一台机器上；当系统组件存在于不同的物理计算机上时，进行分布式安装。

除了声明的系统功能之外，我们还必须保证将主要版本N-1和N-2更新为N，以及所有次要版本（每个版本的补丁和修补程序）进行更新。这是由于以下事实：我们的客户通常拥有相当复杂的IT基础架构，因此更新可能会花费很长时间，因此限制更新的数量（而不是经常进行更新）以避免停机很重要。

所有这些条件为我们的产品提供了足够大的一组配置，对于每种配置，我们必须保证成功进行更新。这是指更新，其结果是：

用户数据不会丢失
旧功能没有损坏
新功能可供使用

在这种情况下，上面列表中需求的优先级按照重要性从高到低的顺序排列。例如，如果您将优先级从使用DLP系统的工作领域转移到上述用户应用程序领域，那么拯救游戏用户可能比启动新游戏的能力更为重要。而且，如果“发送订单”按钮停止工作，则食品订购应用程序的用户不必关心新菜单的可爱程度。

考虑一下发布主要版本3时带有更新表的示例，对于版本1.0.0，发布了两个补丁和三个修复程序，对于版本2.0.0，有两个修复程序。

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

总共，在该示例中，我们有9个版本，必须从中升级到新版本3.0.0。每个版本的产品都有两个操作系统和两个数据库。那些。总共发布了27个更新的配置。而且，如果我们也采用不同的安装方法，则可以轻松地将该数字乘以2，从而得到54。我们的

每个发行版都包含一些重要的功能（从对产品的影响角度而言）。可以更改系统的方法，可以改进分析系统，可以用新数据补充事件，可以更改环境的版本，例如，操作系统或数据库的版本等。

历史上...

在远古时代，我们在测试产品更新时开发了一种研究方法。他在对产品有丰富知识，少数环境和经过测试的配置的条件下证明了自己。但是随着时间的流逝，团队不断壮大并改变了组成：测试人员和开发人员都来了又去了，一些未记录的功能被安全地遗忘了。

在没有良好产品知识的情况下计划研究测试是一项艰巨的任务，其后果是：

每次测试更新花费的时间都不一样。更经常地，时间是根据剩余原则分配的，因为更新是在产品已经稳定下来并在发布之前保留最后的修饰时进行的。
有时会忘记一些环境。
, , . , , , «» - .

最初的准备工作主要还是由测试人员决定的，测试人员可以完成任务，有时甚至不考虑版本中的所有更改。

除了测试过程的内部功能外，文档没有描述产品功能发生的变化，这增加了火势。因此，我们不能测试什么没有更改，但是测试什么不受当前版本的影响。

结果，无法从更新测试报告中清楚地了解执行了哪些检查，以什么值进行检查等。

但是，一段时间以来，我们对研究测试的结果感到满意：没有太多的军事缺陷可用于更新，也没有资源进行更改以取得理论上的优势。

出问题了

但是，当关键更新缺陷对我们的客户造成威胁时，情况发生了变化。最常见的情况是，它们位于远离主要更新方案的某个地方，并且与以下情况相关联：例如，在先前版本中创建并工作的分析技术元素阻止了更新，或者客户端数据库中的某些事件丢失了，或者是最关键的方案升级后，当某些服务没有启动并且我们收到了无法使用的产品时。与基础相关的缺陷也已开始在我们的客户中出现。

在这种情况下，当前的过程不再使我们满意。某些东西必须更改。
我们首先提出了一些问题，这些问题使我们无法更好地测试更新。讨论之后，形成了以下问题列表：

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

此外，对于每个发现的问题，我们试图找到一个有价值的解决方案。除了解决我们为自己提出的特定问题外，我们在讨论过程中决定提出对测试过程本身的要求，我们希望在此基础上进一步开展工作。

该过程应该更加公开透明，为此，我们完全放弃了研究测试，转而使用测试用例。

要创建必要的测试用例，我们需要有关版本之间的更改的信息。需要从产品开发人员和分析师那里获取此信息。

在新方法中，我们结合了对系统对象的检查（在更新过程中未更改和更改）+功能的冒烟检查（旧的，新的或更改的旧检查）的组合。

对于升级，将选择安装系统最困难的选项-分布式安装。对于所有操作系统和数据库。在特殊情况下，省略了较简单的选项。

这些检查的组合将使我们有机会测试以下系统组件：

D B
Web（前端，后端）；
Linux组件

结果，我们提出的每个问题的解决方案如下：
没有足够的有关当前版本中更改的信息。对系统的了解不足，关于系统的信息不足。我们与分析人员和开发人员一起确定更新版本和当前版本之间产品的变化区域。

测试更新变成回归。执行功能测试，而不是执行系统对象及其上的操作。我们将以功能+数据验证的冒烟测试的形式测试测试用例的更新。

难以理解的报告。覆盖范围和结果可以取自测试用例。

该过程是不透明的。 解决了每个单独的问题之后，便形成了一个新的过程，该过程可以满足我们的需求，并且以一种使团队的每个成员现在都可以熟悉其原理的方式进行固定。

新工艺

结果，我们建立了一个相当有效的流程。

我们将测试分为几个阶段，这些阶段提供了更多的计划外奖金，如下所述：

训练。
- 我们分析系统的变化，并与分析人员和开发人员共同为变化的领域做好准备。
- 根据分析结果，我们编译了准备测试更新的系统对象列表。
- 对于每个系统对象，确定必要的状态，状态和参数集。
- 我们使用必要（更新）的产品版本来创建摊位。
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- 检查对象的操作（创建，编辑，删除）。
- 检查对象与其他对象的交互（检测）。

方法的利弊

我们已经实现了我们的目标，即：

该过程已变得透明。我们知道我们正在测试如何，需要多少时间以及将输出什么工件。我们收到了客观的标准，可以根据该标准做出有关有效或无效产品更新的判断。
报告变得清晰。测试用例的存在以及通过测试的结果的报告使我们可以快速向项目经理和技术总监报告所创建组件的质量。
比研究方法更大，更易理解的报道。
现在，我们正在测试数据和功能的更改。多亏了分析人员和开发人员的响应能力，我们才能以很高的准确性说出系统中发生了什么变化以及存在发现缺陷的风险。

但是，围绕着新的测试策略，我们不能不遇到新方法的明显缺点-测试时间大大增加。

我们开始将时间不仅用于直接测试，也用于研究测试。新的时间成本主要与测试准备相关，即：

变更分析；
创建，填充，维护展位以进行更新；
更新旧的测试套件并创建新的套件。

如果不是为了一个“而是”，那么这个负数很可能对决定放弃新方法具有决定性作用。

所有的准备工作（这是最耗时的阶段）可以在释放的最终成分形成后立即进行，即使没有最终产品也是如此。因此，我们根据测试计划“分散”了制剂，而不会导致过度饱和的预释放期。它仍然只需要通过最终稳定产品的测试。

总的来说，根据改进的第一阶段的结果，我们收到了以下信息：我们开始花更多的时间进行测试，但是与此同时，我们拥有透明的过程，清晰的结果显示和更多的覆盖范围，这使我们能够：

通过检查部门中的产品更新来检测更多缺陷；
减少实施工程师在更新客户时的缺陷数量；
减少从技术支持收到的缺陷数量。

下一步是什么？-关于优化

本来可以解决的，但是时间总是金钱。此外，根据新方法的首次破解结果，优化时间成本的方法变得更加清晰可见。

我们以两种方式进行：

基于测试运行分析的优化：此处我们致力于确定测试结果对所使用环境的明显和隐式依赖性。这就是功能测试的方法。
测试自动化。然后我们的自动化团队进行了救援。

我将进一步讨论每条路径。

第一种方法：基于对测试运行的分析进行优化：

我们选择优化主要版本之间的更新测试，即在功能发生重大变化的产品之间。

我们注意到的第一件事是依赖于数据库且仅依赖于数据库的测试。我们能够理解哪些检查足以在每个基础上进行一次检查，然后将其完全从带有OS的组合程序中排除。

第二步是将旧功能的体积检查“折叠”到检查列表中。在第一个迭代中，无论该功能是否出现在当前版本中，在以前的版本中还是始终存在，该功能都依赖于其自己的全面测试。现在，成熟的测试仅依赖于新功能，而旧功能则在清单中进行了检查。

此外，发布修补程序和修补程序时，相同的清单对我们非常有用，其中除了主要版本之间的更新外，检查版本中的更新也很重要。

第二种方式：测试自动化

首先，我想保留一点，我们不打算自动化测试更新，因为它被接受并且通常是很好的基调，但是因为更新是任何发行版都不能排除的测试类型，所以它是主要的发布，修补程序或修补程序。我们选择此路径以减少测试次要版本更新的时间，即补丁和修补程序，即版本之间，功能的组成不会改变。在这种情况下，测试自动化看起来非常有效。

在此阶段，发布补丁和修补程序时测试更新几乎是完全自动化的。

发行主要版本时的测试更新分为手动测试和自动测试。手动检查受功能影响的可变区域。不变区域的测试会自动进行，最常见的是更多地重用已经为先前版本编写的自动测试，而很少更新新版本。

为了开始测试用例的自动化过程，我们不得不进一步完善它们，因为手动测试器的测试语言所带来的困难要比自动测试所能承受的多得多。也就是说，我们还分配了时间来准备自动化测试，这几乎在最初的运行中就获得了回报。

摘要

我们有一个用于测试更新的研究过程。在某个时候，由于更新质量明显下降，他不再满足我们。我们没有选择研究测试的替代品作为现成的技术，而是根据我们发现的问题形成了替代品。我们使用并不断改进的新方法的形成受到问题的解决方案以及测试过程的普遍希望的影响。

我不认为在这种情况下，当我们沿着自己的流程创建专为我们的项目和产品功能量身定制的过程时，便发明了自行车。如果将流程分解为各个组成部分，则通常会获得普遍接受并广泛使用的技术。

尽管事实上我们收集的工作成果并不多，但从理解问题到引入新解决方案和优化测试的整个过程花了我们近两年的时间。

我们试图在这里诚实地描述所有利弊，以及我们决策的陷阱，以便使叙述看起来不仅仅像一个成功的故事“糟透了，而是变了样”。

我们希望您觉得我们的经验有用。

材料作者：特列佐娃（Ryzhova Tatyana）。

我们为什么以及如何测试更新

我们发布什么以及需要更新什么

历史上...

出问题了

新工艺

方法的利弊

下一步是什么？-关于优化

摘要

More articles: