适用于 PowerShell 7.0 及以上版本，需要 Pester v5+ 模块

随着基础设施即代码（IaC）的广泛采用，越来越多的团队使用 PowerShell DSC、Ansible、Terraform 等工具来定义和管理服务器配置。然而，写好了配置代码并不等于部署一定正确——就像应用代码需要单元测试一样，基础设施代码同样需要一套系统化的测试策略来保证部署结果与预期一致。

基础设施测试与传统软件测试有所不同：它验证的不是函数的输入输出，而是操作系统服务是否运行、端口是否监听、文件权限是否合规、注册表键值是否正确。这类测试通常在部署完成后执行，作为 CI/CD 流水线的最后防线，一旦发现异常就阻断发布或触发回滚。

Pester 是 PowerShell 生态中最强大的测试框架，其描述式语法（Describe / Context / It）天然适合编写基础设施验证用例。本文将从 Pester 基础设施测试框架的搭建、合规性测试套件的编写、到部署验证管道的集成，完整展示如何用 PowerShell 构建一套可靠的基础设施测试体系。

适用于 PowerShell 7.0 及以上版本

PowerShell 模块是代码复用和分发的核心单元。将常用的函数打包为模块，不仅可以让团队成员通过 Import-Module 一行命令加载全部功能，还能发布到 PowerShell Gallery（PSGallery）供全球社区使用。然而模块的质量直接影响使用者的信任度——一个没有测试覆盖的模块，任何一次改动都可能引入难以察觉的回归缺陷。

现代 PowerShell 模块开发已经形成了一套成熟的工程实践：使用 Plaster 脚手架工具初始化标准项目结构，用 Pester 测试框架编写单元测试和集成测试，再通过 CI/CD 流水线实现自动化构建、测试和发布。这套流程不仅能保证模块质量，还能让你在发布新版本时充满信心。

本文将从模块项目的标准结构入手，逐步展示 Pester 测试的编写方法，最后介绍如何将模块发布到 PSGallery 并接入 CI/CD 自动化流程。

适用于 PowerShell 7.0 及以上版本

在编写和维护大量 PowerShell 脚本时，你是否想过如何程序化地”理解”一段代码的结构？正则表达式只能处理文本层面的匹配，却无法识别变量的作用域、函数的调用关系或参数的传递方式。PowerShell 内置的 AST（Abstract Syntax Tree，抽象语法树）引擎正是为此而生——它将脚本源码解析为一棵结构化的对象树，每个节点都代表一个语法元素。

AST 是 PSScriptAnalyzer、PowerShell Editor Services（VS Code 的 PowerShell 扩展底层）等工具的核心技术。掌握了 AST，你就能编写自己的代码静态分析工具、自动化重构脚本，甚至构建自定义的代码质量检查规则，在 CI/CD 流水线中实现脚本质量门禁。

本文将从 AST 的基础解析入手，逐步展示代码分析实战，最后实现一个自动重构工具，帮助你把 AST 技术应用到日常开发和运维中。

适用于 PowerShell 5.1 及以上版本

编写 PowerShell 脚本时，很多人只关注”能不能跑通”，却忽略了代码的可读性、安全性和可维护性。变量命名不规范、使用了已弃用的 cmdlet、硬编码凭据等问题，在脚本量少时不容易暴露，但当团队协作或代码库膨胀到数百个脚本时，技术债务会迅速累积。

PSScriptAnalyzer 是 PowerShell 官方提供的静态代码分析工具，基于 .NET Compiler Platform 构建。它内置了数十条规则，覆盖代码风格、潜在 Bug、安全风险和性能问题等多个维度。每条规则都标注了严重级别（Error、Warning、Information），方便团队根据自身需求配置合适的检查策略。

本文将从 PSScriptAnalyzer 的基础使用入手，讲解如何开发自定义规则以满足团队编码规范，最后演示如何将它集成到 CI/CD 流水线中实现自动化的代码质量门控。

适用于 PowerShell 5.1 及以上版本

回顾这一年的技能连载，我们从基础命令一路走到了高级自动化场景。在实际生产环境中，能跑通一段脚本只是起点，让脚本在面对异常输入、网络波动、权限变更时依然稳定运行，才是工程师的真正功力。今天我们就来系统梳理 PowerShell 脚本编写的最佳实践。

这些实践并非教条，而是从大量生产故障中提炼出来的经验总结。遵循它们可以让你的脚本更健壮、更易维护，也让接手代码的同事少踩几个坑。无论你是刚入门的新手还是资深运维工程师，这些原则都值得时刻对照。

适用于 PowerShell 7.0 及以上版本

JSON 已经成为现代配置管理和数据交换的事实标准格式。无论是应用配置文件、CI/CD 流水线定义，还是 REST API 的请求与响应体，JSON 无处不在。然而 JSON 本身并不携带结构约束信息——一个字段是字符串还是数字、哪些字段是必填的、数值的合法范围是什么，这些都需要额外的手段来保证。

JSON Schema（RFC 8927）是一套标准化的 JSON 结构描述规范，可以用声明式的方式定义数据的形状、类型、约束和关系。相比于手写验证逻辑，使用标准的 JSON Schema 具有可复用、可共享、可版本化的优势，而且生态中有大量现成的工具和库。将 JSON Schema 验证集成到 PowerShell 脚本中，可以在自动化流水线的入口处拦截无效数据，避免后续环节出现难以排查的问题。

本文将介绍如何在 PowerShell 中利用 .NET 生态的 JsonSchema.NET 库，实现标准 JSON Schema 验证、高级条件约束以及批量配置文件的验证与报告生成。

适用于 PowerShell 5.1 及以上版本

适用于 PowerShell 5.1 及以上版本

在 PowerShell 生态中，Pester 已经成为事实上的测试框架标准。从简单的断言到复杂的端到端验证，Pester 能够覆盖各种测试场景。然而，许多开发者仅停留在 Should -Be 的基本用法上，对于 Mock、BeforeAll/AfterAll、参数化测试、Code Coverage 等高级特性缺乏了解。

随着 DevOps 实践的深入，持续集成流水线对自动化测试的要求越来越高。一份高质量的 Pester 测试套件不仅能捕捉回归缺陷，还能作为模块行为的”可执行文档”。掌握 Pester 的高级技巧，可以显著提升测试的可维护性、执行效率和覆盖广度。

本文将围绕四个高级主题展开：参数化测试（Data-Driven Tests）、Mock 与 Assert-VerifiableMock、自定义 Should 断言运算符，以及 Code Coverage 集成。每个主题都配有可直接运行的完整示例。

适用于 PowerShell 7.0 及以上版本

JSON 已经成为配置文件和 API 数据交换的事实标准，但 JSON 本身不包含类型和结构约束——一个字段应该是字符串还是数字、一个数组至少有几项、哪些字段是必填的，这些都需要额外的验证。JSON Schema 是一套标准的 JSON 结构描述语言，可以精确验证 JSON 数据的格式和内容。结合 PowerShell 的 JSON 处理能力，可以构建可靠的配置验证系统。

本文将讲解如何在 PowerShell 中实现 JSON Schema 验证和实用的数据校验工具。

适用于 PowerShell 5.1 及以上版本，需要 Pester 模块

单元测试不是可选项，而是生产级脚本的必需品——尤其是被多人调用、影响关键业务逻辑的函数。Pester 是 PowerShell 生态中事实上的测试框架，提供 Describe/Context/It 的 BDD 风格语法、Mock 能力、代码覆盖率统计。从简单的函数验证到复杂的模块测试，Pester 都能胜任。

本文将讲解 Pester 的高级用法，包括 Mock、参数过滤、代码覆盖率，以及测试驱动的开发实践。