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

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

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

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

事情的经过是这样的：

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