AIGC标识 第二次作业

软件工程作业报告：命令行文本计数统计程序 (Text-Counter)

项目 内容
这个作业属于哪个课程 https://edu.cnblogs.com/campus/zjlg/26rjjc
这个作业的目标 C++实现命令行文本计数及自动化测试
姓名-学号 季金哲 2024329301048
作业地址 https://gitee.com/mathlish/text-counter

一、 项目概述与仓库信息

本项目为软件工程课程实践作业，基于 C++ 开发了一款命令行文本计数统计工具（wc.exe）。项目不仅完成了基础的纯英文文本及代码文件统计功能，更在工程化层面进行了探索，实现了一套轻量级的自动化测试运行机制。

项目开源仓库：https://gitee.com/mathlish/text-counter
(注：项目内包含详细的 README 文档与完整源码，欢迎查阅)

二、 项目开发流程与版本更迭

项目全程使用 Git 进行版本控制，在 Gitee 仓库中通过 tag 标签留下了清晰的迭代印记，代码演进过程如下：

v0.1：空项目初始化

  • 改进点：项目起步阶段。完成了 Git 仓库的初始化与基础的空 README.md 文件建立，为后续开发打下基础。

v0.2：基础功能落地与工程结构规范化

相较于 v0.1 的空壳，v0.2 版本实现了质的飞跃：

  1. 核心功能实现：完成了 -c（字符数）、-w（单词数）、-s（句子数）的基础统计功能，并能妥善处理文件不存在等异常输入。
  2. 目录结构重构：摒弃了将文件全部堆在根目录的做法，将源码移入 src/，测试数据移入 tests/，使项目结构初具正规软件的雏形。
  3. 扩充测试用例：针对纯英文段落、含多重标点、空文件、纯空白等边界情况，手动编写了多组 .txt 测试数据。

v0.3：扩展功能实现与自动化测试机制引入（核心亮点）

在 v0.2 的基础上，v0.3 实现了向复杂代码文件统计的跨越，并重写了测试流程：

  1. 扩展功能升级：新增 -l（空行数）、-m（注释行数）、-k（代码行数）参数，能够准确识别单行注释（//）与多行注释（/* ... */），并提供了 -a 参数一键输出全部统计报告。
  2. 引入自动化测试机制：独立开发了 test_runner.exe，彻底告别了手动输入命令测试的低效模式，实现了代码提交前的“一键回归测试”。

三、 深度解析：自动化测试机制与单元测试的工程思想

在 v0.3 版本中，我专门开发了一个名为 test_runner.cpp 的测试运行器。在此，我想重点阐述一下这个设计的初衷及其与“单元测试”的内在联系。

为什么需要它？

在 v0.2 阶段，每次修改完代码，我都需要手动在终端依次敲下多条命令（如 wc.exe -w tests/test001.txt），然后用肉眼去核对输出的数字对不对。这种手动回归测试效率极低，且极易因为疏忽而漏测。

它的运作机制

test_runner.exe 充当了一个测试驱动（Test Driver）的角色。它在代码中预设了针对每一个测试用例的“预期结果”。运行时，它会自动通过系统命令调用主程序 wc.exe，抓取实际输出结果，并与预期结果进行精准的字符串比对。最终，它会以直观的报表形式输出哪些用例 [PASS]，哪些 [FAIL]，如果有错误，还会打印出具体的差异详情。

它与工业级“单元测试”的关系

严格意义上讲，工业界的单元测试（如使用 Google Test 等重型框架）是针对代码中的某个具体函数进行白盒级别的断言（Assert）测试，旨在隔离依赖、验证内部逻辑。

而我所实现的 test_runner.exe，在学术和工程范畴上更准确的称呼是“自动化黑盒测试”或“端到端集成测试”。虽然它没有引入庞大的第三方测试框架，但它完美契合了现代自动化测试的核心思想：

  1. 自动化执行：无需人工介入，一次编写反复运行。
  2. 断言比对（Assertion）：严格比对预期值与实际值。
  3. 测试报告（Report）：清晰反馈总体通过率与失败详情。

因此，虽然它达不到大厂工业级的绝对单元测试标准，但它具备的思路是非常正规且高效的。对于个人开发的小型 CLI 项目而言，这是一种极佳的工程实践，能够最大程度保证代码重构时的健壮性。

四、 全功能命令使用指南

为了方便测试与使用，以下列出了所有支持的参数及实际运行示例（基于编译好的 wc.exe）。

基本语法：wc.exe [参数] [文件名]

1. 基础统计功能

支持统计纯英文 .txt 文本的字符、单词及句子。

# 统计字符数 (不包含换行符)
> wc.exe -c tests/test001.txt
Characters: 70

# 统计单词数
> wc.exe -w tests/test001.txt
Words: 14

# 统计句子数 (以 . ! ? 结尾)
> wc.exe -s tests/test001.txt
Sentences: 4

2. 扩展统计功能 (v0.3 新增)

支持统计 C++ 源码等文本文件的行数情况。

# 统计空行数
> wc.exe -l tests/test101.cpp
Empty lines: 2

# 统计注释行数 (支持单行及块注释)
> wc.exe -m tests/test101.cpp
Comment lines: 4

# 统计代码行数
> wc.exe -k tests/test101.cpp
Code lines: 6

3. 综合统计与自动化测试

# 输出上述所有指标的综合报告
> wc.exe -a tests/test101.cpp
--- All Stats ---
Characters: 180
Words: 25
Sentences: 0
Empty lines: 2
Comment lines: 4
Code lines: 6

# 运行自动化测试框架 (一键执行所有黑盒测试用例)
> .\test_runner.exe
==================================================
        AUTOMATED TEST RUNNER (wc.exe)
==================================================
File                    Parameter       Status
--------------------------------------------------
tests/test001.txt       -w              [PASS]
tests/test001.txt       -s              [PASS]
tests/test001.txt       -c              [PASS]
tests/test003.txt       -w              [PASS]
tests/test003.txt       -c              [PASS]
tests/test001.txt       -x              [PASS]
--------------------------------------------------
--- ALL TESTS SUMMARY ---
Total : 6
Passed: 6 (True)
Failed: 0 (False)

All tests passed successfully! You are awesome!

五、 声明

⚠️ 声明： 本文及对应项目的开发过程中，在 Git 版本控制排错、项目目录结构规划以及自动化测试框架的逻辑设计上，参考了一些正规开源项目以及 AI 助手的建议与提示。项目的核心 C++ 业务代码由本人指导 Deepseek 编写并测试验证通过。

以下是核心部分提示词。

输出v0.2：

先v0.2 项目完成基础功能

输出v0.3:

我想增加一个功能。我记得有一个东西是关于测试的，但是我忘记叫什么了。我个人感受一下大概就是：制作一个exe，然后专门用来调用wc.exe测试所有的tests\*，然后可以输出总体测试的结果，类似这种格式（我自己想的）：
test001.txt -m/-s/.../-a/... 1 2 3...
test002.txt ...
...
--- ALL TESTS ---
true: ... false:...
然后还有输出哪些test错误在之后。
有没有这种东西？我感觉是挺正规的做法，但是我忘记这个流程叫什么名字了，我只是听到了这个专业名字当时，然后现在我打的这些内容都是我自己凭借名字自己想的大概流程。

输出博文：

那生成一个markdown博文，这是作业的要求。我个人的要求是：
1.清晰描述项目流程，关于git的配置则可以跳过或者简单略过因为我个人认为项目本体更重要。
2.需要描述v0.1（空项目，所以可以简单略述），v0.2 v0.3的功能（主要是相较于上一个版本做出了什么改进）
3.我需要你在对应v0.3的部分下重点描述test_runner.exe这个自动化测试机制，而且要描述清楚他和单元测试的关系，主要就是表达“我这个很好，很合格，很正规，虽然没有那种绝对的单元测试工业级别，但是至少也是有类似的思想”
4.额外需要给一个部分，专门描述出所有的功能使用：即类似于示例，不然别人也不知道怎么用它
5.特别注意这是提交作业的博文，而不是项目的README，所以你需要根据作业要求微调描述重心。
6.其它的地方我无要求你可以按作业要求描述，如果作业要求没有提及并且我也没有提及的部分，那就可以省略。
7.markdown发表在博客园，你不需要描述这个信息在博文中，这一条只是防止不同的博客网页的格式差异。
8.cpp的代码不需要出现，代码逻辑也不需要，我觉得想看的会自己去gitee仓库看而不是出现在作业博文中，不然内容太长了。
9.需要在文末声明AI！！！但是要合适恰当
10.请你回复的时候用代码块包裹便于我直接复制
posted @ 2026-11-01 18:09  Mathlish  阅读(12)  评论(0)    收藏  举报