软件需求测试思考

上一篇 / 下一篇  2021-03-03 13:19:43 / 个人分类:用例设计



1.            问题描述

“需求测试?软件需求不应该是测试的依据吗?需求测试测什么呢?”

上面这个问题,很多非软件测试从业者和一些初入软件测试行业的人员可能都存在这个疑问。在软件测试书籍和软件测试模型中已经给出答案,如W模型就强调了“软件测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。本文结合自己测试中的一些案例,尝试在实践中找到一些解答。

2.            解决分析过程

下面结合我在iSolarERP项目遇到的测试案例,说说需求测试的检查点,供大家一起探讨。

第一个案例:关于软件需求的完整性测试

iSolarERP项目有个维护计划管理模块,这是计划闭环管理部分,主要由三大部分组成:①新增计划、②审批计划、③计划审批通过后,填写计划的完成情况。计划的责任人在系统中需要维护两部分内容:计划内容、计划完成内容,系统支持两种维护方式:页面填写、批量导入。

计划维护页面包含:年度、维护项目+设备+内容、责任人、计划时间、实际完成时间、完成情况。

导入模板包含字段:年度、维护项目+设备+内容、责任人、计划时间、完成情况。

新增计划阶段只允许填写计划内容,完成内容不可编辑,当计划审批通过后,计划内容不可编辑,完成内容可编辑。

1维护计划编辑页面

2维护计划导入模板

请留意:新增页面字段跟导入模板不一致,缺少了完成时间,查看需求文档模板定义如此。软件需求文档中说明了支持导入计划,但未说明是否支持导入计划的完成情况。从导入模板看,似乎需要支持导入完成情况,但又缺少了完成时间字段。

跟需求人员沟通确认,需求文档描述不完整,需要支持导入完成情况。跟编码人员沟通并结合软件实际测试结果发现,编码未实现导入完成情况的功能(导入计划的完成情况时,需要检查维护计划是否已经存在、计划是否本人创建、计划是否已经审批通过等完整性约束条件,软件未实现这些逻辑)。考虑项目进度和修改的开发测试成本,需求人员删除了导入模板的完成情况列,改为不支持导入完成情况

这个故事很典型,最后需求的改动对开发和测试影响较小,软件的最终用户也是公司内部同事,如果对外商用的产品可能结果就不太一样了。

 

第二个案例:关于软件需求的二义性测试

iSolarERP项目的电量计划模块的计划分析页面提供了时间查询和图表展示功能,图表根据查询条件刷新显示相应数据,比如设置20202~3月,图表中以安徽区域为例:

【年计划发电量】:显示安徽区域2020年全年的计划发电量

【年上网电量】:显示安徽区域20202月加3月上网电量之和

【计划完成率】:显示安徽区域20202月加3月上网电量之和/ 2020年计划发电量

表格中安徽区域【年计划完成率】:显示安徽区域20202月加3月上网电量之和/ 2020年计划发电量

请留意:该页面【年计划完成率】和显示的数据存在歧义,通常【年计划完成率】定义如下:

年计划完成率(%)=年实际完成数/年计划完成数* 100%

但该页面【年计划完成率】指标数据分子是查询月份的上网电量,并非2020年全年的上网电量,数据与指标存在歧义和不一致。这里的需求定义不清晰,如果需要分析月度计划完成率,应该定义为:20202月上网电量/ 20202月计划发电量,这样更有意义。这一点在需求人员给客户演示时,也得到了了正面,智维用户也提出了这个要求。

3电量计划分信息页面

 

第三个案例:关于软件需求的易用性测试

iSolarERP项目的交接班功能,软件设计交班时,用户需要操作2步:step1:【交接班列表页面】点击【交班】按钮,打开【值班详情页面】(只读状态);step2:点击该页面【交班】按钮,软件会检查所有输入项是否填写正确,如果不正确则弹出错误提示。

4交接班列表页面

5交接班详情页面

当值班信息填写有误导致交班失败时,用户修改需要再操作5步:step3:记住错误提示,关闭当前窗口;step4:从【交接班列表页面】点击【编辑】按钮,进入【值班详情页面】(可编辑状态);step5:根据记忆找到错误所在位置,进行修改;step6:点击【保存】按钮关闭值班详情页面;step:7:重新操作step1step2,重新进行交班操作。

6交接班列表页面

6值班详情编辑页面

假设用户第二次提交又遇到错误,那么用户又需要重复step3~step75个步骤。

这个功能上线后,有很多用户来咨询:为什么不能填写值班详情?为什么交不了班?为什么都正确填写了还提示错误?他们找不到错误的位置、不知道如何才能修改,在功能上线一个月后仍然有人被这个问题困扰,我们需要反复多次给予解答。

看看只是简单的一个易用性问题,但却因此带来很大的维护工作量,假如我们将step2【交接班详情页面】交互设计稍作修改,当用户交班遇到错误提示时,软件自动定位到错误所在位置,用红色标识出来,并允许用户直接编辑修改,再重新交班,这样step3~step64个步骤都可以节省,上面用户使用中遇到的困惑也就解决了,维护成本也会相应下降。

可见产品易用性设计的受益者,不仅仅是用户,还有我们的售后维护人员。需求设计往往会忽略维护阶段的成本,只关注了业务需求本身。

3.            结论与经验

像上面这样的例子还有很多,在实际项目中,一方面由于软件系统的复杂性、需求阶段时间紧张调研不充分、需求信息传递存在失真及需求人员水平差异,导致软件需求定义可能会存在一些错误,比如前面提到的完整性、二义性、不可测试性等问题。另一方面由于需求阶段测试人力投入偏少或者部分测试人员在需求阶段也比较茫然、能力缺乏等等原因,会导致很多需求问题被延迟到软件测试阶段甚至到最终用户端才被发现,这会导致产品的质量不理想、产品修复成本翻倍增长等问题。

7需求问题的影响范围

由上图可见,尽早和有效的开展需求测试,可以有效提高产品质量、降低变更成本。从这一点看需求测试应该是测试的重要工作之一,这对测试人员也提出了很多要求:测试人员要对产品的业务知识理解透彻,要对竞品的优劣势耳熟能详,要能站在用户角度思考、要对市场有一定的了解,要有技术功底、宽泛的知识面等等。一些敏捷开发流程,也都采用TDD测试驱动开发、BDD行为驱动开发,帮助团队集中精力识别、理解和构建业务目标有关的产品特性,确保产品特性被正确定义、设计和实现。


TAG:

 

评分:0

我来说两句

Open Toolbar