【IT168 技术文章】

    软件测试每周一问：不少软件测试管理者都遇到过这样的问题：测试版本质量太差，导致测试过程中出现该版本所规划的需求未实现、基本功能点出现缺陷导致大量测试用例堵塞无法进行、缺陷太多导致继续测试失去意义等等，不得不频繁打回版本、修复缺陷后重新开始测试，使得本该完整的测试过程变成了边测边改、边改边测，不仅使测试进度无法按计划进行，还影响对测试对象质量的完整评估。这种情况是否有好的办法加以规范呢？欢迎大家各抒己见！

    会员huior的精彩回答：

    在软件开发过程不规范的项目组中，这种情况是非常常见的。2001年，我接触过的一个公司，它刚刚成立软件测试部，当时的测试部遇到的情况和上面讲的几乎如出一辙，搞得测试员叫苦不迭，开发部的程序员也天天抱怨头疼。

    具体到当前这个项目遇到的情况，从上面的问题分析，我认为主要原因是：开发部提供的测试版本太过随意，导致质量太差。要解决它，我认为有以下几个关键点：

    在项目开始时，最好能先开发一个原型出来，原型基本上要确定整体界面的风格、统一的操作习惯等，以后的开发要以原型为基础进行；

    开发部使用版本控制工具，比如CVS、VSS等，并且要保证每天定时Check-in和Check-out，避免积累大量代码，同时要强调在Check-out和Check-in的时候要注明缘由，是为了修改某个bug还是增加新功能等；

    每日构建（Daily Build）：每日构建要形成制度，构建过程最好能自动进行，如果因为是第一次这样做，没有经验，遇到技术问题，在这种情况下，建议由测试部指派一名测试员加入到开发部，协助开发部进行人工构建，每日能集成一个能运行起来的完整的软件系统；

    强化冒烟测试（Smoke testing）：加入开发部的测试员在构建后，集成了一个完整的软件系统，要及时对每一个build进行验证（Build Verification Test ），也可以称之为“冒烟测试”，对软件的基本功能点进行验证；

    强化测试的准入条件：软件测试启动是有条件的，并不是说开发部拿个软件过来，开发部就要测试，比如要启动测试活动，必须要有需求规格说明书、设计书、单元测试报告、冒烟测试报告等，这是前提。满足不了这个前提条件，测试活动不会启动。当然这个制度需要公司管理高层的认可，在项目启动时要和项目经理协调好的；

    强化BUG管理：测试组要使用BUG管理工具，例如bugzilla、JiRA等，要保证 bug、版本、以及人员的对应关系，同时分析在不同的版本、不同的时间段、不同的模块中BUG的走势，确定“危险模块”为重点测试对象，预测未来的BUG走势和工作量等。

    积极的态度：无论是开发部还是测试部，在这个困难的过程中都要有积极的态度，遇到问题要及时沟通，以最高效的方式解决问题。

    要从根本上根治这种矛盾，需要一套完整的、规范的开发过程。以上的措施只是一部分，只能在最短的时间内缓解矛盾。