从格式编辑器修改限制功能点看目前项目质量
从格式编辑器修改限制功能点看目前项目质量
关于开发质量:
1 每当测试新模块时, 最常见的bug , 是 走流程走不通 ( 服务没起? 数据对接时没对接好,代码没提交等等之类的问题, 导致进入新模块新功能时界面数据错误,加载不出来, 基本功能没实现等等严重影响测试后续进度的bug). 所以因考虑每当测试新模块时,安排一个人去简单点点功能, 找出走不通流程的bug, 让开发修复.
2 由于目前开发只是对自己开发的模块负责,对整个系统没有一个整体的认识. 当有不同模块联动的功能时, 出现的bug的几率很高. (比如: 以前旭云中,组长不能随便改,但望远中要求能随便改. 虽然在设置组长时,都能随意改了,但是其实在某些阶段,改了后和没改一样, 主要联动的功能点并未同时调整,从而产生bug). 是否需考虑让开发也能对系统的整体基本功能点有个基本的认识(只是个人看法).
关于测试质量:
回顾一下发现"格式编辑器"应该在什么时候就要限制不能随意更改的问题:
以前因这个问题导致严重影响的案例:
1 由于设置理综的试题的科目属性错误,当时系统定义的是又不能更改答题卡,导致成绩中子科目的单科总分全部错误,物理的老师要改化学的题等,后来直接让后台更改了该题的科目属性)
2 由于设置答题卡时,题目属性设置错误, 选做题设成非选做题, 导致阅卷时分配任务未按选做题分配,最后出成绩时,选做题的客观题成绩全部错误,最后导致学生的成绩全部错误.(后面通过让后台修改程序数据后,得到正确的客观题成绩后, 再通过手工的人工处理得到最终正确的总成绩)
因为这个限制对程序的影响会很大,所以我当时问了相关开发和测试,望远中对于这个问题是采用什么样的实现方案,因为了解了程序是如何实现的, 才能根据实现的规则进行测试.
当我只是问这个是怎么实现的时候, 开发立马反应过来的是,这个相关的地方还有问题. 测试反馈的是在扫描上传了就不让再编辑了, 并且要先分配阅卷教师,才可以扫描上传. 开发说: 扫描和分配无关. 最后让开发和测试一起定一下具体什么时候要限制,限制哪些等后,开发反馈要开发4个工作日.(也就是这个及相关联的功能点要4个工作日后才能测试,影响到测试进度)
由此可以反馈出的问题: 测试对系统的了解程度比较欠缺. 这个限制的功能属于系统中非常重要的基本的功能,测试却对此功能并不了解. 当测试都不清楚系统的规则的情况时, 说明这个规则是否实现了,是否有问题, 从来没有测试过.(关于扫描和分配是否有关的规则也同样是这个道理)
个人对于出现这种问题的看法:
1 测试工作中,测试任务不清晰.没有任何文档明确指出这个限制功能以及此功能的重要性. 开发如何开发以及测试如何测哪些功能点,完全依赖自己对系统的个人见解及熟悉程度. (根本原因)
2 测试工作中,测试目标不明确. 对测试过的功能模块(主要指考试阅卷的整个流程),无法保证基本的功能点能用,只能保证按自己的操作思路操作能创建一场普通的考试并阅卷,最后有成绩输出.
3 测试工作,考核制度不完善. (若1.2两项无法解决,此项的考核没有太大意义) 无规矩不成方圆,没有有效的制度约束测试行为, 测试工作完全靠个人责任感及个人心态.
对于以上问题,我的个人建议是:
考虑到项目进度, 安排人将测试任务清晰化,已来不及. 目前只能靠对系统的个人见解及熟悉程度.
1 每当测试新模块时,安排一个人去简单点点功能, 找出走不通流程的bug(相当于测试时的流程初步走通, 测试的比较粗糙,工作量也较小), 让开发修复就够了,没有必要安排两个人的工作量.
2 当流程能走通时, 对走通流程的功能模块进行较细的集成测试, 保证各个功能点的输入输出正常.(此项的工作量比走流程测试要大,所以应该安排多一个人,分小模块负责进行细的测试)
3 所有模块细致化的功能都测完后, 所有测试人员,对系统进行整个系统的流程走一遍.
分工建议: 新模块走流程: 刘林 , 细致化测试: 方迪智,周蓉.
测试,目标建议:
1 走流程测试人员,保证各基础使用的功能点能走通.(基础使用的功能点的定义由此人员定义,并将定义以简单测试用例的方式记录下来)
2 较细的集成测试人员,对自己已测试的各个功能点的各种输入输出情况负责,并对功能点的以个人见解及熟悉程度而测过的输入输出情况以简单测试用例的方式进行记录.