改善意见提交了

    下午公司给我们培训cmmi4，午觉都没得睡。哎，只好将boss吩咐的对与公司当前功能测试改善意见的报告缩水了。

    以下是报告的内容：

    

一、             通用的界面要求、操作要求可以定个标准文档并加以维护，做为软件界面性的统一。前期较难形成具体文档时，可以在项目初期的设计文档中或者维护小组中达成一个统一。

当前经常碰到诸如以下这些问题，web类的控件选用和兼容性；模块中有些保存后显示保存的记录，有的还原为初始化；各个模块提示信息风格、字体、标签长度，按钮大小不统一；维护项目中出现界面问题认为是前期开发人员做好的，这次不修改。有些自定义控件各个项目的共享，例如内管系统的区域自动联想等。当前这里对于界面类修改都是放在后期进行，开发人员各自有自己习惯，例如时间填写、加注释都不统一。其实这个可以慢慢做个标准，在不刻意修改中提升起来。就可以避免验收测试或者需求经理提出问题时，大都是界面导致的问题。

业务类软件的界面对齐方式，提示信息风格、字体类型、控件的选用和共享，保存后是否显示结果、按钮名称等这些可以先做起标准，基本上相同业务领域下区别不会很大。避免后期修改，界面标准模糊，是否改，可能改了还需对模块回归。

 

二、             对于维护项目中需求变动情况下，出现用例修改情况，建议规程化操作。例如，新增用例存放的方式，命名规程是否跟之前的用例一致。修改用例时在描述中增加修改日志等。

当前在做维护单时碰到以下几个问题：有些后期新增的用例以维护单的名称命名，写的用例存在针对本次需求改动，如果出现多次维护单修改同一的模块，可能会出现在跑用例时需求覆盖率是不全的。

 

三、             对于遗留问题，特别是维护单，后续的处理流程如何？

在做维护单时碰到过，对A模块进行维护，在测试中,发现B模块的问题，或者同时处理两个问题，但由于时间紧，优先处理重要问题然后结单。对于这些问题，提单人一般说先把问题记上，结单后就不知道如何处理，并且平台里不关闭问题，还无法结单。

   以前碰到该类问题，除了本次任务的测试报告外，会增加一份遗漏问题分析，写明相应情况，得到提单人、测试主管、客服同意后并决定遗漏问题处理方案后，再发布成果。并且有相应的地方汇总遗漏问题。

 

可能你们看到会觉得奇怪，用例、单子这些本应该是测试管理中最基本，为什么还有问题，主要是因为测试管理软件、任务发放系统等集成平台是公司自己做的。