作者NDark (溺於黑暗)
看板Soft_Job
标题Re: [讨论] 怎样算是一个合格的junior cpp programme
时间Wed Aug 24 23:22:02 2022
※ 引述《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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1661354528.A.5F0.html
1F：推 wulouise: 这个比较偏整合测试？TDD的T通常是指unit test 08/24 23:34
2F：推 bluelink: 这例子在说找不到问题，那就解决提出问题的人？ 08/25 01:41
3F：推 lchcoding: 楼主遇到的问题，可以透过侧录封包来解（ex: Wireshark 08/25 03:25
4F：→ lchcoding: ). 透过-回放-爆炸点时间附近的封包s, 然後一直限缩， 08/25 03:25
5F：→ lchcoding: 你可以找到到底是哪一颗（或哪几颗）封包送进你的serve 08/25 03:25
6F：→ lchcoding: r 後会让它挂掉. 然後，从这个地方开始解. 08/25 03:25
7F：推 vi000246: 可以查特定ip的request log 看看是从哪个点进来的 08/25 11:35
8F：→ vi000246: 加个类似CSRF token的机制把非特定入口进来的reqeust挡 08/25 11:37
9F：→ vi000246: 掉 08/25 11:37
10F：→ brucetu: 领域不同 录封包还是记request log两个做法都不实际 08/27 16:20
11F：→ brucetu: 原po的招数已经算游戏伺服维护这个领域中兼顾危机处理跟 08/27 16:21
12F：→ brucetu: 可以解决问题的良好范例了 08/27 16:21
13F：→ brucetu: 每天有多少骇客在利用你的漏洞挖钱 一定是先灭火再说 08/27 16:22
14F：→ brucetu: 抓出来封号是打击破坏者相当有效的手段 08/27 16:23
15F：→ NDark: 一个容易忽视的点是 这些都是合法玩家 即便他们在钻漏洞 08/27 18:08
16F：→ NDark: 令很多伺服器端的专家会意外的是 08/27 18:09
17F：→ NDark: 从2012游戏开卖值到我2020离开这个专案 08/27 18:10
18F：→ NDark: Client/Server之间的通讯都是明码在传输 08/27 18:10
19F：→ NDark: "应该要加密" 这议题不存在.因我文中已讲 功能永远是高优先 08/27 18:11
20F：→ lchcoding: 所以在灭火封号之後， 08/28 08:13
21F：→ lchcoding: server 上那道可以撞出 08/28 08:13
22F：→ lchcoding: null reference（ex:） 的漏洞， 08/28 08:13
23F：→ lchcoding: 是不用修，还是尽量修. 08/28 08:13
24F：→ lchcoding: 我实在想不出来， 08/28 08:13
25F：→ lchcoding: 在没有神奇子弹的指引下， 08/28 08:13
26F：→ lchcoding: 如何尽量修 08/28 08:13
27F：→ NDark: 修是修到堪用这艘船继续开的情况就好.继续开就继续赚钱. 08/28 10:45
28F：→ NDark: 技术这边无法给出一个重构方案 其成本是小到管理层能买单 08/28 10:46
29F：→ lchcoding: 了解 08/28 11:14
30F：→ longlongint: 这只是很一般的自动测试而已吧 09/11 20:18
31F：→ longlongint: 只是直接尻记忆体满暴力的 09/11 20:18