测试用例设计
1. 确定测试方法
采用边界分析方法
2.编写测试用例
10 程序的规格说明一:保存博文
输入:题目、内容、添加时间、是否置顶
要求:1、题目长度title_length(2~11)
2、内容长度content_length(10~2000)
3、添加时间不能为空
4、置顶类似为数字0或者1,1表示置顶
输出:1、如果保存成功,返回空;
2、如果保存失败,返回错误代码和错误描述
序号 |
错误代码 |
错误描述 |
1 |
10001 |
题目包含非法字符 |
2 |
10002 |
题目长度应该在min~max范围内 |
3 |
10003 |
内容长度应该在min~max范围内 |
4 |
10004 |
添加时间不能为空 |
5 |
10005 |
添加时间有误,应该是当前时间 |
6 |
10006 |
置顶信息出错 |
测试用例:(按顺序提供错误)遇到问题:这里的输出的结果是不是有多个输入决定的了?
用例编号 |
输入 |
预期的输出 |
注解 |
10001 |
Title=我的第一个博客 其他输入互不相关 |
错误码不应该是10001和10002 |
正确的博客名称 |
10002 |
Title=我的 其他输入互不相关 |
错误码不应该是10001和10002 |
正确的博客名称 |
10003 |
Title=我的第一个博客我的第一 其他输入互不相关 |
错误码不应该是10001和10002 |
正确的博客名称 |
10004 |
Title=我的第一个博客我的第一个 其他输入互不相关 |
错误码是10002 |
超出博客题目长度要求 |
10005 |
Title=我 其他输入互不相关 |
错误码是10002 |
超出博客题目长度要求 |
10006 |
Title=!@#$%^&*<> 其他输入互不相关 |
错误码不应该是10001和10002 |
正确的博客名称 |
10007 |
Title=我的第一个博客 Content长度为100个字符 |
错误码不应该是10001、10002、10003 |
正确的博文内容 |
10008 |
Title=我的第一个博客 Content长度为10个字符 |
错误码不应该是10001、10002、10003 |
正确的博文内容 |
10009 |
Title=我的第一个博客 Content长度为2000个字符 |
错误码不应该是10001、10002、10003 |
正确的博文内容 |
10010 |
Title=我的第一个博客 Content长度为9个字符 |
错误码应该是10003 |
超出博客内容长度要求 |
10011 |
Title=我的第一个博客 Content长度为2001个字符 |
错误码应该是10003 |
超出博客内容长度要求 |
10012 |
Title=我的第一个博客 Content=!@#$%^&*<><!> <body> |
错误码不应该是10001、10002、10003 |
正确的博文内容 |
10013 |
Title=我的第一个博客 Content长度为100个字符 Addtime为null |
错误码10004 |
添加时间不能为空 |
10014 |
Title=我的第一个博客 Content长度为100个字符 Addtime为离当前时间大于2天 |
错误码10005 |
添加时间有误 |
10015 |
Title=我的第一个博客 Content长度为100个字符 Addtime当前时间 |
不可能为10001到10005错误 |
正确添加时间 |
10016 |
Title=我的第一个博客 Content长度为100个字符 Addtime当前时间 Is_top=0 |
正确,无返回值 |
正确 |
10017 |
Title=我的第一个博客 Content长度为100个字符 Addtime当前时间 Is_top=1 |
正确,无返回值 |
正确 |
10018 |
Title=我的第一个博客 Content长度为100个字符 Addtime当前时间 Is_top=-1 |
返回错误码10006 |
置顶信息只能是0或者1 |
10019 |
Title=我的第一个博客 Content长度为100个字符 Addtime当前时间 Is_top=-2 |
返回错误码10006 |
置顶信息只能是0或者1 |
10020 |
Title=我的第一个博客 Content长度为100个字符 Addtime当前时间 Is_top=a |
返回错误码10006 |
置顶信息只能是0或者1 |
测试驱动器的方法:一种错误类型一个测试方法?
方法 |
检查到的测试用例 |
testCheckTitleTrue() |
10001, 10002,10003, 10006 |
testCheckTitleFalse() |
10010,10011 |
testCheckContentTrue() |
10007,10008,10009,10012 |
testCheckContentFalse() |
10004,10005 |
testCheckAddTimeTrue() |
10015 |
testCheckAddTimeNull() |
10013 |
testCheckAddTimeFalse() |
10014 |
testCheckBlogInputTrue() |
10016,10017 |
testCheckIsTop() |
10018,10019,10020 |
白盒测试:
判定(代码行数) |
条件 |
正确结果 |
错误结果 |
297 |
User.getUsername()!=null |
用户名不为空 |
用户名为空 |
299 |
USERNAME_EXIST.equals(resultStr) |
用户名已经存在 |
用户名不存在 |
304 |
User.getEmail()!=null |
邮箱地址不为空 |
邮箱地址为空 |
306 |
EMAIL_EXIST.equals(resultStr) |
邮箱地址已经存在 |
邮箱地址不存在 |
311 |
User.getMobile()!=null |
手机不为空 |
手机为空 |
311 |
User.getMobile().getMobileNum()!=null |
手机号码不为空 |
手机号码为空 |
313 |
MOBILE_EXIST.equals(resultStr) |
手机号码已经存在 |
手机号码不存在 |
使用多重条件设计方法,测试用例必须覆盖以下组合:但是路径会被遗漏,遗漏掉的路径需要用黑盒测试方法来补充
1、用户名为空
2、用户名不为空,用户名重复
3、用户名不为空,用户名不重复
4、邮箱地址为空
5、邮箱地址不为空,邮箱地址重复
6、邮箱地址不为空,邮箱地址不重复
7、手机号码为空
8、手机号码不为空,手机号码重复
9、手机号码不为空,手机号码不重复
那么测试用例必须覆盖上面的9个组合,注意了:一个测试用例尽量覆盖多个上面的组合条件
测试用例编号 |
输入 |
预期的输出 |
注释 |
1 |
username=”” email=”email”//邮箱地址可以注册 mobileNum=”” |
程序状态不变 Result=0
|
覆盖了条件:1、6、7 |
2 |
username=“username” email=”” mobileNum=”” 此用户名不存在数据库中 需要给出数据库预置的内容 |
程序状态不变 Result=0
|
覆盖了条件: 3、4、7 |
3 |
username=”existed_username” email=”” mobileNum=”” |
程序返回1 |
覆盖了条件: 2、4、7 |
4 |
email =”existed_ email” username=”” mobileNum=”” |
程序返回2 |
覆盖了条件: 1、5、7 |
5 |
mobileNum =“13960704444” 此手机号码不存在数据库中 需要给出数据库预置的内容 Username=”” Email=”” |
程序状态不变 Result=0
|
覆盖了:1、4、9 |
6 |
mobileNum =”13960704444” 此手机号码重复 Username=”” Email=”” |
程序返回3 |
覆盖了:1、4、8 |
7 |
Username=”” Email=”” mobileNum=”” |
程序返回4 |
覆盖了:1、4、7 |
上面1~10个组合都覆盖了。但是语句路径并不一定都会执行过。比如:1、6、8用户名为空、邮箱地址不重复、手机号码重复。这是一条路径无法执行到。需要使用其他方法补充
测试方法设计:
在《junit in action》书中说道:“一个单元测试等于一个测试方法,不要试图把多个测试塞进一个方法” 什么意思啊?看懂了么?
个人感觉应该是把相同的预期输出类型当作一个测试方法,这样不会乱。
Ps:此处代码有问题,如果全部为空,result=0,而程序中的result=0表示不存在用户重复信息,可用于注册,此处应该处理。
方法 |
检查到的测试用例 |
testAccountExistUserInfoNull |
9 |
testAccountExistUsernameExisted |
3 |
testAccountExistEmailExisted |
4 |
testAccountExistMobileNumExisted |
6 |
testAccountExistUserTrue |
1、2、5 |
步骤一:先写测试方法,然后方法内部使用Assert.fail(“未测试”);
Why?避免遗漏测试方法,养成好习惯:)
<!--[endif]-->
步骤二:填充测试方法
使用测试用例来填充
相关推荐
上一个博文我们已经完成了系统的登录及测试用例的创建,接下来我们需要对这些测试用例进行执行,也就是执行登录之后能够一起既可以创建测试用例,也可以修改测试用例也还可以创建bug及修改bug 一、创建执行用例的...
Mocha和Chai是常用的Node.js测试框架,它们可以帮助我们编写和运行测试用例。 9. **部署**:最后,我们需要将应用部署到服务器上,如Heroku、DigitalOcean或AWS。部署过程中需要注意环境变量的配置、进程管理(如PM...
这篇原创的博文——"[android]am自动化测试框架"探讨了如何利用`am`命令来构建一个高效的自动化测试解决方案。 `am`命令行工具允许开发者执行各种操作,如启动应用、发送广播、启动服务等,这对于测试场景的模拟和...
【描述】虽然描述部分为空,但根据提供的博文链接——"https://goby2008.iteye.com/blog/654302",我们可以推测这可能是一个在线技术博客上发布的Oracle学习心得或教程。在博客中,作者可能会分享实际操作经验,解决...
它的核心功能是生成和管理大量测试用例,以发现程序中的意外行为,尤其是安全漏洞。Sulley的设计理念是灵活性和可扩展性,因此用户可以根据需求自定义模糊策略和测试目标。 二、安装准备 在开始Sulley的安装前,...
在Android应用开发中,这样的测试类通常包含各种测试用例,以确保上下文菜单的正确显示、触发和操作。 基于以上信息,我们可以深入讨论以下几个Android开发相关的知识点: 1. **上下文菜单(Context Menu)**:在...
7. **测试与运行**:编写测试用例,确保整合后的系统能正常执行CRUD操作。运行应用,检查日志和数据库状态以验证整合效果。 在提供的压缩包"ibatis"中,可能包含了示例项目的源代码,包括上述配置文件、Mapper接口...
"Exam"这个名字可能指的是项目中的一个模块或者测试部分,它可能包含了练习题目、测试用例或者是一个模拟考试系统,帮助学习者检验自己对Oracle知识的掌握程度。在实际的学习过程中,通过模拟考试或练习题,学习者...
5. **测试用例**:可能包含JUnit测试,用于验证流程的正确性。 6. **依赖库**:可能有`lib`目录,存放了项目运行所需的JBPM和其他依赖库。 通过分析这个例子,学习者可以掌握JBPM的工作原理,了解如何创建和执行...
3. **测试框架**:如JUnit、pytest,用于编写和运行测试用例,确保程序正确性。 4. **虚拟环境**:如Python的venv或conda,隔离项目依赖,避免版本冲突。 5. **日志管理**:如Log4j、Python的logging,记录程序运行...
- **测试与部署**:编写测试用例验证功能,然后将应用部署到服务器。 6. **项目结构** "bbsws"这个压缩包可能包含了以下文件和目录: - `src/main/java`: 存放源代码,包括Spring配置、业务逻辑、DAO层、Web ...
读者一道探讨了单元测试、ALSA、Desktop check等问题。通过对本章的学习,相信读者会对Audio系统有更深的理解。 第8章以Surface系统为主,分析了Activity和Surface的关系、Surface和SurfaceFlinger的关系以及...