[請益] 單元測試用這樣的方式進行合理嗎?
看板: Soft_Job
作者: alan8656 (跌倒摔一跤)
標題: [請益] 單元測試用這樣的方式進行合理嗎?
時間: 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 (臺灣) ※ 文章網址 ※
→
nh60211as :
可以不用糾結於名稱是什麼，問清楚目標就好
08/28 19:51
→
nh60211as :
但是個人經驗在PC邏輯對不代表在板子上跑的就沒問題
08/28 19:52
→
alan8656 :
現階段的目的應該就真的只是要交一個報告給客戶看，這
08/28 19:57
→
alan8656 :
個單元測試是客戶要求我們做才開始做的，這是本公司第
08/28 19:57
→
alan8656 :
一個開始做單元測試的專案
08/28 19:57
推
yamakazi :
我們單元測試指的是google
gtest，專門測函數的
08/28 20:00
推
strlen :
不要懷疑
單元測試就是只測邏輯
08/28 20:02
推
wulouise :
unit
test不用管硬體，只是測邏輯，你想測的單元是什麼
08/28 20:44
推
guanting886 :
你的業主想要你們交Unit
Test
報告確定邏輯沒問題就
08/28 20:51
→
guanting886 :
好，而你想要免費送到Integration/
System
Test之上
08/28 20:51
→
guanting886 :
我是沒什麼意見
啊你還有時間在那裡摸ㄇ
08/28 20:51
推
s0914714 :
想辦法讓覆蓋率高一點就好啦
至少能交差
08/28 20:53
噓
accessdenied :
你對單元測試的認知是錯的，但他的做法也不算正確。
08/28 21:06
→
accessdenied :
單元測試要能切除所有的相依性，但事先沒有想過這
08/28 21:06
→
accessdenied :
件事，等成品都已經寫成一拖義大利麵之後才開始弄
08/28 21:06
→
accessdenied :
單元測試，是非常困難的！所以他的做法算是不得已
08/28 21:06
→
accessdenied :
的折衷辦法。
08/28 21:06
噓
B0988698088 :
第一次用可不可以就閉嘴聽負責人就好？
是他負責又
08/28 21:33
→
B0988698088 :
不是你負責
08/28 21:33
→
indexcome :
你認知是錯的，UT
只需要管
input
output
,
所以你餵
08/28 22:51
→
indexcome :
進去的是假資料也無所謂。
08/28 22:51
→
alan8656 :
假資料我覺得沒問題，但是我比較有疑慮的是他把要測試
08/28 22:58
→
alan8656 :
的程式修改後才去測這件事情。就像模擬考，考試是假的
08/28 22:58
→
alan8656 :
，可是人要是真的，這是我的想法
08/28 22:58
→
wuyiulin :
我覺得他講的比較對，你講的還考慮
RTOS
有點接近整合
08/28 23:13
→
wuyiulin :
測試
08/28 23:13
→
wuyiulin :
然後就我的經驗，基本上UT就是邏輯通就好，有可能用什
08/28 23:15
→
wuyiulin :
麼套件你板子上沒有的，那就是整合的事情
08/28 23:15
→
wuyiulin :
這邊
V公司不是寫程式給你的，他是提供測試軟體的廠商
08/28 23:17
→
wuyiulin :
吧？你程式自己公司寫的自己公司要負責啊，為什麼會想
08/28 23:17
→
wuyiulin :
問
V公司？
08/28 23:17
→
alan8656 :
當初不確定問題是出在程式還是工具上
08/28 23:28
推
lturtsamuel :
單元測試就是要測邏輯
你還牽扯環境不就是整合測試？
08/28 23:28
→
lturtsamuel :
程式修改也不是不行
弄個編譯選項條件編譯就好
盡量
08/28 23:30
→
lturtsamuel :
貼近不是一定要一百趴貼近
現實沒那麼完美的
08/28 23:30
→
lturtsamuel :
他這做法當然也不太對
他如果有辦法把邏輯抽出來變成
08/28 23:32
→
lturtsamuel :
獨立一包
理應把這包變成函式庫讓主程式用才對
08/28 23:32
→
alan8656 :
感謝大家的指點，這樣看起來unit
test要做的好，程式設
08/28 23:44
→
alan8656 :
計一開始就要想到每個函式的獨立運作性
08/28 23:44
推
brucetu :
你們兩個都有錯
你說的是整合測試
08/28 23:45
→
brucetu :
我要更正一下
你同事有可能是對的
08/28 23:46
→
brucetu :
如果他是把邏輯抽出來
mock掉不需要測的部分
而且他沒有
08/28 23:47
→
brucetu :
亂寫測試
那你同事就是對的
08/28 23:47
→
brucetu :
完美的做法是包成函式庫。礙於現實考量，我認為把程式碼
08/28 23:48
→
brucetu :
複製出來另一個專案，做好mock測過沒問題這個做法可以接
08/28 23:49
→
brucetu :
受，只是你以後要經常維護兩邊的東西一致會很辛苦也很容
08/28 23:49
→
brucetu :
易出問題
08/28 23:49
→
brucetu :
然後你真的沒必要這樣埋頭幹半天才發現根本弄錯方向，你
08/28 23:55
→
brucetu :
應該像AI一樣做事，你在第一時間就該釐清你打算做什麼，
08/28 23:55
→
brucetu :
條列出來，拿著你的工作計畫去找負責人確認：「我打算這
08/28 23:55
→
brucetu :
樣這樣做，你看有沒有問題，沒有問題我就照這樣執行，有
08/28 23:55
→
brucetu :
遇到問題再討論。」埋頭苦幹最後根本做錯方向就是為什麼
08/28 23:55
→
brucetu :
資深員工寧願把東西丟給AI做也不想帶新人的原因。你過去
08/28 23:55
→
brucetu :
一週的表現就像一個收到請求之後要耗費長達一週才回應而
08/28 23:55
→
brucetu :
且還完全搞錯方向的AI。建議不要再繼續用這種埋頭自幹的
08/28 23:55
→
brucetu :
方式做事
08/28 23:55
→
alan8656 :
了解，我可能也要再去搞清楚整合測試以及單元測試的差
08/29 00:06
→
alan8656 :
別。不要埋頭苦幹要先釐清問題這個道理我知道，但是什
08/29 00:06
→
alan8656 :
麼都不懂就馬上問人也是問不出東西，我通常是先做一點
08/29 00:06
→
alan8656 :
有遇到問題再問，我也還在抓這之間的平衡點。
08/29 00:06
→
brucetu :
關於如何拿捏問問題的時機，我想補充說明清楚一點，你需
08/29 00:47
→
brucetu :
要做的是回報你的狀態，回報狀態不是發問，不要求對方花
08/29 00:47
→
brucetu :
時間給你解答，只是讓他掌握你的動向，不用擔心造成對方
08/29 00:47
→
brucetu :
反感。你可以至少兩天一次主動寄信告訴前輩你正在做什麼
08/29 00:47
→
brucetu :
，或者預計要怎麼做，他就會發現你卡在錯誤的方向。我同
08/29 00:47
→
brucetu :
事每天甚至一天兩次回報狀態我覺得完全沒問題。這不是要
08/29 00:47
→
brucetu :
你去問對方「我該怎麼做」而是告知對方「我的計畫是這樣
08/29 00:47
→
brucetu :
」所以你不用擔心這樣的訊息會打擾對方，沒有大問題對方
08/29 00:47
→
brucetu :
通常瞄一眼就關掉了，方向很歪的話就會跟你溝通。通常帶
08/29 00:47
→
brucetu :
你的人不想讓自己顯得像控制狂天天盯你在做什麼，你不主
08/29 00:47
→
brucetu :
動回報就會演變成你辛苦白忙一週還被認定能力有問題。以
08/29 00:47
→
brucetu :
你的例子你可能在第一天告訴前輩：「我正在處理oo的單元
08/29 00:47
→
brucetu :
測試，需要花一些時間研究trace32的參數。」第二天告訴他
08/29 00:47
→
brucetu :
：「早安，關於oo的單元測試，由於編譯有問題，我正在聯
08/29 00:47
→
brucetu :
絡廠商。」如果這是對的路徑他兩秒就關掉你的郵件了，不
08/29 00:47
→
brucetu :
會造成負擔。記得每一封信要簡短清楚寫明你正在做的是哪
08/29 00:47
→
brucetu :
個模組，對方可沒那個腦容量記得每個人是負責什麼部份。
08/29 00:47
→
brucetu :
就算你對一個工作項目一頭霧水至少你也寫得出「早安，進
08/29 00:47
→
brucetu :
度回報，我今天要研究哪一塊程式碼」或是「我正在聯絡誰
08/29 00:47
→
brucetu :
」。只要你別直球叫對方告訴你答案，讓他可以無壓力的已
08/29 00:48
→
brucetu :
讀不回，就不會踩到對方的雷。
08/29 00:48
推
s0914714 :
真正的問題是叫你做unit
test
但你沒做過就直接下去做
08/29 00:52
→
s0914714 :
早期要導unit
test
主管還特地開課教學讓大家有共識
08/29 00:53
→
s0914714 :
畢竟這種方法論還是有很多流派
所以大家有共識很重要
08/29 00:54
→
ichunlai :
單元測試也要教喔...經典書籍就
unit
testing
principle
08/29 01:00
→
ichunlai :
s
practices
and
patterns，自己看
08/29 01:00
推
hackfox :
你扯到系統測試了
08/29 01:30
推
viper9709 :
brucetu講得不錯
08/29 01:39
→
strlen :
不過呢
我覺得啦
等你認真研究UT一陣子之後呢
就會跟上面
08/29 01:44
→
strlen :
報
我們這葛專案不要搞UT好不好
下一個新專案在搞吧
XD
08/29 01:45
→
strlen :
為什麼要UT？其中一個最重要的理由就是強迫你解耦程式
08/29 01:45
→
strlen :
強迫你在寫程式時把邏輯部份抽離
因為這樣才能測試
08/29 01:46
→
strlen :
然後抽離時就會發現
整個系統架構就要大改
然後就.......
08/29 01:50
推
a731977 :
mock
data在單元測試很常見喔，看結果應該是你誤會
08/29 01:52
→
poison5566 :
而且不是原本開發的team要補unit
test
感覺困難重重
08/29 04:32
推
Deltak :
看起來像是剛出社會，怎麼會一週才發現方向錯誤
08/29 08:19
→
Deltak :
我們公司的Unit
Test是開發者要自己寫
08/29 08:22
→
Deltak :
因為如果寫的方式不好測試，代表你需要重構
08/29 08:22
噓
panda04056 :
你要瞎搞可以在自己的side
project搞
08/29 08:28
推
selph1120 :
強烈建議新人們要認真看看
brucetu大
講的內容
08/29 08:30
→
selph1120 :
溝通一直都是在這行業無法順利的最大問題
08/29 08:31
→
kurtsgm :
兄弟
你是錯了
而且都已經要2026了
這種小問題問AI就好..
08/29 09:34
噓
MoonCode :
沒有e2e前寫unit大多是在自慰
08/29 11:00
→
alan8656 :
抱歉，我可能問ai的方式有問題，我在po文前有把文章餵
08/29 11:20
→
alan8656 :
給ai，他是認同我這篇文章的看法，導致我錯誤的認知，
08/29 11:20
→
alan8656 :
之後改進我問的方式
08/29 11:20
推
ppc :
開發者自己寫UT才合理吧..
08/29 11:29
→
alan8656 :
對，這也是我看到的，但是我被排除在開發者之外，我只
08/29 11:33
→
alan8656 :
是專門來幫忙unit
test
的，然後又因為公司第一次導入
08/29 11:33
→
alan8656 :
，所以公司大家其實都沒有很確定怎麼做
08/29 11:33
推
s0914714 :
如果你說的屬實
奉勸你快逃
叫你寫ut然後被排除開發者外
08/29 13:37
→
s0914714 :
先不說測的邏輯對不對
你光了解code就得浪費一堆時間吧
08/29 13:38
推
s0914714 :
還有就像大家說的
問清楚要做什麼
不是糾結名詞
08/29 13:46
推
ck237 :
單元測試跟整合測試差很多也，你是不是搞不懂啊？
08/29 15:02
→
ck237 :
單元測試就很簡單，檢查有沒有無效判定式或例外，說白的就
08/29 15:05
→
ck237 :
是檢查有沒有開發者不小心寫了一個進不去的判定式而已，只
08/29 15:05
→
ck237 :
要確保預設參數會出現相符的結果或例外，就是正確的
08/29 15:05
→
strlen :
真的是大開眼界
居然有公司
開發一組人
寫UI另一組人
XDDD
08/29 15:11
→
strlen :
我der老天
還不快跑？
08/29 15:11
→
strlen :
*UT
08/29 15:11
→
brucetu :
不覺得單元測試很簡單
需求沒有被定義清楚的函式很有可
08/29 15:42
→
brucetu :
能做了單元測試也是白做。同理，負責寫單元測試的人如果
08/29 15:42
→
brucetu :
不清楚被測物的正確行為是什麼，那測也是白測。交報告的
08/29 15:42
→
brucetu :
話只要每個路徑都有走到就可以了沒錯，但每個路徑都有走
08/29 15:42
→
brucetu :
到不表示那個函數是對的，最後老闆會問你：啊不是有測試
08/29 15:42
→
brucetu :
？啊測了一樣會出問題？那幹嘛浪費時間寫測試？
08/29 15:42
→
brucetu :
很多時候測試程式碼本身就是錯的
只是在浪費時間而已
08/29 15:44
→
labbat :
開(ㄋㄧˋ)發(ㄒㄧㄤˋ)產(ㄍㄨㄥ)品(ㄔㄥˊ)的時候測試程
08/29 15:56
→
labbat :
式怎麼會浪放時間，一切的需求都是從測試程式定義出來的
08/29 15:57
→
labbat :
打錯字，浪費
08/29 15:57
→
labbat :
如果有問題，那表示是需求的客製化就要回頭問規格誰訂的
08/29 15:59
→
brucetu :
如果單元測試寫錯了，我們會在整合測試發現問題。如果整
08/29 16:01
→
brucetu :
合測試寫錯了，使用者會發現問題。所以很多時候單元測試
08/29 16:01
→
brucetu :
是多餘的
我只是想表達這個常見的狀況
08/29 16:01
→
labbat :
多於要看代價唄，原則上單元測試是相當廉價的然後整合測試
08/29 16:02
→
labbat :
甚至是系統測試在資源消耗上是相當昂貴的
08/29 16:03
→
labbat :
尤其是在掛勾一堆外掛和除錯套件，系統測試就會天荒地老
08/29 16:04
→
labbat :
當然我放著給使用者當測試，就是死道友的概念
08/29 16:05
推
s0914714 :
單元測試比較像開發時期的保護傘
避免改完bug又被改回來
08/29 17:16
推
Deltak :
單元測試很好用啊，怕東西改壞，就先寫UT
08/29 19:27
推
EricTao :
不同意100樓
因為我覺得老人也要看w
08/29 19:32
推
EricTao :
單元測試至少能幫助debug，就算寫不完全或根本測錯，至
08/29 19:35
→
EricTao :
少你看得到已經測過的部分，不用重新通靈
08/29 19:35
→
newhandfun :
b大回得不錯，可以回文造福類似的人
08/29 19:38
推
NDark :
brucetu是對的
測試老問題了
規格不清楚的東西沒辦法測
08/29 19:46
→
wuyiulin :
我支持單元測試很重要，如果整合系統跟做功能的人不同
08/29 23:47
→
wuyiulin :
更重要
08/29 23:47
→
wuyiulin :
因為這樣才知道到底是需求開錯，還是程式寫錯
08/29 23:47
→
wuyiulin :
這是管理工作氛圍很重要的一點，做系統的資深工程師或
08/29 23:49
→
wuyiulin :
是主管要扛起決策責任，不能整合出問題跑去怪做功能的
08/29 23:49
→
wuyiulin :
新人
08/29 23:49
→
wuyiulin :
丟給使用者做整合測試，如果是內部需求，那情境可能還
08/29 23:51
→
wuyiulin :
可以；如果是客戶，這情況不妙
08/29 23:51
→
brucetu :
講是這樣講
誰家產品沒被客戶測出一堆問題的..
08/30 13:58
→
labbat :
退一萬步來說交給客戶檢查問題了，但客戶又不會端到嘴前
08/30 17:08
→
labbat :
餵食出錯的根本原因，也不會教怎麼改成沒問題的功能唄
08/30 17:08
感謝各位大大給的建議
推
s0914714 :
你前輩的做法的確是錯的
怎麼是拔掉相依的程式
08/30 22:38
簡單用GPT總結如下
→
s0914714 :
每次改版都要自己手動拔
不僅太累而且也可能出錯
08/30 22:38
→
s0914714 :
不過職場百百種啦
如果想在原公司生存就聽主管的吧XD
08/30 22:40
很感謝brucetu給的意見。我會再好好參考!
→
s0914714 :
工作本來就不是做對的事
是做主管(業主)想要的事
08/30 22:41
另外我要澄清一些對我的一些批評。
推
viper9709 :
推工作是做業主想要的事XD
08/31 01:08
1.這個公司第一次導入unit
test，那位資深同事雖然比我資深很多沒錯，但是他在這間
推
rahit :
看你為誰服務
08/31 15:27
沒做過UT的公司做10幾年以上，我可以合理推測他也沒有實際做過UT，然後看到他的方式
→
rahit :
如果教你的是你老闆聽就是了
08/31 15:27
跟我google和問ChatGPT的結果相差不少。因為我也沒有實際經驗判斷他的方法正不正確
→
acgotaku :
不要神話甚至依賴單元測試
，所以我最後想說丟上來給大家罵罵也好，了解一下實務上UT會怎麼進行
→
acgotaku :
講難聽點一堆產品沒測也上線跑爽爽
有測也不一定不會爆
09/05 11:26
2.關於溝通的部分，我要替自己辯護一下，溝通也是要看對象看場合。我以前在前公司的
→
acgotaku :
尤其軟韌跟硬體整合太大
主管沒
care
就他覺得會爆也不
09/05 11:29
時候，覺得溝通就比這邊順利，也許那邊的人比較契合，或是說上司指令比較明確。溝通
→
acgotaku :
會是你這環節爆
issue
09/05 11:30
的方式對人和在不同場合會有所不同，在這間公司我還在調整要怎麼溝通會比較順利
推
selph1120 :
各種測試之間的差異,
你看文章看影片或去上課,
都很難
09/08 10:06
關於UT這件事情我整理一下我看下來的心得：
→
selph1120 :
真正理解各自帶給你的系統的益處是什麼,
我個人覺得這
09/08 10:06
1.公司第一次要做UT，軟體部沒有說明UT的相關規劃，然後叫一個非該專案設計的工程師
→
selph1120 :
是需要經驗累積的
09/08 10:06
來替其他開發者做UT。這點看大家的留言很多認為這公司做的不太對，好幾位大大叫我說
→
selph1120 :
社群上各種概念或原則性的教學,
建議你都把它當作參考
09/08 10:07
可以逃了....
→
selph1120 :
就好,
因為每個人負責的系統跟情境各自不同
09/08 10:08
2.看起來UT是測邏輯沒錯，但是各位大大提到事前應該要做好規劃，看到大大提到抽出邏
→
selph1120 :
你碰到的case讓你覺得困惑,
就問清楚為什麼要這樣做
09/08 10:09
輯、mock等方式，確實很合理。但是我看那位前輩的實作的方式，我看程式的感覺不是那
→
selph1120 :
釐清問題點在哪,
再去思考有沒有優化的空間就好
09/08 10:09
麼經過規劃的方式...，感覺只是另外用手動複製出專案內程式，然後手動剃除其他相依
→
selph1120 :
若case與你認知的"原則"或"概念"不同,
有時不代表它有
09/08 10:10
性程式，剩下接近pseudocode的東西。可能邏輯是一樣的，但是未來改動程式還要另外維
→
selph1120 :
問題,
大多都是因為有一些限制存在
09/08 10:11
護，也很難保證中間手動改動的邏輯不會變。
→
selph1120 :
有時候當下不合你的"概念"或"原則"的做法,
其實是最適
09/08 10:11
3.我會再多多了解整合測試、單元測試、端對端測試之間的差異
→
selph1120 :
合該情境的最佳解
09/08 10:12
感謝大家的留言，讓我更懂得各種軟體測試的實際方向，感謝大家!
→
selph1120 :
看過太多新人滿嘴都是頭頭是道的原則,
無視實務上各式
09/08 10:14
※ 編輯: alan8656 (115.43.108.100 臺灣), 08/30/2025 19:10:17
→
selph1120 :
各樣五花八門的情境
09/08 10:14
※ 編輯: alan8656 (27.51.0.83 臺灣), 08/30/2025 19:17:07
※ 編輯: alan8656 (27.51.0.83 臺灣), 08/30/2025 19:19:24