单元测试之静态测试

合集下载

软件质量保证与测试 第五章 单元测试与集成测试

软件质量保证与测试 第五章 单元测试与集成测试

测试用例的编 写 驱动模块、桩 模块的设计 执行测试用例 记录缺陷
单元测试用例
《缺陷跟踪报 告》
评估 阶段
完备性评估 代码覆盖率评 估
《单元测试报 告》
5.6 单元测试常用工具简介
1. JUnit介绍
2. 在Eclipse中JUnit应用举例
3. Junit+Ant构建自动的单元测试
4. CheckStyle/PMD与FindBug的使用
5.2.1 编码的标准和规范
标准: 建立起来必须遵守的规则 规范: 建议最佳做法,推荐更好方式 实施代码规范的原因: 可靠性 可读性和可维护性 可移植性
C语言编码规范
规范 规范内容 编号 1 一行代码只做一件事情 2 3 代码行的最大长度宜控制在70-80个字 函数与函数之间,说明语句和执行语句 之间最好加空行 在程序开头加注释,说明基本信息;在 重要函数处加注释,说明其功能 不要漏掉函数的参数和返回值,如果没 有,用void表示 是否 通过
检查要点是代码是否符合标准和规范,是否有 逻辑错误
审查(Inspection)

以会议形式,制定目标、流程和规则


按缺陷检查表(不断完善)逐项检查
发现问题适当记录,避免现场修改
发现重大缺陷,改正后会议需要重开。
走查与审查的比较
准备 走 查 审 查 通读设计和编码 事先准备Spec、程序设计 文档、源代码清单、代码 缺陷检查表等 非正式会议 正式会议 开发人员为主 项目组成员包括测试人员 无 缺陷检查表 会议记录 代码标准规范 无逻辑错误 静态分析错误报告 代码标准规范 无逻辑错误
单元测试的过程与文档管理时间依据任务成果计划阶段详细设计阶段后软件需求规格说明书详细设计说明制定测试计划单元测试计划设计阶段单元测试计划提交后单元测试计划软件详细设计说明驱动模块桩模块的设计单元测试用例执行阶段编码完成单元测试用例软件需求规格说明书详细设计说明执行测试用例记录缺陷缺陷跟踪报评估阶段单元测试用例缺陷跟踪报告缺陷检查表完备性评估代码覆盖率评阿迪达斯三条纹标志是由阿迪达斯的创办人阿迪达斯勒设计的三条纹的阿迪达斯标志代表山区指出实现挑战成就未来和不断达成目标的愿望

测试基础理论

测试基础理论

四、名词解释题1.软件测试:软件测试指为了发现软件中的错误而执行软件的过程。

它的目标是尽可能多地发现软件中存在的错误,将测试结果作为纠错的依据。

2.静态测试:指被测试的程序不在机器上运行,而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。

3.动态测试:指通过运行程序发现错误4.黑盒测试:指把测试对象看成一个黑盒子,测试人员完全不考虑程序的内部结构和处理过程,只在软件的接口处进行测试,依据需求规格说明书,检查程序是否满足功能要求,又称为功能测试或数据驱动测试。

5.白盒测试:把测试对象看成一个打开的盒子,测试人员需了解程序的内部结构和处理过程,以检查处理过程的细节为基础,对程序中尽可能多的逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致。

6.语句覆盖:设计足够的测试用例,使被测程序中每个语句至少执行一次7.判定覆盖:指设计足够的测试用例,使被测程序中每个判定表达式至少获得一次“真”值或“假”值,从而使程序的每个分支至少都通过一次,因此判定覆盖又称分支覆盖8.条件覆盖:指设计足够测试用例,使判定表达式中每个条件的各种可能的值至少出现一次。

9.判定/条件覆盖:设计足够的测试用例,使得判定表达式中每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次。

10.条件组合覆盖:指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。

11.路径覆盖:设计足够的测试用例,覆盖被测程序中所有可能的路径12.测试用例:指为寻找程序中的错误而精心设计的一组测试数据13.驱动模块:指用来模拟被测模块的上级调用模块,其功能比真正的上级模块简单得多,它只完成接受测试数据,以上级模块调用被测模块的格式驱动被测模块,接收被测模块的测试结果并输出。

14.桩模块:桩模块指用来代替被测试模块所调用的模块,其作用是返回被测试模块所需的信息。

Spock单元测试框架实战指南六-静态方法测试

Spock单元测试框架实战指南六-静态方法测试

Spock单元测试框架实战指南六-静态⽅法测试本篇主要讲解Spock如何扩展第三⽅Power Mock对静态⽅法进⾏测试实现原理前⾯的⽂章讲到Spock的单测代码是继承⾃Specification基类,⽽Specification⼜是基于Junit的注解@RunWith()实现的,代码如下:@RunWith(Sputnik.class)@SuppressWarnings("UnusedDeclaration")public abstract class Specification extends MockingApi {powermock的PowerMockRunner也是继承⾃Junit,所以使⽤powermock的@PowerMockRunnerDelegate()注解可以指定Spock的⽗类Sputnik去代理运⾏power mock,这样就可以在Spock ⾥使⽤powermock去模拟静态⽅法、final⽅法、私有⽅法等其实Spock⾃带的GroovyMock可以对groovy⽂件的静态⽅法mock,但对Java代码的⽀持不完整,只能mock当前Java类的静态⽅法,官⽅给出的解释如下:()因为我们项⽬中存在很多调⽤静态⽅法的代码,现阶段考虑重构业务代码的成本过⾼,所以这⾥使⽤扩展power mock的⽅式测试静态⽅法Spock 代理 Power Mock先看下需要测试的业务代码⽰例:public UserVO getUserByIdStatic(int uid){List<UserDTO> users = userDao.getUserInfo();UserDTO userDTO = users.stream().filter(u -> u.getId() == uid).findFirst().orElse(null);UserVO userVO = new UserVO();if(null == userDTO){return userVO;}userVO.setId(userDTO.getId());userVO.setName(userDTO.getName());userVO.setSex(userDTO.getSex());if("上海".equals(userDTO.getProvince())){userVO.setAbbreviation("沪");userVO.setPostCode(200000);}if("北京".equals(userDTO.getProvince())){userVO.setAbbreviation("京");userVO.setPostCode(100000);}if(null != userDTO.getTelephone() && !"".equals(userDTO.getTelephone())){userVO.setTelephone(userDTO.getTelephone().substring(0,3)+"****"+userDTO.getTelephone().substring(7));}// 静态⽅法调⽤⾝份证⼯具类Map<String, String> idMap = IDNumberUtils.getBirAgeSex(userDTO.getIdNo());userVO.setAge(idMap.get("age")!=null ? Integer.parseInt(idMap.get("age")) : 0);// 静态⽅法调⽤记录⽇志("response user:", userVO.toString());return userVO;}在倒数第4⾏和倒数第2⾏代码分别调⽤了 "⾝份证⼯具类IDNumberUtils.getBirAgeSex()" 和 "()" ⽇志记录的⽅法,如果要对这两个静态⽅法进⾏mock,我们可以使⽤Spock+power mock的⽅式:import org.junit.runner.RunWithimport org.mockito.Mockitoimport org.powermock.api.mockito.PowerMockitoimport org.powermock.core.classloader.annotations.PrepareForTestimport org.powermock.core.classloader.annotations.SuppressStaticInitializationForimport org.powermock.modules.junit4.PowerMockRunnerimport org.powermock.modules.junit4.PowerMockRunnerDelegateimport org.spockframework.runtime.Sputnikimport ng.Specification/*** 测试静态⽅法mock* @Author: * @Description: 公众号:Java⽼K* @Date: Created in 20:53 2020/7/16* @Modified By:*/@RunWith(PowerMockRunner.class)@PowerMockRunnerDelegate(Sputnik.class)@PrepareForTest([LogUtils.class, IDNumberUtils.class])@SuppressStaticInitializationFor(["com.javakk.spock.util.LogUtils"])class UserServiceStaticTest extends Specification {def processor = new UserService()def dao = Mock(UserDao)void setup() {erDao = dao// mock静态类PowerMockito.mockStatic(LogUtils.class)PowerMockito.mockStatic(IDNumberUtils.class)}def "GetUserByIdStatic"() {given: "设置请求参数"def user1 = new UserDTO(id:1, name:"张三", province: "上海")def user2 = new UserDTO(id:2, name:"李四", province: "江苏")def idMap = ["birthday": "1992-09-18", "sex": "男", "age": "28"]and: "mock掉接⼝返回的⽤户信息"dao.getUserInfo() >> [user1, user2]and: "mock静态⽅法返回值"PowerMockito.when(IDNumberUtils.getBirAgeSex(Mockito.any())).thenReturn(idMap)when: "调⽤获取⽤户信息⽅法"def response = processor.getUserByIdStatic(1)then: "验证返回结果是否符合预期值"with(response) {name == "张三"abbreviation == "沪"postCode == 200000age == 28}}}在UserServiceStaticTest类的头部使⽤@PowerMockRunnerDelegate(Sputnik.class)注解,交给Spock代理执⾏,这样既可以使⽤ Spock + groovy 的各种功能,⼜可以使⽤power mock的对静态,final等⽅法的mock@SuppressStaticInitializationFor(["com.javakk.spock.util.LogUtils"])这⾏代码的作⽤是限制LogUtils类⾥的静态代码块初始化,因为LogUtils类在第⼀次调⽤时会加载⼀些本地资源配置,⽐较耗费时间,所以可以使⽤power mock禁⽌初始化然后在setup()⽅法⾥对两个静态类进⾏mock设置PowerMockito.mockStatic(LogUtils.class),PowerMockito.mockStatic(IDNumberUtils.class)最后在GetUserByIdStatic测试⽅法⾥对getBirAgeSex()⽅法指定返回默认值:PowerMockito.when(IDNumberUtils.getBirAgeSex(Mockito.any())).thenReturn(idMap)(power mock的具体⽤法⽹上资料很多,这⾥不展开说明)运⾏时在控制台会输出:Notifications are not supported for behaviour ALL_TESTINSTANCES_ARE_CREATED_FIRST这是powermock的警告信息,不影响运⾏结果另外,如果你的单元测试代码不需要对静态⽅法, final⽅法mock, 就没必要使⽤power mock, 使⽤Spock⾃带的Mock()就⾜够了因为power mock的原理是在编译期通过ASM字节码修改⼯具修改我们的代码,然后使⽤⾃⼰的classLoader加载,加载的静态⽅法越多会相应的增加测试时长⽂章来源:。

软件测试介绍

软件测试介绍
测试用例(Test Case):测试执行之前设计的详 细测试方案,主要包括测试环境、测试步骤、测试 数据、预期结果。
测试用例=测试环境+输入数据+输出数据 编写测试用例的作用: 分析和明确各个测试点的测试内容 方便测试团队成员之间的交流。 方便项目后续版本重复内容的测试。 方便跟踪测试策略的执行情况。
输入数据集合。 无效等价类:是指不符合需求规格说明,无意
义的输入数据集合。
边界值法
边界值法:检测输入数据最大值和最小 值的测试方法
测试边界值时,一般测试边界值和正好 超过边界值一个单位的值。
边界值时最容易出现问题的地方,也是 测试时要重点测试的内容。
因果图法
因果图法:根据被测系统的逻辑结构,设计输 入和输出的测试方法,主要用于输入条件比较 多的情况。
国内大型软件公司组建自己的软件测试部门或质量保障部。测试人员整体素 质较高,团队意识较强,产品质量较高,客户满意度较好,测试人员职业发 展方向清晰、明确。
测试人员的发展
技术方向(测试顾问、测试专家) 管理方向(测试经理、质量总监) 自主创业(测试外包、测试培训)
软件的基本概念
软件=程序+文档 程序:能够实现某种功能的集合(C语言程序、VB程序、JAVA程序等) 文档:软件开发、使用、维护过程中使用的文字、图片的集合(《需求
为国内大型企事业单位提供人力外包或测试外包服务,中科方德(客户主要 是军工行业),大展科技(客户主要是中国电信等),东南融通(客户主要 是金融行业)。雇佣军、团队归属感差、体力活、技术含量低,不要求外语。
公司的测试工作由开发工程师完成或只有很少比例的测试人员。测试人员不 专业,公司产品质量差,公司对测试人员不重视,测试人员薪资低,职业发 展前景堪忧。

软件测试练习题及答案

软件测试练习题及答案

一、判断(01)测试是为了验证软件已正确地实现了用户的要求。

错(02)白盒测试仅与程序的内部结构有关,完全可以不考虑程序的功能要求。

对(03)白盒测试不仅与程序的内部结构有关,还要考虑程序的功能要求。

错(04)程序员兼任测试员可以提高工作效率。

错(05)黑盒测试的测试用例是根据应用程序的功能需求设计的。

对(06)当软件代码开发结束时,软件测试过程才开始。

错(07)据有关数据统计,代码中60%以上的缺陷可以通过代码审查发现出来。

对(08)无效等价类是无效的输入数据构成的集合,因此无需考虑无效的等价类划分。

错(09)软件本地化就是将一个软件产品按特定国家或语言市场的需要翻译过来。

错(10)在压力测试中通常采用的是黑盒测试方法。

对(11)软件测试员无法对产品说明书进行白盒测试。

对(12)功能测试工具主要适合于回归测试。

对(13)测试人员说:“没有可运行的程序,我无法进行测试工作”。

错(14)自底向上集成需要测试员编写驱动程序。

对(15)测试是可以穷尽的。

错(16)自动化测试相比手工测试而言,能发现更多的错误。

错(17)软件测试自动化可以提高测试效率,可以代替手工测试。

错(18)语句覆盖法的基本思想是设计若干测试用例,运行被测程序,使程序中的每个可执行语句至少被执行一次。

对(19)Beta测试是验收测试的一种。

对(20)软件开发全过程的测试工作都可以实现自动化。

错(21)软件只要经过严格严谨的内部测试之后,可以做到没有缺陷。

错(22)结构性测试是根据软件的规格说明来设计测试用例。

错(23)软件测试工具可以代替软件测试员。

错(24)通过软件测试,可以证明程序的正确性。

错(25)在单元测试中,驱动程序模拟被测模块工作过程中所调用的下层模块。

错(26)软件缺陷可能会被修复,可能会被保留或者标识出来。

对(27)测试用例是由测试输入数据和对应的实际输出结果这两部分组成。

错(28)单元测试通常由开发人员进行。

对(29)现在人们普遍认为软件测试不应该贯穿整个软件生命周期,而应在编程完毕之后再进行,这样可以降低成本。

软件测试-模块(单元)测试

软件测试-模块(单元)测试

K
L
自底向上的增量测试中的驱动模块
A
B
C
D
调用从属模块
调用从属模块, 调用从属模块,
并传递参数
并要求得到参

兼有B,C的功 能
自顶向下测试和自底向上测试的比较
自顶向下 自底向上
优点 缺点
如果主要缺陷发生在程序顶层将非常有利 早期程序框架可以进行演示,即提早发现主要的控 制问题
必须开发桩模块 桩模块可能要比最初表现的更复杂 创建测试环境可能很难,甚至无法实现 观测测试输出比较困难
stuBbB
替桩模块,如B,
并添加B的桩模块;
如图
stubE stuFbF
增量的序列有多种
可能,例如:
ABFJDICGEKHL,
J
加入I后如图
A stubC
stuDbD
stubH
I
自顶向下的增量测试中的桩模块
A
B
C
D
显示跟踪信息 显示传递信息 返回一个值
根据输入返回 一个值
自底向上的增量测试
第一步是测试E,J,G, K,L
按照书P51的规格说明和P53的代码,用你 熟悉的语言重新实现该功能,并对该程序进 行白盒测试,要求使用下面各种覆盖准则设 计测试用例: 判定覆盖 条件覆盖 判定/条件覆盖 多重条件覆盖 准则,并分析效果如何。
优点 缺点
如果主要的缺陷发生在程序的底层将非常有利 提早发现程序当中的主要算法问题 测试环境比较容易建立 观测测试输出比较容易
必须开发驱动模块 直到最后一个模块添加进去,程序才形成一个整体
5.4 执行测试
审核测试用例 当测试用例造成模块输出的实际结果与预期结果不匹配 的情况时,存在两种可能:该模块存在错误,或者测试 用例不正确。因此,执行测试前应审核测试用例集。

实验一 单元静态测试工具pclint的使用(1)

实验一 单元静态测试工具pclint的使用(1)
1.新建一个名为pclint的项,
2.在下面填入command:C:\lint\lint-nt.exe
3.arguments:-u -ic:\lint std.lnt $(FileName)
4.initial directory:$(FileDir)
e Output Window打上勾
6.close完成。
shiyan2.c(51) : Info 716: while(1) ...
_
2、Delay();
shiyan2.c(56) : Warning 522: Highest operation, function 'Delay', lacks
side-effects、
intscoreMath;
intscoreMusic;
};
void main()
{
struct STUDENT stu[30] = {{1,"杨过","男",{1999,12,20},90,83,72,82},{2,"郭靖","男",{1999,07,06},78,92,88,78},
{3,"小龙女","女",{1999,07,06},89,72,98,66},{4,"郭襄","女",{1999,07,06},78,95,87,90}};
{
t->second=0;
t->minute++;
}
if (t->minute==60)
{
t->minute =0;
t->hour++;
}

单元测试与集成测试

单元测试与集成测试

4.驱动模块和桩模块
※ 运行单元程序有时需要基于被测单元的接口,开发相应的驱 动模块和桩模块。
4.驱动模块和桩模块
驱动模块(drive):对底层或子层模块进行(单元或集成)测试 时所编制的调用被测模块的程序,用以模拟被测模块的上级模块。
桩模块(stub):也有人称为存根程序,对顶层或上层模块进行 测试时,所编制的替代下层模块的程序,用以模拟被测模块工作过 程中所调用的模块
※ 面向对象的单元就是类,单元测试实际测试的就是对类的测 试。
※ 类测试的目的主要确保一个类的代码能够完全满足类的说明 所描述的要求
5.类测试
※ 对类的测试可以分成两个层次进行:
方法内测试 方法间测试
※ 类测试一般有两种主要的方式:功能性测试和结构性测试, 即黑盒测试和白盒测试。
功能性测试以类的规格说明为基础,它主要检查类是否符合其规格 说明的要求
单元测试与集成测试
目录
1 单元测试的目标和任务 2 单元的静态测试 3 驱动程序和桩程序 4 单元测试工具 5 集成测试
1
单元测试的目标和任务
※ 测试的4个阶段: 单元测试集成测试系统测试验收测试
按阶段进行测试是一种基本的测试策略
1.什么是单元测试
※ 定义:单元测试是对软件基本组成单元进行的测试。
3.单元测试的目标和任务
任务4:模块边界条件测试
检查临界数据处理的正确性 Checklist: − 普通合法数据的处理。 − 普通非法数据的处理。 − 边界值内合法边界数据的处理。 − 边界值外非法边界数据的处理。 − 其它
3.单元测试的目标和任务
任务5:模块的各条错误处理通路测试
预见、预设的各种出错处理是否正确有效。 Checklist: − 输出的出错信息难以理解。 − 记录的错误与实际不相符。 − 程序定义的出错处理前系统已介入。 − 异常处理不当。 − 未提供足够的定位出错的信息。 − 其它
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
代码审查单
请参见GJB141-2004附录A,也可以根据具体项目情况 自行编写
可编辑ppt
9
代码审查、走查
注意事项
时间和地点应该避免被干扰 每次不应该超过6个小时,每小时审查150-200行代
码 树立正确的态度 实际项目的实施策略:上午组织会议审查,讲解
代码,不超过3个小时。下午测试人员和审查组长 总结上午的审查结果,填写问题报告单,如果可 以,请代码编写人员确认。具体审查的代码行数 可以根据实际情况增加或减少。
8
代码的一致性:即检查代码执行标准的情 况;检查代码逻辑表达的正确性;检查代码结构的合理性; 检查代码的可读性
代码审查的组织
由四人以上组成:组长,资深程序员,程序编写者 (秘书)和专职测试人员。组长不能是被测试程序的编写 者,组长负责分配资料,安排计划,主持开会,记录并保 存被发现的错误。
圏复杂度越大,程序越复杂,可靠性越差,一 些标准均要求圏复杂度小于10
2.注释度量分析
注释行的比例为20%~30%,且头注释、执行 行注释、声明注释均在对应的位置。
可编辑ppt
7
静态分析
静态分析阶段文档
一般不单独出具静态分析报告,但是可以作为测试过 程文件提交用户审阅;
一定要填写问题报告单
可编辑ppt
可编辑ppt
10
软件代码审查问题报告单
软件名称 审查人员 开发方人员 文件名: 缺陷类型 缺陷位置 问题概述 问题详述 填写人
模块名: 缺陷等级 唯一标识
报告日期
可编辑ppt
11
静态测试是重要的测试方法, 不是独立的测试阶段!
可编辑ppt
12
软件静态测试技术
可编辑ppt
1
什么是静态测试?
静态测试,是在不执行代码的情况下对代 码进行测试的过程。
适用对象: 计算机软件单元、计算机软件部件、
计算机软件配置项的源代码。 进入条件:
代码无错误地通过编译。
可编辑ppt
2
静态测试的方法
代码审查
代码走查
静态分析
1.控制流分析:使用控制流程图系统检查被测程序 的控制结构的工作。
5
静态分析
一、规则检查 1.代码符合行业规范,国家标准,企业内部规范 2.把艺术变成科学 3.去掉隐含的编码缺陷 4.前事不忘后事之师
常用工具:CodeWizard、C++ Test 、 Logiscope、 Cpptest、 PRQA
可编辑ppt
6
静态分析
软件度量 1.McCabe圏复杂度
2.数据流分析:使用控制流程图分析数据发生的异 常情况。
3.接口分析:程序静态分析和设计分析。 4.表达式分析:检查表达式的错误。
可编辑ppt
3
单元测试阶段的静态测试流程
1.编译器检查 2.利用工具进行静态分析 3.人工代码审查和代码走查
编译器和解释器是第一步的测试
可编辑ppt
4
可编辑ppt
相关文档
最新文档