测试人生

回归测试只是整个测试流程中的一部分，但是目前很多维护型项目却非常依赖这样的回归。维护性项目的回归测试跟软件工程中讲的回归意义并不完全相同，前者问题发现者为软件使用者，发现阶段为软件正式发布以后，由开发人员在生产环境中找出问题并做相应的修改，当程序修改好以后交给测试部门验证。发现问题的人和最终决定这个问题是否测试通过的人是不同的人，在不同的组织里，这下好了，暂且不说整个组织是否够官僚，单单是两个不同的人之间沟通成本也够大的，前台人员分布全国各地，最高效的沟通方式也只是电话而已，就算沟通效率达到65%，但是剩下还是有35%的风险。这只是问题之一。以下看看这种模式下我们还有哪些问题需要考虑。

一、我们应该每天都修改生产环境的代码吗？
系统频繁发布对整个系统的质量影响是很大的，因为发布的频繁相对来说测试就不充分，为了让软件使用部门暂时性的满意，就每天对他们发现的问题进行修改，一方面开发人员的工作开始变得漫不经心，他们知道今天的工作如果不充分，明天就可以做修复，另一方面生产环境会无休止的提出需求变更，因为他知道今天提的需求明天就能在环境中实现，有时可能会是一个不成熟的需求，而测试部门更是无休止陷入麻烦了，任何今天开发完成的功能，明天太阳出来的时候，客户就要看到，那好了，今天上午全国的前台都可能提BUG，开发人员用了一上午去分析，用了一下午去解决，而测试部门一定要在第二天上班前将这些问题都测试通过。在发布周期的压力面前，在怎么认真的人可能都会犯错误，本来该用10个用例做完的，现在用5个用例吧；本来这个功能有很多关联测试的，这次可能也免了，日积月累下，可能问题就越来越多，这个是频繁发布的情况。
另一种情况就是不频繁发布，暂定一周发布一次。这样的周期，压力却转价到开发部门了，这周如果没赶上发布，或者修改的程序出现其他问题，就得再等一周才能修复，而测试部门从每天的应接不暇变成一天或者两天的集中测试，如果有计划的进行自动化测试，那主要功能由于某次修改而失效的情况还是可以避免的。
以上两种是我经历的两个主要阶段，希望能在质量与生产之间找到更好的流程。

二、测试点由开发人员提出吗？
由于这种回归测试的特殊性，测试人员总是最后一个知道需求的，于是开发人员在提交代码的同时便给出测试说明，描述本次要测试的项目，更有聪明的程序员把测试用例都写好。这种背景下，作为一个负责人的测试人员便会被这样的话折磨的很痛苦，“这个用例不在本次测试范围之内”，“这个问题不是本次代码引起的”，“这次不修改最后个问题，留着下次修改”，“生产环境没有提出这个问题，我们不能修改”。。。有时测试部门甚至不知道这个问题最初提出者是何人，生产上发现的问题到底是什么问题，只是按照开发人员写的测试方法执行一遍，这样做是不能让人放心的。
我们为软件使用者也建立一个缺陷管理工具来代替OA，所有发现的问题或需求变更都通过缺陷管理工具来提交，而开发人员在提交测试申请时要同时说明这个测试关联到哪个缺陷，甚至提供开发人员和提交问题者交流记录，只有让最终测试人员完全了解真正需求才能摆脱“不修改”的魔咒。

三、测试的功能覆盖率要100%吗？
时间有了，需求也明白了，剩下的质量风险大部分落在测试部门了，降低风险的一个有效措施就是提高测试覆盖率。一个主要功能修改可能是牵一发而动全身，一个细节问题修改可能与其他程序没半点关系，如何去取舍便成了测试部门内部的规范制度了。整个组织内部一定要有统一的思想才能做好质量控制，经常会接到开发人员的投诉，说某某太官僚，本来程序只修改了这个模块，测试的时候却测了另一个模块，就算有问题也不能把这个代码给退回去呀。真想给他讲讲什么叫责任心。
不过最终我们的解决办法还是和组织妥协了。只是根据经验去判断哪些模块之间有关联，对于修改的代码可能有联系的功能模块还是做到高覆盖，其他周边暂不做考虑。这种测试方法总还是会有问题的，不过趋于进度的压力也只能暂且如此了。

四、这种频繁发布的系统能做自动化吗?
经过不断的努力，自己觉得完美的一份方案经过阉割以后终于启动了，希望今年能有所收获。。。

五、各阶段的评审如何做？
由于同时参与项目的公司态度，大家很难统一脚步，所以作为CMMI中最重要的环节-评审，目前仍然无法实施，这个问题在今年也应该做为重点来解决，散兵游勇的时代应该早日过去。

scott 原创|转帖