测试只是一个了解业界软件技术发展的切入点，当然单纯从测试维度找提升产品/服务质量/TTM的思路不一定能直接找到可以试用的方案。另外学术界可能也有一些比较超前的理论方案，后续有时间再学习&更新。

测试维度的三段式思考：

第一段：测试方法论、测试策略、分层策略；
第二段：用例设计、维护；
第三段：和各类技术/平台/工具结合的应用，如：+CID、+云原生、+DevOps、+测试环境；

感谢武昆教练提供的素材和输入。

测试方法论/策略

Thoughtworks一页纸测试策略图测试分层策略/模型随着软件技术的迭代而发生改变。

一、技术

1.1 故障

1.1.1 基于风险的故障建模

基于风险的故障建模是一种用于了解系统发生故障的可能性、潜在影响和检测手段的方法。交付团队逐渐开始使用这种方法来设计和评估预防故障所需的控制措施。该方法源自故障模式与影响分析（FMEA）的实践。FMEA 是一种诞生于上世纪 40 年代的风险评分技术，成功运用于航空航天和汽车等建造复杂物理系统的行业中。与这些行业一样，软件故障也可能产生严重后果，例如危及人类健康和隐私。这就是为什么我们越来越需要对系统进行严格分析的原因。该方法首先识别可能的故障模式，然后对根本原因进行分析，并根据故障发生的可能性、影响的大小以及发现根本原因的概率给出评分。
设计影响系统70%的性能、可用性、安全和合规，而系统本身的运行只影响30%。
故障风险分析和缓减手段： Risk analysis and mitigation process

1.2 安全

1.2.1 攻击路径分析

攻击路径分析是一种分析和评估潜在攻击路径的安全分析方式，黑客可能按照这些来自组织内系统网络的潜在攻击路径进行攻击。此前的多数安全分析策略或工具主要聚焦在特定分线领域，例如错误的配置，脆弱的容器，和常见漏洞上。这些孤立的方法意味着团队们不能看到这些风险与技术栈上其他层的弱点组合产生的危险攻击路径。Orca、Wiz等工具在对这些攻击路径分析的基础上推出了一系列的平台服务，而且这些平台服务可以融入到CID流程中。

1.3 Test

1.3.1 对告警规则的单元测试

可观测性和监控对于软件团队至关重要。鉴于特定事件的不可预测性，创建具有复杂规则的准确告警机制至关重要。然而，只有当事件真实出现时，这些规则才能得到真正的验证。对告警规则的单元测试让团队通过预先、主动地测试和完善规则，来更好地定义规则，从而增加对规则的信心。这有助于减少误报，并确保报告真正的事件。Prometheus对告警规则进行单元测试

1.3.2 基于AI的测试

TBD

二、工具

2.1 Snyk

提供静态应用程序安全测试（SAST）和软件组件分析（SCA）测试，以帮助您在软件开发生命周期中寻找、修复和监控安全问题。 snyk

保护你的代码：使用 Snyk Open Source 修复开源依赖项中的漏洞，使用 Snyk Code 来修复源码中的漏洞；
保护你的容器：使用 Snyk Container 来修复容器镜像和 k8s 应用中存在的漏洞；
保护你的基础设施：使用 Snyk IaC 修复 Terraform、CloudFormation、Kubernetes 和 Azure 模板中存在的漏洞；

2.2 Checkov

是一个专门用于基础设施即代码（laC）的静态安全扫描器。

pip install checkov

通过checkov检测TF文件，结果输出如下所示：

Passed checks: 4, Failed checks: 0, Skipped checks: 0

Check: "Ensure all data stored in the S3 bucket is securely encrypted at rest"
 PASSED for resource: aws_s3_bucket.foo-bucket
 File: /example.tf:1-25


Check: "Ensure the S3 bucket has access logging enabled"
 PASSED for resource: aws_s3_bucket.foo-bucket
 File: /example.tf:1-25


Check: "Ensure all data stored in the S3 bucket have versioning enabled"
 PASSED for resource: aws_s3_bucket.foo-bucket
 File: /example.tf:1-25


Check: "S3 Bucket has an ACL defined which allows public access."
 PASSED for resource: aws_s3_bucket.foo-bucket
 File: /example.tf:1-25

2.3 容器结构测试（CST）

是由 Google 开发的一个工具，用于测试容器镜像的结构。CST 可以用于检查镜像文件系统中某个文件的存在或缺失，验证文件的内容，检查容器中发出的特定命令的输出或错误，并检查容器镜像的元数据（例如标签、入口点和命令），以确保符合 CIS Docker Benchmark 的规范。

2.4 Terratest

它是一个 Golang 库，用来简化基础设施代码的自动化测试编写。通过基础设施即代码的工具，例如 Terraform，你可以创建真实的基础设施组件（如服务器、防火墙或负载均衡器），在它们之上部署应用程序，并使用 Terratest 验证预期的行为。在测试结束后，Terratest 可以取消应用的部署并清理资源。我们的团队们认为这种测试基础设施组件的方式有助于提供对基础设施即代码的自信。它为常见基础设施测试任务提供了各种帮助函数和模式，包括：

Testing Terraform code
Testing Packer templates
Testing Docker images
Executing commands on servers over SSH
Working with AWS APIs
Working with Azure APIs
Working with GCP APIs
Working with Kubernetes APIs
Testing Helm Charts
Making HTTP requests
Running shell commands
And much more

2.5 KWOK（Kubernetes WithOut Kubelet）

是一个模拟虚拟节点和 pod 生命周期的工具，旨在测试 Kubernetes 集群的控制面板。在没有显著大型集群的情况下，很难对自定义 Kubernetes 控制器和操作器进行压力测试。在没有显著大型集群的情况下，很难对自定义 Kubernetes 控制器和操作器进行压力测试。然而，通过 KWOK，你可以在笔记本电脑上轻松设置一个拥有数千个节点的集群，而无需消耗大量 CPU 或内存资源。这种模拟支持节点类型和 pod 的不同配置，以测试各种场景和边缘情况。

2.6 localstack

功能齐全的本地 AWS 云堆栈。离线开发和测试你的云和无服务器应用程序。

三、平台

3.1 Orca

Orca 是一个专有的云安全平台，用于识别、优先级排序和修复安全风险和合规问题。它支持主流的云提供商和混合设置。Orca 拥有广泛的安全查询和规则，以持续监控已部署的工作负载，检测配置错误、漏洞和合规性问题。它支持云虚拟机、无服务器函数、容器以及已部署工作负载的 Kubernetes 上部署的应用。**共有 10 多个类别的 1,300 多个配置控制：包括身份验证、数据保护、日志记录和监控、网络配置、Kubernetes 配置和系统完整性。这些内置的安全规则会定期更新，以跟上不断演进的合规标准和威胁向量。**由于 Orca 无需代理，因此提供了良好的开发者体验，并且易于设置。 Orca alerts 另一个显著的特点是它促进了安全的左移。 Orca in CI 还可以单独扫描容器镜像和IAC模板并识别相关风险。 Scan images by Orca

3.2 Wiz

它能让用户在一个平台上预防、检测和应对安全风险和威胁。Wiz 能对尚未部署到生产环境的构建产物（容器镜像、基础设施代码）以及生产工作负载（容器、虚拟机和云服务）的错误配置、漏洞和泄漏的机密数据进行检测并发出警报。它还能将发现的问题置于特定客户的云环境的上下文中，使响应团队能够更好地了解问题并确定修复优先级。 wiz

2023年业内测试能力调研