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

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

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

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

目录
相关文章
|
1月前
|
人工智能 测试技术 调度
写用例写到怀疑人生?AI 智能测试平台帮你一键生成!
霍格沃兹测试开发学社推出AI智能测试用例生成功能,结合需求文档一键生成高质量测试用例,大幅提升效率,减少重复劳动。支持自定义提示词、多文档分析与批量管理,助力测试人员高效完成测试设计,释放更多时间投入核心分析工作。平台已开放内测,欢迎体验!
|
11天前
|
人工智能 自然语言处理 测试技术
让AI帮你跑用例-重复执行,不该成为测试工程师的主旋律
测试不该止步于重复执行。测吧科技推出用例自动执行智能体,通过AI理解自然语言用例,动态规划路径、自主操作工具、自动重试并生成报告,让测试工程师从“点点点”中解放,专注质量思考与创新,提升效率3倍以上,节约人力超50%,重构测试生产力。
|
4月前
|
测试技术 Python
Python测试报告生成:整合错误截图,重复用例执行策略,调整测试顺序及多断言机制。
如何组织这一切呢?你可以写一本名为“Python测试之道”的动作指南手册,或者创建一个包含测试策略、测试顺序、多断言机制的脚本库。只要你的测试剧本编写得足够独到,你的框架就会像一位执行任务的超级英雄,将任何潜伏于代码深处的错误无情地揪出来展现在光天化日之下。这些整理好的测试结果,不仅有利于团队协作,更像冒险故事中的精彩篇章,带给读者无尽的探索乐趣和深刻的思考。
123 10
|
Java 测试技术 开发者
在软件开发中,测试至关重要,尤以单元测试和集成测试为然
在软件开发中,测试至关重要,尤以单元测试和集成测试为然。单元测试聚焦于Java中的类或方法等最小单元,确保其独立功能正确无误,及早发现问题。集成测试则着眼于模块间的交互,验证整体协作效能。为实现高效测试,需编写可测性强的代码,并选用JUnit等合适框架。同时,合理规划测试场景与利用Spring等工具也必不可少。遵循最佳实践,可提升测试质量,保障Java应用稳健前行。
125 1
|
9月前
|
前端开发 JavaScript 测试技术
使用ChatGPT生成登录产品代码的测试用例和测试脚本
使用ChatGPT生成登录产品代码的测试用例和测试脚本
240 35
|
11月前
|
测试技术 开发者 UED
探索软件测试的深度:从单元测试到自动化测试
【10月更文挑战第30天】在软件开发的世界中,测试是确保产品质量和用户满意度的关键步骤。本文将深入探讨软件测试的不同层次,从基本的单元测试到复杂的自动化测试,揭示它们如何共同构建一个坚实的质量保证体系。我们将通过实际代码示例,展示如何在开发过程中实施有效的测试策略,以确保软件的稳定性和可靠性。无论你是新手还是经验丰富的开发者,这篇文章都将为你提供宝贵的见解和实用技巧。
|
测试技术
软件测试用例设计之微信群抢红包经典用例
作者在浏览招聘网站时遇到为微信群发和抢红包设计测试用例的问题,作为软件测试新手,作者通过实际体验并撰写测试案例来加深对业务的理解,并分享了测试案例表格。需要注意的是,该用例未考虑添加银行卡支付、红包类型选择及红包描述。
348 5
软件测试用例设计之微信群抢红包经典用例
|
测试技术 数据安全/隐私保护
北邮人论坛登录页面测试用例
北邮人论坛登录页面测试用例
214 1
|
人工智能 测试技术 Python
基于 LangChain 的自动化测试用例的生成与执行
本章节详细介绍了如何利用人工智能技术自动化完成Web、App及接口测试用例的生成与执行过程,避免了手动粘贴和调整测试用例的繁琐操作。通过封装工具包与Agent,不仅提升了测试效率,还实现了从生成到执行的一体化流程。应用价值在于显著节省时间并提高测试自动化水平。
基于LangChain手工测试用例转App自动化测试生成工具
在传统App自动化测试中,测试工程师需手动将功能测试用例转化为自动化用例。市面上多数产品通过录制操作生成测试用例,但可维护性差。本文探讨了利用大模型直接生成自动化测试用例的可能性,介绍了如何使用LangChain将功能测试用例转换为App自动化测试用例,大幅节省人力与资源。通过封装App底层工具并与大模型结合,记录执行步骤并生成自动化测试代码,最终实现高效自动化的测试流程。

热门文章

最新文章