前段时间程序出了一些问题，搞得焦头烂额的，起早摸黑的找问题所在，最后还是一些测试工具帮了我大忙。
以前，虽然口头上认可测试的重要性，但说实话并没有落实到实际中，老是认为，测试嘛，不是我们程序员的事情。以前就是写好代码，也不进行什么白盒黑盒测试，直接就送上面进行实际功能测试，其实这很不规范，自己也知道，但现状下也没法改变（呵呵，毕业了一定要去一家规范的公司），谁叫人手紧张呢，谁叫自己那么在乎那点钱而舍不得换个地方呢，扯太远啦。而且之前总是抱着幻想，认为对于小型项目，测试并不是很重要，重要的是赶时间完成任务。后来，因为SPECIFICATION在不断更新，功能在不断修改，自己曾经以为很牢靠的代码和逻辑，因为一次又一次的修改而引入了内存漏洞，以及逻辑上的差错，以前测试好的部分修改后发现又有问题了，有些问题还特别奇怪，那几天搞得真的狼狈。痛定思痛，引入了一些白盒测试工具后，问题终于找到并修改掉了，一颗悬着的心也算踏实了。
这次教训最终得出一个经验，即使对于小型项目，特别是嵌入式项目，代码测试是很必要的。因为嵌入式项目的运行环境，在PC机上难以完整模拟，如果没有进行必要的单元检测，那么整合后发现问题再回来找问题无异于大海捞针，而且嵌入式设备测试的方便性也是个大难题，到后来浪费大量时间，搁置进度。必要的测试不光是保证项目顺利进行的关键，也是规范纠正个人一些错误编码习惯的向导。
以前，虽然口头上认可测试的重要性，但说实话并没有落实到实际中，老是认为，测试嘛，不是我们程序员的事情。以前就是写好代码，也不进行什么白盒黑盒测试，直接就送上面进行实际功能测试，其实这很不规范，自己也知道，但现状下也没法改变（呵呵，毕业了一定要去一家规范的公司），谁叫人手紧张呢，谁叫自己那么在乎那点钱而舍不得换个地方呢，扯太远啦。而且之前总是抱着幻想，认为对于小型项目，测试并不是很重要，重要的是赶时间完成任务。后来，因为SPECIFICATION在不断更新，功能在不断修改，自己曾经以为很牢靠的代码和逻辑，因为一次又一次的修改而引入了内存漏洞，以及逻辑上的差错，以前测试好的部分修改后发现又有问题了，有些问题还特别奇怪，那几天搞得真的狼狈。痛定思痛，引入了一些白盒测试工具后，问题终于找到并修改掉了，一颗悬着的心也算踏实了。
这次教训最终得出一个经验，即使对于小型项目，特别是嵌入式项目，代码测试是很必要的。因为嵌入式项目的运行环境，在PC机上难以完整模拟，如果没有进行必要的单元检测，那么整合后发现问题再回来找问题无异于大海捞针，而且嵌入式设备测试的方便性也是个大难题，到后来浪费大量时间，搁置进度。必要的测试不光是保证项目顺利进行的关键，也是规范纠正个人一些错误编码习惯的向导。
