导入测试用例的设计

目前很多产品中都支持导入导出的功能,根据自己测试的一些经验,总结了以下一些测试用例

1、 确定支持哪种导入文本格式。有些支持excel格式、有的支持txt格式,支持哪种文件格式需要前台约束文件后缀

2、 如果导入格式为excel文件,最好支持xls后缀的,因为xlsx可以转成xls格式的,反之则不可以

3、 空文件导入验证。上传空文件,查看页面和后台是否报错

4、 导入文件里面所有字段格式验证。验证包括空、空格、特殊字符、长度、唯一性等验证

5、 文件中最大行数的验证。Excel2003一个工作表最多可有65536行,Excel 2007及以后版本,一个工作表最多可有1048576行,这个同样适用于导出功能,如果使用2003的版本,导出不能超过65536,如果对最大行数不确定的,建议适用txt文件。

6、 Excel中单元格内容(文本)的长度 32,767 个字符,曾经我们做过一个项目,把帮助文档以html的格式导出到excel中就超出了32767个字符,所以这点也需要特别注意

7、 如果有导出的功能,一定要先导出再导入验证看看是否可以正常导入

8、 Excel导入有sheet的概念,可以放在sheet2中导入试试看

9、 导入是否有错误提示。一般做法有二种:第一个是一行一行读取,如果有字段不满足则直接抛弃掉,然后在页面上提示成功导入多少行,抛弃了多少行;第二种是一行一行读取只要发现有错误则批量回滚,在前台页面或者后台日志中提示用户哪一行有问题,让用户修改完了再导入

10、 导入的时候刷新页面,看看页面和后台是否报错

11、 Excel中单元格输入超长的数字,会显示E+什么的,需要设置成文本格式,这个在导出的时候需要特别注意。如果导入的话,建议给个导入的模板,用户按照模板填充数据再导入

12、 导入的性能测试,比如一次导入1万行,大概时间是多少,客户是否可以接受

时间: 2024-10-14 04:30:29

导入测试用例的设计的相关文章

测试小笔记(黑\白盒测试及区别、测试用例的设计)

测试的概念: 白盒测试 黑盒测试 白盒测试.黑盒测试优劣比较   测试用例的设计 一般而言,在所有的方法中效率最低的是随机输入测试,即在所有可能的输入值中随机选取某个子集来对程序进行测试的过程. 白盒测试的方法:1)语句覆盖.2)判定覆盖.3)条件覆盖.4)判定/条件覆盖.5)多重条件覆盖. 1.>语句覆盖:较弱的准则,将程序中的每条语句至少执行一次. 2.>判定覆盖或分支覆盖:较强的逻辑覆盖准则,必需编写足够的测试用例,使得每个判断都至少有一个为真和为假的输出结果.也就是说每条分支路劲都必须

测试用例的设计方法

测试用例的设计方法有: 等价类划分方法,边界值分析方法,错误推理方法,因果图方法,判定表驱动分析方法,正交实验设计方法,功能图分析方法,场景设计方法 等价类划分方法: 基本概念: 一.方法简介 1.定义 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 2.划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等

软件测试用例的设计和编写

一.为什么要写测试用例 写测试用例可以让测试的需求覆盖更加全面,让测试工作进行得条理有序,且方便移交和交流 好的测试用例要做到:结构设置和理,case覆盖全面,且具有可执行性,可重复等特点. 二.软件测试文档 1.测试范围列表:需求编号.模块名称.功能名称.复杂度.复用性.自测充分性.是否公用模块.使用频率.优先级 2.测试用例一般包含的要素:用例编号.测试项目.用例标题.优先级(致命.严重.一般.微小.建议).预置条件.输入参数.执行步骤.预期结果 3. 缺陷报告要素:缺陷编号.缺陷标题.严重

从“系统登陆”测试用例案例来分析测试用例的设计

编写测试用例是软件测试工程师最基本的工作.但是如何要编写出好的测试用例,这还真是需要我么对平时的工作认真的进行总结一下. 下面我以"系统登陆"黑盒测试用例设计来分析一下测试用例到底如何来写? 一.案例描述 测试对象:是一个以B/S结构系统的登陆功能点. 功能描述:1.用户在地址栏输入相应的地址,要求限时登陆界面 2.输入用户名.密码和验证码,登陆,系统自动校验,并给出相应提示信息. 3.如果用户名.密码.验证码任一信息未输入,登陆后系统给出相应提示信息. 4.连续3次未通过验证时,自动

测试用例的设计步骤

测试用例的设计步骤作为测试新人,如何实现测试用例的设计一直是我的一个疑惑,在工作中写过几个项目的测试用例,尝试总结一个测试用例的设计步骤.前提:编写测试用例之前我们需要对项目的需求有清晰的了解,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数,作为测试用例的编写者不仅了解要有常见的测试用例编写方法,同时需要了解被测软件的设计.功能规格说明.用户试用场景以及程序/模块的结构.步骤:1.测试需求分析从项目部拿到软件的需求规格说明书后,开始对项目的需求进行分析,通过自己的分析.理解,整理成为测

单元测试中测试用例的设计方法

单元测试中测试用例的设计方法 1. 用于语句覆盖的基路径法 基路径法保证设计出的测试用例,使程序的每一个可执行语句至少执行一次,即实现语句覆盖.基路径法是理论与应用脱节的典型,基本上没有应用价值,读者稍作了解即可,不必理解和掌握. 基路径法步骤如下: 1)画出程序的控制流图 控制流图是描述程序控制流的一种图示方法,主要由结点和边构成,边代表控制流的方向,节点代表控制流的汇聚处,边和结点圈定的空间叫做区域,下面是控制流图的基本元素: 以下代码: void Sort(int iRecordNum,

011-黑盒测试的测试用例常见设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

黑盒测试的测试用例常见设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用. 1)等价类划分 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2)边界值分析法 边界值分析方法是

在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?

导语:”在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?” 偶然在知乎上看到一篇关注度很高的话题,标题如上. 作为一名从业8年有余的软件测试工程师,并且一直在外企做测试的我, 忍不住想发表一些自己的看法和见解. 我觉得在国内,很多公司或者个人把自动化测试当成一个了不起的资本,根本是源于国内大家对代码的无上崇拜,这也造就了国内现在IT互联网行业内一个鄙视链: 开发---> 测试开发--->自动化测试---&g

测试用例的设计思路

在结对项目中,我负责测试用力的设计以及执行.在设计测试用例的过程中,我运用到了以下思路. 良好测试用例的特征: 可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求既不过分复杂.也不能过分简单 使软件缺陷的表现可以清楚的判定 测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰.格式一致.分类组织 测试用例的几种设计思路: 对于白盒测试: 1. 语句覆盖:设计若干个测试用例,使程序中的每个可执行语句至