时间：项目监控期第二天
　
起因：项目上线后发现了一个bug
　
经过：
TL：XX，今天下午把TK后台再回归一下！
测试：啊？！为什么？
TL：我们对超时处理的那部分代码做了优化，因为当时时间比较紧，那部分代码写得逻辑比较混乱，可能会存在隐蔽的问题，所以优化了一下，理论上不会影响原来功能。
测试：嗯。那能否解决那个bug呢？
TL：不一定，可能会解决。
测试：你们说，理论上不影响原来功能，那实际上你们对自己修改的那部分代码有多少把握呢？
TL：把握不是很大。
测试：不是吧？！那我要回归哪些地方呢？
TL：最好TK后台的功能全部再走一遍！
测试：哇！不是吧！这么多！改之前怎么没有通知我们测试？影响范围这么大，我觉得改之前应该先评估一下风险还有测试的工作量吧！
TL：……测试大概需要多少时间？
测试：重要功能回归，起码一个工作日。加上不重要的，起码还要半个工作日。
TL：最好明天早上能预发。
（中间省略若干字）
测试：好吧，那我马上去准备数据。好吧，那我今天晚上加班加晚点。好吧，那我今天把重要的功能一定都走一遍。其他功能点尽量也走一遍。
　
结果：
经过当天下午和晚上的奋战，总共发现4个bug，包括原来线上的bug。其中3个在项目监控期内都fix了，有一个也就是原来线上的那个bug仍旧存在，只不过出现的几率貌似比原来少了。还好。。。还好。。。没出大问题。。。
　
总结：
1.这次算是有惊无险，结果也还令人满意。
2.虽然，SQA的同学说开发这样改代码（改前TL允许，改后通知测试）是完全符合流程规范的，但是，项目监控期改动影响范围较大的代码，改前开发没有通知测试，导致风险无法控制和测试工作量无法评估测试工作无法合理安排，这一点对于测试来说比较被动。