PTT職涯區 / Soft_Job (軟體人)

[請益] 單元測試用這樣的方式進行合理嗎?

看板Soft_Job (軟體人)作者 (跌倒摔一跤)時間2周前 (2025/08/28 19:43), 2周前編輯推噓21(25推 4噓 137→)
留言166則, 30人參與, 2周前最新討論串1/1
最近被分配到要去做單元測試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://www.ptt.cc/bbs/Soft_Job/M.1756381410.A.DDC.html
→
08/28 19:51, 2周前 , 1F
可以不用糾結於名稱是什麼，問清楚目標就好
08/28 19:51, 1F
→
08/28 19:52, 2周前 , 2F
但是個人經驗在PC邏輯對不代表在板子上跑的就沒問題
08/28 19:52, 2F
→
08/28 19:57, 2周前 , 3F
現階段的目的應該就真的只是要交一個報告給客戶看，這
08/28 19:57, 3F
→
08/28 19:57, 2周前 , 4F
個單元測試是客戶要求我們做才開始做的，這是本公司第
08/28 19:57, 4F
→
08/28 19:57, 2周前 , 5F
一個開始做單元測試的專案
08/28 19:57, 5F
推
08/28 20:00, 2周前 , 6F
我們單元測試指的是google gtest，專門測函數的
08/28 20:00, 6F
推
08/28 20:02, 2周前 , 7F
不要懷疑 單元測試就是只測邏輯
08/28 20:02, 7F
推
08/28 20:44, 2周前 , 8F
unit test不用管硬體，只是測邏輯，你想測的單元是什麼
08/28 20:44, 8F
推
08/28 20:51, 2周前 , 9F
你的業主想要你們交Unit Test 報告確定邏輯沒問題就
08/28 20:51, 9F
→
08/28 20:51, 2周前 , 10F
好，而你想要免費送到Integration/ System Test之上
08/28 20:51, 10F
→
08/28 20:51, 2周前 , 11F
我是沒什麼意見 啊你還有時間在那裡摸ㄇ
08/28 20:51, 11F
推
08/28 20:53, 2周前 , 12F
想辦法讓覆蓋率高一點就好啦 至少能交差
08/28 20:53, 12F
噓
08/28 21:06, 2周前 , 13F
你對單元測試的認知是錯的，但他的做法也不算正確。
08/28 21:06, 13F
→
08/28 21:06, 2周前 , 14F
單元測試要能切除所有的相依性，但事先沒有想過這
08/28 21:06, 14F
→
08/28 21:06, 2周前 , 15F
件事，等成品都已經寫成一拖義大利麵之後才開始弄
08/28 21:06, 15F
→
08/28 21:06, 2周前 , 16F
單元測試，是非常困難的！所以他的做法算是不得已
08/28 21:06, 16F
→
08/28 21:06, 2周前 , 17F
的折衷辦法。
08/28 21:06, 17F
噓
08/28 21:33, 2周前 , 18F
第一次用可不可以就閉嘴聽負責人就好？ 是他負責又
08/28 21:33, 18F
→
08/28 21:33, 2周前 , 19F
不是你負責
08/28 21:33, 19F
→
08/28 22:51, 2周前 , 20F
你認知是錯的，UT 只需要管 input output , 所以你餵
08/28 22:51, 20F
→
08/28 22:51, 2周前 , 21F
進去的是假資料也無所謂。
08/28 22:51, 21F
→
08/28 22:58, 2周前 , 22F
假資料我覺得沒問題，但是我比較有疑慮的是他把要測試
08/28 22:58, 22F
→
08/28 22:58, 2周前 , 23F
的程式修改後才去測這件事情。就像模擬考，考試是假的
08/28 22:58, 23F
→
08/28 22:58, 2周前 , 24F
，可是人要是真的，這是我的想法
08/28 22:58, 24F
→
08/28 23:13, 2周前 , 25F
我覺得他講的比較對，你講的還考慮 RTOS 有點接近整合
08/28 23:13, 25F
→
08/28 23:13, 2周前 , 26F
測試
08/28 23:13, 26F
→
08/28 23:15, 2周前 , 27F
然後就我的經驗，基本上UT就是邏輯通就好，有可能用什
08/28 23:15, 27F
→
08/28 23:15, 2周前 , 28F
麼套件你板子上沒有的，那就是整合的事情
08/28 23:15, 28F
→
08/28 23:17, 2周前 , 29F
這邊 V公司不是寫程式給你的，他是提供測試軟體的廠商
08/28 23:17, 29F
→
08/28 23:17, 2周前 , 30F
吧？你程式自己公司寫的自己公司要負責啊，為什麼會想
08/28 23:17, 30F
→
08/28 23:17, 2周前 , 31F
問 V公司？
08/28 23:17, 31F
→
08/28 23:28, 2周前 , 32F
當初不確定問題是出在程式還是工具上
08/28 23:28, 32F
推
08/28 23:28, 2周前 , 33F
單元測試就是要測邏輯 你還牽扯環境不就是整合測試？
08/28 23:28, 33F
→
08/28 23:30, 2周前 , 34F
程式修改也不是不行 弄個編譯選項條件編譯就好 盡量
08/28 23:30, 34F
→
08/28 23:30, 2周前 , 35F
貼近不是一定要一百趴貼近 現實沒那麼完美的
08/28 23:30, 35F
→
08/28 23:32, 2周前 , 36F
他這做法當然也不太對 他如果有辦法把邏輯抽出來變成
08/28 23:32, 36F
→
08/28 23:32, 2周前 , 37F
獨立一包 理應把這包變成函式庫讓主程式用才對
08/28 23:32, 37F
→
08/28 23:44, 2周前 , 38F
感謝大家的指點，這樣看起來unit test要做的好，程式設
08/28 23:44, 38F
→
08/28 23:44, 2周前 , 39F
計一開始就要想到每個函式的獨立運作性
08/28 23:44, 39F
還有 88 則推文
→
08/29 15:42, 2周前 , 128F
到不表示那個函數是對的，最後老闆會問你：啊不是有測試
08/29 15:42, 128F
→
08/29 15:42, 2周前 , 129F
？啊測了一樣會出問題？那幹嘛浪費時間寫測試？
08/29 15:42, 129F
→
08/29 15:44, 2周前 , 130F
很多時候測試程式碼本身就是錯的 只是在浪費時間而已
08/29 15:44, 130F
→
08/29 15:56, 2周前 , 131F
開(ㄋㄧˋ)發(ㄒㄧㄤˋ)產(ㄍㄨㄥ)品(ㄔㄥˊ)的時候測試程
08/29 15:56, 131F
→
08/29 15:57, 2周前 , 132F
式怎麼會浪放時間，一切的需求都是從測試程式定義出來的
08/29 15:57, 132F
→
08/29 15:57, 2周前 , 133F
打錯字，浪費
08/29 15:57, 133F
→
08/29 15:59, 2周前 , 134F
如果有問題，那表示是需求的客製化就要回頭問規格誰訂的
08/29 15:59, 134F
→
08/29 16:01, 2周前 , 135F
如果單元測試寫錯了，我們會在整合測試發現問題。如果整
08/29 16:01, 135F
→
08/29 16:01, 2周前 , 136F
合測試寫錯了，使用者會發現問題。所以很多時候單元測試
08/29 16:01, 136F
→
08/29 16:01, 2周前 , 137F
是多餘的 我只是想表達這個常見的狀況
08/29 16:01, 137F
→
08/29 16:02, 2周前 , 138F
多於要看代價唄，原則上單元測試是相當廉價的然後整合測試
08/29 16:02, 138F
→
08/29 16:03, 2周前 , 139F
甚至是系統測試在資源消耗上是相當昂貴的
08/29 16:03, 139F
→
08/29 16:04, 2周前 , 140F
尤其是在掛勾一堆外掛和除錯套件，系統測試就會天荒地老
08/29 16:04, 140F
→
08/29 16:05, 2周前 , 141F
當然我放著給使用者當測試，就是死道友的概念
08/29 16:05, 141F
推
08/29 17:16, 2周前 , 142F
單元測試比較像開發時期的保護傘 避免改完bug又被改回來
08/29 17:16, 142F
推
08/29 19:27, 2周前 , 143F
單元測試很好用啊，怕東西改壞，就先寫UT
08/29 19:27, 143F
推
08/29 19:32, 2周前 , 144F
不同意100樓 因為我覺得老人也要看w
08/29 19:32, 144F
推
08/29 19:35, 2周前 , 145F
單元測試至少能幫助debug，就算寫不完全或根本測錯，至
08/29 19:35, 145F
→
08/29 19:35, 2周前 , 146F
少你看得到已經測過的部分，不用重新通靈
08/29 19:35, 146F
→
08/29 19:38, 2周前 , 147F
b大回得不錯，可以回文造福類似的人
08/29 19:38, 147F
推
08/29 19:46, 2周前 , 148F
brucetu是對的 測試老問題了 規格不清楚的東西沒辦法測
08/29 19:46, 148F
→
08/29 23:47, 2周前 , 149F
我支持單元測試很重要，如果整合系統跟做功能的人不同
08/29 23:47, 149F
→
08/29 23:47, 2周前 , 150F
更重要
08/29 23:47, 150F
→
08/29 23:47, 2周前 , 151F
因為這樣才知道到底是需求開錯，還是程式寫錯
08/29 23:47, 151F
→
08/29 23:49, 2周前 , 152F
這是管理工作氛圍很重要的一點，做系統的資深工程師或
08/29 23:49, 152F
→
08/29 23:49, 2周前 , 153F
是主管要扛起決策責任，不能整合出問題跑去怪做功能的
08/29 23:49, 153F
→
08/29 23:49, 2周前 , 154F
新人
08/29 23:49, 154F
→
08/29 23:51, 2周前 , 155F
丟給使用者做整合測試，如果是內部需求，那情境可能還
08/29 23:51, 155F
→
08/29 23:51, 2周前 , 156F
可以；如果是客戶，這情況不妙
08/29 23:51, 156F
→
08/30 13:58, 2周前 , 157F
講是這樣講 誰家產品沒被客戶測出一堆問題的..
08/30 13:58, 157F
→
08/30 17:08, 2周前 , 158F
退一萬步來說交給客戶檢查問題了，但客戶又不會端到嘴前
08/30 17:08, 158F
→
08/30 17:08, 2周前 , 159F
餵食出錯的根本原因，也不會教怎麼改成沒問題的功能唄
08/30 17:08, 159F
感謝各位大大給的建議 簡單用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
推
08/30 22:38, 2周前 , 160F
你前輩的做法的確是錯的 怎麼是拔掉相依的程式
08/30 22:38, 160F
→
08/30 22:38, 2周前 , 161F
每次改版都要自己手動拔 不僅太累而且也可能出錯
08/30 22:38, 161F
→
08/30 22:40, 2周前 , 162F
不過職場百百種啦 如果想在原公司生存就聽主管的吧XD
08/30 22:40, 162F
→
08/30 22:41, 2周前 , 163F
工作本來就不是做對的事 是做主管(業主)想要的事
08/30 22:41, 163F
推
08/31 01:08, 2周前 , 164F
推工作是做業主想要的事XD
08/31 01:08, 164F
推
08/31 15:27, 2周前 , 165F
看你為誰服務
08/31 15:27, 165F
→
08/31 15:27, 2周前 , 166F
如果教你的是你老闆聽就是了
08/31 15:27, 166F
‣ 更多 alan8656 的文章
文章代碼(AID): #1ei43YtS (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 alan8656 的文章
文章代碼(AID): #1ei43YtS (Soft_Job)