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

軟工

1040

: 補充一下,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
wulouise1樓這個比較偏整合測試?TDD的T通常是指unit test 08/24 23:34
bluelink2樓這例子在說找不到問題,那就解決提出問題的人? 08/25 01:41
lchcoding3樓樓主遇到的問題,可以透過側錄封包來解(ex: Wireshark 08/25 03:25
lchcoding4樓). 透過-回放-爆炸點時間附近的封包s, 然後一直限縮, 08/25 03:25
lchcoding5樓你可以找到到底是哪一顆(或哪幾顆)封包送進你的serve 08/25 03:25
lchcoding6樓r 後會讓它掛掉. 然後,從這個地方開始解. 08/25 03:25
vi0002467樓可以查特定ip的request log 看看是從哪個點進來的 08/25 11:35
vi0002468樓加個類似CSRF token的機制把非特定入口進來的reqeust擋 08/25 11:37
vi0002469樓 08/25 11:37
brucetu10樓領域不同 錄封包還是記request log兩個做法都不實際 08/27 16:20
brucetu11樓原po的招數已經算遊戲伺服維護這個領域中兼顧危機處理跟 08/27 16:21
brucetu12樓可以解決問題的良好範例了 08/27 16:21
brucetu13樓每天有多少駭客在利用你的漏洞挖錢 一定是先滅火再說 08/27 16:22
brucetu14樓抓出來封號是打擊破壞者相當有效的手段 08/27 16:23
本人15樓一個容易忽視的點是 這些都是合法玩家 即便他們在鑽漏洞 08/27 18:08
本人16樓令很多伺服器端的專家會意外的是 08/27 18:09
本人17樓從2012遊戲開賣值到我2020離開這個專案 08/27 18:10
本人18樓Client/Server之間的通訊都是明碼在傳輸 08/27 18:10
本人19樓"應該要加密" 這議題不存在.因我文中已講 功能永遠是高優先 08/27 18:11
lchcoding20樓所以在滅火封號之後, 08/28 08:13
lchcoding21樓server 上那道可以撞出 08/28 08:13
lchcoding22樓null reference(ex:) 的漏洞, 08/28 08:13
lchcoding23樓是不用修,還是盡量修. 08/28 08:13
lchcoding24樓我實在想不出來, 08/28 08:13
lchcoding25樓在沒有神奇子彈的指引下, 08/28 08:13
lchcoding26樓如何盡量修 08/28 08:13
本人27樓修是修到堪用這艘船繼續開的情況就好.繼續開就繼續賺錢. 08/28 10:45
本人28樓技術這邊無法給出一個重構方案 其成本是小到管理層能買單 08/28 10:46
lchcoding29樓了解 08/28 11:14
longlongint30樓這只是很一般的自動測試而已吧 09/11 20:18