精华内容
下载资源
问答
  • 如何解决测试资源问题
    万次阅读
    2018-05-22 11:24:27
    

    软件测试是一项存在风险的工作,它是不可避免的,总是存在的。作为一名测试管理人员必须在平时的工作中,分析这些风险的类别,并且找出对策尽最大程度的降低这些风险。
    一:软件需求的风险主要表现在以下的几个方面:
    1.软件需求本身不清晰或者开发商对产品的需求特性理解不准确有偏差,这样导致最终开发的产品功能可能不是用户真正想要的功能。
    2.需求变更风险,在项目的后期用户总是不停的提出需求变更,从而影响设计、代码,并且最终反映到测试中来。需求变更后,测试用例没有及时更新;更重要的是在项目的后期频繁的需求会导致测试的时间不充分。
    解决办法:
    1.在项目开发过程中的每一个阶段,尽量让有决策权的核心用户看到产品已经实现的每个阶段的功能,如果不是用户想要的东西尽早提出来,总之要让用户参与进来。
    2.另外对于后期用户不停的提出需求变更作为开发商来说,应该多和有决策权的核心用户多沟通,争取更充分的研发时间和测试时间,或者最好能把后期提出的功能放到下一个版本中实现。

    二:人员的风险
    人员的风险常常表现在以下等方面:
    1.核心测试人员的请假、离职
    2.测试人员的工作态度不端正、工作状态差
    3.测试人员的测试技术不足,比如说产生测试的思维定势,有些有问题的地方始终测试不到位
    解决办法:
    1.对于核心的测试人员可能离职而延误测试的情况,作为测试管理者可以在平时给这些核心人员配置一些可以候补的测试人员来向他们学习,以避免这些核心人的请假、离职的时候,可以立即补充上来。
    另外,对于一些关键的业务和技术一定要有文档。

    2.另外可以通过对测试工程师进行考评的方式监督他们每天的工作情况,看看其工作态度是不是尽心尽力符合目前的项目测试工作,如果发现不符合的话,测试管理者可以找其单独谈话督促其改正。
    3.每个测试工程师的思维方式肯定有差别,所以测试管理者多让这些工程师在测试每一轮后,在进行不同模块的交叉测试。

    三:代码质量的风险
    如果开发人员提交上来的代码质量很差、很烂的话,软件缺陷很多,那么对于测试工程师来说漏测的可能性就越大。
    解决办法:对于程序员的提交给测试部门的代码一定要在前期做好充足的单元测试、对于核心模块的代码一定要有资深的研发工程师进行前期检查

    四:测试环境的风险
    测试人员在测试过程中搭建的测试环境,虽然原则上是尽可能模拟用户实际使用的环境。但是不可能100%完全和用户的环境一样,这样就会存在一定的风险,因为有些软件的缺陷只有在特定的环境下(包括硬件、操作系统、杀毒软件和软件的不同版本的补丁和用户实际使用的数据等)才能出现。
    解决办法:测试部门在测试过程中搭建的测试环境的时候,尽量尽一切可能无限制的模拟用户使用的环境(硬件、操作系统的版本和补丁,数据库的版本和补丁)在测试的时候尽量和用户沟通要到用户真实的数据进行测试。以减少风险。

    五:测试工程师对产品的业务不熟悉
    对业务产品的不熟悉一般表现在以下几个方面:
    测试工程师不了解用户究竟是如何操作该产品和用户的操作习惯
    测试工程师介入到项目测试的时间太短

    解决办法:可以找一些相关行业的专家给测试人员进行培训,当然用户也就是最好的行业专家。另外测试人员一定要在项目的前期就介入到项目中去熟悉产品,对产品越熟悉找出的软件缺陷越有价值。

    六:测试深度和广度的风险
    1.测试的广度,用户的操作肯定是千变万化的,测试工程师在测试的时候肯定不能100%覆盖到这些千变万化的操作。有些极端的情况容易被遗漏、测试不到。
    2.测试的深度,比如有些软件只有在特定的情况下,比如多用户并发的情况下使用的过程中才会产生软件的缺陷bug,但是测试工程师在测试的时候忽略了这种情况,只有某几个测试工程师在测试使用这些功能。
    解决办法:测试工程师在写测试用例的时候尽量提高测试用例的覆盖率(在测试用例完成后组织进行测试用例的评审工作),如果测试用例能覆盖不同的用户千变万化的操作最好。特别是一些边界值、深层次的逻辑关系等。以及用户实际使用环境下的场景(比如大用户量的并发操作等)。

    七:测试工具本身可能产生误差
    1.测试工具能模拟用户的手工操作,但是这种工具本身就存在误差、或者使用者操作不当产生的误差,比如:在项目后期的回归测试的时候使用自动化功能测试工具QTP进行回归测试的时候,由于修改了某些脚步导致QTP每次测试都能通过,但是到用户现场的话有可能会最简单的功能都通不过。
    2.在进行性能测试工具的时候大家常常使用Webload、Jemeter、Loadrrunner等,但是这些工具并不能100%模拟用户的并发操作;比如用工具模拟500个用户同时并发登录系统,但是这些并发都是从1台或者某几台测试机器上发出请求的。但是在用户实际使用环境的情况下这500个用户可能来自全国或全世界的各个地方。

    解决办法:
    1.对于自动化的测试工具,一定要选择一些知名大企业比较成熟的测试工具,比如:HP公司的Loadrunner,QTP或者IBM的系列测试工具
    2. 测试工程师在使用测试工具的过程中应该大胆的排除一些不合理的测试值,比如:进行了5次的大用户的并发测试,其中有一次的测试结果与另外4次的测试结果偏差较大,那么测试工程师就可以排除这1次偏差较大的测试(因为这1次测试结果可能受到一些其他因素的影响而导致不准确,比如受到网络因素的影响等)。
    3.另外测试工具仅仅是提高测试效率的,由于测试工程师在使用测试工具的过程中某些参数设置不合理而导致测试结果不准确。所以不要过分的相信测试工具,最后一定要进行人工的审核和检查才可靠。
    4.另外可以用不同的测试工具运行相同的测试场景,如果不同的测试工具运行相同的测试场景的测试结果相近的话,可以认为这种测试是有效的。

    八:测试资源的不充分
    测试资源的不充足表现在很多方面,比如:
    1.硬件资源不够,国内的很多小型的软件企业开发和测试居然使用同一个环境,这样肯定会影响测试效果的。
    2.软件资源不充分,比如在项目的后期进行回归测试的工作量很大,但是测试的人手不够。
    3.测试的时间不充足,在企业实际的研发过程中,研发人员由于各种原因(如用户提出修改或者新增某些功能、甚至研发人员的技术水平等)导致提交到测试部门的延迟,这样无形中减少了测试人员的测试,测试时间不充足会影响到测试的效果的。

    解决办法:作为一名测试管理者有义务向公司里申请更多的测试资源,如购置独立的测试服务器把测试环境和研发环境分开;要求招聘更多的测试人员;测试管理者应当做好测试风险的预估,比如:在制定测试计划的时候要预留一定的多余时间以应对临时变化的一些特殊情况。


    原文:http://www.hezongedu.cn/269.html

    更多相关内容
  • Win11:资源管理器卡顿问题解决

    万次阅读 2021-10-14 09:00:47
    10.5 日 Windows 11 正式发布,于是第一时间升级到最新系统,其它基本还好没有什么大问题,只有一个本人认为最严重的问题就是:Win11 新版的资源管理器存在比较大的 Bug,会造成 CPU 占用率高,操作感觉明显卡顿。...

    温馨提示:相信此问题很快就会被微软以更新补丁的形式解决,所以此文可能很快会过时。

    更新提醒:2022-01-26,此 bug 已于近日微软发布的 KB5008353 补丁中彻底解决,下面内容不用看了~

    问题描述

    10.5Windows 11 正式发布,于是第一时间升级到最新系统,其它基本还好没有什么大问题,只有一个本人认为最严重的问题就是:Win11 新版的资源管理器存在比较大的 Bug,会造成 CPU 占用率高,操作感觉明显卡顿

    如下图,在用鼠标点选文件夹或者键盘上下方向选择文件夹时,明显卡顿及 CPU 占用 26% 左右。

    20211014_082910.png

    解决方案

    另外还有报道 AMD 处理器也受到此次影响,不过相信微软会在近期内解决(据说 Win11 在 AMD 平台上的 bug 将于 10.19 修复)。

    🎉临时解决方案是切换回旧版资源管理器

    1、打开注册表。

    开始 - 运行 - regedit

    2、定位到以下目录。

    \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions

    3、右键 Blocked 选择 新建 - 字符串值 名称为 {e2bf9676-5f8f-435c-97eb-11607a5bedf7}

    20211014_084901.png

    1)如果原来没有 Blocked 则右键 Shell Extensions 新建项即可。
    2)如果原来 Blocked 下已存在值(我电脑为{776dbc8d-7347-478c-8d71-791e12ef49d8}),我选择备份后删除。

    4、重启资源管理器后还原为旧版,测试流畅。(重启方法:Ctrl+Shift+Esc打开任务管理器,找到资源管理器右键。)

    20211014_083129.png

    参考资料

    https://weiku.co/article/641/

    展开全文
  • jmeter作为一个开源的纯Java性能测试工具,工作中极大的方便了我们进行接口、性能测试,但使用过程中也遇到了很多的问题,下面就记录一下自己遇到的问题,后续会不断更新。。。 1、获取日志 在使用jmeter过程中,...

    jmeter作为一个开源的纯Java性能测试工具,工作中极大的方便了我们进行接口、性能测试,但使用过程中也遇到了很多的问题,下面就记录一下自己遇到的问题,后续会不断更新。。。

    1、获取日志

    在使用jmeter过程中,如果想获得更详细的日志,可以修改jmeter\bin\jmeter.properties文件中的一个属性:所有log_level.jmeter的后缀由info改为debug,如下:

    2、jmeter安装

    安装使用jmeter时候不需要设置classpath以及class变量,只需要默认安装好JDK即可(通常情况下),然后解压jmeter安装包,启动jmeter\bin\jmeter.bat程序即可;

    因为jmeter是以Java_jar的方式启动,而且会忽略该变量,这对所有Java程序都适用。

    3、请求/响应数据显示乱码

    有时候在发送请求/查看响应数据时,服务端接收到的请求中包含乱码,导致无法解析报错,解决方法有如下几种:

    请求数据显示乱码,可以在请求中如下设置:

    返回数据包含乱码时,可以修改jmeter\bin\jmeter.properties文件中的一个属性:将encoding=后面的编码格式改为utf-8,如下:

    PS:此模块更详细的原因说明,可参考这篇博客:http://blog.csdn.net/cakushin7433/article/details/53039566

    4、内存OOM(OutOfMemoryError:内存溢出)

    在执行压力测试时候,有时候会遇到OutOfMemoryError这样的异常;JMeter是一个纯Java开发的工具,内存是由java虚拟机JVM管理;如果出现了内存溢出的问题,

    可以通过调整JVM内存相关的参数进行优化。

    具体过程如下:

    ①找到jmeter.bat文件,也就是我们启动jmeter的脚本:

    ②打开jmeter.bat文件,对一下这些配置项进行编辑:

    ③参数调整:

    调整堆内存的大小:

    将默认的set HEAP=-Xms512m -Xmx512m,调整为set HEAP=-Xms1024m -Xmx1024m;

    调整堆内存中新生带的大小:

    将默认的set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m,调整为set NEW=-XX:NewSize=256m -XX:MaxNewSize=256m;

    调整堆内存中永久带的大小:

    将默认的set PERM=-XX:PermSize=64m -XX:MaxPermSize=128m,调整为set PERM=-XX:PermSize=128m -XX:MaxPermSize=256m;

    调整后重启jmeter,问题一般可以得到解决(参数的调整不能一概而论,具体根据测试机的硬件配置来决定)。

    5、Listener使用技巧

    listener作为一个收集sampler的结果数据和呈现结果的文件,其本身会在每次sampler运行完成后执行一次,即一个test plan中的listener数量越多,运行时listener本身带来的资源消耗

    就越大(尤其是view results in table以及view results tree等)。

    因此实际执行test plan时,应首先禁用不需要的listener,再开始执行;更好的方式是每次运行时将生成的结果写入结果文件中,方便以后用不同的listener展现保存的结果数据。

    当然,在并发量较大的情况下,一般的测试机限于配置等因素,无法支撑较大的并发数,可以用以下的方法来进行测试,方法如下:

    去掉listener,为sampler添加断言(一般是响应断言),根据断言结果来判断请求是否成功,测试报告以plugins插件中的报告形式或文本形式写入文件中来提升测试效率。

    PS:这个方法是我认识的一个妹子她之前说的一种方法,感兴趣的可以去看看她的博客,链接:http://www.cnblogs.com/sunshine2016/

    6、调试test plan

    很多测试人员在初始进行性能测试时,脚本都是录制得到的,但录制的脚本一般都包含很多对本次测试来说无用的sampler,以及录制的sampler需要重新修改参数等内容,才能使用。

    所以调试test plan就很有必要,常用的有以下2种方法:

    ①使用listener观察sampler的请求和相应

    录制的脚本,一般都需要剔除无用的sampler,然后修改参数,进行调试,才能用于测试执行,一般用于调试的listener是结果树,可以在测试计划中将线程组的数量修改为1,然后执行。

    listener显示的每一个sampler结果为绿色(表示通过),但jmeter仅根据http返回码来判断sampler执行是否成功,这样无法判断sampler语义上的错误;因此,一般都是在sampler

    中插入对应的检查点(Assertion:断言),根据返回的内容,来判断sampler是否真正成功。

    ②使用http Mirror server观察sampler发出的请求

    在调试和修改sampler时,经常会为其增加一些额外的设置,例如额外的信息头、cookie管理器等,但设置完成后直接运行脚本进行测试,并不能保证请求真的和我们预期的一致。

    如果不想将请求发送给被测应用,可以使用http mirror server组件(http镜像服务器)。

    http mirror server可以启动一个镜像服务器,其可以把所有接收到的请求原封不动的返回,这样就可以查看发出的请求的具体内容。

    使用方法如下:

    点击工作台,右键添加→http mirror server,如有必要修改服务器端口(一般修改为localhost:8080,方便调试),然后启动镜像服务器;

    其次修改需要调试的sampler,将其请求发送到mirror server启动的端口,运行测试计划,即可以从listener中查看响应数据。

    PS:其实http mirror server更大的作用是检查浏览器是否发送了特殊的http头,启动mirror server,使用浏览器访问该server,则可以在返回页面看到浏览器发送请求的完整内容。

    Jmeter性能测试(14)--HTTP请求之content-type

    展开全文
  • 总结起来,传统的测试工作主要面临以下问题。 1.开发与测试对立 在传统软件公司组织结构里面,开发与测试往往分属不同部门,担负不同的职责。开发人员为了实现功能需求,从而生产出代码;测试人员则是为了查找

    测试概述

    软件测试的目的,一方面是为了检测出软件中的Bug,另一方 面是为了检验软件系统是否满足需求。

    然而,在传统的软件开发企业中,测试工作往往得不到技术人员的足够重视。随着Web应用的兴起,特别是以微服务为代表的分布式系统的发展,传统的测试技术也面临着巨大的变革。

    传统的测试所面临的问题

    总结起来,传统的测试工作主要面临以下问题。

    1.开发与测试对立

    在传统软件公司组织结构里面,开发与测试往往分属不同部门,担负不同的职责。开发人员为了实现功能需求,从而生产出代码;测试人员则是为了查找出更多功能上的问题,迫使开发人员返工,从而对代码进行修改。表面上看,好像是测试人员在给开发人员“找茬”,无法很好地相处,因此开发与测试的关系处于对立。

    2.事后测试

    按照传统的开发流程,以敏捷开发模式为例,开发团队在迭代过程结束过后,会发布一个版本,以提供给测试团队进行测试。由于在开发过程中,迭代周期一般是以月计,因此从输出一个迭代,

    到这个迭代的功能完全测试完成,往往会经历数周时间。也就是说,等到开发人员拿到测试团队的测试报告时,报告里面所反馈的问题,极有可能已经距离发现问题一个多月 了。别说让开发人员去看一个月前的代码,即便是开发人员自己在一个星期前写的代码,让他们记忆起来也是挺困难的。

    开发人员不得不花大量时间再去熟悉原有的代码,以查找错误产生的根源。

    所以说,对于测试工作而言,这种事后测试的流程,时间间隔得越久,修复问题的成本也就越高。

    3.测试方法老旧

    很多企业的测试方法往往比较老旧,无法适应当前软件开发的大环境。很多企业测试职位仍然是属于人力密集型的,即往往需要进行大量的手工测试。手工测试在整个测试过程中必不可少,但如果手工测试比重较大,往往会带来极大的工作量,而且由于其机械重复性质,也大大限制了测试人员的水平。测试人员不得不处于这种低级别的重复工作中,无法发挥其才智,也就无法对企业的测试提出改进措施。

    4.技术发生了巨大的变革

    互联网的发展急剧加速了当今计算机技术的变革。当今的软件设计、开发和部署方式,也发生了很大的改变。随着越来越多的公司从桌面应用转向Web应用,很多风靡一时的测试书籍里面所提及的测试方法和最佳实践,在当前的互联网环境下效率会大大下降,或者是毫无效果,甚至起了副作用。

    5.测试工作被低估

    大家都清楚测试的重要性,一款软件要交付给用户,必须要经过测试才能放心。但相对于开发工作而言,测试工作往往会被“看低一等” ,毕竟在大多数人眼里,开发工作是负责产出的,而测试往往只是默默地工作在背后。大多数技术人员也心存偏见,认为从事测试工作的人员,都是因为其技术水平不够,才会选择做测试职位。

    6.发布缓慢

    在传统的开发过程中,版本的发布必须要经过版本的测试。由于传统的测试工作采用了其事后测试的策略,修复问题的时间周期被拉长了,时间成本被加大了,最终导致产品发布的延迟。延期的发布又会导致需求无法得到客户及时的确认,需求的变更也就无法得到提前实现,这样,项目无疑就陷入了恶性循环的“泥潭”。

    如何破解测试面临的问题

    针对上面所列的问题,解决的方法大致归纳为以下几种。

    1.开发与测试混合

    在How Google Tests Sofiware-一文中,关于开发、测试及质量的关系,表述为:“质量不等于测试。当你把开发过程和测试放到一起,就像在搅拌机里混合搅拌那样,直到不能区分彼此的时候,你就得到了质量。

    这意味着质量更像是一种预防行为, 而不是检测。质量是开发过程的问题,而不是测试问题。

    所以要保证软件质量,必须让开发和测试同时开展。开发一段代码就 立刻测试这段代码,完成更多的代码就做更多的测试。

    在Google公司有一个专门的职位,称为“软件测试开发工程师( Software Engineer inTest)”,简称SET。Google 认为,没有人比实际写代码的人更适合做测试,所以将测试纳入开发过程,成为开发中必不可少的一部分。当开发过程和测试一起联合时,即是质量达成之时。

    2.测试角色的转变

    在GTAC 2011大会上,James Whittaker和Alberto Savoia发表演讲,称为“Test is Dead (测试已死)”。当然,这里所谓的“测试已死”并不是指测试人员或测试工作不需要了,而是指传统的测试流程及测试组织架构要进行调整。测试的角色已然发生了转变,新兴的软件测试工作也不再只是传统的测试人员的职责了。

    在Google,负责测试工作的部门称为“工程生产力团队”,他们推崇“You build it, you breakit, you fix it!"的理念,即自己的代码所产生的Bug需要开发人员自己来负责。这样,传统的测试角色将会消失,取而代之的是开发人员测试和自动化测试。与依赖于手工测试人员相比,未来的软件团队将依赖内部全体员工测试、Beta 版大众测试和早期用户测试。

    测试角色往往是租赁形式的,这样就可以在各个项目组之间流动,而且测试角色并不承担项目组主要的测试任务,只是给项目组提供测试方面的指导,测试工作由项目组自己来完成。这样保证了测试角色人员比较少,并可以最大化地将测试技术在公司内部蔓延。

    3.积极发布,及时得到反馈

    在开发实践中推崇持续集成和持续发布。持续集成和持续发布的成功实践,有利于形成“需求→开发→集成→测试→部署”的可持续的反馈闭环,从而使需求分析、产品的用户体验及交互设计、开发、测试、运维等角色密切协作,减少了资源的浪费。

    一些互联网的产品,甚至打出了“永远Beta版本”的口号,即产品在没有完全定型时就直接上线交付给了用户使用,通过用户的反馈来持续对产品进行完善。特别是一些开源的 、社区驱动的产品,由于其功能需求往往来自真正的用户、社区用户及开发者,这些用户对产品的建议往往会被项目组所采纳,从而纳入技术。比较有代表性的例子是Linux和GitHub。

    4.增大自动化测试的比例

    最大化自动测试的比例有利于减少企业的成本,同时也有利于测试效率的提升。

    Google刻意保持测试人员的最少化,以此保障测试力量的最优化。最少化测试人员还能迫使开发人员在软件的整个生命期间都参与到测试中,尤其是在项目的早期阶段:测试基础架构容易建立的时候。

    如果测试能够自动化进行,而不需要人类智慧判断,那就应该以自动化的方式实现。当然有些手工测试仍然是无可避免的,如涉及用户体验、保留的数据是否包含隐私等。还有一些是探索性的测试,往往也依赖于手工测试。

    5.合理安排测试的介入时机

    测试工作应该及早介入,一般认为,测试应该在项目立项时介入,并伴随整个项目的生命周期。

    在需求分析出来以后,测试不止是对程序的测试,文档测试也是同样重要的。需求分析评审的时候,测试人员应该积极参与,因为所有的测试计划和测试用例都会以客户需求为准绳。需求不但是开发的工作依据,同时也是测试的工作依据。


    测试的类型和范围

    在当今的互联网开发模式中,虽然传统的测试角色已经发生了巨大的变革,但就其测试工作而言,其本质并未改变,其目的都是检验软件系统是否满足需求,以及检测软件中是否存在Bug。下面就对常用的测试方案做下探讨。

    测试类型

    图4-1展示的是一个通用性的测试金字塔。

    在这个测试金字塔中,从下向上形象地将测试分为不同的类型。

    1.单元测试

    单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

    单元测试的范围局限在服务内部,它是围绕着- -组 相关联的案例编写的。例如,在C语言中,单元通常是指一-个函数; 在Java等面向对象的编程语言中,单元通常是指一个类。 所谓的单元,就是指人为规定的最小的被测功能模块。因为测试范围小,所以执行速度很快。

    单元测试用例往往由编写模块的开发人员来编写。在TDD ( Test Driven Development, 测试驱动开发)的开发实践中,开发人员在开发功能代码之前,就需要先编写单元测试用例代码,测试代码确定了需要编写什么样的产品代码。TDD在敏捷开发中被广泛采用。

    单元测试往往可以通过xUnit等框架来自动化进行测试。例如,在Java平台中,JUnit 测试框( htt:nit.rg/ )已是用于单元测试的事实上的标准。

    2.集成测试

    集成测试主要用于测试各个模块能否正确交互,并测试其作为子系统的交互性,以查看接口是否存在缺陷。

    集成测试的目的在于,通过集成模块检查路径畅通与否,来确认模块与外部组件的交互情况。

    集成测试可以结合CI (持续集成)的实践,来快速找到外部组件间的逻辑回归与断裂,从而有助于评估各个单独模块中所含逻辑的正确性。

    集成测试按照不同的项目类型,有时也细分为组件测试、契约测试等。例如,在微服务架构中,微服务中的组件测试是使用测试替代与内部API端点通过替换外部协作的组件,来实现对各个组件的独立测试。组件测试提供给测试者- -个受控的测试环境,并帮助他们从消费者角度引导测试,允许综合测试,提高测试的执行次数,并通过尽量减少可移动部件来降低整体构件的复杂性。组件测试也能确认微服务的网络配置是否正确,以及是否能够对网络请求进行处理。而契约测试会测试外部服务的边界,以查看服务调用的输入/输出,并测试该服务能否符合契约预期。

    3.系统测

    系统测试用于测试集成系统运行的完整性,这里面涉及应用系统的前端界面和后台数据存储。

    该测试可能会涉及外部依赖资源,如数据库、文件系统、网络服务等。系统测试在一些面向服务的系统架构中被称为“端到端测试”。因此在微服务测试方案中,端到端测试占据了重要的角色。在微服务架构中有一些执行相同行为的可移动部件,端到端测试时需要找出覆盖缺口,并确保在架构重构时业务功能不会受到影响。

    由于系统测试是面向整个系统来进行测试的,因此测试的涉及面将更广,所需要的测试时间也更长。.

    测试范围及比例

    1.测试范围

    不同的测试类型,其对应的测试范围也是不同的。单元测试所需要的测试范围最小,意味着其隔离性更好,同时也能在最快的时间内得到测试结果。单元测试有助于及早发现程序的缺陷,降低修复的成本。系统测试涉及的测试范围最广,所需要的测试时间也最长。如果在系统测试阶段发现缺陷,则修复该缺陷的成本自然也就越高。

    在Google公司,对于测试的类型和范围,一般按照规模划分为小型测试、中型测试、大型测试,也就是平常理解的单元测试、集成测试、系统测试。

    小型测试:小型测试是为了验证一个代码单元的功能,一般 与运行环境隔离。小型测试是所有测试类型里范畴最小的。在预设的范畴内,小型测试可以提供更加全面的底层代码覆盖率。小型测试中外部的服务,如文件系统、网络、数据库等,必须通过mock或fake来实现。这样可以减少被测试类所需要的依赖。小型测试可以拥有更加频繁的执行频率,并且可以很快发现问题并修复问题。

    ●中型测试:中型测试主要是用于验证多个模块之间的交互是否正常。一般情况下,在Google由SET来执行中型测试。对于中型测试,推荐使用mock来解决外部服务的依赖问题。有时出于性能考虑,在不能使用mock的场景下,也可以使用轻量级的fake。

    大型测试:大型测试是在一个较高的层次 上运行的,以验证系统作为一个整体是否工作正常。

    2.测试比例

    每种测试类型都有其优缺点,特别是系统测试,涉及的范围很广,花费的时间成本也很高。所以在实际的测试过程中,要合理安排各种测试类型的测试比例。正如测试金字塔所展示的,越是底层,所需要的测试数量将会越大。那么每种测试类型需要占用多大的比例呢?实际上,这里并没有一个具体的数字,按照经验来说,顺着金字塔从上往下,下面一层的测试数量要比上面一层的测试数量多出-一个数量级。

    当然,这种比例也并非固定不变的。如果当前的测试比例存在问题,那么就要及时调整并尝试不同类型的测试比例,以符合自己项目的实际情况。

    本篇给大家介绍的内容是如何破解测试所面临的问题、测试的类型和范围两块内容!

    1.下篇内容给大家介绍如何进行微服务的测试;

    2.觉得文章还不错的朋友,可以转发关注小编一下;

    3.感谢大家的支持!!

    展开全文
  • 测试管理中可能存在的问题及分析

    千次阅读 2019-01-02 12:30:00
    摘要:本文结合实践,主要探讨了在中小型软件企业中,在测试资源不是很充足的情 况下的软件测试管理。文中前两部分简要介绍了软件测试管理及测试的范围,方法及重要性,之后对当前国内中小型软件企业在测试及测试...
  • 在Win10中,文件资源管理器经常出现崩溃未响应的问题,可能出现的问题是,双击“此电脑”进入就出现Windows资源管理器未响应的问题,或者任意软件通过打开文件对话框选择文件出现资源管理器总是崩溃等等,那么Win10...
  • 本文总结了一些软件测试入门必须要了解和学习的BUG基础知识,主要包括BUG定义、测试BUG的等级划分、Bug流程以及Bug解决优先级等内容。下面一起来梳理一遍这些基础知识吧! BUG基础知识 1、BUG定义 软件的Bug也叫缺陷...
  • 性能测试知识问题整理(一)

    万次阅读 2020-05-09 14:19:02
    参考高楼的《性能测试实战30讲之问题问答整理》,觉得他写的好,但是看原文一问一答的方式,比较散乱,我就重新按自己的想法整理一下,主要是抽取核心的内容方便自己查阅: 一、性能测试的概念到底是什么? 性能...
  • 由公司APP大面积闪退问题引发的测试基建思考
  • 软件测试总结——常见的面试问题(一)

    万次阅读 多人点赞 2019-10-12 18:40:58
    1.软件测试级别? 单元测试:单元测试是...(测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试) 集成测试:(集成测试也称联合测试、组装测试,将程序模块采用适当的集成策略组装起...
  • 问题描述: 当前端代码和后台代码不在一个服务器的时候;或者在一个服务器上,端口不一样的时候。 前端请求后台的时候就涉及到跨域的问题,如果是协议和端口造成的跨域问题“前台”是...解决办法: 常...
  • 软件测试面试题(含答案)

    万次阅读 多人点赞 2021-03-01 15:15:38
    软件测试面试题(含答案)
  • 资源管理器的正常运转是我们能够在桌面正常办公条件...阅读下文了解开机后提示“Windows资源管理器已停止工作”的解决办法。操作步骤:1、原因探查:查看一下你的文件夹中是否存放的音频和视频文件过多,如果是这样...
  • 测试知识汇总

    千次阅读 2021-10-20 10:12:42
    提交 Bug 并推动 Bug 解决 回归测试 编写并提交测试报告 软件测试方法 白盒测试 黑盒测试 等价类 灰盒测试 动态测试 α测试 β测试 冒烟测试 回归测试 随机测试 探索测试 为什么引入自动化测试 自动...
  • Monkey测试问题解决方法

    万次阅读 2015-10-10 21:02:59
    目录 1.1 Monkey测试简介... 1 1.2 Monkey程序介绍... 1 1.3 Monkey命令的简单帮助... 2 1.4 Monkey命令参数...1.6 Monkey测试问题分析及处理技巧... 3 1.7 Monkey测试注意事项... 3 1.8 Monkey测试命令... 3 1.9 Mo
  • 点击查看原因及解决方法
  • 软件测试常见问题

    千次阅读 2019-04-10 09:20:39
    1.如果能够执行完美的黑盒测试,还需要进行白盒测试吗?(白盒与黑盒的区别) 任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。 黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了...
  • 前后端分离项目跨域问题解决方案

    万次阅读 多人点赞 2020-04-18 20:00:01
    2、前后端分离项目中的跨域问题 3、方法一:SpringBoot后端进行处理 4、方法二:在Vue前端进行处理 5、总结 1、什么是跨域 请求同域资源: 在域名 (或 ip 地址)相同,端口号相同下的请求资源,可以看做是同...
  • 文章目录前言关于Vue中图片打包的问题(可跳过)准备工作问题描述静态资源访问设置首页出错页面处理另外的处理方式结束 前言         为了完成学校的课程设计,我使用了...
  • 软件测试之Android单元测试

    千次阅读 2022-03-19 22:08:36
    根据维基百科的解释,单元测试又称为模块测试。是针对程序单元来进行正确性校验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序,函数,过程等,对于面向对象编程,最小单元就是...
  • 解决 Win11 资源管理器卡顿

    万次阅读 多人点赞 2021-09-23 16:25:42
    经过本人测试确实是微软对新版的资源管理器优化做的不好,如果换回Win10的资源管理器就不会出现卡顿,下面给出解决方法 解决方法 Win+R 输入 regedit,转到 计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\...
  • 【docker系列】docker解决的实际问题及应用场景

    千次阅读 多人点赞 2022-03-29 10:10:16
    笔者打算写一个完整系列的docker知识总结,本文是第一篇,主要介绍docker是什么?主要的应用场景是什么?解决了哪些问题?和虚拟机有什么区别?
  • Windows10 explorer资源管理器CPU占用过高的一种情况和解决办法1.系统基本信息2.explorer高占有率查因3.解决方法4. 附加:CPU状态 ...问题测试方法: 1).为了便于观察,使用快捷键windows + E 快速 打开10个资
  • 记一次性能测试过程中遇到的问题的定位思路

    万次阅读 多人点赞 2018-10-28 10:38:21
    这个场景容易测试出来响应时间慢或者服务器资源利用率高的问题,交易的性能问题会在这个场景中暴露很多。 2.3 混合场景容量测试 把需要压测的交易按照一定的比例混合,以客户要求的最低并发数为基准,以一定的...
  • 单元测试与集成测试

    万次阅读 多人点赞 2019-09-17 08:25:00
    测试策略和过程,软件测试分为单元测试、集成测试、确认测试和系统测试。 按软件系统工程,测试是软件质量保证的最后的一关。 高质量的程序取决于以下几个方面: 高质量的设计 规范的编码 有效的测试 开发部...
  • 软件测试中遇到的缺陷等

    千次阅读 2021-09-22 16:20:09
    软件测试中遇到的缺陷等 缺陷:就是软件或程序中存在的某种破坏正常运行能力的问题,错误,或者是隐藏的功能缺陷,软件缺陷的属性包括缺陷标识 缺陷类型,缺陷严重程度,缺陷优先级,缺陷来源,缺陷原因等 缺陷产生...
  • 软件测试流程

    千次阅读 2022-05-29 16:10:20
    将用户需求转化为功能需求,明确测试活动的五个要素(测试需求是什么、决定怎么测、明确测试时间、确定测试人员、确定测试环境,测试中需要的技能,工具以及相应的背景知识,测试过程中可能遇到的风险等,测试需求...
  • 1、前后端分离框架,前端用的是vue、element,后端使用springboot2、后端采用spring security作为安全认证框架如果直接访问,结果是这样的:{"msg":"请求访问:/equip/detail/1,认证失败,无法访问系统资源",...
  • 2021年软件测试面试题大全

    万次阅读 多人点赞 2020-11-30 15:16:59
    简述测试流程: 1、阅读相关技术文档(如产品PRD、... 7、执行测试用例,记录发现的问题。 8、验证bug与回归测试。 9、编写测试报告。 10、产品上线。 补充测试用例设计过程: 根据需求得出测试需求 设计测试
  • 这一篇文章,主要是介绍一下智能座舱自动化测试解决方案用到的技术,以及几个典型应用场景。 关于AutoTest自动化测试的基本概念,如果你不是很清楚,可以参考一下我先前发的文章 智能座舱自动化测试竟然可以如此...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 779,639
精华内容 311,855
关键字:

如何解决测试资源问题