作者alan8656 (跌倒摔一跤)
看板Soft_Job
标题[请益] 单元测试用这样的方式进行合理吗?
时间Thu Aug 28 19:43:28 2025
最近被分配到要去做单元测试Unit test，然後我开始研究某V公司的测试工具，讨论编译
设定、trace32等模拟器如何运行。
然後大概过一个礼拜，研究有点卡顿，因为我第一次用单元测试，而且我不是负责那个专
案的程式专写。所以遇到一些link error有在询问V公司解决。
这时负责这个专案的程式担当来看我怎麽弄那麽久，然後跟我说，这个不需要设定什麽编
译。
????!!!!我的认知单元测试不是就是动态测试的一种，怎麽可能不用做编译的设定。
继续询问下他说不会直接跑在target上测，也不用到模拟器trace32，直接用一般的g++编
译器在电脑上跑就可以了，我们只是要"测逻辑"而已。
我有点半信半疑，觉得这个方式怪怪的，我看到的单元测试就是需要模拟实机，所以会需
要用到类似trace32这种模拟器，V公司的人也是跟我们说用这个。
然後更不可思议的是，他直接拿出一包程式，不是原本的专案程式，是经过他"整理过"的
专案程式，替除掉QT、freeRTOS...等等，剩下的程式型态类似於pseudocode的形式，他
说这样比较好编得过，然後可以测试程式逻辑。
????!!!!是这样子?这跟已经跟我认知的单元测试不同，这跟测试的概念也相违背了吧。
测试的目的是要"拿真的东西，去模拟的环境测试"，拿人为修过的程式下去测的意义是?
我现在看到单元测试的几个点
1.属於动态测试的一种，嵌入式系统可使用模拟器进行测试
2.改完程式当下可以马上看到设定好的测试结果
3.好的单元测试可以能够完全自动化
即使我是第一次接触单元测试，我怎麽看他叫我做的方法都不可能是正确的单元测试，然
後用手动整理过的程式下去测试是哪招?
我有提出质疑，他们可能觉得，客户就是要看报告，如果要做比较正确的单元测试之後在
其他比较简单的机种上面执行。
我真的不知道该说什麽，因为我没有很资深，在这方面也不是了解很多，看看各位的想法
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 115.43.108.100 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1756381410.A.DDC.html
1F：→ nh60211as: 可以不用纠结於名称是什麽，问清楚目标就好 08/28 19:51
2F：→ nh60211as: 但是个人经验在PC逻辑对不代表在板子上跑的就没问题 08/28 19:52
3F：→ alan8656: 现阶段的目的应该就真的只是要交一个报告给客户看，这08/28 19:57
4F：→ alan8656: 个单元测试是客户要求我们做才开始做的，这是本公司第08/28 19:57
5F：→ alan8656: 一个开始做单元测试的专案 08/28 19:57
6F：推 yamakazi: 我们单元测试指的是google gtest，专门测函数的 08/28 20:00
7F：推 strlen: 不要怀疑 单元测试就是只测逻辑08/28 20:02
8F：推 wulouise: unit test不用管硬体，只是测逻辑，你想测的单元是什麽08/28 20:44
9F：推 guanting886: 你的业主想要你们交Unit Test 报告确定逻辑没问题就08/28 20:51
10F：→ guanting886: 好，而你想要免费送到Integration/ System Test之上08/28 20:51
11F：→ guanting886: 我是没什麽意见 啊你还有时间在那里摸ㄇ08/28 20:51
12F：推 s0914714: 想办法让覆盖率高一点就好啦 至少能交差 08/28 20:53
13F：嘘 accessdenied: 你对单元测试的认知是错的，但他的做法也不算正确。08/28 21:06
14F：→ accessdenied: 单元测试要能切除所有的相依性，但事先没有想过这08/28 21:06
15F：→ accessdenied: 件事，等成品都已经写成一拖义大利面之後才开始弄 08/28 21:06
16F：→ accessdenied: 单元测试，是非常困难的！所以他的做法算是不得已08/28 21:06
17F：→ accessdenied: 的折衷办法。08/28 21:06
18F：嘘 B0988698088: 第一次用可不可以就闭嘴听负责人就好？ 是他负责又 08/28 21:33
19F：→ B0988698088: 不是你负责08/28 21:33
20F：→ indexcome: 你认知是错的，UT 只需要管 input output , 所以你喂08/28 22:51
21F：→ indexcome: 进去的是假资料也无所谓。08/28 22:51
22F：→ alan8656: 假资料我觉得没问题，但是我比较有疑虑的是他把要测试 08/28 22:58
23F：→ alan8656: 的程式修改後才去测这件事情。就像模拟考，考试是假的 08/28 22:58
24F：→ alan8656: ，可是人要是真的，这是我的想法 08/28 22:58
25F：→ wuyiulin: 我觉得他讲的比较对，你讲的还考虑 RTOS 有点接近整合08/28 23:13
26F：→ wuyiulin: 测试08/28 23:13
27F：→ wuyiulin: 然後就我的经验，基本上UT就是逻辑通就好，有可能用什 08/28 23:15
28F：→ wuyiulin: 麽套件你板子上没有的，那就是整合的事情 08/28 23:15
29F：→ wuyiulin: 这边 V公司不是写程式给你的，他是提供测试软体的厂商08/28 23:17
30F：→ wuyiulin: 吧？你程式自己公司写的自己公司要负责啊，为什麽会想08/28 23:17
31F：→ wuyiulin: 问 V公司？08/28 23:17
32F：→ alan8656: 当初不确定问题是出在程式还是工具上08/28 23:28
33F：推 lturtsamuel: 单元测试就是要测逻辑 你还牵扯环境不就是整合测试？08/28 23:28
34F：→ lturtsamuel: 程式修改也不是不行 弄个编译选项条件编译就好 尽量 08/28 23:30
35F：→ lturtsamuel: 贴近不是一定要一百趴贴近 现实没那麽完美的08/28 23:30
36F：→ lturtsamuel: 他这做法当然也不太对 他如果有办法把逻辑抽出来变成08/28 23:32
37F：→ lturtsamuel: 独立一包 理应把这包变成函式库让主程式用才对 08/28 23:32
38F：→ alan8656: 感谢大家的指点，这样看起来unit test要做的好，程式设08/28 23:44
39F：→ alan8656: 计一开始就要想到每个函式的独立运作性08/28 23:44
40F：推 brucetu: 你们两个都有错 你说的是整合测试 08/28 23:45
41F：→ brucetu: 我要更正一下 你同事有可能是对的08/28 23:46
42F：→ brucetu: 如果他是把逻辑抽出来 mock掉不需要测的部分 而且他没有08/28 23:47
43F：→ brucetu: 乱写测试 那你同事就是对的08/28 23:47
44F：→ brucetu: 完美的做法是包成函式库。碍於现实考量，我认为把程式码 08/28 23:48
45F：→ brucetu: 复制出来另一个专案，做好mock测过没问题这个做法可以接 08/28 23:49
46F：→ brucetu: 受，只是你以後要经常维护两边的东西一致会很辛苦也很容 08/28 23:49
47F：→ brucetu: 易出问题08/28 23:49
48F：→ brucetu: 然後你真的没必要这样埋头干半天才发现根本弄错方向，你08/28 23:55
49F：→ brucetu: 应该像AI一样做事，你在第一时间就该厘清你打算做什麽， 08/28 23:55
50F：→ brucetu: 条列出来，拿着你的工作计画去找负责人确认：「我打算这 08/28 23:55
51F：→ brucetu: 样这样做，你看有没有问题，没有问题我就照这样执行，有08/28 23:55
52F：→ brucetu: 遇到问题再讨论。」埋头苦干最後根本做错方向就是为什麽08/28 23:55
53F：→ brucetu: 资深员工宁愿把东西丢给AI做也不想带新人的原因。你过去08/28 23:55
54F：→ brucetu: 一周的表现就像一个收到请求之後要耗费长达一周才回应而08/28 23:55
55F：→ brucetu: 且还完全搞错方向的AI。建议不要再继续用这种埋头自干的08/28 23:55
56F：→ brucetu: 方式做事 08/28 23:55
57F：→ alan8656: 了解，我可能也要再去搞清楚整合测试以及单元测试的差08/29 00:06
58F：→ alan8656: 别。不要埋头苦干要先厘清问题这个道理我知道，但是什08/29 00:06
59F：→ alan8656: 麽都不懂就马上问人也是问不出东西，我通常是先做一点 08/29 00:06
60F：→ alan8656: 有遇到问题再问，我也还在抓这之间的平衡点。08/29 00:06
61F：→ brucetu: 关於如何拿捏问问题的时机，我想补充说明清楚一点，你需08/29 00:47
62F：→ brucetu: 要做的是回报你的状态，回报状态不是发问，不要求对方花 08/29 00:47
63F：→ brucetu: 时间给你解答，只是让他掌握你的动向，不用担心造成对方08/29 00:47
64F：→ brucetu: 反感。你可以至少两天一次主动寄信告诉前辈你正在做什麽08/29 00:47
65F：→ brucetu: ，或者预计要怎麽做，他就会发现你卡在错误的方向。我同08/29 00:47
66F：→ brucetu: 事每天甚至一天两次回报状态我觉得完全没问题。这不是要 08/29 00:47
67F：→ brucetu: 你去问对方「我该怎麽做」而是告知对方「我的计画是这样 08/29 00:47
68F：→ brucetu: 」所以你不用担心这样的讯息会打扰对方，没有大问题对方 08/29 00:47
69F：→ brucetu: 通常瞄一眼就关掉了，方向很歪的话就会跟你沟通。通常带08/29 00:47
70F：→ brucetu: 你的人不想让自己显得像控制狂天天盯你在做什麽，你不主08/29 00:47
71F：→ brucetu: 动回报就会演变成你辛苦白忙一周还被认定能力有问题。以 08/29 00:47
72F：→ brucetu: 你的例子你可能在第一天告诉前辈：「我正在处理oo的单元 08/29 00:47
73F：→ brucetu: 测试，需要花一些时间研究trace32的参数。」第二天告诉他08/29 00:47
74F：→ brucetu: ：「早安，关於oo的单元测试，由於编译有问题，我正在联08/29 00:47
75F：→ brucetu: 络厂商。」如果这是对的路径他两秒就关掉你的邮件了，不08/29 00:47
76F：→ brucetu: 会造成负担。记得每一封信要简短清楚写明你正在做的是哪08/29 00:47
77F：→ brucetu: 个模组，对方可没那个脑容量记得每个人是负责什麽部份。08/29 00:47
78F：→ brucetu: 就算你对一个工作项目一头雾水至少你也写得出「早安，进 08/29 00:47
79F：→ brucetu: 度回报，我今天要研究哪一块程式码」或是「我正在联络谁08/29 00:47
80F：→ brucetu: 」。只要你别直球叫对方告诉你答案，让他可以无压力的已08/29 00:48
81F：→ brucetu: 读不回，就不会踩到对方的雷。 08/29 00:48
82F：推 s0914714: 真正的问题是叫你做unit test 但你没做过就直接下去做08/29 00:52
83F：→ s0914714: 早期要导unit test 主管还特地开课教学让大家有共识08/29 00:53
84F：→ s0914714: 毕竟这种方法论还是有很多流派 所以大家有共识很重要 08/29 00:54
85F：→ ichunlai: 单元测试也要教喔...经典书籍就 unit testing principle08/29 01:00
86F：→ ichunlai: s practices and patterns，自己看08/29 01:00
87F：推 hackfox: 你扯到系统测试了08/29 01:30
88F：推 viper9709: brucetu讲得不错 08/29 01:39
89F：→ strlen: 不过呢 我觉得啦 等你认真研究UT一阵子之後呢 就会跟上面 08/29 01:44
90F：→ strlen: 报 我们这葛专案不要搞UT好不好 下一个新专案在搞吧 XD 08/29 01:45
91F：→ strlen: 为什麽要UT？其中一个最重要的理由就是强迫你解耦程式08/29 01:45
92F：→ strlen: 强迫你在写程式时把逻辑部份抽离 因为这样才能测试08/29 01:46
93F：→ strlen: 然後抽离时就会发现 整个系统架构就要大改 然後就....... 08/29 01:50
94F：推 a731977: mock data在单元测试很常见喔，看结果应该是你误会 08/29 01:52
95F：→ poison5566: 而且不是原本开发的team要补unit test 感觉困难重重08/29 04:32
96F：推 Deltak: 看起来像是刚出社会，怎麽会一周才发现方向错误08/29 08:19
97F：→ Deltak: 我们公司的Unit Test是开发者要自己写08/29 08:22
98F：→ Deltak: 因为如果写的方式不好测试，代表你需要重构08/29 08:22
99F：嘘 panda04056: 你要瞎搞可以在自己的side project搞08/29 08:28
100F：推 selph1120: 强烈建议新人们要认真看看 brucetu大 讲的内容 08/29 08:30
101F：→ selph1120: 沟通一直都是在这行业无法顺利的最大问题08/29 08:31
102F：→ kurtsgm: 兄弟 你是错了 而且都已经要2026了 这种小问题问AI就好..08/29 09:34
105F：嘘 MoonCode: 没有e2e前写unit大多是在自慰08/29 11:00
106F：→ alan8656: 抱歉，我可能问ai的方式有问题，我在po文前有把文章喂 08/29 11:20
107F：→ alan8656: 给ai，他是认同我这篇文章的看法，导致我错误的认知，08/29 11:20
108F：→ alan8656: 之後改进我问的方式08/29 11:20
110F：推 ppc: 开发者自己写UT才合理吧.. 08/29 11:29
111F：→ alan8656: 对，这也是我看到的，但是我被排除在开发者之外，我只 08/29 11:33
112F：→ alan8656: 是专门来帮忙unit test 的，然後又因为公司第一次导入 08/29 11:33
113F：→ alan8656: ，所以公司大家其实都没有很确定怎麽做08/29 11:33
114F：推 s0914714: 如果你说的属实 奉劝你快逃 叫你写ut然後被排除开发者外08/29 13:37
115F：→ s0914714: 先不说测的逻辑对不对 你光了解code就得浪费一堆时间吧 08/29 13:38
116F：推 s0914714: 还有就像大家说的 问清楚要做什麽 不是纠结名词 08/29 13:46
117F：推 ck237: 单元测试跟整合测试差很多也，你是不是搞不懂啊？08/29 15:02
118F：→ ck237: 单元测试就很简单，检查有没有无效判定式或例外，说白的就08/29 15:05
119F：→ ck237: 是检查有没有开发者不小心写了一个进不去的判定式而已，只08/29 15:05
120F：→ ck237: 要确保预设参数会出现相符的结果或例外，就是正确的08/29 15:05
121F：→ strlen: 真的是大开眼界 居然有公司 开发一组人 写UI另一组人 XDDD08/29 15:11
122F：→ strlen: 我der老天 还不快跑？ 08/29 15:11
123F：→ strlen: *UT08/29 15:11
124F：→ brucetu: 不觉得单元测试很简单 需求没有被定义清楚的函式很有可08/29 15:42
125F：→ brucetu: 能做了单元测试也是白做。同理，负责写单元测试的人如果 08/29 15:42
126F：→ brucetu: 不清楚被测物的正确行为是什麽，那测也是白测。交报告的08/29 15:42
127F：→ brucetu: 话只要每个路径都有走到就可以了没错，但每个路径都有走08/29 15:42
128F：→ brucetu: 到不表示那个函数是对的，最後老板会问你：啊不是有测试 08/29 15:42
129F：→ brucetu: ？啊测了一样会出问题？那干嘛浪费时间写测试？08/29 15:42
130F：→ brucetu: 很多时候测试程式码本身就是错的 只是在浪费时间而已08/29 15:44
131F：→ labbat: 开(ㄋㄧˋ)发(ㄒㄧㄤˋ)产(ㄍㄨㄥ)品(ㄔㄥˊ)的时候测试程08/29 15:56
132F：→ labbat: 式怎麽会浪放时间，一切的需求都是从测试程式定义出来的 08/29 15:57
133F：→ labbat: 打错字，浪费 08/29 15:57
134F：→ labbat: 如果有问题，那表示是需求的客制化就要回头问规格谁订的 08/29 15:59
135F：→ brucetu: 如果单元测试写错了，我们会在整合测试发现问题。如果整08/29 16:01
136F：→ brucetu: 合测试写错了，使用者会发现问题。所以很多时候单元测试08/29 16:01
137F：→ brucetu: 是多余的 我只是想表达这个常见的状况 08/29 16:01
138F：→ labbat: 多於要看代价呗，原则上单元测试是相当廉价的然後整合测试 08/29 16:02
139F：→ labbat: 甚至是系统测试在资源消耗上是相当昂贵的08/29 16:03
140F：→ labbat: 尤其是在挂勾一堆外挂和除错套件，系统测试就会天荒地老08/29 16:04
141F：→ labbat: 当然我放着给使用者当测试，就是死道友的概念08/29 16:05
142F：推 s0914714: 单元测试比较像开发时期的保护伞 避免改完bug又被改回来08/29 17:16
143F：推 Deltak: 单元测试很好用啊，怕东西改坏，就先写UT08/29 19:27
144F：推 EricTao: 不同意100楼 因为我觉得老人也要看w 08/29 19:32
145F：推 EricTao: 单元测试至少能帮助debug，就算写不完全或根本测错，至08/29 19:35
146F：→ EricTao: 少你看得到已经测过的部分，不用重新通灵08/29 19:35
147F：→ newhandfun: b大回得不错，可以回文造福类似的人 08/29 19:38
148F：推 NDark: brucetu是对的 测试老问题了 规格不清楚的东西没办法测08/29 19:46
149F：→ wuyiulin: 我支持单元测试很重要，如果整合系统跟做功能的人不同08/29 23:47
150F：→ wuyiulin: 更重要 08/29 23:47
151F：→ wuyiulin: 因为这样才知道到底是需求开错，还是程式写错08/29 23:47
152F：→ wuyiulin: 这是管理工作氛围很重要的一点，做系统的资深工程师或08/29 23:49
153F：→ wuyiulin: 是主管要扛起决策责任，不能整合出问题跑去怪做功能的08/29 23:49
154F：→ wuyiulin: 新人 08/29 23:49
155F：→ wuyiulin: 丢给使用者做整合测试，如果是内部需求，那情境可能还 08/29 23:51
156F：→ wuyiulin: 可以；如果是客户，这情况不妙 08/29 23:51
157F：→ brucetu: 讲是这样讲 谁家产品没被客户测出一堆问题的..08/30 13:58
158F：→ labbat: 退一万步来说交给客户检查问题了，但客户又不会端到嘴前08/30 17:08
159F：→ labbat: 喂食出错的根本原因，也不会教怎麽改成没问题的功能呗 08/30 17:08
感谢各位大大给的建议
简单用GPT总结如下
https://i.imgur.com/uzCXlUT.png
很感谢brucetu给的意见。我会再好好参考!
另外我要澄清一些对我的一些批评。
1.这个公司第一次导入unit test，那位资深同事虽然比我资深很多没错，但是他在这间
没做过UT的公司做10几年以上，我可以合理推测他也没有实际做过UT，然後看到他的方式
跟我google和问ChatGPT的结果相差不少。因为我也没有实际经验判断他的方法正不正确
，所以我最後想说丢上来给大家骂骂也好，了解一下实务上UT会怎麽进行
2.关於沟通的部分，我要替自己辩护一下，沟通也是要看对象看场合。我以前在前公司的
时候，觉得沟通就比这边顺利，也许那边的人比较契合，或是说上司指令比较明确。沟通
的方式对人和在不同场合会有所不同，在这间公司我还在调整要怎麽沟通会比较顺利
关於UT这件事情我整理一下我看下来的心得：
1.公司第一次要做UT，软体部没有说明UT的相关规划，然後叫一个非该专案设计的工程师
来替其他开发者做UT。这点看大家的留言很多认为这公司做的不太对，好几位大大叫我说
可以逃了....
2.看起来UT是测逻辑没错，但是各位大大提到事前应该要做好规划，看到大大提到抽出逻
辑、mock等方式，确实很合理。但是我看那位前辈的实作的方式，我看程式的感觉不是那
麽经过规划的方式...，感觉只是另外用手动复制出专案内程式，然後手动剃除其他相依
性程式，剩下接近pseudocode的东西。可能逻辑是一样的，但是未来改动程式还要另外维
护，也很难保证中间手动改动的逻辑不会变。
3.我会再多多了解整合测试、单元测试、端对端测试之间的差异
感谢大家的留言，让我更懂得各种软体测试的实际方向，感谢大家!
※ 编辑: alan8656 (115.43.108.100 台湾), 08/30/2025 19:10:17
※ 编辑: alan8656 (27.51.0.83 台湾), 08/30/2025 19:17:07
※ 编辑: alan8656 (27.51.0.83 台湾), 08/30/2025 19:19:24
160F：推 s0914714: 你前辈的做法的确是错的 怎麽是拔掉相依的程式 08/30 22:38
161F：→ s0914714: 每次改版都要自己手动拔 不仅太累而且也可能出错 08/30 22:38
162F：→ s0914714: 不过职场百百种啦 如果想在原公司生存就听主管的吧XD 08/30 22:40
163F：→ s0914714: 工作本来就不是做对的事 是做主管(业主)想要的事 08/30 22:41
164F：推 viper9709: 推工作是做业主想要的事XD 08/31 01:08
165F：推 rahit: 看你为谁服务 08/31 15:27
166F：→ rahit: 如果教你的是你老板听就是了 08/31 15:27
167F：→ acgotaku: 不要神话甚至依赖单元测试 把他当测试一部分就好 09/05 11:25
168F：→ acgotaku: 讲难听点一堆产品没测也上线跑爽爽 有测也不一定不会爆 09/05 11:26
169F：→ acgotaku: 尤其软韧跟硬体整合太大 主管没 care 就他觉得会爆也不 09/05 11:29
170F：→ acgotaku: 会是你这环节爆 issue 09/05 11:30
171F：推 selph1120: 各种测试之间的差异, 你看文章看影片或去上课, 都很难 09/08 10:06
172F：→ selph1120: 真正理解各自带给你的系统的益处是什麽, 我个人觉得这 09/08 10:06
173F：→ selph1120: 是需要经验累积的 09/08 10:06
174F：→ selph1120: 社群上各种概念或原则性的教学, 建议你都把它当作参考 09/08 10:07
175F：→ selph1120: 就好, 因为每个人负责的系统跟情境各自不同 09/08 10:08
176F：→ selph1120: 你碰到的case让你觉得困惑, 就问清楚为什麽要这样做 09/08 10:09
177F：→ selph1120: 厘清问题点在哪, 再去思考有没有优化的空间就好 09/08 10:09
178F：→ selph1120: 若case与你认知的"原则"或"概念"不同, 有时不代表它有 09/08 10:10
179F：→ selph1120: 问题, 大多都是因为有一些限制存在 09/08 10:11
180F：→ selph1120: 有时候当下不合你的"概念"或"原则"的做法, 其实是最适 09/08 10:11
181F：→ selph1120: 合该情境的最佳解 09/08 10:12
182F：→ selph1120: 看过太多新人满嘴都是头头是道的原则, 无视实务上各式 09/08 10:14
183F：→ selph1120: 各样五花八门的情境 09/08 10:14