![](https://img-blog.csdnimg.cn/20190918140145169.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
测试
关于工作中,相关测试,性能测试,极限测试的问题总结。
mzhan017
小张
展开
-
[程序员] [项目管理]完备回归测试集的重要性
最近产品出现好多问题,需要分析,总结发现这个回归测试的测试集很不完备;由于产品的持久性实在是太久,到目前为止已经有二十多年的历史,在整个开发的过程中,已经欠下了很大的回归测试债务,或者是当时的测试环境受限;如果这样推理过来,其实和现实的社会的演变也是一模一样,如果测试完备,哪里可能出现问题,这样就不会显示出来什么乱世,也就无所谓英雄,三侠五义;所以和平年代的稳定,其实是要归功于回归测试/测试的完备,也就是质量的反复确认人员;少了回归测试,问题就不免暴露在外,而且出现的概率也是随着开发量的增大而增大!原创 2024-03-03 10:50:29 · 431 阅读 · 0 评论 -
Python: network:sip: pyVoIP;sip测试工具
本机的系统是Windows,从网上找到的相关测试工具大多是c/c++实现,需要安装特定的编译软件,所以准备这个编译环境就需要很多的准备工作要做。今天向大家推荐一个开源项目,这个是python实现的一个VoIP的终端模拟器。看着就是一个非常好的通信测试软件。python实现,可以批量化(部分模拟sipp功能)实现通信压力测试,满足一定的需求。需要注意的是可能需要自己在这个代码基础上做一些定制化的代码改动。这也算是python的一个非常明显的优势,可以在面试时遇到相关问题,举得一个例子。怎么找到的这个软件呢?原创 2024-01-14 07:04:40 · 932 阅读 · 0 评论 -
测试之新员工光临的规律
这就和标题对应上了,因为如果是一名新手刚入门产品测试,和研发的交际就少,没有形成类似开发的定式思维,所以会东一锤头,西一榔头的拿着产品做实验,多多少少的就涵盖了,由于之前开发和老测试人员定式思维所不能覆盖的区域。在之前的工作经历中,不止一次发现这个规律:新手测试人员,刚上手的时候,总是能找到成熟产品(经过好几轮测试)的几个问题,货真价实的问题。怎么想起来这个规律了呢?从这里也可以看出来,测试人员的测试在征求其他人的建议,这里要说明,征求建议可以,但是不能完全的依赖这个建议,尤其是和研发比较近的人的建议。原创 2023-12-22 06:58:44 · 414 阅读 · 0 评论 -
[测试] fuzztest
可以用来做模糊测试的工具,和google test的框架差不了太多。原创 2023-12-06 15:32:54 · 430 阅读 · 0 评论 -
测试:gmock-global的使用规则
这个头文件是将全局函数的mock,是在gmock的上层,又做了一层全局函数的简化,方便使用。最近遇到了一个问题,和这个的使用相关,先总结如下;这个头文件实现的宏定义:MOCK_GLOBAL_FUNC*_;主要的是一个类定义,和两个全局符号:一个全局instance对象,一个全局的mock函数;在这个mock函数里调用instance的方法来实现mock机制的内部逻辑判断。}\如果多个cpp,同时使用这个宏MOCK_GLOBAL_FUNC*_,可能导致符号重复定义的错误。原创 2023-10-31 15:47:11 · 222 阅读 · 0 评论 -
[测试] 回归测试;regression;顾名思义
rɪ`ˇrɛs/ v [I, Ipr] ~ (to sth) (fml 文) return to an earlier or less advanced form or state 退步;其实“回归”这个词,有时候感觉达不到“顾名思义”的地步,有名的关联词语是“回归故里”,回到老地方;就是新开发的功能,不能破坏原有功能的逻辑。这个有点像类里的继承,父类的功能子类不要破坏。n. 退回, 复归权, 回归, 倒退, 退步, 退化, 退行。vi. 退回, 复归, 回归, 倒退, 退步, 退化, 退行。原创 2023-10-20 07:49:55 · 132 阅读 · 0 评论 -
安全:协议模糊测试
文章目录说明工具需要的能力说明属于通信/网络协议健壮性测试范畴。目标是测试对象对于异常数据包的处理能力是否够健壮。工具新思科技:Defensics Fuzz Testinghttps://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/ds-defensics-fuzztesting.pdfhttps://www.synopsys.com/software-integrity/security-testing/fuzz-te原创 2021-06-18 05:20:49 · 944 阅读 · 0 评论 -
[程序员][测试] 工作总结的重要性
从我的理解,关于总结的工作,有时候也不能完全依赖于员工自觉的去做,而是要给其一定的时间来做,要以摊派的形式给特定员工来做总结性的工作。最近听一个测试同事分享关于VMware的知识,最后被问到:你们测试中遇到的单纯的VMware的问题多不多,这名同事虽然回答了,但是感觉好像也没有回答,或者说没有回答到点上。其实提问的人想得到的是一个关于VMware问题的总结性的数据。因为自由的环境里,作为一个完整的团体,而且都是高智慧生命体,不是说体重二百斤的话语权会更重,话语权更重的是拿数据与事实做为依据。原创 2023-08-10 07:17:58 · 91 阅读 · 0 评论 -
[测试]性能测试之前的工作
举一个例子:最近遇到一个性能问题,在打起来业务后,发现socket上的发送queue满了,但是不能确定是那一块有问题,是业务数据实际发生了过载,还是网络除了问题呢?所以怀疑是设备的网络问题导致的TCP业务数据有问题。当然比较难debug,需要将两端的网络包都抓取出来,然后对比看网络的哪一个设备有问题。其实在性能测试之前,要准备很多东西其中与一个概念是关于冒烟测试。就是要确保所搭建的测试环境可以完成基本的业务功能。如果手上有上面基础性能测试的性能数据,也许可以帮助我们定位问题的所在之处。原创 2023-07-14 20:36:21 · 415 阅读 · 0 评论 -
[测试]必备技能-性能统计数据分析
在开出来任何一个关于压力测试的问题的分析过程中,都避免不了使用分析工具,而且分析的第一步就是要用分析工具,分析:通过数据来分析压力模型是否是预期的。根据统计报表来判断中间有没有错误出现,有没有异常发生。作为系统测试人员,不管是使用Excel或者是python脚本,或者其他任何可以用来分析的工具,至少需要掌握一门。而且如果用的好,还可以提高自己的知名度。这也算是磨刀不误砍柴功的一个例子。假如产品还没有这样的工具,那就开始准备开发一个吧。如果数据量小,建议用Excel,至少可以画个图,将压力测试结果可视化。原创 2023-06-30 21:59:29 · 125 阅读 · 0 评论 -
测试环境:更新(淘汰)意识;一劳永逸
如果非得在RHEL6上安装openssl-1.1,可能找不到相应的rpm包。因为RHEL6已经没有人在维护,必须自己下载源代码,重新编译,而且在老系统里编译新版本的openssl,可能会遇到各种各样的未知的新问题。随着科技的进步,测试使用的有些老设备,系统该淘汰就要淘汰,系统该升级就升级;如果不是为了节约成本,建议使用新的设备,新设备总可以提高生产效率。不如升级系统,然后找到对应的rpm包,来的方便快捷,一劳永逸。如果不是必须使用老系统,来测试,千万不能图省事,使用老系统。原创 2023-06-29 06:56:23 · 56 阅读 · 0 评论 -
[程序员]经典挖坑场景-2
后来调查发现,这个问题的主要原因是在每条记录处理的时候,会在C程序里调用一个shell脚本,调用这个脚本的开销,依据CPU的处理能力来说耗时不等,有的需要20ms,有的需要40ms;不巧的是,这个线程还被用于“表活”的功能,就是每两秒要向其他监控进程发送心跳包(heartbeat),如果记录数太多,而且处理的慢,就会间接导致其他监控进程认为当前进程死掉了,进行未“表活”的一系列的容灾处理。如果想知道精确的时间,说何时会掉进去,就需要对这个坑进行研究,做大量的测试工作。如果有的话,就要平衡两者之间的关系。原创 2023-06-28 05:49:14 · 134 阅读 · 0 评论 -
gmock:googlemock: g_gmock_implicit_sequence;通过名称无法判断其类型
这个类型的全局变量,会在get方法里申请heap的内存,以便自己使用,然后将这个内存地址放到thread local的变量。而且是一个全局变量,如果想在运行测试用例的时候加快运行,可以事调用get,提前申请内存。需要注意这个使用规则。这个名称有些让人联系不上它的类型,所以下面的调用栈,初看的时候有些困扰。看gmock/gtest的时候需要注意。google这个网站也是不能访问。原创 2023-06-15 04:03:05 · 86 阅读 · 0 评论 -
[测试]边界测试、极限测试
说之前socke上往外发送GARP是没有问题的,但是将IP的个数增加到256个之后,后面的IP的GARP就发不出了。最后debug发现是errno-11:https://mzhan017.blog.csdn.net/article/details/128577580。原因就是在短时间内的socket缓冲区被用光了,导致后续的GARP出现错误。如果逻辑里判断一下EAGAIN;也可以解决这种情况。如果不是测到最后一个IP地址,这个问题其实不好处理。而且要将数据的量全部满配。这里就可以发现边界测试的重要性。原创 2023-06-10 09:00:42 · 193 阅读 · 0 评论 -
sipp: bind_local;watchdog timer trip
这个错误就是在建立tcp链接时,发现链接不能建立起来。需要使用tcpdump看看具体是什么原因。一半说来,如果有这个strip的日志,代表当前CPU的压力比较大,处理上慢于定时器。只有在使用UDP的时候,retrans这个属性才生效。因为UDP本身就是不可靠传输。后续应该可以绑定到-i指定的ip上去了。从3.5开始有的这个功能。原创 2022-11-28 21:21:21 · 378 阅读 · 0 评论 -
Ansible:软件诡异事件原因探究——猜猜猜
说明一下:这一步需要的时间大约半个小时,所以就想让ansible-wait_fore帮我们监听设备是否已经安装成功,如果安装成功,就走的下一步做自动测试。这里我们想说的一件事情是,如果我们有能力,而且有资料可以探查事件发生原由的时候,就不要猜了!不是说不能猜,而是说需要将我们猜的结果和实际的原因做对比,以验证我们猜的能力。这里根据注释说明,我们可以得到我们想要的一个结果是每个10秒做一次检查,最多检查30分钟,这样如果中间15分钟的时候设备启动起来了,接着就可以继续做测试了。当然开源软件的长处一定要用上!原创 2023-04-27 20:10:09 · 356 阅读 · 0 评论 -
[测试]性能测试
月底要出一个新版本。测试人员发现这个新版本在相同的负载的情况下,会有队列使用负荷过高的警告。最近遇到一个性能测试的问题,虽然最后确定是一个乌龙问题。这里还是总结一下,看是否有可以从中学到什么。所以总结下来,会发现,上面说的第四步应该先做,然后根据第四步的结果,再做第3, 1,2;最后确实发现前后两个版本的测试脚本有差别,后面脚本发送的消息数量有增加。正常的性能测试问题的步骤是;原创 2023-02-18 04:58:02 · 496 阅读 · 1 评论 -
[项目管理] 关于测试与测试设备的一些想法
当一名好的测试,在遇到问题时,第一时间的应对步骤是:开个bug/ticket,或者主动分析一下,而不应该重装系统/重启系统等操作来尝试恢复。有时候测试开出问题之后,可能以问题描述作为问题分析的起始点,这样就有可能导致遗漏系统警告信息,因为测试可能没有注意到警告,在问题描述力没有提及。从各方的设想,管理人员,开发,周围同事,还是需要一些debug问题的能力,即使不是那面强烈的能力,也需要基本分析能力(有助于增加自己的reputation)。既然是问题,如果可以正向解决是最好不过,即使是测试环境问题。原创 2023-02-04 08:51:59 · 491 阅读 · 0 评论 -
关于测试环境问题的理解
如果说硬件问题不好解决,那只是时间问题,时间到了硬件都要淘汰。这样导致的一个问题,恰如同事所说:“自动化这样的操作,使得自动话完美的避开了我们要测的环境测试”。如果遇到问题,只要是被说成环境问题,我们就有理由将其看成是一种推卸责任的借口。而现场的环境既复杂又掺杂难以预料的几率事件,我们想要模拟环境问题还来不及,怎么能忽略。环境怎么会有问题呢,环境没有问题,环境无时无刻不在变化,世间万物都在适应环境。如果软件不能适应环境,就说明软件有问题,或者容错性差。即使用例失败,也只是用例问题,不会出现环境问题。原创 2021-01-07 15:46:36 · 465 阅读 · 3 评论