大家好，我叫谢尔盖 我正在测试Yandex.Market前端。 我知道在Habr的读者中，有许多IT专家以某种方式与发布过程和测试有关。 我有一个问题要问你。 在您的实践中，有没有发生过长时间不生产功能的情况？ 您是否知道肿的释放物及其体积检查？
我想每个人都有。 3年前，我来到Yandex，我们的团队还很年轻，流程还没有完全建立。 我面对面遇到了这些问题。
照原样
当时，我们的产品团队没有特定的职责范围，仅参与为其创建的项目。 然后他们分崩离析。 测试也与开发团队无关。 它作为服务存在，并根据需要连接到项目。
只能手动检查任务，集成测试不稳定，自动测试的覆盖率很小。 支票持续了很长时间。 准备进行计算的任务池正在不断增长，并且可能达到巨大的规模。
至于发布，其中一位经理从事组装和计算。 我们与所有经理举行了会议，并决定将在下一版本中发布哪些内容以及可以推迟哪些内容。
他们随意地检查了释放：只要有时间检查它们，他都会检查。 重点是手动回归测试，该测试可能会持续几天。 尽管发布了一个自动测试包，并且有一个部门编写并支持了这些测试，但事实并非如此。
因此，已解决的问题落入测试范围，最多可以测试2天。 然后她进入了发行版，再检查了4天。 在生产中，任务最多只能在一周内完成。 很少有人喜欢它，因此有必要进行一些更改。 而最重要的更改是流程。
等高线
我们要做的第一件事是将轮廓划分为各个领域的专家团队。 与以前的团队不同，轮廓在项目结束后不会中断。 他们继续在自己的职责范围内产生新的项目和想法。
每个电路中有1至3名测试人员负责测试。 从构思到任务汇报，每个负责任的电路测试人员都在产品开发的各个阶段。
值班
为了组织发布的工作，我们在测试团队中引入了两个角色：发布向导和发布测试器。 作为发布主管，我们一次有4位测试员值班，每个人都参与发布职责。 对于这些角色中的每一个，我们都组织了工作时间表。
值班时出现的任务优先于测试电路中的产品功能。 为了使测试人员不必长时间等待就不会中断，发布任务安排如下：一个值班是从星期一到星期三，第二个值班是从星期三到星期五结束。 每班-4人，每个平台2人。
该文件
那文档呢？ 我们没有那么多，但确实如此。 例如，在推出功能时，我们与开发人员和管理人员一起确定最佳的自动测试数量。 如果我们无法使某些事情自动化，或者某个功能需要在没有自动测试的情况下立即发布，则会在所有Market验证案例的测试套件中编写一个案例，并在必要时将其包含在回归测试的发布测试套件中。
如果我们检查了错误修复程序，并且发现自动测试未写在该错误上，那么我们还设置了开发该任务的任务，编辑立即随写在其上的测试一起滚动。
在布置每个实验时，我们有一个清单，因为我们事先不知道实验是否会成功。
清单是对实验功能的一组肯定检查。 在实验进行期间，版本测试人员会在每个版本中使用它。 如果实验成功并且我们将其推广到100％的用户，则此清单也可以作为将来自动化任务的空白。
在检查发行版时，我们会根据发行版的复杂性和完整性来使用各种测试套件。 我们既有小型测试套件，又有数量最多的测试用例套件。 发布测试人员决定使用哪个测试套件。
在某些方面，我们还使用针对开发人员的肯定检查清单。 有了它，开发人员可以亲自检查任务并预见功能开发中的瓶颈。 如果测试人员对项目进行了更改，这将帮助新专家迅速加入该项目。 清单是在开发开始之前，计划任务之后立即编写的。
仅此而已。
我们如何测试任务
我们使用各种测试设计技术：等效类，边界值，成对测试，用户场景。 测试人员的专业知识也很重要。 市场是一台巨大的机器，您需要了解其所有零件的工作方式才能进行维修或改进。 例如，我们有4种类型的商品卡和6种类型的商品卡。 不知道这一点，就不可能定性地测试更改这些页面的任务。
自动测试在检查任务中起着重要作用。 我们为执行的每个任务运行功能自动测试，分析崩溃并报告错误。
在特殊情况下，当任务影响到Market的许多组件时，我们还会运行屏幕测试-它们可以帮助我们捕获错误。
任务验证完成后，我们发表评论说一切都很好，可以将任务放行。 在评论中，我们指出已编写了多少测试，或者我们说不需要测试，并将任务转换为“待发布”状态。
接下来，任务由发布向导拾取，并将其与其他经过验证的任务一起发送到发布中。 我们尝试用任务填充发行版，以便由4位测试人员在8小时内对其进行检查：其中2个是Market的触摸版，而2个是桌面版。 我们的目标是至少发布5个版本。 也就是说，将任务交付到产品的速度提高了5倍。
我们如何检查发布
我们通过检查自动测试和屏幕测试开始检查发布。 查看报告后，我们可以立即解决多达90％的问题。 我们分析测试的崩溃：如果它们与错误相关或在发行版中被票证破坏，我们将寻找可重现此崩溃的任务，并要求对其进行修复。 如果不这样做，则该任务不会落入发行版中。
测试也可能会自行死亡。 在这种情况下，我们从自动测试运行中关闭测试，并开始修复它的任务，并在必要时创建mox。
根据发行版中的任务，我们可以使用完整发行版测试套件，也可以完全拒绝手动回归。 该决定由发布测试人员做出。
如果发行版具有几个小的编辑，则在本地执行任务检查，并通过检查自动测试报告来替换手动回归。
不管发布和任务的完整性如何，发布测试人员团队都会检查目前在生产中以不同百分比的用户显示的实验。 使用由实验测试人员编写的清单。
完成所有检查后，发布测试人员会在注释中列出所有发布活动，并在必要时编写任务以修复损坏的测试。
发布主管分析启动报告（负载测试），如果发现错误增加，请重新启动它们。 如果这无济于事，他将寻找罪魁祸首或从值班开发商寻求帮助。
如果拍摄结果一切正常，则发布向导将打开Market的图表，并开始将发布发布到生产环境中。 需要监控图表，以免遗漏错误。
如果应将错误的增加归咎于发行版，则发行主版将其回滚并理解原因。 如果计划是正常的，则他完成发布并开始从现成的任务中收集新的计划。
追求最好
尽管一切正常，但您应该始终追求最好。 我们正处在一个更光明的未来连续交付的边缘，在该阶段中，任务将在生产中彼此平行地进行测试和推出，而无需中间阶段的发布。 这将使您在发布时不会被手表分心，并显着加快了向用户交付功能的速度。
我们决定分阶段切换到CD。 第一步是引入单一存储库，该存储库在一个发行版中将功能扩展到两个平台（触摸屏和台式机）。 这种方法对于开发和测试均具有优势。 我们花费更少的时间测试组件。 现在，任务集中在一处，使导航更加容易。 经理可以更轻松地进行导航，因为他知道在产品中推出发布任务的确切时机，并且在推出平台之间也不会产生任何抵触情绪。
CD的下一步将是引入“绿色伤口”。 对于测试人员检查的每张票证，将针对两种平台启动两种类型的测试：功能测试和屏幕测试。 所有测试都需要安装moki。 如果针对其中一个平台的测试失败，则该任务将不被视为已验证。 如果测试失败，则需要了解为什么会发生这种情况。 仅在没有掉落测试和没有成功完成所有检查的情况下，任务才会被发送到产品。
谢谢您的关注。 希望我们的经验对您有所帮助，我在评论中等待着您。