一十一
发表于 2017-11-15 16:17:39
名称解释：
CT：持续测试
有些人可能会认为，除了理解明显的TestOps好处以外，它是成功发布和有效开发的关键。从我看到的关于这个主题的各种文章和书籍看来，还是存在没有明确持续测试（CT）的定义存在。
“持续测试是作为软件交付渠道的一部分执行自动化测试的过程，以获得与软件候选版本相关的业务风险的即时反馈。”
除探索性测试以外的每一个CT步骤都应该完全自动化并且尽可能经常运行。 基本上，如果我们的基础架构允许我们在每个分支的每一次提交之后运行每一个CT步骤，我们就应该充分利用这一点。 如果不能每晚进行CT。 CT应该使用Jenkins，TeamCity，Go，GitLab CI等工具整合到交付管道中。
我相信我们可以区分使CT完成的一些事情：
1.持续集成（CI）和单元测试
在主分支应用程序的每一次提交都应该被编译和构建之后。此时还应该执行单元测试，以尽可能快地提供反馈。如果发生故障，某些事件（邮件，松散通知）仅适用于团队或肇事者（变更导致失败的人）。单元测试快速并行执行是非常重要的。开发人员在开始下一个任务之前应该看到失败通知，以避免分心。单元测试应该由开发者编写（最好用TDD的方式），但Google测试博客建议测试人员在这方面有很强的技能。如果不好的做法（测试太慢，没有平行性，测试太少，没有遵循测试金字塔，测试质量差/可读性/可维护性），我们应该改变和改进。有时候也建议把集成/ E2E测试移到较低的水平来加速整个管道。
很少有作者将突变检测区分为独立的CT步骤。我不同意这一点。突变测试是一种检查单元测试效果的方法。我们基本上确保他们能够在逻辑恢复的情况下报告失败。
2.代码覆盖率和静态分析
在开发者向主分支提交代码之后，他应该被告知他的特性如何改变了整个代码覆盖率统计。 您可能会对此感到惊讶，但是在您的流程中引入游戏化元素通常会对单元测试的数量产生非常积极的影响。 没有一个开发者希望成为一个让统计数字恶化的落后者。
像SonarQube这样的静态代码分析工具也非常有用。 他们能够以自动化的方式进行非个人代码评估和白盒测试。 他们识别安全问题，错误，代码味道等。您不仅可以修改/删除现有规则，还可以添加新的规则。
理想情况下，您需要将静态代码分析工具与代码审阅过程集成 这使得审稿人可以集中于广泛的图片（架构，可维护性），而不是辩论如果给定的变量应该是最终的。
3.持续交付/自动部署
应用程序构建完成后，您要测试您的部署过程。理想情况下，应该以生产发布的方式进行。每天执行大量的测试环境部署可以让您确信您的发布管道工作正常。
4.整合/ E2E /可视化测试
在测试环境中成功部署应用程序后，您可以开始更高级别的测试。我将它们作为一个整体进行分析，因为测试用例的实际分布很大程度上取决于您的策略。一般来说，为了缩减昂贵的E2E / Selenium测试，您希望覆盖集成/ API级别的多种功能。这有时会造成视觉验证中的空白，这可以通过BackstopJS或Galen框架等工具来实现。
这里的重要节点：这个级别的测试应该由整个团队拥有，而不仅仅是测试人员。这意味着您的测试策略应该由您的项目中的每个人讨论并达成一致。
5.性能测试
随着功能测试，你想检查你的应用程序在重负载下如何做。 我正在计划在这个问题上的一个单独的职位，但在这一点上值得注意的是：
性能测试应该有独立的环境，尽可能接近生产 - 如果你不能实现这一点，通常更好的做生产环境的性能测试
这有时意味着你不能把性能测试添加到你的管道中。
6.安全测试（DevSecOps）
可怕的名字 - DevSecOps的最新趋势。 安全变得越来越重要，因为使用像Burp这样强大的工具，黑客越来越容易。 有时你可以通过将现有的工具集成到管道中来获得快速的胜利。 例子是OWASP依赖性检查，OWASP Zed攻击代理（ZAP）或Gauntlt。 如果您没有进行安全测试，强烈建议尽快启动。
7.探索性测试
时间是最具争议的话题 - 手动探索性测试。 在这里触发无尽辩论的词最有可能是“手动”的。 现在，我绝对不是手动活动的粉丝，但我也看到在熟练的探索性测试中的价值。 我认为在完成大功能和发布之前执行它们是值得的。
如果这一步有价值的话，经常评估一下 - 你不想让无用的手动活动减慢你的过程。
8.生产测试（TiP）
第六章：TestOps的先决条件与TiP的类型
你需要更多阅读丰满你的知识体系：
2214
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
