软件测试方案设计

软件测试方案设计文章目录1、软件框架2、测试方案设计2.1、测试覆盖2.2、功能测试和压力测试2.3、自动化测试2.4、持续集成1、软件框架站在软件的角度,一个系统通常可以分为以下四个层次:应用软件层(applayer)。用户重点自己开发的应用代码,例如我们的运动控制器要跑运动控制app,我们的示教器要跑qt用户交互app;中间软件层(middlelayer)。在用户app和os系统之间的软件,一般是一些通用的库文件,比如qt库、算法库;操作系统层(oslayer)。给用户层提供标准os服务的软件,一般

1、软件框架

在这里插入图片描述

站在软件的角度,一个系统通常可以分为以下四个层次:

  • 应用软件层(app layer)。用户重点自己开发的应用代码,例如我们的运动控制器要跑运动控制app,我们的示教器要跑qt用户交互app;
  • 中间软件层(middle layer)。在用户app和os系统之间的软件,一般是一些通用的库文件,比如qt库、算法库;
  • 操作系统层(os layer)。给用户层提供标准os服务的软件,一般包括kernel和驱动部分;
  • 硬件层(hardware layer)。最低层的基本硬件;

2、测试方案设计

我们的最终目标是交付给用户高质量可靠地产品,我们希望我们的系统每个角落都是经过严格测试的,我们要在实验室里模拟到用户可能会碰到的各种问题,才能经得起大规模商用后大量用户场景的考验。

所以我们在设计测试方案时,要考虑到尽可能多的对软件路径进行测试覆盖。

软件测试和硬件测试对比,有以下难点:

  • 测试对象比较虚幻。对硬件来说有可见的实体;对软件来说如果不了解细节你觉得它只是一个整体,但是当你了解细节以后,就会发现其中有越来越多的软件模块,每个模块都有自己的逻辑,都可能出错都需要被测试;
  • 测试对象非常多。软件的逻辑模块非常多,通常高出硬件模块几个数量级;
  • 测试对象逻辑复杂。对单个模块来说,软件模块可能出现的逻辑状态也是远高于硬件模块的;
  • 逻辑组合非常复杂。最终产品是要把多个模块组合成一个整体的,多个模块组合在一起就是(N x M x …)的复杂度;

考虑到以上难点后,我们尝试使用以下手段来增加测试的覆盖度。

2.1、测试覆盖

上述的四层模型,每一层都为上一层提供服务,下一层的能力肯定是大于上一层的需要,因为上一层的应用用不到下一层所有的功能。

比如:同一hardware既支持linux os又支持vxworks os,同一linux os既支持运动控制又支持qt应用。

所以从严格意义上讲,四层的能力模型是一个金字塔型的:
在这里插入图片描述

在这种模型下,从任一上层层次来设计测试用例,它都会贯穿测试到下面的层次,但是下面层次都是有覆盖不到的情况:
在这里插入图片描述
既然是这种情况,那么是不是可以这样认为:如果已经从底层进行了完全的测试,那么是不是不需要经过上层的测试就能说明底层已经非常稳定?

答案是否定的。底层自我测试的面可能更广,但是自我测试模拟不了上层带来的场景。

比如我们针对os层已经做了针对os层的所有测试,这个时候我们还不能说os层完全没问题了。因为设计的测试用例只是尽可能覆盖,但是永远不可能完全模拟到所有真实的使用场景。我们还要经过中间层、应用层的测试完成后,我们才能说os在这种应用的场景中大部分是没问题的。

所以,一个完备的测试方案,需要在每一层次上设计测试用例,才能形成一个完整的测试覆盖:
在这里插入图片描述

2.2、功能测试和压力测试

上一节描述为了完备的测试覆盖,我们需要在每一层次上设计测试用例。

那么针对某一层次的测试用例,应该怎么样来设计呢?

从功能上可以简洁的分为两大类:功能测试和压力测试。

1、功能测试:

  • 站在使用者的角度,测试提供的所有接口功能是否ok;
  • 还可以进一步对这一层次代码进行单元测试、集成测试,来充分验证代码逻辑;

2、压力测试:

  • 对提供的基本功能,进行一个时间、空间上的压力验证。例如:正常请求1s 1次,压力请求1s 1000次;正常流量10M,压力流量 100M。只有在测试环境中经过更加严苛的测试,才能经受住实际复杂环境的考验。
  • 对于提供压力的形式也不是一味重载,还需要构造负载剧烈变化的场景。例如:重载、轻载、重载。。。。(随机变化)
  • 如果每一层次都有了自己的测试用例,我们还可以把这些用例组合起来,生成新的压力场景。例如:os层进行压力测试的同时,app层进行功能测试,验证在压力场景下app的功能还是否正常。
  • 使用自动化的方式,大量重复的去跑常规功能测试用例,这本身就是一个很好的压力测试场景。

对四层模型来说,每一层的功能测试和压力测试有以下特点:

Layer Function Test Pressure Test App Layer 1、从用户的角度测试所有提供的功能;

2、单元测试+集成测试,验证代码逻辑; 1、重载压力测试;

2、轻重载随机变化测试; Middle Layer 一般中间层可能没有源码以库的形式提供,而且用户对它的整个架构理解的也不充分。

1、如果条件允许,可以让中间层厂商提供对应的报告;

2、如果资源有限,很多时候也没有对中间层设计专门的测试用例; 依赖对应厂商 OS Layer 1、对OS kernel公共部分的功能测试,比如:cpu、内存。。。;

2、对OS driver部分的功能测试,比如:网口、USB、存储、显示、input。。。;

3、单元测试+集成测试,验证代码逻辑; 1、重载压力测试;

2、轻重载随机变化测试; Hardware Layer 对硬件功能的完备性测试,一般是在产线上进行的:

1、在硬件大规模量产时,会允许软件还有些bug,但是不允许硬件出现任何的功能性问题,因为硬件基本是不能修改的;

2、量产时需要提供硬件功能测试软件给产线,来筛选出硬件不良品; 在硬件出厂前,在产线上还需要对硬件进行老化,让每个元器件度过初始震荡期,进入平稳运行期:

1、提供老化测试软件,对硬件器件施加压力,让她们能迅速老化;

2、软件能筛选出老化失败的不良品;

另外从bug发生的故障率来说,用户自己修改的代码出现问题的概率最大。对应在四层模型中,app代码os驱动代码出错的概率最大。

因为中间层代码、os kernel部分、hardware部分,使用的人一般很多,经过了多个用户的使用和测试后已经暴露出了较多的问题。而app代码和驱动代码基本都是用户自己开发/移植的,出错的概率更大一些。所以这两部分代码需要重点测试,给它们设计更多的测试用例。

2.3、自动化测试

从测试用例的数量和软件功能的数量来说,测试用例要大于软件功能的几倍,才能保证软件的质量。

同时这也带来一个问题,庞大的测试用例,如果用人工来执行,测试周期会非常久。这对bug的发现、bug的修复、版本的快速发布都是不可容忍的。

在今天这个产品开发周期越来越快的时代,越来越多的用到了自动化测试。如果是纯软件的项目,测试用例的自动化覆盖率应该达到100%;如果是嵌入式项目,测试用例的自动化覆盖率也应该达到80%以上。

1、自动化测试模型如下:
在这里插入图片描述

  • 自动化测试pc通过控制通道和被测设备进行连接,可以控制被测设备的行为,一些内部测试用例可以直接这样就能测试。控制通道可能是串口、usb、网口等等;
  • 自动化测试pc通过控制通道和测试仪器/设备进行连接,测试仪器/设备通过数据通道和被测设备进行连接,pc上的测试代码可以操控测试仪器被测设备进行测试。需要挑选支持代码控制的测试仪;
  • 跑在自动化测试pc上的自动化测试代码,一般使用python或者java来开发;

2、web管理 + 自动化测试:

在这里插入图片描述
在自动化测试的进阶阶段,有多套测试方案+多个测试开发人员+多个测试执行人员+多个开发人员,这样复杂的场景下需要一个有效的管理。

一般使用web来实现这些管理功能:

  • 配置测试方案。测试哪个版本的软件,要测试哪些case,每个测试case的配置;
  • 记录测试事件、测试log、测试结果、自动分析、自动提交bug;
  • 从bug记录上可以找到具体的测试信息;
  • 统计和报表呈现;
  • 权限管理;

2.4、持续集成

测试用例自动化的一个重要目的,就是支持持续集成。

持续集成CI(Continuous integration)是来自于敏捷开发(Agile software development)的一个重要概念。在敏捷开发模式下,我们的产品是迭代式的开发,从最小功能做起,随时修改随时可用。产品随时保持可用的状态,可以随时发布。

在新的代码合入以后,需要测试在极短的测试时间中,验证代码合入的新功能,以及验证对原来的功能是否有影响。如果不使用自动化测试,人工测试是不可能完成的。
在这里插入图片描述

实现了持续集成以后,我们会得到这样的理想场景:

  • 每天开发人员提交完代码,下班以后;
  • 自动编译系统,拉取最新的代码进行编译;
  • 编译完成后自动烧录到被测系统,并启动自动测试;
  • 自动测试完成后,会把测试不过的情况和log邮件发送给前一天有对应代码提交的开发人员;
  • 开发人员上班以后,处理前一天提交的错误,并开发新功能提交代码;
  • 晚上,又是新一轮的自动验证;

今天的文章软件测试方案设计分享到此就结束了,感谢您的阅读,如果确实帮到您,您可以动动手指转发给其他人。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/24695.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注