芯片bring-up的测试用例

文章目录


前言

最近做了一些用测试用例点亮芯片的工作,从测试用例的规划和编写,记录几点开发测试用例的心得体会。


一、测试用例的规划和编写原则

在测试用例前期的规划时,应当遵循由简单到复杂这个原则。

这里从简单到复杂,将测试用例分为如下几类:

  1. 冒烟测试
  2. 遍历测试
  3. 随机测试
  4. 性能测试
  5. 压力测试

1、冒烟测试

冒烟测试是目的是初步评估整个芯片的功能是否完好,其要遵循的原则是小而美。

在编写冒烟测试过程中,在覆盖测试的功能的前提下,应当越简单越好,尽量减少模块之间的依赖,减少因为别的模块有问题,而阻塞当前功能的测试。

芯片回来后,需要在最短的时间内完成冒烟测试,因为冒烟测试可以很大程度提升团队的信心,所以对于冒烟测试,我们往往需要做一些预备方案,要假设冒烟测试可能存在哪些问题,如果出现了这些问题,我应该准备哪些预备方案去应对,这样可以提前准备一些应对措施,快速完成冒烟测试。

冒烟测试可以简单分为:(1)电源时钟复位测试;(2)寄存器扫描测试;(3)单一功能冒烟测试。下面我们挨个介绍。

1)电源时钟复位测试

拿到芯片首先要进行电源,时钟以及复位测试,利用示波器或者相关的寄存器,来确认电源供电是否正常,时钟频率是否正确,复位是否释放。

所以,这个过程我们需要提前准备的是,分析清楚芯片的供电、时钟以及复位方案。

关于供电,(1)检查输入电压和静态电流。电源从哪个pad管脚输入,电压应该是多少,静态电流应该是多少,通过静态电流可以初步判断芯片是否有短路的情况。(2)检查内部各个模块的供电情况。梳理清楚哪些模块是电源线直连的,哪些要经过LDO/DCDC做电压切换,切换的寄存器是多少,切换后的电压如何查询。

关于时钟,梳理时钟树,顺着树根到枝叶依次检查。首先,检查树根,时钟是从哪个pad管脚输入,频率应该是多少;其次,检查中间节点,内部有没有pll,是否有分频,是否有时钟门控;最后,检查枝叶上的时钟是否正常。

关于复位,确认是高有效还是低有效复位,梳理复位树。和时钟一样,先检查树根,确认复位是否被释放;其次,检查中间节点,是否有门控;最后,检查枝叶上的复位是否正常。

2)寄存器扫描测试

搞定电源时钟复位后,就可以进行寄存器扫描测试了。

寄存器扫描测试,要将正常和异常寄存器的扫描分开,先测试正常的,再测试异常的。正常寄存器扫描主要是指可读写的寄存器,异常寄存器扫描测试主要包括:reserved,read only,write1clear等。

在编写寄存器扫描测试时,要遵循小而美的原则,不要将所有的寄存器扫描都写到一个task/function中,一个模块在一种场景下,要单独封装到一个task/function,通过层层嵌套和封装的方式,最终实现整个寄存器扫描,中间加上相关的打印信息,这样做的目的是,一方面可以快速定位到是哪个模块的哪个寄存器挂了,另一方面通过屏蔽部分代码,可以快速扫其他寄存器,而不被当前的问题阻塞,扫完后,只需要调用有问题地方的task/function即可复现问题,从而节省时间。

3)单一功能冒烟测试

搞定寄存器扫描后,就可以进行单一功能冒烟测试了。

这里为什么称之为单一功能冒烟测试,原因是这里的功能测试也是,在保证功能覆盖的前提下,越简单越好。例如,芯片里边有个资源例化了128份,在这里只需要测试其中1份就ok了,然后,可以给这128份资源进行分组测试,例如每16个一组,挑选其中8个作为一个测试用例进行测试。

二、遍历测试

冒烟测试完成后,需要对所有的资源进行遍历测试,确保所有的资源都可以正常使用。例如,硬件例化了128个加法器,那么这里需要对这128个加法器的功能进行挨个遍历测试。

在一些重要的配置中,当其中一些配置,与另外一些配置,需要交叉的场景,也要进行遍历。例如,其中一组配置是a、b、c、d,另外一组配置是1、2、3、4,那么需要对其进行排列组合进行遍历,把所有的场景都覆盖到。

三、随机测试

当配置非常多的时候,排列组合的场景非常多,再去进行遍历,会导致测试用例非常多,这个时候,就需要考虑用一些随机的配置去重复跑,尽可能多的去构造出不同的排列组合的场景,必要的时候,可以写一些覆盖率模型,去收集覆盖到的场景,从而指导随机的方向,做到哪些配置覆盖了,哪些没有覆盖,心里有数。

四、性能测试

性能测试需要提前规划好场景,再根据这些规划好的场景去设计测试用例,测试用例最好能做成自动化。

性能测试用例的场景会比较多,在设计测试用例的时候,最好能做成自动化,即敲一个命令,完成所有的测试,这是因为,在进行性能测试的时候,通常需要对参数进行调优,在调优的过程中,同一个性能测试用例可能需要跑很多遍进行对比。

在性能测试用例非常多的情况下,如果每个测试用例还需要进行参数调优,那么这个工作量会非常巨大,再加上测试过程中,每个测试用例的启动都需要时间,每个测试步骤都基本相同,那么性能测试就变成枯燥无味且耗时的体力活,测试过程中,加入越多的人为因素,也非常容易出错。

五、压力测试

在前面的测试都做完后,可以确认芯片的基本功能没什么问题,但这往往是不够,还需要测试芯片的鲁棒性,即面对大压力,高负载的时候,能不能保持稳定,这个时候就需要进行压力测试。

压力测试往往是需要挂在那里一直跑的测试用例,所以要考虑其自动化,确保能循环一直跑。

压力测试首先要明确,这个压力是指什么,通常在真实芯片中,是模拟实际的应用场景,将流量打满,让其一直工作在满负载的情况下。


总结

本文主要总结在点亮芯片的过程中,我们需要做哪些测试用例,以及编写这些测试用例的时候,有哪些注意事项。

相关推荐
测试老哥1 天前
需求不明确时如何设计测试用例?
自动化测试·软件测试·python·功能测试·测试工具·职场和发展·测试用例
程序员雷叔1 天前
外包功能测试就干了4周,技术退步太明显了。。。。。
功能测试·测试工具·面试·职场和发展·单元测试·测试用例·postman
程序员小雷1 天前
应对自动化测试中的异步操作:策略与实践
功能测试·selenium·测试工具·jmeter·单元测试·测试用例·postman
Dreams°1232 天前
【新手入门软件测试--该如何分辨前后端问题及如何定位日志--前后端问题分辨与日志定位查询问题】
功能测试·测试工具·测试用例
互联网杂货铺3 天前
软件测试八股文个人总结
自动化测试·软件测试·功能测试·测试工具·面试·职场和发展·测试用例
blues_C5 天前
Pytest-Bdd-Playwright 系列教程(5):仅执行测试用例的收集阶段
自动化测试·测试用例·pytest·bdd
程序员雷叔5 天前
自动化测试类型与持续集成频率的关系
功能测试·测试工具·jmeter·ci/cd·单元测试·测试用例·postman
MJH8275 天前
技术分享 —— JMeter接口与性能测试实战!
自动化测试·网络协议·测试工具·jmeter·测试用例·压力测试·postman
测试杂货铺6 天前
Selenium4自动化测试常用函数总结,各种场景操作实战
自动化测试·软件测试·windows·python·测试工具·单元测试·测试用例