表格作为数据库数据在UI层面的直观展示,是用户实现信息管理的最佳媒介,因此在测试活动中经常涉及到这方面的测试。

 

【案例 后台商品管理列表测试】

ECShop系统的后台商品管理功能页面,采用的是表格形式展现数据,如图1所示。

 

表格测试

图1 ECShop后台商品信息列表

 

表格测试一般关注数据显示、翻页、附加功能等几个方面。

01

数据显示

 

用户与系统的交互信息,很多时候通过数据形式记录在数据库中,通过逻辑代码处理,以表格形式展示相关信息,用户增加、修改、删除以及查询数据的最终结果都体现在表格上,因此验证数据显示的正确性是表格测试的核心。

 

数据显示主要涉及标题栏、数据内容、字符编码、列宽等几个方面。

 

1) 标题栏

 

标题栏应该与产品需求/DEMO设计相同,字体设计一致,排序需遵从用户习惯确定,如果系统有增加数据的功能,则标题栏的内容、顺序应与增加界面的布局相同。

 

以ECShop商品管理为例,添加商品的界面如图2所示。

 

表格测试

图2 添加商品信息界面

 

从上图得知,商品信息添加功能的字段分别是:商品名称、商品货号以及价格,那么商品列表标题栏显示顺序也应当是商品名称、商品货号、价格等,如图3所示。如果商品货号排在商品名称前面,则测试工程师可提出建议性缺陷。

 

表格测试

图3 商品列表显示界面

 

图3标题栏显示顺序与添加商品信息界面中的字段布局相同,因此测试通过。但需注意的是,添加商品信息时的“商品货号”在商品列表中显示为“货号”,这种情况虽无大碍,但测试工程师可以提交一个建议性的缺陷,建议开发工程师将二者表述统一,做到上下文一致。

 

2) 数据内容

 

表格显示格式确定后,需验证数据内容是否正确,如果“商品名称”列下显示的是“商品货号”,则是很严重的缺陷,测试工程师应当细致检查数据,尤其是通过字段名称跳转到新页面的数据信息,如点击“商品名称”可打开该商品的详细信息,在测试过程中需仔细校对数据的正确性。

 

3) 字符编码

 

字符编码一般跟程序代码有关,可能由于浏览器编码设置错误,导致乱码,如图4所示。

 

表格测试

图4 商品信息显示乱码

 

上述情况是由于FireFox浏览器编码改为简体中文,导致数据显示乱码,将浏览器重新设置为Unicode格式后显示正常,测试工程师在执行测试时,需确认是由于浏览器编码原因导致乱码错误还是因为程序代码字符集设计错误导致乱码。

 

有时候乱码错误可能是因为数据导入数据库时造成的错误,以Mysql数据库为例,执行SQL导入时,如果不进行匹配的字符集设置,可能导致乱码,这种情况一般是环境搭建问题,与程序代码无关,设置好数据库字符集格式即可。

 

表格测试

图5 数据库数据乱码

 

4) 列宽

 

列宽设置不合理将会导致表格界面显示错乱,或者当列数据内容较多时,会导致页面被撑开,从而导致界面显示错误,这种情况下,需测试系统是否具有自适应功能,当数据超过界面定义的边界时自动截取或收缩,如果没有自适应功能,则具体情况具体分析,但必须保证界面显示美观。

 

表格测试

图6 商品分类列宽显示界面

 

ECShop商品分类管理中,针对商品类别名称长度进行了控制,当超过20个汉字时,系统自动截取,仅保留前20个汉字,并在显示列表中固定列宽,这种情况下,就不会出现界面被撑开、显示错乱的现象。但此处仍有个细节问题,商品分类列表中,单行可容纳20个汉字,但在19个汉字时换行,第二行仅有1个字,测试工程师可提出建议,加大列宽,以容纳换行的1个汉字,或者单行超过10个汉字时换行,尽可能美化UI,当然,这仅仅是建议,可根据UI设计人员的设计测试。

 

02

翻页

 

翻页功能是绝大多数表格都应用到的功能,通常有第一页、最后一页、上一页、下一页、跳转第_页等,这类功能测试根据字面意思测试即可,跳转功能这可根据文本编辑框的测试方法进行,如输入非数字、输入单引号等。

 

有些翻页功能设计时,次页显示的第一条数据是前一页的最后一条数据,设计如此,并非缺陷,测试工程师在测试时应当与开发工程师确认。

 

03

附加功能

 

表格中有时候会提供查看、增加、修改、删除数据以及设置每页显示多少条数据的功能,测试工程应当逐个测试,以确保每项功能正确。

 

1) 查看数据

 

不同的设计方法,提供了不同的功能,有些表格通过记录名称打开数据详细信息,有些则通过功能按钮打开数据详细信息,无论哪种,需确保数据信息的正确性,这类测试如有条件,可连接数据库通过SQL语句直接查询相关数据,与界面数据信息进行对比测试。

 

2) 增加数据

 

测试增加数据功能时,点击“增加”按钮,如果是弹出窗口,则表格数据信息不应当刷新,在新的界面中添加相关数据,添加完成返回时,界面应当全部或局部刷新,显示新增加的数据。

 

如果新增加的数据未能出现在列表中,首先应当确认该数据是否应该显示在当前页面,如果是,再检查是否是因为浏览器缓存问题导致页面刷新错误,最后验证数据库是否存入成功数据。

 

3) 修改数据

 

很多产品在设计修改功能时,要求将原来的设计读取出来,这点与根据产品设计确定。如果需读出原数据,测试工程师需确认原数据读取是否正确,其他测试方法与增加数据类似。

 

修改数据时,有些字段是不可重新编辑的,如系统自动生成的id号,或者分配的流水号,贷款申请单号等,如果进入修改页面,这些数据处于可编辑状态,无论是否能否真正编辑,都应当提交缺陷。

 

修改数据时的必填项设置应该与增加数据设置一致。

 

修改数据具有一定的破坏性,因此数据修改操作在提交时应该给予信息提示,提示信息应与产品需求一致。

 

修改数据需考虑数据锁定问题,即数据被其他用户或操作打开时,该数据不可编辑(修改或删除),以保证数据的一致性与安全性。

 

4) 删除数据

 

删除数据最具破坏性,在执行删除数据操作前,系统应当给予提示,如有必要可进行二次确认,如果用户放弃删除操作,则列表不应当刷新,如果用户确认执行删除操作,删除操作完成后,列表进行刷新,已删除的信息不应当出现。

 

删除数据与修改数据一样,同样需考虑数据锁定问题,用户在打开某条记录时,其他用户或操作不可进行修改或删除操作。常用的一个测试方法是具有权限的两个用户同时打开某条记录,A用户先执行删除操作,B用户再执行修改操作,验证被测对象的处理方式。

 

以ECShop商品类别管理为例,后台管理分别利用两个浏览器登陆后,选择某个商品类别进行修改及删除操作。先删除类别,再进行修改,ECShop提示修改成功,但返回类别列表时,该类别并不存在,这种情况测试工程师应当提出缺陷,因为用户在实际应用过程中可能会出现类似冲突的问题,系统应当给予合理的处理。

 

5) 设置每页显示条数

 

与跳转功能一样,需测试合法输入与非法输入的情况,其他根据需求确认即可。