※ 引述《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又两手一摊没办法重现只好自救的时候,不失为一个方法.