改善意见提交了
上一篇 /
下一篇 2011-02-22 16:41:14
/ 个人分类:功能测试
下午公司给我们培训cmmi4,午觉都没得睡。哎,只好将boss吩咐的对与公司当前
功能测试改善意见的报告缩水了。
以下是报告的内容:
一、 通用的界面要求、操作要求可以定个标准文档并加以维护,做为软件界面性的统一。前期较难形成具体文档时,可以在项目初期的设计文档中或者维护小组中达成一个统一。
当前经常碰到诸如以下这些问题,web类的控件选用和兼容性;模块中有些保存后显示保存的记录,有的还原为初始化;各个模块提示信息风格、字体、标签长度,按钮大小不统一;维护项目中出现界面问题认为是前期开发人员做好的,这次不修改。有些自定义控件各个项目的共享,例如内管系统的区域自动联想等。当前这里对于界面类修改都是放在后期进行,开发人员各自有自己习惯,例如时间填写、加注释都不统一。其实这个可以慢慢做个标准,在不刻意修改中提升起来。就可以避免验收测试或者需求经理提出问题时,大都是界面导致的问题。
业务类软件的界面对齐方式,提示信息风格、字体类型、控件的选用和共享,保存后是否显示结果、按钮名称等这些可以先做起标准,基本上相同业务领域下区别不会很大。避免后期修改,界面标准模糊,是否改,可能改了还需对模块回归。
二、 对于维护项目中需求变动情况下,出现用例修改情况,建议规程化操作。例如,新增用例存放的方式,命名规程是否跟之前的用例一致。修改用例时在描述中增加修改日志等。
当前在做维护单时碰到以下几个问题:有些后期新增的用例以维护单的名称命名,写的用例存在针对本次需求改动,如果出现多次维护单修改同一的模块,可能会出现在跑用例时需求覆盖率是不全的。
三、 对于遗留问题,特别是维护单,后续的处理流程如何?
在做维护单时碰到过,对A模块进行维护,在测试中,发现B模块的问题,或者同时处理两个问题,但由于时间紧,优先处理重要问题然后结单。对于这些问题,提单人一般说先把问题记上,结单后就不知道如何处理,并且平台里不关闭问题,还无法结单。
以前碰到该类问题,除了本次任务的测试报告外,会增加一份遗漏问题分析,写明相应情况,得到提单人、测试主管、客服同意后并决定遗漏问题处理方案后,再发布成果。并且有相应的地方汇总遗漏问题。
可能你们看到会觉得奇怪,用例、单子这些本应该是测试管理中最基本,为什么还有问题,主要是因为测试管理软件、任务发放系统等集成平台是公司自己做的。
收藏
举报
TAG: