测试思想 单元测试用例基础设计思想总结

简介: 测试思想 单元测试用例基础设计思想总结

单元测试用例基础设计思想总结

by:授客QQ1033553122

 

基于网络相关资料,加上个人理解,总结的单元测试用例设计思想。

 

语句覆盖

要求设计足够多的测试用例,使得函数中的每条语句都至少执行一次。

例子

 

 

对应代码:

   // 语句覆盖

   public intfunc1(intx) {

       inta =0;

       if(x <0) {

           a = a +1;

       }

       returna;

   }

 

 

用例设计

x  = -1

 

注:简单的说,用例大致由3部分组成,一部分是操作,一部分是操作时使用的测试数据,另一部分是输出及预期结果等,这里操作和输出预期结果等都暂且不提,这里说的用例设计,主要是指设计测试数据,因为这个是核心,下同,不再赘述

 

缺点分析

语句覆盖不考虑判断条件,容易导致漏测,如上,虽然执行了每条语句(int a = 0; a = a + 1; return a;),但是因为没考虑条件if (x < 0),导致x >= 0的情况未被测到。

 

判定覆盖

也称为分支覆盖,要求设计足够多的测试用例,使得函数中的每个判断的的每条分支都必须至少执行一次。

例子

 

 

 

对应代码

public voidfunc2(inty) {

       if(y ==0) {

           y = y +1;

       }else{

           y = y +2;

       }

   }

 

public voidfunc3(inti) {

switch(i) {

          case  1: i = i +1;break;

           case  2: i = i +2;break;

           case  3: i = i +3;break;

       }

}

 

 

用例设计

y = 0

y = 1

 

i = 1

i = 2

i = 3

 

 

对应代码

public intfunc4(intx, inty){

   inta;

   if(x <2) {

       x = x +1;

   }

 

   if(y >3) {

       y = y +3;

   }

 

   a = x + y;

   returna;

}

 

用例设计

x = 1, y = 2

x = 3, y = 4

 

代码:

public intfunc5(inta, intb) {

   if(a <1&& b >5) {

       returna - b;

   }else{

       returna + b;

   }

}

 

用例设计

a = 0

a = 2

 

缺点分析

1、判定覆盖只考虑了判断的每条分支,但是未考虑所有判断的分支组合,如上,绿色线条所代表的路径(第一个判定结果为false,第二个判定结果为true的情况)就未测到

2、判定覆盖只考虑了判断的最终结果,未考虑判断中每个条件的取值情况,这容易导致业务逻辑漏测,如上最后一个例子,假设a < 1 && b > 5应该写成a < 1 || b > 5,按上述用例也无法发现这个问题

 

 

条件覆盖

要求设计足够多的测试用例,为函数中每个判断中的每个条件表达式的设计了所有可能结果值。

例子

 


 

对应代码:

   public intfunc5(inta, intb) {

       if(a <1&& b >5) {

           returna - b;

       }else{

           returna + b;

       }

   }

 

 

 

用例设计

a = 0(条件表达式a<1true),b = 4(条件表达式b>5false)

a = 2(条件表达式a<1false), b = 6(条件表达式b>5true)

 

缺点分析

1同判定覆盖,条件覆盖只考虑了判断里的条件表达式,未考虑每个判断的结果分支组合,会导致漏测

2、条件覆盖更关注判断中每个条件的取值覆盖,未考虑判断中所有条件的取值结果组合(整个判断的结果会受到条件表达式之间的 && ||等逻辑关系影响),这容易导致漏测,如上,虽然每个条件表达式都设计了可能值,但是return a - b 仍未执行到。

3、未考虑判断中所有条件的取值结果组合,这容易导致业务逻辑漏测

 

 

 

判定/条件覆盖  

要求设计足够多的测试用例,使得函数中的每个判断的每条分支都必须至少执行一次,且用例为每个判断中的每个条件表达式的设计了所有可能结果值。

例子

   public intfunc5(inta, intb) {

       if(a <1&& b >5) {

           returna - b;

       }else{

           returna + b;

       }

   }

 

 

 

a = 0(条件表达式a<1true),b=6 (条件表达式b>5true)   判断结果为true

a = 1(条件表达式a<1false, b=5(条件表达式b>5false)判断结果为false

 

缺点分析

1、同条件覆盖,只考虑了判断里的条件表达式,未考虑每个判断的结果分支组合,会导致漏测

2、同条件覆盖,关注判断中每个条件的取值覆盖,未考虑判断中所有条件的取值结果组合(整个判断的结果会受到条件表达式之间的 && ||等逻辑关系影响),这容易导致业务逻辑上的漏测,比如上述条件        a < 1 && b > 5本应该是  a < 1|| b > 5,按上述测试数据,也无法发现这个错误。

 

 

条件组合覆盖

要求设计足够多的测试用例,为每个判断中的所有条件表达式的可能结果组合结果设计了所有可能值。

 

例子

 

 

对应代码:

   public intfunc5(inta, intb) {

       if(a <1&& b >5) {

           returna - b;

       }else{

           returna + b;

       }

   }

 

 

 

用例设计

a = 0(条件表达式a<1true),b=6 (条件表达式b>5true)

a = 0(条件表达式a<1true, b=5(条件表达式b>5false)

a = 1(条件表达式a<1false, b=5(条件表达式b>5false)

a = 1(条件表达式a<1false, b=6(条件表达式b>5true)

 

缺点分析

同条件覆盖,只考虑了单个判断,未考虑函数中所有判断的结果分支组合,会导致漏测

 

 

 

路径覆盖

顾名思意,覆盖函数中的每一条路径,也可以简单理解为所有判断条件的分支组合

 

 

例子

 

 

 

对应代码:

 

// 前一个判定的一个、多个分支路径中变量取值结果影响后续判定中的变量取值

   // (前提:前一个判定分支路径的执行不会结束函数的执行,判定与判定直接处于同一层级,即同胞关系,非嵌套包含,形如以下则为嵌套包含关系

// if (express1) { if (express2) {}}下同

   public intfunc6(intx, inty){

       intz =0;

       inta =0;

       if(x <2) {

           z = z +1;

       }

 

       if(y >3) {

           a = z +2;

       }

       returna;

   }

 

   // 前一个判定的一个、多个分支路径中变量取值结果影响后续判定中的判定取值

   public intfunc7(intx, inty){

       intz =0;

       inta =0;

       if(x <2) {

           z = z +1;

       }

 

       if(y >3) {

           if(z !=0) {

               a =10;

           }

       }

       returna;

   }

 

   // 不同判定的一个、多个分支路径中变量取值结果影响后续非判定分支路径中的语句的结果取值

   public intfunc8(intx, inty){

       inta;

       if(x <2) {

           x = x +1;

       }

 

       if(y >3) {

           y = y +3;

       }

 

       a = x + y;

       returna;

   }

}

 

 

用例设计

(以第一个函数为例子)

x = 1 (x<2 true), y=4 (y>3true)

x = 1 (x<2 true), y=3 (y>3false)

x = 2 (x<2 false), y=4 (y>3true)

x = 2 (x<2 false), y=3 (y>3false)

 

 

缺点分析

1、路径复杂的情况下,用例数可能太多,无法实现

2、同判定覆盖,只考虑了判断的最终结果,未考虑判断中每个条件的取值情况,这容易导致业务逻辑上的漏测

 

最终总结

1、无特殊情况下,使用条件组合覆盖(不对判断的路径做组合覆盖,只提供必要路径,即走完前一个判断,能走到下一个判断; 当然,这里的所说的条件组合覆盖是默认包含了语句覆盖),测试时结合实际业务逻辑检查相关判断表达式是否正确

2、当函数中存在多个判断条件,存在以下几种情况之一的,条件覆盖的基础上,可以根据实际情况补充路径覆盖(暂时只想到这些)

Ø 前一个判的一个、多个分支路径中变量取值结果影响后续判定中的变量取值

Ø 前一个判的一个、多个分支路径中变量取值结果影响后续判定中的判定取值

Ø 不同段的一个、多个分支路径中变量取值结果影响后续非判定分支路径中的语句的结果取值

 

路径深度:同一层级相关判断的分支

纳入路径覆盖范围的判断:正如上述说的影响“取值”的那些判断

 

 

3、在上述基础上,适当结合等价类划分,边界值等用例设计方法,适当补充、修改用例,特别注意入口参数,结合业务考虑是否存在“隐式”的条件

目录
相关文章
|
4月前
|
Java 测试技术 开发者
在软件开发中,测试至关重要,尤以单元测试和集成测试为然
在软件开发中,测试至关重要,尤以单元测试和集成测试为然。单元测试聚焦于Java中的类或方法等最小单元,确保其独立功能正确无误,及早发现问题。集成测试则着眼于模块间的交互,验证整体协作效能。为实现高效测试,需编写可测性强的代码,并选用JUnit等合适框架。同时,合理规划测试场景与利用Spring等工具也必不可少。遵循最佳实践,可提升测试质量,保障Java应用稳健前行。
55 1
|
1月前
|
测试技术 开发者 UED
探索软件测试的深度:从单元测试到自动化测试
【10月更文挑战第30天】在软件开发的世界中,测试是确保产品质量和用户满意度的关键步骤。本文将深入探讨软件测试的不同层次,从基本的单元测试到复杂的自动化测试,揭示它们如何共同构建一个坚实的质量保证体系。我们将通过实际代码示例,展示如何在开发过程中实施有效的测试策略,以确保软件的稳定性和可靠性。无论你是新手还是经验丰富的开发者,这篇文章都将为你提供宝贵的见解和实用技巧。
|
3月前
|
测试技术
软件测试用例设计之微信群抢红包经典用例
作者在浏览招聘网站时遇到为微信群发和抢红包设计测试用例的问题,作为软件测试新手,作者通过实际体验并撰写测试案例来加深对业务的理解,并分享了测试案例表格。需要注意的是,该用例未考虑添加银行卡支付、红包类型选择及红包描述。
100 5
软件测试用例设计之微信群抢红包经典用例
|
3月前
|
人工智能 测试技术 Python
基于 LangChain 的自动化测试用例的生成与执行
本章节详细介绍了如何利用人工智能技术自动化完成Web、App及接口测试用例的生成与执行过程,避免了手动粘贴和调整测试用例的繁琐操作。通过封装工具包与Agent,不仅提升了测试效率,还实现了从生成到执行的一体化流程。应用价值在于显著节省时间并提高测试自动化水平。
|
3月前
|
测试技术
基于LangChain手工测试用例转App自动化测试生成工具
在传统App自动化测试中,测试工程师需手动将功能测试用例转化为自动化用例。市面上多数产品通过录制操作生成测试用例,但可维护性差。本文探讨了利用大模型直接生成自动化测试用例的可能性,介绍了如何使用LangChain将功能测试用例转换为App自动化测试用例,大幅节省人力与资源。通过封装App底层工具并与大模型结合,记录执行步骤并生成自动化测试代码,最终实现高效自动化的测试流程。
|
3月前
|
IDE 测试技术 持续交付
Python自动化测试与单元测试框架:提升代码质量与效率
【9月更文挑战第3天】随着软件行业的迅速发展,代码质量和开发效率变得至关重要。本文探讨了Python在自动化及单元测试中的应用,介绍了Selenium、Appium、pytest等自动化测试框架,以及Python标准库中的unittest单元测试框架。通过详细阐述各框架的特点与使用方法,本文旨在帮助开发者掌握编写高效测试用例的技巧,提升代码质量与开发效率。同时,文章还提出了制定测试计划、持续集成与测试等实践建议,助力项目成功。
92 5
|
4月前
|
测试技术
基于LangChain手工测试用例转Web自动化测试生成工具
该方案探索了利用大模型自动生成Web自动化测试用例的方法,替代传统的手动编写或录制方式。通过清晰定义功能测试步骤,结合LangChain的Agent和工具包,实现了从功能测试到自动化测试的转换,极大提升了效率。不仅减少了人工干预,还提高了测试用例的可维护性和实用性。
|
4月前
|
JSON 测试技术 数据格式
单元测试问题之使用JCode5插件生成测试类如何解决
单元测试问题之使用JCode5插件生成测试类如何解决
183 3
|
4月前
|
测试技术
单元测试问题之使用TestMe时利用JUnit 5的参数化测试特性如何解决
单元测试问题之使用TestMe时利用JUnit 5的参数化测试特性如何解决
62 2
|
4月前
|
人工智能 自然语言处理 测试技术
基于LangChain手工测试用例转接口自动化测试生成工具
本文介绍利用大语言模型自动生成接口自动化测试用例的方法。首先展示传统通过HAR文件生成测试用例的方式及其局限性,随后提出结合自然语言描述的测试需求与HAR文件来生成更全面的测试脚本。通过LangChain框架,设计特定的提示词模板,使模型能够解析测试需求文档和HAR文件中的接口信息,并据此生成Python pytest测试脚本。示例展示了正常请求、非法请求及无效路径三种测试场景的自动化脚本生成过程。最终,整合流程形成完整代码实现,帮助读者理解如何利用大模型提高测试效率和质量。