延续HL2018的一系列摘要。 Badoo的家伙（弗拉基米尔·
扬茨 （Vladimir
Yants）的狂热者和尼古拉·克拉普尼（Nikolai Krapivny））帮助我检查了这份
简编 ，为此，我非常感谢。 我希望这对报告信息的质量有积极的影响。
开发过程的特点：
开发人员的责任并不会随着后端的发布而结束。 在平台上实施之前，他负责。
有手动测试，但是客户端在发布时尚未准备就绪，并且发布（具有不可预测的延迟）。 我们通常不知道客户何时开始实施它。 有时（不经常）功能会在很长一段时间后开始执行。 因此，用手进行测试很困难，并非一帆风顺。 因此，需要自动测试。
测验
单元测试
用phpunit写。
测试一个小单元。 他们不去数据库或服务（它们不应该与任何东西交互）。
传统仍然存在并使测试过程变得复杂。
他们开发了softMocks库-它的所有钩子都包含/ require，并将其替换为已更改的库。
您可以结束任何方法：静态，私有，最终。
该库是开放源代码。
问题：软弹放松，并允许您编写未经测试的代码（并用测试覆盖它）。
接受规则：
- 新代码应该易于测试phpunit
- SoftMocks-极端情况（旧代码/长/昂贵/复杂）
我们来看这些规则的代码审查。
测试质量
变异测试
- 拿代码
- 进行代码覆盖
- 我们解析代码并应用变异（change + =>-; true => false，等等）
- 对于每个突变，我们运行一组测试。
- 如果测试失败，则大约。 如果不是这样，它们将不够有效。 我们了解，更改/添加测试。
有现成的解决方案（Humbug，Infection），但它们不适合（与softmocks不兼容，代码覆盖率很困难）。 因此，他们写了自己的书。
突变测试尚不能用于手动测试。 可从控制台手动运行。 现在我们正在CI管道中实现它，我们正在构建过程。 结果将在Habr上。
整合测试
结合测试多个组件的运行； 我们通过基础和/或服务检查工作。
数据库测试的标准方法（DBUnit）：
- 提升测试数据库
- 填满
- 运行测试
- 我们清理数据库
问题：
- 必须支持数据表和数据集（数据库内容的相关性）
- 准备数据库需要时间
- 并行启动使测试不稳定并导致死锁
解决方案：DBMocks库（自己的解决方案）
工作原理：
- 在setUp测试中使用SoftMocks拦截的DB驱动程序方法
- 从请求parsim db +表
- Tmpfs创建具有相同架构的临时表
- 所有查询仅进入临时表
- 在TearDown上，它们被删除。
该库很小，但尚未在开源中开放。
结果：
- 测试不能破坏原始表中的数据
- 测试彼此隔离（可以并行运行）
- 测试查询与MySQL版本的兼容性
API测试
- 模拟客户会话
- 能够发送后端请求
- 后端的响应几乎就像真实的客户一样
通常，此类测试需要授权用户。 它必须在测试之前创建，然后在测试之后删除。 这会带来其他风险（复制，后台任务）。
解决方案：我们汇集了一组测试用户。 了解了如何清洁它们。
测试用户与真实用户处于同一环境中，因为devel！= Prod。 必须隔离测试用户和实时用户。
为了隔离，已为该用户添加了is_test_user标志。 并且这些用户也被排除在分析和a / b测试结果之外。
可以通过将测试用户“送到南极洲”来使其更便宜，该地区没有人可以看到他们（企鹅除外）。
质量检查API
用于在api测试中准备环境的工具，本质上是后端中的后门，用于快速更改用户/环境设置。
- 有据可查的api方法
- 快速轻松地管理数据。
- 开发人员写后端
- 只能应用于测试用户。
允许用户更改不可变数据（例如，注册日期）。
需要保护：
- 在网络级别（仅可从办公室网络获得）
- 每个请求都会传递一个秘密，并检查其有效性
- 方法仅适用于测试用户。
HackerOne上有一个BugsBounty程序。 他们为发现的漏洞付费。 发现使用质量检查API的一种方法。
远程模拟
Moki用于远程后端。
在软模拟的基础上工作。 测试要求后端为模拟会话初始化。 收到请求后，后端将检查会话的mox列表，并使用SoftMocks应用它们。
测试示例：
API测试太方便了。 编写它们而不是单位是很诱人的。 但是API测试要慢得多。
通过了一套规则：
- API测试的目的是测试协议和集成
- 有效检查复杂流程
- 小变异性无法测试。
- 在代码审查中，我们也测试了测试。
UI测试
backend命令不写。
稳定后，Ui测试将覆盖该功能。
硒用于网络。 对于移动葫芦。
试运行
100,000个单元测试。 6,000个集成，14,000个api测试。
在1个流中，时间为40分钟/ 90分钟/ 10小时。
Made Cloud-运行测试的云。
测试在线程之间的分布：
- 您可以平等地使用（严重的是，所有测试都是不同的，结果时间部分不相等）
- 运行多个线程并一次输入一个phpunit测试（初始化开销。长！）
解决方案：
- 收集有关运行时的统计信息。
- 测试的布局，以便块运行不超过30秒
api测试的问题是时间长，资源很多，并且不允许其他人执行。
为了解决此问题，我们将云分为两部分：
- 仅运行快速测试。
- 运行两种类型的测试。
结果是加速了以下时间：
代码覆盖率运行
要执行哪些测试？ 将显示代码覆盖率。
- 我们得到分支差异
- 创建已修改文件的列表
- 获取这些文件的测试列表。
- 我们仅通过这些测试来运行套件。
主分支每天晚上覆盖一次。 结果（差异）将添加到数据库中。
优点：
- 我们运行更少的测试：更少的硬件负载和更快的测试反馈
- 您可以运行补丁测试。 这使您可以快速推出此修复程序。 在补丁程序中，速度是最重要的。
缺点：
- 后端每天发布2次。 午餐后，报道的意义不大（但是当您开始节拍时，我们始终会驾驶全套）。
- Api测试涵盖了广泛的范围。 对于他们来说，这种方法并不能提供太多的节省。
如果开发人员需要立即查看代码覆盖率，即可以在控制台中启动并立即获得针对特定文件/组件的覆盖范围的新指标的工具。
这被认为是棘手的：在coverege master上获取数据，添加所有修改后的测试，结果是一个已经考虑了覆盖率的小型套件。
总结
- 需要所有测试水平
- 数量！=质量。 做代码审查和变异测试
- 将测试用户与真实用户隔离开。
- 后端中的后端简化并加快了编写测试的速度
- 收集测试统计信息。
参考文献