YACW 株式会社 - Alpha 冲刺测试随笔

[YACW株式会社]

这个作业属于哪个课程	2023 年福大-软件工程实践-W 班
这个作业要求在哪里	团队作业——站立式会议+alpha 冲刺
这个作业的目标	测试随笔
其他参考文献	无

目录

• 测试工具选择
• 测试工作安排
• Commit 阶段
• Pull Request 阶段
• 每日构建
• 测试用例设计
• 测试体会
• 项目测试评述

测试工具选择

我们使用 GitHub Actions、Docker Hub 作为 CI/CD (持续集成/持续部署) 工具；

使用 pre-commit 将测试工具与 git 相结合；

使用 EsLint 作为前端代码格式与语法的检查工具；

使用 golangci-lint 作为后端代码格式与语法的检查工具，gotest 作为单元测试、集成测试框架。

测试工作安排

我们小组将代码测试与编码紧密结合在一起，下面将介绍我们的开发流程是如何与测试相结合的。

Commit 阶段

我们在前端和后端仓库部署了 pre-commit 脚本。

当开发人员向分支提交代码（创建 commit）时，会自动运行对应语言的 Lint 工具，检查其代码格式与语法正确性。

若无法通过 pre-commit 测试，开发者将 无法 向分支提交代码，这保证了最直观的错误会留在本地，直到被修复。

pre-commit 检查大大减少了代码走查所消耗的时间。

前端 pro-commit 脚本

后端 pre-commit 脚本

Pull Request 阶段

当开发者积攒一定的 Commit，向 dev 分支开启 Pull Request 时，CI 系统会自动运行测试脚本：

• 前端 CI 将运行 EsLint 与 vite 构建测试，确认开发者提交的代码没有语法错误，且可以成功编译；
• 后端 CI 将运行 golangci-lint, gotest 与 go 构建测试，确认开发者提交的代码没有语法错误、可以通过所有单元/集成测试，且可以顺利编译为二进制程序。

前端 CI 测试运行记录

后端 CI 测试运行记录

在 CI 测试脚本通过后，该 Pull Request 还需要由 其他两名 开发者审查后，才可合并至 dev 分支。

Pull Request 阶段的两个检查任务可以保证每行代码经过机器及人工的检查，且并入 dev 分支的代码不会影响程序的编译、运行。

每日构建

在每天晚上的固定时间（一般是 11:00），我们会冻结今日的 dev 分支，合并所有通过检查和审查的提交，为今日的 dev 分支打上 tag，发布新 release 并开始自动构建与部署，也就是上述的 CD 环节。

自动构建方面，我们使用 GitHub Actions 编译前后端项目，构建成多个操作系统版本的 Docker 镜像，并上传至 Docker Hub。

自动部署方面，服务器会定期检索 Docker Hub，自动拉取最新的镜像并部署。

通过每日构建，我们可以第一时间拿到部署在生产环境的前后端应用，便于我们开展系统测试。

前端自动构建记录

服务器 Docker 化部署

测试用例设计

在 Alpha 冲刺阶段，我们对后端 API 进行了较为充分的测试。

对于可以确定范围的输入变量，我们使用三点法构建测试用例；对于字符串等无法确认输入范围的变量，我们尽可能多地考虑其输入情况，并针对每一种情况编写测试用例。

我们将在 Beta 冲刺阶段进一步加强测试用例的覆盖程度。

测试用例文档地址：https://github.com/yacw-team/yacw-backend/blob/dev/%E6%B5%8B%E8%AF%95%E6%96%87%E6%A1%A3.md

测试体会

我们随机采访了小组成员，下列为他们对此次项目采取持续集成测试的看法。

某前端同学：

当我的代码被 lint 拦下来的时候确实很恼火，但这次实践过程中，我们没有遇到一次 dev 分支代码跑不了的情况，挺神奇的。

某后端同学：

单元测试写起来真的真的很烦，尤其是每个 API 都要写四五个。但想到接下来每次提交都能清晰看到哪些 API 跑得了，哪些跑不了，很爽。

项目测试评述

从项目开发的过程中，我们可以清楚地看到，自动化测试对代码质量保证作出了巨大的贡献，这也是我们第一次做到了保证 dev 分支永远可以编译运行这一目标。

对后端接口严格测试带来的好处，在对接的过程中提现了出来，我们无需为后端无法运行、接口一跑就报错而苦恼了。