PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 怎樣算是一個合格的junior cpp programme

看板Soft_Job (軟體人)作者 (溺於黑暗)時間3年前 (2022/08/24 23:22), 編輯推噓4(4推 0噓 27→)
留言31則, 7人參與, 最新討論串11/13 (看更多)
※ 引述《HZYSoft (PCMan)》之銘言： : 補充一下，TDD 是還沒有開始寫任何的 code 之前，就先針對 : 程式寫好之後 "預期應該要有的行為" 先寫 test cases : 接著，先跑一次測試親眼看著他 fail : 因為還沒寫任何 code，所以測試絕對會 fail， : 如果沒寫 code 卻 pass 那表示你的 test case 根本沒有測到。 : 接著才開始寫 code，重複跑測試直到確認 pass 為止，就是完成了。 : 不同於先寫 code 再測試，TDD 是顛倒，先測試再寫 code，所以才叫 test driven : 如果程式被報 bug，也是先寫一個會 fail 的 test case，確認可以重現 bug : 接著才開始改 code 修正，直到測試 pass 為止，就表示修好了。 : 這是一個觀念很特別的流派，他們的主張都是有道理的，就只是比較違反直覺不好實現。 : 如果你無法先寫出測試，那表示你還沒弄清楚要實作什麼行為， : 或是你原先構思的 API 介面難以使用，以至於你寫不出 test case : 這是強迫你釐清 spec 以及設計好介面的方法，但實在有點極端，被不少人視為邪教 XD 推文看到有人問前端. 我個人是做客戶端所以很多傳統的測試方法論對介面其實效用很低. 上述段落讓我想起以前寫作的經驗.單純分享. 我在2018~2020年在阿布達比UB維護手機線上遊戲Growtopia. 當時的案子有很多駭客想要破解我們的遊戲的攻擊行為. 當時的主程式教給我一個我以前沒這樣試過的技巧. (但我必須強調.這整個系統跟時程就是不允許我們重構. 所以也不可能有甚麼有序的測試方式. 功能($$$)產生的速度就是比測試碼(COST)來得快 該專案幾年的程式碼簡單來講就是靠優秀的程式員無止盡的縫補.) 不過.當我分享給同僚的時候.他們都給我一種我在講甚麼歪理的眼神. 簡單說 我們當時遇到很多透過奇妙行為(譬如說破解封包)來try我們遊戲server的行為. 因為那些行為不是正規動作.所以我們的QA部門無法用正規手段重現這些步驟. (當然終歸到底就是沒有那麼多時間/資源 去真的學著逆向重建一個駭客軟體 /線上的問題就是以天為單位要解掉) 所以我們無法知道這些破壞到底起因如何.(來龍去脈/竄改點) 我們只能夠知道具體來說發生破壞的時間點.(ex.爆炸點/因為有exception log) A) 爆炸點 已知爆炸發生了.程式碼假如這樣: { Func1();// 我們只知道這函式進去的特定一行發生爆炸(ex. null reference), // 而函式發生前server環境就已經被竄改/攻擊為會爆炸的情況 } B) 埋點: 製作一個駭客的模擬入口 { DEBUG_HACKER_ACTION(); // 製作一個入口, // 我們猜測並刻意模擬駭客的行為就是會把上述那個會爆 // 炸的某個記憶體抹掉. Func1(); } C) 用後門指令手動觸發埋點 DEBUG_HACKER_ACTION() : OK 現在可以重現駭客的爆炸了. (紅燈) D) 修復: 在Func1()裡面布下重重安全機制.只要有異常就吐LOG然後封鎖該玩家(強制離 開/行動取消/黑名單,etc) E) 這步驟最重要.再次用特殊指令手動觸發埋點DEBUG_HACKER_ACTION() : OK server安 全了.Log正常吐出. (綠燈) F) 把後門指令+埋點mark起來.上線測試.抓有問題的玩家.封號. G) 這步也很重要,如果之後又發生類似的問題.再把後門指令搬過去開起來用.快速觸發錯 誤.同時也可以確認之前修掉的問題沒有再出現. 好像不是甚麼很玄妙的高招. 但是面對一些客戶端/前端無法重現 (譬如說一秒鐘按鈕連打60下這種不可能正常可以達到的行為所觸發)的問題. QA又兩手一攤沒辦法重現只好自救的時候,不失為一個方法. -- "May the Balance be with U"(願平衡與你同在) 遊戲設計教學，討論，分享。歡迎來信。 黑水溝歷史文庫 https://ndark.wordpress.com/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.169.35.216 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1661354528.A.5F0.html
推
08/24 23:34, 3年前 , 1F
這個比較偏整合測試？TDD的T通常是指unit test
08/24 23:34, 1F
推
08/25 01:41, 3年前 , 2F
這例子在說找不到問題，那就解決提出問題的人？
08/25 01:41, 2F
推
08/25 03:25, 3年前 , 3F
樓主遇到的問題，可以透過側錄封包來解（ex: Wireshark
08/25 03:25, 3F
→
08/25 03:25, 3年前 , 4F
). 透過-回放-爆炸點時間附近的封包s, 然後一直限縮，
08/25 03:25, 4F
→
08/25 03:25, 3年前 , 5F
你可以找到到底是哪一顆（或哪幾顆）封包送進你的serve
08/25 03:25, 5F
→
08/25 03:25, 3年前 , 6F
r 後會讓它掛掉. 然後，從這個地方開始解.
08/25 03:25, 6F
推
08/25 11:35, 3年前 , 7F
可以查特定ip的request log 看看是從哪個點進來的
08/25 11:35, 7F
→
08/25 11:37, 3年前 , 8F
加個類似CSRF token的機制把非特定入口進來的reqeust擋
08/25 11:37, 8F
→
08/25 11:37, 3年前 , 9F
掉
08/25 11:37, 9F
→
08/27 16:20, , 10F
領域不同 錄封包還是記request log兩個做法都不實際
08/27 16:20, 10F
→
08/27 16:21, , 11F
原po的招數已經算遊戲伺服維護這個領域中兼顧危機處理跟
08/27 16:21, 11F
→
08/27 16:21, , 12F
可以解決問題的良好範例了
08/27 16:21, 12F
→
08/27 16:22, , 13F
每天有多少駭客在利用你的漏洞挖錢 一定是先滅火再說
08/27 16:22, 13F
→
08/27 16:23, , 14F
抓出來封號是打擊破壞者相當有效的手段
08/27 16:23, 14F
→
08/27 18:08, , 15F
一個容易忽視的點是 這些都是合法玩家 即便他們在鑽漏洞
08/27 18:08, 15F
→
08/27 18:09, , 16F
令很多伺服器端的專家會意外的是
08/27 18:09, 16F
→
08/27 18:10, , 17F
從2012遊戲開賣值到我2020離開這個專案
08/27 18:10, 17F
→
08/27 18:10, , 18F
Client/Server之間的通訊都是明碼在傳輸
08/27 18:10, 18F
→
08/27 18:11, , 19F
"應該要加密" 這議題不存在.因我文中已講 功能永遠是高優先
08/27 18:11, 19F
→
08/28 08:13, , 20F
所以在滅火封號之後，
08/28 08:13, 20F
→
08/28 08:13, , 21F
server 上那道可以撞出
08/28 08:13, 21F
→
08/28 08:13, , 22F
null reference（ex:） 的漏洞，
08/28 08:13, 22F
→
08/28 08:13, , 23F
是不用修，還是盡量修.
08/28 08:13, 23F
→
08/28 08:13, , 24F
我實在想不出來，
08/28 08:13, 24F
→
08/28 08:13, , 25F
在沒有神奇子彈的指引下，
08/28 08:13, 25F
→
08/28 08:13, , 26F
如何盡量修
08/28 08:13, 26F
→
08/28 10:45, , 27F
修是修到堪用這艘船繼續開的情況就好.繼續開就繼續賺錢.
08/28 10:45, 27F
→
08/28 10:46, , 28F
技術這邊無法給出一個重構方案 其成本是小到管理層能買單
08/28 10:46, 28F
→
08/28 11:14, , 29F
了解
08/28 11:14, 29F
→
09/11 20:18, , 30F
這只是很一般的自動測試而已吧
09/11 20:18, 30F
→
09/11 20:18, , 31F
只是直接尻記憶體滿暴力的
09/11 20:18, 31F
‣ 更多 NDark 的文章
文章代碼(AID): #1Z1a8WNm (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 11 之 13 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共13篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 NDark 的文章
文章代碼(AID): #1Z1a8WNm (Soft_Job)