项目中存在的问题弊端及解决方法.doc

第页共NUMPAGES2页
项目中存在的弊端及改进建议

测试人员介入太晚，基本上都是等代码开发完成时，才介入。
改进建议：在项目需求开始启动时，就能有相应测试人员跟进，并随之开始测试的一系列活动；由于在需求阶段可能测试人员的工作量可能较少；可以让其同时兼顾其它项目任务；到测试用例编写阶段才全职投入。

需求变化太多太乱，相关文档没有随之更新，文档与项目实际功能不相符；造成很多时候最新的需求都只是藏在个别人的脑中，而测试人员总是最后一个知道需求变化的人。
改进建议：能够建立需求变更体系，到什么阶段时必须停止需求变更（必须在项目前期就让需求提出人明确这一点）；每次需求变更必须让需求提出人员确认；需求变化后必须由专人更新相关文档（这些文档都是测试人员编写计划及用例的依据）；并能知会相关人员。这样才能做到程序人员修改相应的程序，测试人员修改相应的用例，且能对需求变更后的程序进行正确的测试。

项目无分阶段送测，造成无法对阶段性的开发成果进行测试，测试任务积压、问题无法及时发现。
改进建议：在项目前期制定项目计划时，将各阶段性送测纳入到计划中；开发人员根据项目计划进行开发，而测试人员可根据项目计划来安排自身编写用例的先后顺序以及在各阶段性送测时间要求送测（此阶段性送测可视项目的大小、项目与其它系统的关联来定好每个阶段送测的内容）；

测试人员没有独立的稳定的测试环境，无法控制版本更新；造成太多重复无效的测试，也常会因为提交无效的BUG。
改进建议：最好可以给测试人员提供一个独立的测试环境（包括数据库以及应用程序都是独立的），以保证测试人员所有的BUG都是稳定的、可重复的环境下发现的；如果不能做到独立测试环境情况下，也尽量做到能让测试人员去控制版本更新的频度，以控制测试的有效性。

没有一个行之有效的BUG跟踪机制；造成BUG提交重复、回归不及时，或不能正常被回归。
改进建议：项目中的所有成员都利用同一种方式去进行BUG提交、跟踪；BUG分发人员需做到BUG的过滤，来达到BUG的有效性；在BUG表单中需要能及时体现BUG的最新状态；这样项目组人员才都能对项目中已发现、已解决的BUG做到心中有数；项目管理人员也可以对整个项目的状态做到心中有数。

无完善的测试用例检查机制，无法对测试过程进行检查，也即无法保证测试结果的真实性。
改进建议：测试人员之间对测试用例进行走查，或开发人员分配时间出来对测试用例进行走查，以保证用例对需求的覆盖率；测试用例能与BUG对应，使用工具管理用例在每个阶段的执行情况，以对测试过程进行跟踪。

开发人员与专业测试人员比例严重不合理，而非专业测试（用户测试）介入太早。
改进建议：一般在国内的情况，测试人员与开发人员的比例是1:5左右，但在这里的比例严重不止，一个测试人员都负责多个项目，严重影响测试的质量；对于用户测试一般是在项目验收阶段才介入的，现在都提前介入了；如果用户必须提前介入测试，且作为测试的人力来算的话，那应该由测试来统一安排这些调度，以保证测试的合理分工。