编写背景：

5 月份测试的一个项目由于需求变更频繁，修改新需求出了些小事故，一直很想记录这件事情，但由于 6 月份忙于找合租房子，就一直没有记录；如今回忆这个小事故，想记录记录，让我想起了收费系统；好快， 8 月份来了，今年的收费系统的性能能否经得住考验，心中有些牵挂。离开这个系统就快一年了，不知道它运行的好不好。

也许有的人认为用这个题目来形容测试工作有些夸张， ^_^ ，之所以会起这个题目，是因为我当时有这样的感觉。

回头看，事情是这样的，这个系统业务、功能不是很复杂（嘿嘿，对于我来说），但需求给的不够细（应该说用户不知道这个系统具体能帮他们实现什么，但是他们需要这样的系统来便于管理），等到系统做出来后，刚测试好，就马上要上线了。期待啊，这是大家的心血，加班那么多天赶出来的软件，就要开始用了，这是部门内所有成员的第一次合作成果。第一步的业务功能用的反馈效果还可以，用户提出的多是字面描述上的修改。第二步的业务功能在使用的前两周，用户突然提出了很多新需求，并且要求在短时间内修改好，不影响上线使用。

就这样在短时间内，在开发人员人力紧缺的情况下，解决这个新需求后的程序提交测试后，出现了很严重的问题。离上线的时间越来越近，开发人员、测试人员就像医生在手术室里抢救生命，过了用户的使用期，这个系统做的再好那也用不上了。终于在早上的凌晨，系统的严重问题都已经解决，可以顺利上线使用，身心很是疲惫，还好的是大家辛苦的付出，软件还是活过来了。

出现这样的现象，原因是：新需求的修改策略出现了失误，开发人员过分的修改了程序。这更一次提醒了我，工作一定要把握和认清楚自己的目的和范围，一定要做适用的工作计划；只有这样工作才是有效率的。对于领导安排的没有做过的高压力工作，可以接受，但是要提醒领导自己的能力和情况，不要对结果抱乐观，自己只能是全力以赴的去做。

做测试工作很累，因为要站在不同角色来思考和测试所开发的软件；站在技术支持人员的角色，就希望软件容易维护；站在用户角色，就希望功能使用简单、好用；站在测试人员的角色，就想知道这样的设计会出什么样的问题等等。除此之外还要想办法使用有效的方法快速测试软件。

做测试管理工作也很累，因为想要带好队伍，把队伍发展好、管理好；要做决策，要承担决策的风险；心里压力比较大。

其实干哪一行，想干好，都很累，为什么那么累了还一直充满热情的做下去，也许就是因为爱好，它能激发人本身所不知道的潜能。