以前也经常看一些文章，谈到测试多么多么的重要，其实对于重要性来看，自己也已经略有了解，只是一直以来对如何采用单元测试，编写测试样例之类还没有太深的感触，直到手头的项目再一次面临结项的时候……

这个版本已经是第三个版本了，前面的两个版本产品感觉还不是特强烈，可能也是和自己在项目中的角色慢慢转变有关系，以前自己只是负责自己的一亩三分地，大家加班，自己加班，有问题处理，没有问题测试版本，对于同事在忙的部分有太多的不了解，所以缺乏整体概念是当时的一大特色，我想，很多开发人员都会 有过这样的感觉吧~

经历了三个版本的开发，自己逐渐对项目有了整体概念，也做了一些整体框架方面的大的调整，在熟悉了项目的各个细节后，会经常有很多的“想法”，比如，这个 地方的逻辑过于复杂、前台脚本过于臃肿、业务流程是否还有优化的余地等等，当然，在平衡了项目资源之后，有一些想法可以终变为现实，但有一些想法只能暂时处于待命状态~

但这不是想说的，想说说为啥自己突然对单元测试和测试样例的态度有了巨大的转变？

事情的经过是这样的：

开发人员添加新需求 + 处理系统bug =》提交测试版本 =》 测试人员进行系统测试 =》 发现系统bug，并提交开发进行处理 =》 重现bug，并处理bug（有可能会引发其他问题；测试不彻底……） =》 测试人员反测，发现有问题继续返回，抑或没有发现隐含的bug =》开发人员……

大概是这么一个生死轮回！眼看结项日期越来越近，但是上述轮回依旧，不同的，可能是问题数量和严重级别上的差异，但每发现一个问题，需要重新出一个版本，需要测试全面的测试，然后我们大家都在盼望奇迹的发生……可是貌似噩梦一直延续，这是我们的现状！

你或许会说，产品总不会是完美的，总会多多少少有一些瑕疵的吧~这个道理我也知道，但是，上面的轮回显然会出现一个很大的漏洞，那是在缺少详细的测试样例指导和完整的单元测试情况下，再加上人手的限制，那么带来的不会是一段愉快的回忆！

总之，我们不能破罐子破摔是一定的，因为当我们进入公司参加工作以后，这个想法不应该存在了！好吧，那我们看看在现在的这个烂摊子上，我们能怎么稍微挣扎一下：

（1） 合理安排好结项期间的开发任务：

i. 保证测试人员发现bug后，开发人员能够第一时间处理。

ii. 如还有新需求研发，一定要能够合理评估，不能盲目进行添加，尤其对开发难度和开发时间有足够的把握，否则完全可以放到下面的版本进行完善。

iii. 开发人员在修改了一个bug后，至少要通过两遍的测试，一个是自己开发环境的，一个是测试的现场环境，而且在测试完毕，将代码更新到服务器，并填写适当的描述文字。

iv. 一定要控制好版本的发布间隔，过长或过短都是不太合适的，一般情况下，可以控制在1-2天，当然，如果出现严重的影响正常流程的问题，还是需要马上进行版本更新的，这样也是为了保证测试人员的测试质量和心情。

（2） 合理安排好测试任务：

i. 每新出一个新的版本，先不要发布，首先由开发人员该版本修正的问题进行反测，并保证基本业务流程的正确性，直到没有异常再发布新版本，提由测试人员进行测试，这样可以明显减轻测试人员的压力.

ii. 对于测试人员，建议能够抽时间对系统的测试工作进行一些样例总结，开始可以只对主要流程进行总结，而后根据时间情况再补充后面的内容，因为一个系统中可能存在多个功能模块，完全有必要按照模块来划分人力进行重点的测试，从而避免这个版本发现这个功能模块有很多问题，但是其他部分没有仔细地测试，而下一个版 本，这个模块虽然好一些了，但是发现另外的模块又出现N多bug，这种情况其实完全可以一次发现一次解决的，如果拉长战线的话，会给人一种bug无穷无 尽，末日来临，增加无谓的压力！这也是不能把版本周期设定过短的另外一个原因，如果时间太仓促的话，测试人员也不是三头六臂，很定会有很多的遗漏，而且频繁地发布版本更会降低测试人员测试的激情，降低测试效率，这些都是很现实的问题！

iii. 不断的往复测试加上结项日期的压力，都使得这个阶段的气氛和压力要高于往常，所以一定要保证开发人员和测试人员精神状况的饱满，此时如果团队中有一个到两个人能起到活跃和放松气氛的作用，那真是不幸中的万幸，因为保证轻松的心情才能更有效地发现和处理问题。对于测试人员来说，不能因为想着马上结项而放松测 试的要求，开发人员也不能一味想着好没有bug，万事大吉，下班回家的心态，一定要知道，越早发现问题，代价越小，如果到了客户上线后再发现，那后果都 是非常严重的，而代价将不是数倍的增加！

（3） 其他一些实用的小技巧：

i. 有必要为“版本发布期”做一个主体的计划，即需要定几个关键点，并分别设定版本目标，但没有必要过于频繁，一般保证在3个左右可能效果会好一些，如果没有 这些关键时间点的话，人的惰性会大大降低我们的效率，对项目的顺利结项也是一个很大的威胁。

ii. 将修改后的代码更新后，负责更新版本包的人员，有必要在获取新代码的时候对修改的代码进行一下审查，因为不同开发人员的视角往往不同，因为和修改bug 的人员相比，审查人员没有将精力聚焦在问题本身，往往可以跳出问题的怪圈，可能会发现一些修改遗漏和潜在隐患，或者能提出更好的方法也不一定。

iii. 从“版本结项期”伊始，我们需要创建一个版本改善意见簿，其目的很简单，是为了记录在这个“测试轮回”中，开发人员的一些“想法”，可以是有关某一部 分功能模块的重构意见，也可以是对某些相同代码的重构，或者是对一些更炫的功能的实现等等，总之，因为在这个阶段，我们和系统会有很亲密的接触，所以会更加容易发现系统的很多问题，同时激发我们的思考。错过这么好的机会，真的是非常可惜的。

iv. 在为测试提供修改后的版本的dll的时候，好把dll的小版本进行修改，而且测试人员也不要进行直接覆盖，好能够把原有文件进行备份，方便还原问题环境。

v. 每次测试开始之前，都需要首先将此次版本中修改的问题进行反测，必须做到一个不剩，然后再按照既定方案进行全面测试。

vi. 在发布版本的过程中，每个人都会出现一些比较低级的错误，例如，笔误、忘记更新代码、忘记打包、和测试人员的摩擦等等，我们必须心怀若谷，尤其是对一个团队来讲，更需要彼此的理解和尊重，记住没有人故意犯错！