质量保证

代码质量需要从多个角度进行把控。

文档辅助

代码规范

根据团队使用的编程语言和框架，可以在网上找到很多现成的代码规范文档，可以参考使用。

这里只写一些比较重要的点：

• Single source of truth
• 使用有意义的变量和函数名
• 单个函数体内容不可过多
• 保持代码简洁
• 注意模块化
• 添加必要但不冗余的注释（避免违背“Single source of truth”）

项目文档

对于复杂项目，一个项目介绍文档和对相关业务知识的介绍，可以大幅度减小新人对项目的理解，写代码时更有自信。

流程把控

版本控制

合适代码提交记录具有以下优点：

• 方便回滚代码
• 方便排查 Bug
  • 如果能定位到问题代码，可以很方便的直接定位出提交者，进一步了解详情协助排查
  • 如果无法定位到问题代码，但是bug可稳定复现，可以在明确无 bug 的提交记录到当前提交记录之间，通过二分法查找的思路来定位提交记录，缩小排查范围
  • 如果能定位到bug范围（比如某个页面），那可以优先将排查范围锁定到对应范围内的提交记录缩小排查范围

合适的分支管理具有以下优点：

• 代码冲突会引入强制人工 review
• 多 feature 分支并行开发可以方便多线并行迭代
• 分支的管理策略本身起到了隔离脏代码的作用，测试通过的分支代码才会被合并入主干分支

注意：如果代码无法定位到人，大家就会对代码失去敬畏之心。

Code Review

一个正经的项目，Code Review 一定需要人工介入，而且如果是比较大的变动，在时间允许的前提下，最好组织团队成员一起或轮流进行 Code Review。

需求评审

不合理的需求会对代码产生非常大的影响。

有些需求合理，但是如果风险较大，并且存在风险较小的替代方案时，应尽量争取。

脚本检测

Formatter

.editorconfig

.editorconfig 的存在是为了跨编辑器、IDE 统一代码风格。大部分开发工具及 Prettier 都内置了对该文件的支持，所以基本上不需要特意写脚本来处理该文件。

.editorconfig 示例文件

# EditorConfig is awesome: https://editorconfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8

# 4 space indentation
[*.py]
indent_style = space
indent_size = 4

# Tab indentation (no size specified)
[Makefile]
indent_style = tab

# Indentation override for all JS under lib directory
[lib/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2

Prettier

Prettier 是一个支持众多语言的通用代码格式化工具。

Linter

ESLint

ESLint 是一个代码质量检测工具，用于快速找出潜在的质量问题。

markdownlint

markdownlint 是一个使用 Node.js 实现的 Markdown linter 工具。

类型检测

TypeScript

Typescript 提供了非常好用的类型系统，可以在静态分析阶段提到代码质量。

Zod

Zod 可以实现运行时的 Schema 校验，配合 TypeScript 可以实现更可靠的类型校验。

构建验证

目前主流的前端构建工具是 Vite 和 Webpack。是否能构建成功，本身也是一种测试。有其对于 Vite 这种构建工具来说，在开发阶段如果问题页面没被访问到的话即使有问题也不会暴露出来。

Vite

Vite 是目前最主流的前端编译打包工具。

Webpack

Webpack 是 Gulp 之后、Vite 之前这段时期内前端构建工具里的绝对主流，即使目前仍然有不少项目在使用 Webpack。

测试

测试基本上可以认为是代码被真实用户使用前、验证代码质量的最后一环。

按测试阶段分类

单元测试 Unit Test

这是 ROI 最高的测试方式，但有适用场景，非常适合用于函数、方法、类的测试。

目的：提前拦截底层代码 bug。

集成测试 Integration Test

模块/接口之间联调：前后端接口、微服务之间、第三方 SDK 交互。

目的：解决模块调用、参数传递、数据交互问题。

系统测试 System Test

完整软件打包后整体测试，基于完整需求文档，覆盖全部功能、页面、流程。

目的：验证整体系统是否符合产品需求。

用户验收测试 UAT

• α 测试：开发环境，内部产品 / 测试人员模拟用户
• β 测试：线上灰度环境，真实外部用户试用

目的：确认产品满足业务使用，可上线。

按测试实现方式分类

手工测试

对于一个正式项目来说，人工测试是很重要的一环。因为有很多细节是很难甚至无法通过编程来实现测试目的的。

手工测试适用于界面交互、UI 美观、复杂业务流程、临时探索测试。

自动化测试

脚本代替人工，重复回归场景：

• 单元自动化：Jest、JUnit、Pytest
• 接口自动化：Postman、Apifox、Python+Requests
• UI 自动化：Selenium、Playwright、Appium

半自动化测试

人工操作 + 脚本辅助校验数据

按测试目标 / 测试类型分类

功能测试

验证软件功能是否和需求一致：正常流程、异常输入、边界值、报错提示、数据增删改查。

非功能测试/专项测试

性能测试

• 负载测试：逐步加压，看系统正常负载上限
• 压力测试：超高并发压测，找到系统崩溃临界点
• 稳定性测试（耐久测试）：长时间持续运行，观测内存泄漏、服务宕机
• 并发测试：多用户同时操作，处理并发锁、重复提交问题

工具：JMeter、Locust

兼容性测试

• 系统兼容：Windows/macOS/Linux、Android/iOS 各版本
• 浏览器兼容：Chrome、Edge、Safari、Firefox
• 设备兼容：手机、平板、不同分辨率屏幕
• 版本兼容：新旧客户端、新旧接口兼容

易用性 / UI 测试

界面布局、字体、颜色、操作逻辑是否符合用户习惯，有无页面错乱、交互卡顿。

安全测试

防 SQL 注入、XSS 跨站、权限越权、密码加密、接口防刷、敏感数据泄露、文件上传漏洞。

接口测试

单独校验前后端 API：请求参数、返回字段、状态码、异常参数、权限校验，是集成测试核心。

回归测试

版本迭代修改代码后，重新跑原有全部用例，验证新改动没有破坏旧功能（自动化最适合做回归）。

冒烟测试

版本打包后极简快速测试：核心流程能否跑通，程序能否正常启动，失败则直接打回，不开展详细测试。

探索式测试

无预设用例，测试人员自由操作，凭经验随机发掘隐藏 bug。

按代码可见性分类

白盒测试

测试人员可查看源码，关注代码逻辑、分支、循环、覆盖率；单元测试属于典型白盒。

黑盒测试

不看内部代码，只通过输入输出验证功能；系统测试、UAT 验收都是黑盒。

灰盒测试

兼顾接口、数据库、日志，不完全看底层源码，是日常最常用的测试（接口测试、集成测试）。

其他场景分类

• 灰度测试（金丝雀发布）：线上小流量用户测试，无问题再全量发布
• 混沌测试：主动模拟服务器宕机、网络中断、数据库故障，验证系统容灾能力
• 数据测试：校验数据库数据一致性、脏数据、数据迁移准确性

钩子

CI/CD