黑盒测试用例设计实践-配置表单输入内容

1概念

等价类划分方法参考：https://www.jianshu.com/p/57cfcd11888e
边界值设计方法参考：https://www.cnblogs.com/whylaughing/p/5821898.html
MySQL的VARCHAR类型字符长度说明：https://www.cnblogs.com/zhuyeshen/p/11642211.html
MySQL的DECTMAL类型字符长度说明：https://blog.csdn.net/resilient/article/details/85768133

2测试用例设计实例

下面在实际项目中抽取一个实例，通过逐步分析得出不同阶段测试用例设计及其优化过程。
主要针对数据表单内容的测试和提交测试。

2.1需求阶段

原需求是通讯模块配置中会有一个RTU配置信息，填写提交至MySQL某张数据表中，需求阶段不是太明确，也没有原型图参考，无法知道配置信息里有什么内容。这时我们只能通过交流和错误推断法得出一个类似测试大纲的用例，所以需求不清晰的时候无所谓什么用例设计方法，用例颗粒度只要尽可能的覆盖明确的测试点即可，也可以使用思维导图的方式分析测试点。

2.1.1获得需求隐喻内容

1.增加的方式：通过导入添加、逐行增加、批量添加、通过复制添加（本篇不设计流程相关用例）
2.配置表单提交结果：成功、失败、取消
3.配置表单列输入内容：

序号	输入内容类型	分析
1	键值	一般自动生成键值，但可能用户填写，如果自动生成需要确认是否根据其它表单拼接而成，如果用户有方式可以影响键值的改写，则测试入口就是那个改写方式。
2	非键值
3	可见内容	需要确认哪些是可见内容，对表单完整性进行检查，非可见内容不能展示，可见内容不能隐藏
4	非可见内容
5	可编辑内容	需要确认哪些属性是不能编辑但可以查看的，浏览属性内容不能编辑，并且有明显标识
6	不可编辑内容	需要确认哪些属性是不能编辑但可以查看的，浏览属性内容不能编辑，并且有明显标识
7	必填项	需要确认哪些列是必填项，必填项不填将提交失败并给出提示，填写时也应该有明显标识
8	非必填项
9	允许输入的字符类型	确认可输入框的字符类型
10	不允许输入的字符类型	确认不可输入框的字符类型
11	有默认值	确认必须要有默认值的输入项
12	允许没有默认值
13	可为空值	确认输入项是否可以为空，不能为空将提交失败并给出提示
14	不可为空值
15	是输入框
16	是选择框	注意选择框内容的完整性
17	既可输入又可选择	注意两者操作可行性
18	字符的长度	注意是否输入长度限制，限制的位置可以是在输入框截断，可以是提交时自动截断，或者给出提示
19	中文版本
20	英文版本	英文操作系统不应该存在中文字符，注意英文版本是否支持中文字符输入

注：如流程上非必要提交测试用例，项目执行又比较紧急，可使用测试大纲的形式，根据测试点整理即可用作测试执行，否则后期维护成本很高，但要求测试人员素养要高一些。

2.1.2生成测试用例

由于我们并不知道操作的内容具体是什么，用例可以往粗写，因为配置表单是提交所有列，所以生成的第一条测试用例必须是正向且有效的，这样才能保证以二维的形式进行逐项测试，而且用例写这么粗的好处是它可以沿用在所有配置项，维护程度极低，但坏处就是在测试过程中容易出现遗漏，而且测试输入描述也不够具体导致测试数据不可靠最终影响测试质量。

用例ID	测试用例	测试预期	覆盖测试点
test_001	所有输入项均填写正确的内容提交配置表单	提交成功	2、3、5、8、12、15、16
test_002	检查键值是否可修改，重复提交一行相同键值的配置表单	提交失败	1、3、5、8、12、15、16
test_003	检查可见内容是否齐全	内容齐全，不可见内容不显示	4
test_004	检查浏览属性内容是否可编辑	不可编辑，有明显标识	2、3、5、8、12、15、16
test_005	检查必填项是否有标识，只不填写必填项提交配置表单提交配置表单	提交失败	2、3、6、8、12、15、16
test_006	检查允许输入的字符类型，输入允许的字符类型提交配置表单	提交成功	2、3、5、8、9、12、15、16
test_007	检查不允许输入的字符类型，输入允许的字符类型提交配置表单	提交成功	2、3、5、8、10、12、15、16
test_008	检查必须有默认值的输入项，并按默认值提交配置表单	提交成功	2、3、5、8、11、12、15、16
test_09	检查允许输入空值输入项，输入空值并提交配置表单	提交成功	2、3、5、8、12、13、15、16
test_010	检查允许输入不空值输入项，输入空值并提交配置表单	提交失败	2、3、5、8、12、14、15、16
test_011	检查既可输入又可选择的输入框的操作可行性，	既可使用下拉框选择选项，也可直接输入内容	17
test_012	输入最大字符长度提交配置表单（边界测试）	提交成功	2、3、5、8、12、15、16、18
test_013	输入最大字符长度+1（边界测试）提交配置表单	提交失败或提交成功，但只显示允许的最长字符串	2、3、5、8、12、15、16、18
test_014	检查显示信息是否以中文为主		19
test_015	英文版本输入中文字符	不支持中文字符输入	20

这样就可以覆盖输入项所有的测试点，然后根据添加流程、UI界面等，或使用场景法、错误推断法再补充一些测试用例。

2.2设计阶段完善

2.2.1获得需求资源

需求做得比较好的项目一般会有原型图，如果需求阶段颗粒度不足以支持细化测试用例，可以再设计阶段去完善。
如下界面是在评审会议、和开发沟通后最终定稿的RTU配置增加界面、数据库表、xml资源文件、以及界面显示效果。
RUT配置界面

数据库设计表单

xml文件

界面显示效果

以上信息反馈的RTU配置表单已经非常清晰了，切合实际与开发方、产品经理确认设计没问题后就可以开始着手测试用例设计，这里注意一下，如果有歧义的需求，或者很可能在接下来的阶段中发生变更的需求建议按照粗略写法，特别清晰的需求则把颗粒度做细。

2.2.2分析需求资源

从获取的信息提取内容
1.列输入属性含义

2.提取的列输入属性（需求分解）






其中标签名、通道号为自动生成，灰色底色不可编辑；RTU名称、RTU描述、RTU号、RTU使能、所属位置、所属专业、通道号、RTU站址为必填项描述前带“*”符号。

2.2.3需求裁剪

1.不可编辑内容先列在补充用例中
2.自定义参数1、自定义参数2、自定义参数3为保留字段，可裁剪。
3.RTU站址、接收错误限值、目录树召唤时间均为常规通讯设置值，一般不超过2位数，无需进行边界测试
4.所属位置、所属专业、通道名称、RTU报警使能、61850服务器类型、录波使能、遥控禁止、设备离线数据清零中选择属性的输入项以观察的形式测试，放在补充用例。
5.录波目录一般为路径，可裁剪字符限制测试
6.录波描述无字符限制，可裁剪字符限制测试
7.责任区为隐藏列，可裁剪

2.2.4测试用例设计分析

等价类划分
配置表单输入项等价类划分表

2.2.6生成测试用例

用笛卡尔积考虑表单所有组合情况算一下强健壮等价类的用例数：
(2+3)*(2+3)*(1+3)*(1+2)*(1+2)*(1+2)*(1+3)*(2+2)*(2+2)*(2+2)*(2+1)*(2+2)*(2+1)*(3+2)=124416000，太多了不实际。
考虑组合的等价类一般是针对相互影响的输入项，无需考虑所有组合，明显这个配置表单不需要考虑组合情况，所有只涉及弱健壮等价类用例即可满足需求。
因为是以表单形式提交数据，所以第一条正向用例可多覆盖一些内容，后面的内容以二维的形式修改提交，即保持其它项为正向用例的基本项，只修改需要测试的输入项即可。
截图展示不清晰，可以直接下载文件，无需积分：
https://download.csdn.net/download/Hughier/13606443

预期输出只填写有效或无效是因为针对无效项程序的处理后的表现形式有可能不一样，但那都是合理的，有些是给出提示，如不填写必填项，有些是提交成功由程序处理，如超长字符不在输入框限制长度，在程序里截断等等。预期输入没有特别规范和明确的定义建议稍微写粗一些。

2.2.7补充测试用例

1.根据裁剪内容补充一些用例，配置表单内选择项用例补充
2.利用错误推断法延展一些可能出现BUG的地方，如：
a):输入框本身没有输入字符长度限制，只是在提交表单之后由程序截断，如果一直输入字符有可能出现BUG
b):RTU标签名生成规则是：厂站名称.专业名称.通道名称.RTU名称，长度均为64个字符，而标签名的字符长度限制也是64个字符，如果拼接起来超过64个字符极有可能出现BUG
c):利用标签名生成规则生成重复的标签名，最好方法是利用导入功能，可以测试到主键冲突
等等内容尽可能地增加测试用例的健壮性，让它们能够找出更多问题。

2.2.8开发设计的缺陷

除了关注用例设计内容之外，我们在这个过程当中，其实可以发现很多开发设计上的缺陷，文章的需求信息其实已经是后面更改得比较完善的了。我总结了一部分他们设计表单输入项时出现的一些问题。
1.字符限制规范性不够，部分输入项或表单需要做一样的字符限制，但是开发经常很随意，想到就限制，没想到就限制，就文章内的需求里就有，如录波描述输入项
2.字符限制不够或者限制错误，没有字符限制会经常因为一些敏感出现错误，本是限制数字却限制为其它字符等。
3.描述规范性不够，如在这张表叫RTU名称，另一张表又叫RTU名，而且部分下拉选项有些是名称，有些是描述。
4.内容表单显示的顺序不合理
5.必填项没有明显标识
6.只读项没有明显标识，甚至可输入内容
7.应是只读项可以编辑
8.提示信息不准确
9.表单填写麻烦，严重影响效率
等等情况，类似于这种在他们在设计表单的时候就需要及时提出，越到后期越是麻烦，甚至最后草草处理。

3总结

至此配置表单的输入内容测试用例设计就已经结束了，本文重点用到了等价类划分法，边界值法，利用错误推断法补充，实际项目应用中千变万化，方法都是一样的，重要的是你怎么去应对变化，不断地提高测试有效性，健壮性。