精华内容
下载资源
问答
  • 一台笔记本电脑或者是一台DIY台式电脑,都是由处理器、显卡、硬盘等配件构成,而每个配件都有自己的性能,性能是高是低我们可以进行单项测试。对于整机性能我们也可以对其进行测试,来看看它的真实性能到底如何。 ...

    一台笔记本电脑或者是一台DIY台式电脑,都是由处理器、显卡、硬盘等配件构成,而每个配件都有自己的性能,性能是高是低我们可以进行单项测试。对于整机性能我们也可以对其进行测试,来看看它的真实性能到底如何。

     

     

    CPU中文名叫中央处理器,它是一台电脑中最核心的部件,俗称为电脑的大脑。CPU性能的高低直接决定了电脑性能的高低,目前的处理器分为Inter和AMD两大平台。CPU的更新换代非常之快,各种产品分类非常细致,往往搞得初学者一头雾水。当然,CPU检测与测试软件也在不断地更新,功能也越来越丰富。而我们来介绍两款关于CPU的检测和测试软件的黄金组合:CPU-Z和Super PI。

    CPU-Z(ZPUID)

     

    展开全文
  • 总结上次经验,这次可以分成几个方向进行测试用例编写: 1. 功能方面 :正常的功能能不能正常使用,图片上限 2. 性能方面 :网络、时间、类型等 3. 安全方面 :会不会携带不安全因素 4. 兼容方面 :手机、电脑能...

    QQ电脑版添加表情:

    微信添加表情:

    手机版QQ添加表情:

     

    总结上次经验,这次可以分成几个方向进行测试用例编写:

    1. 功能方面 :正常的功能能不能正常使用,图片上限

    2. 性能方面 :网络、时间、类型等

    3. 安全方面 :会不会携带不安全因素

    4. 兼容方面 :手机、电脑能不能同步等

     

    接下来具体地分:

    1. 功能方面 

    正常情况

    • 电脑内存空间充足,图片格式、大小允许,网络稳定,进行表情收藏

    异溃情况

    • 网络不稳定
    • 网络突然断开
    • 收藏过程中点击右上角关闭收藏操作

    图片类型

    • 添加的图片类型规定
    • 动图过大
    • 表情是视频
    • 如果是动图,添加后点击发送(动态)

    图片大小

    • 超过了大小限制进行添加
    • 添加表情图片大小限制
    • 表情图片分辨率很高

    表情来源

    • 多人聊天收藏收到的表情
    • 多人聊天中不是好友的人发出来的表情的收藏
    • 多人聊天中收藏自己发送的表情
    • 基本表情收藏
    • 表情图片是内置的个人专利需要收费,进行收藏
    • 自己发出去的表情
    • 对方发来的表情我的列表已经存在
    • 自己发给自己的表情
    • 本地上传的图片

    公共测试

    上述图片来源、大小和类型不同组合带入下面的测试用例中:

    • 正确添加到所选的分组
    • 新创建一个分组添加表情
    • 添加成功后发送
    • 连续收藏多个不同的表情
    • 超过收藏个数上限
    • 同一个表情添加了两次或多次
    • 收藏表情个数(VIP/普通用户)

    2. 性能方面 

    网络

    • 双方的上网的运营商不同
    • 双方跨国上网聊天
    • 双方不同省份地域上网
    • 网速很慢的情况

    时间

    • 隔了很久失效的表情图片进行收藏
    • 撤回的表情但是对方已经点开了收藏界面
    • 对方离线发送的表情进行收藏
    • 自己发送给对方的表情已失效,进行收藏

    3. 安全方面 

    • 表情里携带不安全因素
    • 表情里存在病毒
    • 表情里携带强制下载安装的软件
    • 表情会跳转到某个不安全网站
    • 表情中存在不合法信息
    • 表情存在不健康信息

    4. 兼容方面 

    • 双方的QQ/微信版不同(国际版/普通版/精简版)
    • 双方的QQ/微信版本不同
    • 双方的操作系统不同(安卓版、IOS版)
    • 双方的登陆硬件不同(手机、电脑)
    • 双方设备分辨率不同
    • 电脑收藏的表情,手机上查看
    • 电脑上收藏的动图,手机上展现
    • 电脑上收藏的表情,手机进行发送
    • 登陆不同版本号的客户端显示已收藏表情
    • 登陆在不同的版本类型的客户端显示已收藏表情
    • 登陆在不同硬件设备上显示已收藏表情
    • 登陆在不同的网域显示已收藏表情
    • 对方用电脑发的表情,手机上收藏
    • 对方用手机发的表情,电脑上收藏

     


    这次终于分了类,但还只是很大的框架,具体也是想一条写一条,慢慢努力,多加练习一定能找到规律,游刃有余;

    展开全文
  • 性能测试新手误区

    千次阅读 2013-07-29 15:48:21
    性能测试新手误区(一):找不到测试点,不知为何而测 发布时间: 2012-4-17 10:19 作者: msnshow 来源: 51Testing软件测试博客     有过一些性能测试经验的人很容易进入此状态,他们已经熟悉了性能测试的...

    性能测试新手误区(一):找不到测试点,不知为何而测

    发布时间: 2012-4-17 10:19    作者: msnshow    来源: 51Testing软件测试博客 

     

      有过一些性能测试经验的人很容易进入此状态,他们已经熟悉了性能测试的基本流程,能够比较熟练的使用测试工具开展工作。我大概从事性能测试一年左右时遇到了这个问题,那时我觉得性能测试的过程没有太多挑战,遇到的每一个系统,仿佛都可以用同样的流程完成。半天时间填写测试方案,一天时间来准备测试环境,一天时间准备测试脚本,一到两天来完成各种测试用例(基准测试、日常压力测试、峰值压力测试、绝对并发测试、稳定性测试等),然后就是调优、问题复测和完成测试报告。在我看来,性能测试好像变成了用一些工具去执行一个个固定的用例。

     

      这样的工作持续了一段时间后,我感到有些不对劲,一定是哪里出了问题。性能测试难道真的这么简单,简单到把任何一个系统套入标准的流程中就可以了?于是我开始思考测试的意义,为什么要进行性能测试?是因为性能测试可以提供关于瓶颈、缺陷、效率等等我们认为有价值的信息。那仅仅通过一个工具,或者是一个固定的流程,就可以发现不同系统的这些信息么?这显然是不可能的。

     

      我开始尝试尽量深入的去理解被测系统,这个系统的目的是什么,用户是如何使用系统的,用户对哪些业务的性能比较敏感,系统的一些关键业务实现逻辑是怎么样的,从设计实现的角度来看哪些业务的性能可能存在隐患。这些很少是技术层面上的问题,需要做的只是思考,再深入思考。慢慢的我有了些收获,开始了解为什么要测这个系统,针对这个特定的系统哪些内容是最重要的,为了获得需要的信息我需要从哪几个方面进行测试,为了实现我的想法又需要哪几种方法或者工具。(现在我的性能测试过程中,用于理解被测系统、理解用户、整理测试思路的时间投入大大增加了。你呢,投入了多大比例?)

     

      要做好这些其实很难,每一个被测系统对我来说,仿佛就变成了一个新的挑战。但是逐渐的我发现自己思考问题更全面了、可以更快的抓住系统的重点、找到更重要的BUG、对系统的实际性能有了更准确的评估。这里提一个简单的问题,如何确保你的测试结果和生产环境的性能表现是一致的,也就是说测试结果能够真正的反应实际的性能,而不仅仅是代表了你选取的几个测试场景的性能。话说起来比较绕,但是请认真想一想,你有多大的把握呢?

     

      上面只是写了一些个人的感想,我觉得如果在“思想”上没有办法上到一个新的台阶,你的性能测试生涯可能也就达到“瓶颈”了。如何突破这个瓶颈,那就需要努力改变自身,多思考多学习,最核心的能力恐怕不是能培训出来的。一定会有一些人认为性能测试的重点在于“技术”上,于是他们不断的记住各种调优配置参数,以为自己掌握了性能的精髓,仿佛什么系统到了他们手上,只要改几个参数就会出现奇迹。我也经历了这个阶段,也有过几次自以为挺高明的调优经历,也为自己会各种中间件数据库的配置调优而有些小得意。但现在想想,那还真是一个比较低的层次,思想上抓不住重点、看不全大局,技术上其实也只是一点皮毛。面对这类人,只要问几个为什么就会让他们无法回答,为什么要调优?为什么要调这个参数?如何证明这次调整的效果?

     

      将上文简单的总结成几点,希望能给性能测试新手提供一丁点的帮助吧:

     

      1、性能测试的难点在于对被测系统的理解,在于对测试点的分析。为了实现测试的思想,可以有多种方法,手段永远只是辅助的,只有思想才是根本的。工具(如LR)更不等于性能测试,不要以为会用LR就懂了性能测试,那只是最低级的测试执行。也不要以为会调几个参数就懂了性能测试,那同样是个比较低的层次。

     

      2、调优等技术不是性能测试的主要目的,好的性能也不是调出来的。测试人员一定要明白自己存在的价值所在,所谓的“技术”只是为了达成自己测试目的的一些手段,同开发人员、DBA相比,你在这些技术上永远是外行。

     

      3、不要照着文档模板,填入测试方案。每一个系统都是不同的,要真正的认识到这一点,为每个系统设计出有针对性的测试方案。思考你每一步工作的意义和目的。

     

      4、如何证明测试结果的有效性,其实是个很难的问题,值得花费时间去认真思考。这个过程涉及到一些很重要的内容,如用户模型的建立,后续会有专门的文章。

     

    5、性能测试是一个需要不断改进的过程,每一次只需尽量的做到更好,多做一点点以前没有想到的东西。经过不断的积累,你会发现自己对性能测试有了更深的认识。

     

    性能测试新手误区(二):为什么我模拟的百万测试数据是无效的?

      测试环境的重要性无需多说,大家都知道测试环境要尽量的模拟生产环境,当然也包括数据。这样测试的结果才会更加准确的反应真实的性能。就连开发过程,都已经开始在大数据量下加压开发了。那么,关于测试数据,你了解多少呢?

      通常说的测试数据可以分为两类:

      一是为了测试性能而准备的数据,这是用来模拟“压力”的数据。也就是常说的数据量、历史数据等。一般都会根据需求或者经验很容易估算出来,比如案件年增长量为5%,去年数据量为100W,测试需要保证3年后系统仍可正常运行,那么就需要计算并模拟出3年后的总数据量,在这个基础上进行测试。

      二是用来辅助测试使用的数据。比如有一个对案件进行打分的功能,只有符合一定条件的案件才会出现在打分列表中。那么我们要测这个打分的操作,首先就要保证有可用的案件,这就需要去生成测试数据,该数据可能一经使用就失效了(已经打过分就不能再打了)。这样,每次测试这个功能,就需要准备这样一批数据。这里的测试数据,更多的是和测试流程有关,是为了能够正常的进行测试,而不是涉及到性能的。

      我们这里要说的是第一类,对性能测试结果产生直接影响的数据。

      先看两个小案例,涉及到了案件表(T_AJ)和法院编号列(N_FY)、立案日期列(D_LARQ)。案件表中模拟了一百万测试数据,测试简单的查询操作,根据经验,预期响应时间在2秒之内。

      案例1.查询本院案件列表,相应的SQL如下:

    select * from T_AJ

    where N_FY=10

    order by D_LARQ desc

     执行这个操作耗时近10s,显然达不到正常预期。

      经排查,生成的100W测试数据中,所有的N_FY列值都为10。这样,最明显的问题就是,查询的结果集数量完全偏离了正常范围。如果实际有100家法院,正常分布下,每家法院只有1W的案件,但测试数据的FY只有一个值,通过这个查询,查出了原来100家法院的数据。无论是在数据库处理中(如本例的排序),还是在程序的处理中(如展现或者是对数据做进一步处理),两者的性能差异都是很显著的。所以这个测试结果是无效的。

      有人说,这个例子太弱了,结果集差了100倍,性能当然不一样了。那是不是数据总量和结果集大小都一致,测试结果就是有效了呢?

      案例2.查询本院一个月内收的案件,相应SQL如下:

    select * from T_AJ

    where N_FY=10 and D_LARQ between '20110101' and '20110201'


     这个操作,查出来的结果只有一千条数据,属于正常范围。但查询的时间还是超过5秒,依然超出了我们的预期。

     

      查看数据发现,N_FY=10的数据有近50万,占了总数据量的一半,D_LARQ在一月份的数据也占了差不多一半。但是同时符合两个条件的数据还是一千条左右。那么这里的问题就不在于结果集了,而是是否能利用索引进行查询,看如下两个图就能很好理解了。

     

      在正常数据中,每家法院的数据可能占总数据量的1%,一个月时间段内的数据可能占总数据量更少,假设是0.5%。那么这时我们通过N_FY和D_LARQ两个条件进行查询,数据库会进行估算:符合D_LARQ查询条件的数据大概有5000条,符合N_FY查询条件的数据大概有1万条,那么用D_LARQ上的索引进行查询是最快的,可以迅速的将查询范围缩小到5000条,然后在这5000条中去检查N_FY是否也符合条件。

     

    过程如图一所示(手绘草图^_^)。


    注:数据按行存储,小方块表示符合该列查询条件的数据,阴影表示符合所有查询条件,也就是最终的结果集。箭头线段表示为了完成查询,需要扫描的数据量,本图中即符合LARQ查询条件的数据。下同。

     但在本例中不正常的数据条件下,数据库会知道:符合N_FY查询条件的数据有50万条,符合D_LARQ的也有近50万条,如果使用其中一列的索引将一百万的范围缩减到50万,比从头到尾扫描整个表做的工作还要多(为什么呢?需要了解索引的结构和原理),那还是不要用索引了吧。于是数据库会依次检查每一条数据,判断N_FY和D_LARQ是否符合条件。

     

      如图二所示。


      注:本图中实际扫描的数据量就是整张表的数据,但结果集和图一是一样大的。

      这样,就可以知道,总数据量一样,结果集大小一样,为什么性能差了很多了。就是因为数据分布不合理,导致数据库无法正常使用索引,从而进行了全表扫描。当然,这个数据分布,我们依然可以归类到结果集中去,那就是要保证每一个查询条件“单独的结果集”都要符合真实情况,而不仅仅是整个查询最终的“总结果集”。

      看个这两个简单的小例子,我们再来总结一下关于测试数据,需要注意的内容:

      1、最根本、也是大家都知道的就是数据量,性能测试必须保证能在预期的数据量下进行测试。在一万条记录中查询,和在一百万数据中查询,显然是大大不同的,可以把数据量看做一种“压力”,这个就不用再解释了。

      但是在比较大型的系统中,这一点可能也不是很容易做好,因为这类系统往往有着复杂的数据库,上百张的数据表。对每张表都进行数据模拟显然是不现实的,也是没有意义的,因为不是每张表都涉及到大数据量。那么如何选取不容易遗漏呢?通常通过两种方式:从设计和业务角度分析表间关系、从现有实际数据量进行分析推测。

      2、确保结果集在正常范围内。结果集的大小直接影响后续很多工作的性能,如数据排序分组、分页、程序中的逻辑校验或者是展现。

      3、数据分布必须合理,尽量接近真实。数据的分布,其实也就是数据的真实性,它直接决定了数据库是否使用索引、选用哪个索引,也就是常说的查询计划。不同的查询计划也就是不同的数据访问路径,性能差别可能会很大。

      这里主要涉及到的是索引的问题,需要大家对索引的原理有一定的了解,索引如何工作、数据库如何选择索引、和索引有关的一写重要概念如区分度(selectivity)等等。

      4、最好的数据来自生产环境。这是显而易见的,使用真实的数据测出来的结果才是最准确的。但是绝大多数情况下,我们没有这样的好运,可能是客户禁止、也可能是生产环境数据量比较小。那就只好自己想办法来模拟了,需要注意的也就是上面说到的几点。这里再推荐一种方法,数据翻倍。比如已经有了真实的数据十万条,但我们需要一百万条,那就可以通过写一些SQL或者存储过程,将现有的数据不断翻倍(简单的说,复制到临时表,根据需要修改一些列,再插回到原表),这样的数据真实性还是比较高的。

      关于测试数据,我想说的就是以上几点了。另外再补充上一些相关内容,也是性能测试人员需要关注的。

      ● 重点了解IO的概念,更准确的说应该是物理IO。一般来讲,数据库的瓶颈或者查询的主要耗时就是IO。所以,数据库优化的一个重要方向就是尽量减小IO。

      IO是不是只和数据量(行数)有关呢?举一个例子:

    select co1, col2, col3, col4, col5 from T_AJ

    where condition...


      T_AJ数据量有100万,表中有近200列,此查询耗时大于10秒。而另一种实现方式,首先将col1-col5以及查询条件中的几个列的数据抽取到一张临时表(#T_AJ)中。然后,

    select co1, col2, col3, col4, col5

    from #T_AJ where condition...


      临时表#T_AJ和原数据表有同样的数据量(行数),但是此查询却只需要1秒(暂不考虑抽取到临时表的耗时),这就是不同IO引起的差异。通常我们使用的数据库都是行式存储的,可以简单的理解为,一行数据从头读到尾,才能进入到下一行。这样,不管一行中的200列,你只读取其中的一列还是几列,其余的190多列仍然需要一定的IO。在大数据量下,这个性能差异就很明显了。所以上面的这个例子就是一种典型的优化手段,索引覆盖也是处理类似问题的典型方法,各位自行了解吧。列式存储数据库(如Sybase IQ)之所以性能这么高,也是同样的道理。

      ● 尽量深入了解这些概念,如执行计划,基于开销的估算,统计信息等等。我用一句话来简单描述:数据库通过统计信息来估计查询开销,统计信息不准时,开销估计就可能不准确,从而导致选择了错误的执行计划。

      ● 测试过程中数据的清理。性能测试过程中可能又会生成大量的数据,积累到一定程度又会对性能结果造成影响,所以每一轮测试时都应该清理掉之前测试过程中产生的数据,保证每次测试是在相同的条件下进行的。

      ● 性能测试过程中,如果定位到了某一个查询或SQL有问题,首先要确认的是数据是否合理。通过查询计划来判断是否按预期进行了查询,如果不是,查看数据的分布是否真实。一般数据库会提供很多种手段来进行验证。

      最后,本文所写内容都是针对传统的行式存储数据库的,还请大家注意。

     

    性能测试新手误区(三):用户数与压力

     

    同样的项目、同样的性能需求,让不同的测试人员来测,会是相同的结果么?

      假设有这样一个小论坛,性能测试人员得到的需求是“支持并发50人,响应时间要在3秒以内”,性能测试人员A和B同时开始进行性能测试(各做各的)。

      只考虑发帖这个操作,A设计的测试场景是50人并发发帖,得到的测试结果是平均完成时间是5秒。于是他提出了这个问题,认为系统没有达到性能期望,需要开发人员进行优化。

      B设计的测试场景是,50个人在线,并且在5分钟内每人发一个帖子,也就是1分钟内有10个人发帖子,最后得到的测试结果是平均完成时间2秒。于是他的结论是系统通过性能测试,可以满足上线的压力。

      两个人得到了不同的测试结果,完全相反的测试结论,谁做错了?

      或许这个例子太极端,绝对并发和平均分布的访问压力当然是截然不同的,那我们再来看个更真实的例子。

      还是一个小论坛,需求是“100人在线时,页面响应时间要小于3秒”。A和B又同时开工了,这时他们都成长了,经验更加丰富了,也知道了要设计出更符合实际的测试场景。假设他们都确认了用户的操作流程为“登录-进入子论坛-(浏览列表-浏览帖子)×10-发帖”,即每个用户看10个帖子、发一个帖子。于是他们都录制出了同样的测试脚本。

      A认为,每个用户的操作,一般间隔30s比较合适,于是他在脚本中的每两个事务之间加上了30秒的等待(思考时间)。

      B想了想自己看论坛时的情景,好像平均每次鼠标点击要间隔1分钟,于是他在脚本中的每两个事务之间加上了1分钟的等待。

      他们都认为自己的测试场景比较接近实际情况,可惜测试结果又是不同的,很显然A场景的压力是B的两倍。那谁错了呢?或者有人说是需求不明确导致的,那么你需要什么样的需求呢?

      看看我随手在网上(51testing)找的提问吧,和上面的内容如出一辙。一定有很多的性能测试人员每天接到的就是这种需求,又这样就开展了测试,结果可想而知。


      这里我想问几个问题,希望各位看完了上面的小例子后想一想:

      如果有另一个人和你测同样的系统,你们的测试结果会一致么?

      如果不一致,那么谁是正确的?

      如何证明测试结果是有效的?

      如果你有了一些疑惑,对之前的测试结果少了一些自信,那么请继续。

    服务器视角 vs. 用户视角

      性能测试中非常重要的一块内容就是模拟预期的压力,测试系统运行在此压力下,用户的体验是什么样的。

      那么压力是什么?压力是服务器在不断的处理事情、甚至是同时处理很多事情。压力是服务器直接处理的“事情”,而不是远在网络另一端的用户。

      下图中,每一个颜色的线段代表一种操作。在任意一个时刻,服务器都知道它有10个事务需要处理,这10个事务也是有10个用户产生的。但它不知道的是,整个时间段内的所有事务,是由多少个用户与系统交互而产生的。


      这句话好像有点绕,我再试着更形象的解释一下。时刻1,10个当前事务是由10个用户发起的。时刻2,依然是10个正在进行的事务,但可能是完全不同的10个人发起的。在这段时间内,服务器每一个时刻都在处理10个事务,但是参与了这个交互过程(对服务器产生压力)的人可能会达到上百个,也可能只有最开始的10个。

      那么,对于服务器来说,压力是什么呢?显然只是每时刻这10个同时处理的事务,而到底是有10个人还是1000个人,区别不大(暂不考虑session等问题)。

      下面再从用户的视角来看看。实际的情况中,不可能出现很多用户同一时刻开始进行操作的场景,而是有一定的时间顺序的。正如下图所示,在这个时间段内,一共有23个用户进行了操作。


      但是服务器能看到这些用户么?它知道的只是某一个时间点上,有多少个正在执行的事务。大家可以数一下,此图中任意时刻的并发事务依然是10个。

      其实这两个图描述的本来就是同一个场景,只不过观察者的视角不同罢了。

      那么大家想想,在性能需求中最常见到的“并发用户”到底是指的什么呢?

    并发用户

      很多使用“并发用户”这个词的人,并没有从服务器视角进行考虑。他们想的是坐在电脑前使用这个系统、对系统产生压力的人的个数。基于这个原因,我很少使用这个容易让人误解的词汇,而是进行了更细的划分。主要有这么几个:系统用户数(注册用户数)、在线用户数(相对并发用户数)、绝对并发用户数。

      上面几个例子中所说的“并发用户”,实际就是在线用户数。其实我更喜欢叫做相对并发用户数,因为这个词更容易让人感受到“压力”。相对并发用户数指的是,在一个时间段内,与服务器进行了交互、对服务器产生了压力的用户的数量。这个时间段,可以是一天,也可以是一个小时。而需求人员必须要描述的,也正是这个内容。

      而绝对并发用户,主要是针对某一个操作进行测试,即多个用户同一时刻发起相同请求。可以用来验证是否存在并发逻辑上的处理问题,如线程不安全、死锁等问题;也可提供一些性能上的参考信息,比如1个用户需要1秒,而10个用户并发却需要30秒,那很可能就会有问题,需要进行关注,因为10个用户请求排队处理也应该只需要10秒啊。但这种绝对并发的测试,同实际压力下的用户体验关系不大。

      再回到相对并发这个概念上来,它与服务器的压力到底是什么关系呢?如果你理解了前面的所有内容,那么就会知道这两者其实没有直接联系(当然了,同一个测试用例中,肯定是用户数越多压力越大)。也就是说,你得到的这种性能需求,是无法知道服务器到底要承受多大压力的。

      那么如何开展性能测试?

    如何模拟压力

      既然我们知道了所谓的压力其实是从服务器视角来讲的,服务器要处理的事务才是压力,那么我们就从这出发,来探寻一下性能测试需要的信息。依然用之前的小论坛为例,我们需要测试活跃用户为500人时,系统的性能是否能还能提供良好的用户感受。

      假设现在的活跃用户有50个人(或者通过另一个类似的系统来推算也行),平均每天总的发帖量是50条、浏览帖子500次,也就是每人每天发一个帖子、浏览十个帖子(为了方便讲解,假设论坛只有这两个基本功能)。那么我们就可以推算,活跃用户达到500时,每天的业务量也会成比例的增长,也就是平均每天会产生500个新帖子、浏览帖子5000次。

      进一步分析数据,又发现。用户使用论坛的时间段非常集中,基本集中在中午11点到1点和晚上18点到20点。也就是说每天的这些业务,实际是分布在4个小时中完成的。

      那我们的测试场景,就是要用500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量。

      注意上面的两处,“平均每天……”、“分布在4个小时……”。敏感的测试人员应该能发现,这个场景测的是平均压力,也就是一个系统最平常一天的使用压力,我喜欢称之为日常压力。

      显然,除了日常压力,系统还会有压力更大的使用场景,比如某天发生了一件重要的事情,那么用户就会更加热烈的进行讨论。这个压力,我习惯叫做高峰期压力,需要专门设计一个测试场景。

      这个场景,需要哪些数据呢,我们依然可以从现有的数据进行分析。比如上面提到的是“平均每天总的发帖量……”,那么这次我们就要查到过去最高一日的业务量。“分布在4个小时”也需要进行相应的修改,比如查查历史分布图是否有更为集中的分布,或者用更简单通用的80-20原则,80%的工作在20%的时间内完成。根据这些数据可以再做适当的调整,设计出高峰期的测试场景。

      实际工作中可能还需要更多的测试场景,比如峰值压力场景。什么是峰值压力呢,比如一个银行网站,可能会由于发布一条重磅消息使访问量骤增,这个突发的压力也是性能测试人员需要考虑的。

      需要注意高峰期压力和峰值压力的区别,高峰期压力是指系统正常的、预期内压力的一个高峰。而峰值压力是指那些不在正常预期内的压力,可能几年才出现一次。

      这里只是举了个最简单的例子,实际工作远比这复杂的多。需要哪些数据、如何获取,很可能要取得这些数据就要花费很大的功夫。这其实就涉及到了一个很重要的内容,用户模型和压力模型的建立,以后会有专门的文章进行讲述。

      为什么要花这么大的精力来收集这些信息呢?是因为只有通过这些有效的数据,才能准确的去模拟用户场景,准确的模拟压力,获取到更加真实的用户体验。只有这样,“不同的测试人员,测出相同的结果”才会有可能实现,而且结果都是准确有效的。

    要点回顾

      ● 最后通过几个小问题来总结回顾一下:

      ● 你真的理解“并发用户”的意义么?

      ● 什么是用户视角和服务器视角?

      ● 什么是压力?

      ● 如何模拟预期压力?

     

    性能测试新手误区(四):一切来自录制

     

      经常会有性能测试新手问这样的问题:

      C/S的系统如何录制,应该选择什么协议呢?

      待测系统A的一个功能,是由B系统调用的,也需要搭建B系统的测试环境并对其录制么?

      我的回答是,先弄清楚你想测的是什么?对它而言,压力又是什么?

      新手总是想着如何录制客户端的操作,如何模拟客户端的点击。这种想法应该是受到了主流测试工具影响,性能测试的入门基本都是从工具开始,比如使用最广的LR,其最方便好用的功能应该就是录制了。但是需要清楚的是,录制只是为性能测试提供便利的一个功能(可以傻瓜式的产生向服务器施加压力的脚本),录制本身并不是性能测试的根本或者所必需,能够产生压力的那些脚本或是程序才是关键所在。

    第一个问题,比如一个即时通讯类的软件如何测试?

      首先要明确你想测的是客户端还是服务端,如果是服务端,那么服务端承受的压力是什么呢?

      是每一条消息都要经过服务器么?

      服务器是要将消息进行存储,还是仅仅转发?

      不同的功能,如普通会话和多人会话,从服务端来看的区别是什么?

      客户端是如何同服务端通信的,是采用了一些标准的开源协议(如XMPP),还是经过了自己的重新扩展?

      ……

      为了回答那两个看似很简单的问题(想测什么?压力是什么?),其实你需要了解整个系统的运行方式。这些信息完全可以从一些设计文档或者开发人员的口中获取到,并不需要你能读懂源码。

      如果我知道了这个软件使用了XMPP协议,一条普通的会话是客户端向服务器发送了这样一条信息:


     而多人会话是客户端发送了这样的信息:

    那么应该会知道,表面上这些不同的功能,其实只是客户端发送信息中个别字段的区别而已。那么我就可以想办法直接向服务器发送这些信息,让服务器根据接收信息的内容去完成相应的功能。也许根本没有必要去想如何录制客户端发起一个会话并发送消息这个动作,或者发送文件、群消息等等其他操作。

      至于如何实现,如果你有编码能力,可以将开源代码引入到自己的测试代码中(需是标准协议),否者可能需要让程序的开发人员实现一个测试程序。不要不敢开口,开发人员协助进行性能测试是很正常的,而且这种工作量不会很大,只是把程序中的一些代码封装成一个可配置可方便调用的执行文件。

      让开发人员来实现测试工具不丢脸,怕的是你自己不知道测试工具应该实现成什么样。(当然,如果自己可以看源码来实现工具那就更好了)

    第二个问题,同样的,所谓的B系统调用A系统这个动作,是如何实现的?

      会不会只是一个简单的HTTP请求?

      或者是调用A系统的一个webservice接口?

      你要测的是A的这个功能么?

      如果是,那我们为什么一定要通过B系统来录制这A的这个功能呢?完全可以直接向A发送请求或者是调用接口(如LR中的webservice协议)。

      至于具体如何做,可能有很多现成的接口测试工具,也可能仍然需要开发人员的协助。比如B与A之间传递的数据是经过加密的,那对(黑盒)测试来说就会非常困难,这种情况下,确实有可能通过B来录制会更简单。

    在51Testing上看到的一个问题,问如何测试一个统计报表的另存为(excel)功能。

      点这个按钮后,服务器会生成一张报表,然后弹出浏览器的另存为对话框,保存为本地文件。提问题的这个人遇到的困难是,LR中好像没法录制“另存为”这个动作。

      之所以会有这样的问题,根本原因还是没有理解系统的运行原理,没有区分哪是服务器、哪是客户端。

      一般来说,这个过程是这样的:

      1、点另存为按钮时,向服务器发送了一个计算报表的请求,这个请求中会包含一些参数,如报表类型、统计时间等等。

      2、服务器计算完成后,将结果数据返回给客户端(浏览器)。

      3、浏览器本身的功能,将数据保存为一个本地文件。

      (这里假设了计算过程是另存为按钮触发的,如果是打开页面时就计算完,那点按钮时甚至有可能根本没与服务器进行交互)

    如果明白了这个过程,那么就不会纠结于录制“另存为”这种事情了,你要做的只是向服务器发送一个请求,然后接收响应数据。

      那么就不需要生成本地文件了么?当然不是,否则怎么验证返回的数据没有问题呢。只不过这个文件的操作需要自己来实现了,创建文件、写入数据、关闭文件。

    最后再总结一下要点:

      ● 理解系统的运行原理

      ● 区分服务端和客户端

      ● 弄清楚你要测的是什么,哪些东西其实是可有可无的

      ● 要模拟的是服务器的压力,而不是客户端的操作

      ● 录制只是一种手段,很多情况下并不是最佳选择

      ● 开发人员的协助是应当的,但前提是你要明确的知道应该如何测试

     

    性能测试新手误区(五):如何提出一个好的性能问题

     

      经常会见到新人提出这样的性能问题:

      “100用户时,A操作响应时间达到了XX秒,请修改。”

      面对这样的问题,开发人员一定会觉得很无助,他们甚至不知道问题是什么。

      即使从测试人员的角度来看,这也算不上是一个合格的问题。

      那么一个好的性能问题应该是什么样呢?

      好问题要描述清晰

      100个用户,是指绝对并发操作么?还是什么样的场景?

      是只测这一个A操作?还是有多个操作在同时进行?

      如果有多个操作,是只有这一个操作变慢?还是普遍变慢?

      测试环境是什么样的?测试数据量是多少?

      也许开发人员理解了详细的测试场景后,会告诉你,这个场景在业务中是不可能的,或者测试数据量是不合理的。

      好问题要有尽量准确的定位

      只是描述清晰还不够,要明白什么是表面现象,什么才是问题。

      问题是需要定位才能发现的。

      “100个用户操作时,A事务的响应时间过长”,这只是一个现象,问题是什么呢?

      响应慢是慢在哪?是中间件还是数据库?这是最基本的分层定位。

      是服务器达到了硬件瓶颈么?如果硬件或操作系统上没有瓶颈,那么瓶颈在哪?

      是不是由于一些基本配置问题导致了排队呢?比如中间件的HTTP线程数和数据库的连接数。

      如果基本配置没有问题,那么再深入一些,是内部的哪些资源产生了争用和等待么?

      是哪些SQL引起了数据库内部资源的争用呢?应用程序上又是哪个方法在占用资源呢?

      ……

      定位的越深入,需要的技术能力也就越高。

      好问题应该用最简单的手段复现

      比如上面的100个用户,导致了数据库的一张表的争用,因此产生了大量锁等待现象,最终导致了外部的A响应时间过长。但是通过之前的分析和定位,我们发现也许引发问题的那些SQL语句,只来自100用户中的10个特殊类型的用户。那么这个问题就完全可以简化成用10个用户去复现,其他90个用户都是干扰。这样问题被简化了,开发人员也就更容易理解问题,对于测试的复测也更加方便。

      不过还是要记住,最终的用户场景模拟才是决定性的验证。

    最后再总结一下,性能问题到底应该如何提呢?其实只有一个标准,那就是能让开发理解问题、找到根本原因并进行修正的就够了(假设开发人员无所不能)。再进一步深入的分析,可能是为了减轻开发的一些负担,也可能是为了锻炼自己的能力,这就不是每个测试人员都会去做的了。

     

    性能测试新手误区(六):性能监控

     

     “数据库(或中间件)非常慢了,如何监控它的性能”

      “你想得到什么性能指标?”

      “就是……内部的性能指标”

      收到性能测试人员这样的问题后,通常会发生上面的对话。

      我的观点是,准确的说出你想要做什么,比你会不会做更重要。

      那么对于性能测试人员来说,”性能监控“这门必修课,该从何下手呢?

      监控什么

      如果我给你一个黑盒子,告诉你里面是一部机器,要监控它的性能。你能做到么?当然不能。因为你不知道这部机器如何运行,你不知道对它而言性能是什么。

      性能测试也一样,说到操作系统,大家都知道性能指标要看CPU、MEMORY、DISK IO以及NETWORK等等。但是到了数据库和中间件,如果测试人员说不出具体内容,这表明他不知道针对这个对象,性能是什么,即便把最完整的性能指标摆在面前,恐怕也是没有意义的。

      当然知识和经验是一步步积累起来的,但也需要测试人员去主动的学习。从系统体系结构、运行原理到性能监控、性能调优基础和方法,官方手册总是最好的教材。

      那么在没有掌握这些知识之前,我希望上面的问题是这样问,“数据库(或中间件)非常慢了,一般需要监控它的哪些性能指标呢”,得到回答后赶紧翻资料吸收相关的知识。

      过程中的监控

      性能测试新手容易忽略测试过程中的性能监控,而只给出一个最终的测试运行结果。

      比如这个问题,“测试运行3小时后,系统没有响应,中间件无法连接”。

      对于这样的问题,期望开发人员如何处理呢?中间件已经无法连接,想获取到一些内部的性能指标恐怕都已做不到。只有重运行一次,让开发人员来关注过程中的运行状况,但这本应是由测试人员来做的。

      如果我们知道,中间件本身无法响应一般可能是因为这两个问题:

      JVM堆内存用满,不停的进行GC,导致响应超慢(但是还没有OOM,否则就报错了)

      处理HTTP请求的线程,都被占用或者锁住

      那么我们就可以在测试过程中去监控这两项数据,跟踪变化趋势,直到系统再次无法响应。如果正好其中的一个资源也耗尽了,那么就可以确认“无法响应“这个现象的直接原因。实际上,这两个指标基本也是中间件最重要的指标,理应每次测试过程都进行监控和数据采集了。

      监控的层次

      系统的性能表现会涉及到多个层面,比如:

      中间件 -> 中间件操作系统 -> 数据库 -> 数据库操作系统 -> 客户端

      监控时也要着眼于多个层面,这样才有可能更接近问题的本质。还是上面那个中间件无法响应的问题,假设我们观察到了所有HTTP线程都被占用,也许更进一步我们又会发现这些线程都在执行数据库的查询,而这些查询在数据库中的状态依然是running,那就说明更根本的原因是在数据库层面。这也就是问题的逐步定位。

      全面的监控

      片面的数据不足以说明问题,系统的方方面面常常是相互影响的。

      比如数据库的CPU占用很高,并不能证明系统是计算密集型、CPU是瓶颈,也有可能是spinlock的争用导致了CPU骤增。

      再比如大量的page-in IO可能会使内存出现瓶颈。

      上面的层次问题其实也属于”全面“的范围。只有拿到全面的数据,才有可能分析出正确的结论。

      当然,这又是一个需要积累的过程,如果连spinlock都不知道,又怎么可能有准确的判断呢。

      方法还是一个,主动的学习,系统的学习。

     

    性能测试新手误区(七):你需要调优么

     

      测试人员喜欢在得到某个达不到预期的性能结果后,进行一下“调优”。

      PM有时也会布置任务,测试完成后“调一个优”。

      一些人貌似有了这种观念:调优才使性能测试有意义、性能测试的目的就是调优、做调优才能显出测试人员的水平……

      随着经验的增长和对性能更深入的认识,我越来越体会到调优是一个复杂的过程,不是动动嘴、改俩个参数这么简单,只有通过科学的方法和扎实的技能才能做好,以至于我使用这个词的频率越来越低,因为不敢轻易说出口……

      在你再一次调优之前,先考虑以下几个问题:

      为什么需要调优

      如果问起这个问题,得到的回答通常是“因为性能不够好”,那么接下来我会问性能不好体现在哪里?你要调什么?希望得到什么结果?

      如果你不能足够准确的回答第一个“体现在哪里”的问题,后两个也一定没有答案,所谓的调优自然也无从谈起。而这第一个问题的答案其实也就是定位的过程。

      举一个小例子。如果我已经发现数据库较慢,通过进一步监控又发现了一个cache的spinlock contention这个指标超过了正常的范围。那么我会猜测可能是这块缓存的争用导致了数据库的运行状况变差,针对这个现象我知道可以通过将cache分区来减少争用,改变配置后再重新测试和监控,这就可以算是一次调优的尝试。

      但如果你只停留在数据库慢的这个层面上,又怎么能进行调优呢?

      所以,需要调优的一个前提是“定位到问题”或者“发现了瓶颈”。

      又有人说了,没有问题为什么不能调优?没有问题,我们可以让系统变得更好!

      但是,所谓的“更好”如何衡量?“好”到什么程度时不需要继续“好”了呢?

      请记住,瓶颈永远存在,消灭了一个,就必然会引入另一个。

      调优的目标也不是“没有瓶颈”,而是系统在其所承受的压力下,性能表现足够好,那就够了!

      “足够好”其实也就是没有问题。

      调优调什么

      理解了上面的内容,这个问题的答案就很明显,调优必然是针对具体的问题或瓶颈。

      而问题和瓶颈,指的是“性能不好”这个现象的直接原因,而不是那些不痛不痒的其他因素。

      好比奥拓比奥迪跑得慢,最主要的问题在于发动机(不懂车,随便一说),而不是奥拓车的外型不够流线、轮胎抓地不够好……

      如果把精力放在改善外型、轮胎这些方面上,确实会让奥拓变得更“快”,但是从原问题(比奥迪慢)上来看,这都是没有意义的。

      至于如何准确的定位出问题,针对问题又如何下手,这就是技术能力,只能依靠不断的学习、长期的积累了。

      不过依然存在一些比较科学的工作方法,可以让你尽快的抓住重点。如在系统运行正常时采集一份足够完整的性能指标作为基准,当出现状况时再次采集一份相同的指标,对比其中的差异,从差异处入手。

      经常见到这种人,一听到数据库慢,直接加大内存分配、加缓存、加连接数、加大各种资源配置……典型的胡乱“调优”。

      调优的层次

      同一个问题,可能可以从多个方面进行处理。

      一个慢SQL,优化的方式可能是加个索引、绑定缓存、改写SQL、表分区、甚至是升级硬件。

      资源争用问题,既可以从配置层面进行优化、减小争用发生的机率,又可以从程序的实现方式上做改变、从源头上避免争用。

      假设多种处理方式,都可以满足期望,那么应该从哪个层面下手呢?

      这就需要考虑到工作量、效果、隐患等多种因素,当然也不排除几种优化共同作用。

      调优有效么

      这是一个工作方法是否科学的问题。

      每一次试验,都需要能够验证是否有效。有效的保留,无效的则复原。

      除了对原问题的验证,还必须确认对其他部分是否产生了副作用。理论上这就需要在每一次调优尝试后,进行一次足够全面的复测。

      否则,很容易出现“拆东墙补西墙”的问题。

      记住以下几个要点:

      ● 每次只改变一处。

      ● 每次改变后进行复测。有效的保留,无效的复原。

      ● 不断的迭代,直到达到预期。

    只有真正理解调优的目的,并按照科学的方法行动,你的努力才会体现出价值。

     

    性能问题的分析定位方法

     

    主要讲一个有效的性能问题应该是什么样的,其中提到了定位的问题。但是那篇文章只说了WHAT,并没有说HOW,只说tester要有明确的定位,却没提如何才能定位。实际工作中,我也总是接到这种问题,所以还是要写一篇关于方法的文章,来说说HOW TO DO。

      以一个典型的WEB系统来举例,性能问题一般体现在客户端请求后的响应时间上。在性能测试过程中,即压力增大到某个程度后,响应时间指标迅速增长。但如那篇文章所说,这只能叫做一个现象,测试人员需要找到问题所在,HOW TO DO?

      首先要搞清楚,客户端从发出请求直到看到最终结果,共经历了哪些过程。如果绘制出一张完整的路径图,我们的问题必将定位到这张图中的某一点上。下面是我画的一个常见的WEB系统请求的流转过程。


      客户发出一个请求,这个请求首先会到达中间件的监听端口,专门的监听线程负责接待它,并将它分配给一个空闲的HTTP处理线程。HTTP线程根据请求内容,去执行相应的程序代码,这里会涉及程序的内部资源,比如专用的线程、一些队列等,程序的内部也许还有多个组件,依然可以拆分。再往后,从中间件维护的数据库连接池中取出一个空闲连接,通过它来与数据库进行交互。数据库收到查询请求后,同样需要找到一个可用的执行线程,然后才能执行具体的SQL,这里又会牵扯到很多数据库的内部资源,如锁、缓存等等。

      可以看到,从用户点击鼠标发出请求,到显示器上展现出结果,实际是经过了很多处理过程的,这里的每一个节点出现问题,都会导致我们最终看到的“响应慢”现象出现(这里不考虑操作系统层面、网络层面等一些外层的因素)。

      理解了这个过程,只需采取一些科学的方法即可逐渐逼近问题根源,那就是层层剥离、不断排除。从实际经验来看,数据库端最容易出问题,那么首先就要对其进行验证。数据库的性能一般是直接体现在SQL的执行效率上,我们可以捕获到出现问题时所有执行过的SQL,看其耗时是否正常。如果判断数据库端没有问题,那么再来到中间件端,这里又可分为应用服务器本身和我们自己的程序,可以先看看最容易验证的部分,应用服务器本身通常维护了一些线程池,很容易可以观察到它们的使用情况,如果这里没有发现异常,那么问题很可能就出现在我们程序的代码内部。如果在某一点上发现了异常现象,不要急于断定这里就是问题根源,而是要同时观察与之相邻节点的表现,一个节点的故障通常也会导致另一节点的异常。

      一个很有效的排查手段就是日志,在每一个节点上输出接收到的请求和处理结果的日志,通常都会很容易的发现问题。

      大致思路就是这样,总结起来其实很简单。一是要理解请求处理的完整流程,二是通过科学合理的方法去分析。

      最后推荐个比较典型的问题排查过程供大家体会,超级奇怪的“黑色10秒钟”。我自己也有一些这种很有代表性的分析过程,有时间整理好也贴上来。

     

     ***********************************************

    `弄清目的后请开发协助。

    `日常压力&高峰期压力&峰值压力

    `spinlock中文译名为“自旋锁”。是专为防止多处理器并发而引入的一种锁。使得当我们在修改某个重要的资料结构时,不能被中断,即使被中断了,这个资料结构由于还没修改完,别的行程也都不能去读取和修改它。

     


    展开全文
  • 2021年软件测试面试题大全

    万次阅读 多人点赞 2020-11-30 15:16:59
    简述测试流程: 1、阅读相关技术文档(如产品PRD、UI设计、产品流程图等)。 2、参加需求评审会议。 3、根据最终确定的需求文档编写测试计划。 4、编写测试用例(等价类划分法、边界值分析法等)。 5、用例评审...

    目录

     

    一、面试基础题

    简述测试流程:

    什么是软件测试?软件测试的目的与原则

    问:软件生存周期及其模型是什么?

    什么是软件质量?

    自动化测试脚本开发的主要步骤:

    目前主要的测试用例设计方法是什么?

    常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

    测试的策略有哪些?

    单元测试的策略有哪些?

    正交表测试用例设计方法的特点是什么?

    软件的安全性应从哪几个方面去测试?

    需求测试的注意事项有哪些?

    问:你在测试中发现了一个  bug ,但是开发经理认为这不是一个  bug ,你应该怎样解决。

    问:给你一个网站,你如何测试?

    问:一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压,有什么区别? ?

    软件的安全性应从哪几个方面 去测试?

    软件质量保证体系是什么 国家标准中与质量保证管理相关的几个标准是什么? ? 他们的编号和全称是什么? ?

    测试人员在软件开发过程中的任务是什么?

    在您以往的工作中,一条软件缺陷(或者叫 Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    黑盒测试和白盒测试是软件测试的两种基本方法,请分别说明各自的优点和缺点!

    什么是系统瓶颈?

    手机APP测试

    什么是并发?在lordrunner中,如何进行并发的测试?集合点失败了会怎么样?

    详细的描述一个测试活动完整的过程。

    在您以往的工作中,一条软件缺陷(或者叫  Bug )记录都包含了哪些内容?如何提交高质量的软件缺陷( Bug )记录?

     您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员 良好的人际关系的关键是什么?

    软件测试项目从什么时候开始?为什么?

    测试结束的标准是什么?

    您是否了解以往所工作的企业的软件开发过程?如果了解,请试述一个完整的开发过程需要完成哪些工作?分别由哪些不同的角色来完成这些工作?您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

    请你回答一下性能测试有哪些指标,对一个登录功能做性能测试,有哪些指标,怎么测出可同时处理的最大请求数量

    什么是兼容型测试?兼容性测试侧重哪些方面?

    软件测试项目从什么时候开始,?为什么?

     

    二、测试实战面试题

    我现在有个程序,发现在Windows上运行的很慢,怎么判别是程序存在问题还是软硬件系统存在问题

    一个程序有n个变量采用边界值分析可以产生几个测试用例

    请设计一个关于ATM自动取款机的测试用例。

    如何测试一个 纸杯?

    我手上这支笔,请你根据这支笔设计测试用例

    测试手机开机键 

    如何回答登录功能怎么进行测试?

    如何回答京东购物车功能怎么进行测试?

    支付流程测试

    对于有系统大量并发访问,你会如何做测试,有什么建议

    请对这个系统做出测试用例:一个系统,多个摄像头,抓拍车牌,识别车牌,上传网上,网上展示

    请你说一说PC网络故障,以及如何排除障碍

    微信红包

    微信发朋友圈点赞

    如何对淘宝搜索框进行测试

    就linux下的CP命令设计测试用例。

    请问如果用户点击微博的关注图标但是app上面没有反应,应该怎么排查这个问题

    现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

     

    三、基础知识点

    什么是桩模块?什么是驱动模块?

    什么是扇入?什么是扇出?

    8020原则:在需求分析开始到集成测试阶段引入测试手段,能发现所有缺陷的80%,系统测试阶段发现16%,在运行维护阶段经过长时间大量运行软件后,能够发现4%。起源于经济学。

    什么是耦合?什么是内聚?

    缺陷严重程度:

    缺陷优先级:

    缺陷状态:

    简单的软件缺陷生命周期:

    复杂的软件缺陷生命周期:

    什么是在线用户数?什么是并发用户数?

    分布式软件架构分为:

    测试人员的能力:

    简述负载测试与压力测试的区别。

    软件缺陷管理工具有哪些

    弱网测试

     

    四、智力题


    一、面试基础题

    简述测试流程:

    • 1、阅读相关技术文档(如产品PRD、UI设计、产品流程图等)。
    • 2、参加需求评审会议。
    • 3、根据最终确定的需求文档编写测试计划。
    • 4、编写测试用例(等价类划分法、边界值分析法等)。
    • 5、用例评审(主要参与人员:开发、测试、产品、测试leader)。
    • 6、开发提交代码至SVN或者GIT ,配管搭建测试环境。
    • 7、执行测试用例,记录发现的问题。
    • 8、验证bug与回归测试。
    • 9、编写测试报告。
    • 10、产品上线。

    补充测试用例设计过程:
    
    根据需求得出测试需求
    
    设计测试方案,评审测试方案
    
    方案评审通过后,设计测试用例,再对测试用例进行评审

     

    什么是软件测试?软件测试的目的与原则

    使用人工或自动手段,来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

    软件测试的目的:

    • 测试是程序的执行过程,目的在于发现错误。
    • 一个成功的测试用例在于发现至今未发现的错误。
    • 一个成功的测试是发现了至今未发现的错误的测试。
    • 确保产品完成了它所承诺或公布的功能,并且用户可以访问到的功能都有明确的书面说明。
    • 确保产品满足性能和效率的要求。
    • 确保产品是健壮的和适应用户环境的。

     

    问:软件生存周期及其模型是什么?

    软件生存周期是软件开发全部过程、活动和任务的结构框架,是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。在经历需求、分析、设计、实现、部署后,软件将被使用并进入维护阶段,直到最后由于缺少维护费用而逐渐消亡。这样的一个过程,称为"生命周期模型"(Life Cycle Model)。

     

    什么是软件质量?

    软件质量:软件产品的特性可以满足用户的功能、性能需求的能力。

     

    自动化测试脚本开发的主要步骤:

    1、通过某些方式定位到我们要执行的对象、目标( Target)

    2、对这个对象进行什么操作(command)

    3、通过操作对定位到的元素赋值(value)

    4、添加断言操作

     

    目前主要的测试用例设计方法是什么?

    白盒测试:

    • 逻辑覆盖
    • 循环覆盖
    • 基本路径覆盖

    黑盒测试:

    • 边界值分析法
    • 等价类划分
    • 错误猜测法
    • 因果图法
    • 状态图法
    • 测试大纲法
    • 随机测试场景法

     

    常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

    1)等价类划分划分

    等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。

     

    2)边界值分析法

    边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设(面试题目:什么样的工作环境适合你&#from一个常见的软件测试面试题来自end#lt;结束)计测试用例,可以查出更多的错误。

     

    使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

     

    3)错误推测法

    基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。

    错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如,在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等,这些就是经验的总结。还有,输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

     

    4)因果图方法

    前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等。考虑输入条件之间的相互组合,可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图(逻辑模型)。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

     

    5)正交表分析法

    有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。

     

    6)场景分析方法

    指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。

     

    测试的策略有哪些?

    黑盒/白盒/灰盒,静态/动态,手工/自动,冒烟测试,回归测试,公测(Beta测试的策略)

    补充:公测是什么?还有没有其他的测试策略?测试策略和测试方法以及测试类型有什么区别?

    按测试 策略分类:
      1、静态与动态测试
      2、黑盒与白盒测试
      3、手工和自动测试
      4、冒烟测试
      5、回归测试;
      按测试阶段分类:单元测试、集成测试、系统测试;
      其他常见测试方法:1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测12、恢复测试

    α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha 测试不能由程序员或测试员完成。

    β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta 测试不能由程序员或测试员完成。

    回归测试(对软件的新版本测试时,重复执行上一个版本测试时的用例,是为了验证缺陷是否真正修复,确认修复后是否影响其它功能);

    冒烟测试:对新版本测试之前,先验证下软件的基本功能是否实现,是否具备可测性。

     

    单元测试的策略有哪些?

    逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

     

    正交表测试用例设计方法的特点是什么?

    答:用最少的实验覆盖最多的操作,测试用例设计很少,效率高,但是很复杂;对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来;但是更深的缺陷,更复杂的缺陷,还是无能为力的;具体的环境下,正交表一般都很难做的。大多数,只在系统测试的时候使用此方法。

    补充:什么时候用系统测试,测试的每个阶段是什么,比如单元、集成、系统、公测,每个阶段需要什么技术,有什么要求

     

    软件的安全性应从哪几个方面去测试?

    • (1) 用户认证机制:如数据证书、智能卡、双重认证、安全电子交易协议
    • (2) 加密机制
    • (3) 安全防护策略:如安全日志、入侵检测、隔离防护、漏洞扫描
    • (4) 数据备份与恢复手段:存储设备、存储优化、存储保护、存储管理
    • (5) 防病毒系统

    软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

    用户认证安全的测试要考虑问题:

      • 明确区分系统中不同用户权限
      • 系统中会不会出现用户冲突
      • 系统会不会因用户的权限的改变造成混乱
      • 用户登陆密码是否是可见、可复制
      • 是否可以通过绝对途径登陆系统(拷贝用户登陆后的链接直接进入系统)
      • 用户退出系统后是否删除了所有鉴权标记,是否可以使用后退键而不通过输入口令进入系统
      • 系统网络安全的测试要考虑问题
      • 测试采取的防护措施是否正确装配好,有关系统的补丁是否打上
      • 模拟非授权攻击,看防护系统是否坚固
      • 采用成熟的网络漏洞检查工具检查系统相关漏洞(即用最专业的黑客攻击工具攻击试一下,
      • 现在最常用的是 NBSI 系列和 IPhacker IP )
      • 采用各种木马检查工具检查系统木马情况
      • 采用各种防外挂工具检查系统各组程序的外挂漏洞

    数据库安全考虑问题:

      • 系统数据是否机密(比如对银行系统,这一点就特别重要,一般的网站就没有太高要求)
      • 系统数据的完整性(我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整,对于这
      • 个系统的功能实现有了障碍)
      • 系统数据可管理性
      • 系统数据的独立性
      • 系统数据可备份和恢复能力(数据备份是否完整,可否恢复,恢复是否可以完整)

     

    α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环

    境下进行的受控测试,Alpha 测试不能由程序员或测试员完成。

    β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在

    测试现场,Beta 测试不能由程序员或测试员完成。

    需求测试的注意事项有哪些?

    •        是否使用了公司的模板
    •   文档内容是否符合规范
    •   所有的需求是分级是否清析适当?
    •   所有的需求是否具有一致性
    •   需求是否可行(即,该需求组合有解决方案)
    •   需求可否用己知的约束来实现
    •   需求是否足够(即,可以把它送到一个规范的开发组织,并有一个生产出所需要产品的合理的可能性)
    •   所有的其它需求是交叉引用是否正确
    •   用户描述是否清楚
    •   是否用客户的语言来描述需求
    •   每个需求描述是否清楚没有岐义,可以移交给一个独立的组去实现时也能理解
    •   是否所有的需求都是可验证的
    •   是否每条需求都具有独立性,即使发生了变化也不会影响其它需求
    •   性能指标是否明确
    •   非功能性需求是否得到充分表现
    •   是否完整列出适用的标准或协议
    •   标准和协议之间是否存在冲突

    问:你在测试中发现了一个  bug ,但是开发经理认为这不是一个  bug ,你应该怎样解决。

    1. 将问题提交到缺陷管理库里面进行备案。
    2. 要获取判断的依据和标准:     根据需求说明书、产品说明、设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据;     如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否是缺陷;   根据用户的一般使用习惯,来确认是否是缺陷;
    3. 与设计人员、开发人员和客户代表等相关人员探讨,确认是否是缺陷;
    4. 合理的论述,向测试经理说明自己的判断的理由,注意客观、严谨,不参杂个人情绪。
    5. 等待测试经理做出最终决定,如果仍然存在争议,可以通过公司政策所提供的渠道,向上级反映,并有上级做出决定。

     

     

    问:给你一个网站,你如何测试?

    1、查找需求说明、网站设计 m 等相关文档,分析测试需求。

    2、制定测试计划,确定测试范围和测试策略,一般包括以下几个部分:

         功能性测试;界面测试;性能测试;数据库测试;安全性测试;兼容性测试

    3、设计测试用例:

         功能性测试可以包括,但不限于以下几个方面:

         链接测试。链接是否正确跳转,是否存在空页面和无效页面,是否有不正确的出错信息返回等。提交功能的测试。

         多媒体元素是否可以正确加载和显示。多语言支持是否能够正确显示选择的语言等。

         界面测试可以包括但不限于一下几个方面:

    • 页面是否风格统一,美观
    • 文字检查
    • 对于必须但为安装的空间,是否提供自动下载并安装的功能
    • 控件是否正常使用
    • 页面布局是否合理,重点内容和热点内容是否突出                                                       

     

    问:一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压,有什么区别? ?

    300 个用户在一个客户端上,会占用客户机更多的资源,而影响测试的结果。线程之间可能发生干扰,而产生一些异常。300 个用户在一个客户端上,需要更大的带宽。IP 地址的问题,可能需要使用 IP Spoof 来绕过服务器对于单一 IP 地址最大连接数的限制。所有用户在一个客户端上,不必考虑分布式管理的问题;而用户分布在不同的客户端上,需要考虑使用控制器来整体调配不同客户机上的用户。同时,还需要给予相应的权限配置和防火墙设置。

    你工作中遇到最具价值的bug,就是重大bug咯,例如app性能测试测哪些,那你就看一看性能测试的视频咯

     

    软件的安全性应从哪几个方面 去测试?

    软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

    用户认证安全的测试要考虑问题:

    • 明确区分系统中不同用户权限
    • 系统中会不会出现用户冲突
    • 系统会不会因用户的权限的改变造成混乱
    • 用户登陆密码是否是可见、可复制
    • 是否可以通过绝对途径登陆系统(拷贝用户登陆后的链接直接进入系统)
    • 用户退出系统后是否删除了所有鉴权标记,是否可以使用后退键而不通过输入口令进入系统
    • 系统网络安全的测试要考虑问题
    • 测试采取的防护措施是否正确装配好,有关系统的补丁是否打上
    • 模拟非授权攻击,看防护系统是否坚固
    • 采用成熟的网络漏洞检查工具检查系统相关漏洞(即用最专业的黑客攻击工具攻击试一下,
    • 现在最常用的是 NBSI 系列和 IPhacker IP )
    • 采用各种木马检查工具检查系统木马情况
    • 采用各种防外挂工具检查系统各组程序的外挂漏洞

    数据库安全考虑问题:

    • 系统数据是否机密(比如对银行系统,这一点就特别重要,一般的网站就没有太高要求)
    • 系统数据的完整性(我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整,对于这个系统的功能实现有了障碍)
    • 系统数据可管理性
    • 系统数据的独立性
    • 系统数据可备份和恢复能力(数据备份是否完整,可否恢复,恢复是否可以完整)

     

     

    软件质量保证体系是什么 国家标准中与质量保证管理相关的几个标准是什么? ? 他们的编号和全称是什么? ?

    SQA 由一套软件工程过程和方法组成,以保证(软件的)质量。SQA 贯穿整个软件开发过程,(它)应包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试。

     

    测试人员在软件开发过程中的任务是什么?

    1、寻找 Bug;

    2、避免软件开发过程中的缺陷;

    3、衡量软件的品质;

    4、关注用户的需求。

    总的目标是:确保软件的质量。

     

    在您以往的工作中,一条软件缺陷(或者叫 Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    一条 Bug 记录最基本应包含:编号、Bug 所属模块、Bug 描述、Bug 级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等;

    要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认

    肯定,然后再向外发布如此才能提高提交 Bug 的质量。

     

     

    黑盒测试和白盒测试是软件测试的两种基本方法,请分别说明各自的优点和缺点!

    黑盒测试的优点有:

           比较简单,不需要了解程序内部的代码及实现;与软件的内部实现无关;从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题;基于软件开发文档,所以也能知道软件实现了文档中的哪些功能;在做软件自动化测试时较为方便。

    黑盒测试的缺点有:

           不可能覆盖所有的代码,覆盖率较低,大概只能达到总代码量的 30%;自动化测试的复用性较低。

    白盒测试的优点有:

         帮助软件测试人员增大代码的覆盖率,提高代码的质量,发现代码中隐藏的问题。

    白盒测试的缺点有:

           程序运行会有很多不同的路径,不可能测试所有的运行路径;测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可能会漏掉一些功能需求;系统庞大时,测试开销会非常大。

     

     

    什么是系统瓶颈?

    参考答案:

    瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求,“特定”是指瓶颈会在某些条件下会出现,因为毕竟大多数系统在投入前。

    严格的从技术角度讲,所有的系统都会有瓶颈,因为大多数系统的资源配置不是协调的,例如CPU使用率刚好达到100%时,内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论:关键是看系统能否满足用户需求。在用户极限使用系统的情况下,系统的响应仍然正常,我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。

    因此我们测试系统瓶颈主要是实现下面两个目的:

    -发现“表面”的瓶颈。主要是模拟用户的操作,找出用户极限使用系统时的瓶颈,然后解决瓶颈,这是性能测试的基本目标。

    -发现潜在的瓶颈并解决,保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时,系统能够适应变化。满足用户目前需求的系统不是最好的,我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化,或者通过简单扩展系统就可以适应新的变化。

     

    手机APP测试

    :主要包括功能、性能测试、稳定性、兼容性、用户测试。

     

    性能测试:CPU占用/内存占用 /耗电测试 /流量消耗测试 /安装包大小 /加载时间测试 /核心功能相应时间 (①启动时间检测:检测App在终端上首次启动时间。 ②内存、CPU耗用检测:检测App在终端上运行时不同时段占用内存、CPU情况。 ③流量耗用检测:检测App在终端上运行时的网络流量消耗情况。 ④电池温度检测:检测App在终端上运行时,对终端的电池温度等性能指标的影响情况 )

     

    兼容性测试:屏幕分辨率 /网络状态,状态切换 /android版本 /安装卸载升级等 /权限设置 /与其他APP兼容性 (①安装卸载测试:测试App在指定终端上是否可正常安装、正常卸载,准确定位错误原因。 ②遍历测试:自动识别App可执行的功能,在一定时间内遍历App的不同功能界面,通过截图记录操作路径 并输出日志、定位异常现象。 ③运行稳定性测试:类似Monkey的随机性压力测试,测试App运行期的稳定性。 ④UI适配测试:测试App的UI与目标终端的屏幕是否适配,记录是否存在渲染失败、错位、黑边框、黑白屏等现象。)

     

    稳定性测试包括:服务器异常时稳定性 /外部事件影响(电话,短信等) /内存是否有溢出或者泄漏 /多线程问题 。

     

     

     

    什么是并发?在lordrunner中,如何进行并发的测试?集合点失败了会怎么样?

    参考答案:

    在同一时间点,支持多个不同的操作。

    LoadRunner中提供IP伪装,集合点,配合虚拟用户的设计,以及在多台电脑上设置,可以比较好的模拟真实的并发。

    集合点,即是多个用户在某个时刻,某个特定的环境下同时进行虚拟用户的操作的。集合点失败,则集合点的才操作就会取消,测试就不能进行。

     

     

    详细的描述一个测试活动完整的过程。

    答案:(供参考,本答案主要是瀑布模型的做法)

           项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后 SQA 进入项目,开始进行统计和跟踪开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。测试用例完成后,测试和开发需要进行评审。测试人员搭建环境开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现 BUG后提交给 BugZilla。开发提交第二个版本,包括 Bug Fix 以及增加了部分功能,测试人员进行测试。重复上面的工作,一般是 3-4 个版本后 BUG 数量减少,达到出货的要求。如果有客户反馈的问题,需要测试人员协助重现并重新测试。

     

    在您以往的工作中,一条软件缺陷(或者叫  Bug )记录都包含了哪些内容?如何提交高质量的软件缺陷( Bug )记录?

    在传统的 BugZilla 中,BUG 描述应该包括以下的信息和 BUG 产生对应的软件版本和模块开发的接口人员BUG 的优先级BUG 的严重程度BUG 可能属于的模块,如果不能确认,可以用开发人员来判断BUG 标题,需要清晰的描述现象BUG 描述,需要尽量给出重新 Bug 的步骤BUG 附件中能给出相关的日志和截图。高质量的 BUG 记录就是指很容易理解的 BUG 记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位,因此提交高质量的软件缺陷记录需要注意对 BUG 记录的描述质量多且准确。

     

     您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员 良好的人际关系的关键是什么?

           尽量面对面的沟通,其次是能直接通过电话沟通,如果只能通过 Email 等非及时沟通工具的话,强调必须对特性的理解深刻以及能表达清楚。运用一些测试管理工具如 TestDirector 进行管理也是较有效的方法,同时要注意在TestDirector 中对 BUG 有准确的描述。在团队中建立测试人员与开发人员良好沟通中注意以下几点:一真诚二是团队精神三是在专业上有共同语言四是要对事不对人,工作至上当然也可以通过直接指出一些小问题,而不是进入 BUG Tracking System 来增加对方的好感。

     

    软件测试项目从什么时候开始?为什么?

          软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.

     

    测试结束的标准是什么?

           从微观上来说,在测试计划中定义,比如系统在一定性能下平稳运行 72 小时,目前 BugTracking System 中,本版本中没有一般严重的 BUG,普通 BUG 的数量在 3 以下,BUG 修复率 90%以上等等参数,然后由开发经理,测试经理,项目经理共同签字认同版本 Release。如果说宏观的,则是当这个软件彻底的消失以后,测试就结束了。

     

    您是否了解以往所工作的企业的软件开发过程?如果了解,请试述一个完整的开发过程需要完成哪些工作?分别由哪些不同的角色来完成这些工作?您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

    开发过程---需求调研(需求人员)、需求分析(需求人员)、概要设计(设计人员)、详细设计(设计人员)、编码(开发人员)测试过程---需求评审、系统测试设计、概要设计评审、集成测试设计、详细设计评审、单元测试设计、测试执行测试工作的整个过程都做过,擅长做测试设计过程决定质量,软件的过程改进正是为了提高软件的质量,将过往的种种经验和教训积累起来。

    补充

    1.明确测试的目标,增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确

    2.坚持“5W”规则,明确内容与过程

    “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。

    3.采用评审和更新机制,保证测试计划满足实际需求

    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。分别创建测试计划与测试详细规格、测试用例,应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

     

    请你回答一下性能测试有哪些指标,对一个登录功能做性能测试,有哪些指标,怎么测出可同时处理的最大请求数量

    参考回答:

    性能测试常用指标:

    从外部看,主要有

    1、吞吐量:每秒钟系统能够处理的请求数,任务数

    2、响应时间:服务处理一个请求或一个任务的耗时

    3、错误率:一批请求中结果出错的请求所占比例

    从服务器的角度看,性能测试关注CPU,内存,服务器负载,网络,磁盘IO

    对登录功能做性能测试

    单用户登陆的响应界面是否符合预期

    单用户登陆时后台请求数量是否过多

    高并发场景下用户登录的响应界面是否符合预期

    高并发场景下服务端的监控指标是否符合预期

    高集合点并发场景下是否存在资源死锁和不合理的资源等待

    长时间大量用户连续登录和登出,服务器端是否存在内存泄漏

    怎么测出可同时处理的最大请求数量

    可以采用性能测试工具(WeTest服务器性能),该工具是腾讯wetest团队出品,使用起来很简单方便,但测试功能相当强大,能提供10w+以上的并发量,定位性能拐点,测出服务器模型最大并发

     

    什么是兼容型测试?兼容性测试侧重哪些方面?

    兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行,即是通常说的软件的可移植性。兼容的类型,如果细分的话,有平台的兼容,网络兼容,数据库兼容,以及数据格式的兼容。兼容测试的重点是,对兼容环境的分析。通常,是在运行软件的环境不是很确定的情况下,才需要做兼容。根据软件运行的需要,或者根据需求文档,一般能够得出用户会在什么环境下使用该软件,把这些环境整理成表单,就得出做兼容测试的兼容环境了

    兼容和配置测试的区别在于,做配置测试通常不是在Clean OS下做测试,而兼容测试多是在Clean OS环境下做的。

    补充:做兼容测试的具体步骤:在列好的软硬件环境清单做冒烟测试,还是每一步都测试。测出不兼容,怎么和开发沟通,开发面对这些不兼容需要做什么。如果修复成本很高,怎么和产品经理沟通。和谁确认表单

     

     

    软件测试项目从什么时候开始,?为什么?

    软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发

    过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费

    的成本就越大.

     

     

    二、测试实战面试题

     

    我现在有个程序,发现在Windows上运行的很慢,怎么判别是程序存在问题还是软硬件系统存在问题

    1、检查系统是否有中毒的特征

    2、检查软件/硬件的配置是否符合软件的推荐标准

    3、确认当前的系统是否独立,即没有对外提供什么消耗CPU资源的服务

    4、如果是C/S或者B/S结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成

    5、在系统没有任何负载的情况下,查看性能监视器,确认应用程序对CPU/内存的访问情况

    补充:每一步该怎么实现,需要用到什么技术

     

    一个程序有n个变量采用边界值分析可以产生几个测试用例

    4n+1

     

    请设计一个关于ATM自动取款机的测试用例。

    1)功能

    a)ATM所识别卡的类型;

    b)密码验证(身份登陆、是否为掩码、输入错误密码时是否提示,连续三次错误吞卡等);

    c)取款功能:

    i、金额多少的限制,单次最大最小提取金额、每天最大提取金额等);

    Ii、取款币种的不同,如人民币、美元、欧元等。

    d)是否提示客户操作完成后,打印相关操作信息;

    e)查询功能是否正常;

    f)转账功能是否正常;

    g)是否提示客户操作完成后,取回客户卡;

     

    2)性能

    a)是否有自动吞卡:非法客户\密码错误客户\规定时间内未完成相关操作功能的客户。(如果有,有无报警功能(保密报警))

    b)平均无故障时间,平均故障修复时间,输入密码后验证时间,出钞票时间,查询余额等待时间。

     

    3)易用性

    a)ATM各个操作功能(硬件)是否正常、易懂;

    b)ATM的界面显示是否友好;

    c)ATM是否支持英文操作;

    d)ATM是否存在异常(断电、黑客入侵)有自动保护(报警)功能;

     

    如何测试一个 纸杯?

    功能度:用水杯装水看漏不漏;水能不能被喝到

    安全性:杯子有没有毒或细菌

    可靠性:杯子从不同高度落下的损坏程度

    可移植性:杯子在不同的地方、温度等环境下是否都可以正常使用

    兼容性:杯子是否能够容纳果汁、白水、酒精、汽油等

    易用性:杯子是否烫手、是否有防滑措施、是否方便饮用

    用户文档:使用手册是否对杯子的用法、限制、使用条件等有详细描述

    疲劳测试:将杯子盛上水(案例一)放 24 小时检查泄漏时间和情况;盛上汽油(案例二)

    放 24 小时检查泄漏时间和情况等

    压力测试:用根针并在针上面不断加重量,看压强多大时会穿透

     

     

     

    我手上这支笔,请你根据这支笔设计测试用例

       首先我要测它的外观、颜色是否符合要求、所占的空间是多大、是否环保、接下来测它的质量、这支笔是否能够写字流畅、写出的自得颜色是否符合要求、能使用多长时间等

     

     

    测试手机开机键 

    功能测试:按下开机键,屏幕能否亮起

    性能测试:按下开机键,屏幕能否在规定时间内亮起

    压力测试:连续多次按下开机键,观察屏幕是否能一直亮起,到多久时间失灵

    健壮性测试:给定一个中了病毒的手机或者是淘汰许久的老机子,安歇开机键观察屏幕能否亮起

    可靠性测试:连续按下开机键有限次数,比如1万次,记录屏幕未亮起的次数

    可用性测试:开机键按下费不费力,开机键的形状设计是否贴合手指,开机键的位置设计是否方便

     

     

    如何回答登录功能怎么进行测试?

     

    首先,进行界面测试。

    查看界面上的所有元素是否齐全;

    没有输入内容时,是否有相应的提示语;

    验证码是否能够显示;

    移动鼠标,【登陆】按钮默认不能点击;

    【忘记密码】是否有个小问号“?”(其他都有);

     

    第二,进行功能测试。

    输入正确的用户名、密码、验证码,点【登陆】能登陆;

    输入正确的用户名、错误的密码、正确的验证码,提示用户名或密码错误;

    输入错误的用户名、正确的验证码,提示用户名或密码错误;

    输入正确的用户名、密码,错误的验证码,提示验证码错误;

    输入不符合规则的手机号或者邮箱应该提示错误;

    页面长时间不登陆和操作,验证码会不会过期;

    点【记住密码】,登录后退出,再次登陆是不是可以不输入密码;

    点【忘记密码】能够跳转到密码设置页面(至于是什么不用管,就是能不能跳转)

    只点击验证码图案,验证码能不能刷新;

    页面刷新,验证码图案能不能刷新;

    输入栏是否设置快速删除按钮;

    用户名和密码是否大小写敏感;

    用户名和密码前后有空格的处理;

    登陆成功,是否有记住密码功能;

    登陆失败后,不能记录密码的功能;

    新用户第一次登陆成功,是否有修改密码提示;

    用户登录过程中log中是否有个人信息明文打印;

    是否支持第三方登陆;

    刷新页面时是否会刷新验证码;

    输入密码的时候,大写键盘开启的时候要有提示信息  ;

    不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确;

     

    第三、业务安全测试。

    有没有登陆错误次数的限制;

    每次登陆错误之后有没有限制再次登陆的时间间隔;

    是否支持一个账号多地登陆;

    不同机型登陆,异地登陆是否有提醒  ;

    不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面;

     

    第四、兼容性测试。

    在相同浏览器的不同版本上打开登录页面,效果是否一致;在不同浏览器上打开登录页面,效果是否一致;在不同操作系统的不同浏览器打开登录页面,效果是否一致;在不同的屏幕分辨率下打开登录页面,效果是否一致;

     

    第五、代码安全性测试。

    用户输入登录信息登陆时,个人信息是不是会显示在浏览器地址栏;

    用户登陆的时候,通过抓包工具抓数据,密码是否加密;

    查看页面源代码,验证码是否直接显示在代码中;

    密码在后台储存时是否加密;

    是否可以使用登录的API发送登录请求,并绕开验证码校验;

    用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串,验证系统的返回页面;

    用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串,验证系统行为是否被篡改;

     

    第六、页面性能测试。

    单用户登录的响应时间是否小于3秒;

    通过工具向登录页发起大量请求,查看页面响应时间的变化;

    通过工具对登陆功能进行并发测试;通过工具向登录页发起大量请求,查看页面何时崩溃;

    通过工具向登录页发起大量请求,查看页面崩溃后有没有良好的提示信息;

    通过工具向登录页发起大量请求,查看页面崩溃后多长时间能够恢复服务;

    弱网,不同网速时登陆的时间,网络切换和网络延迟时登陆界面是否正常;

     

    最后、易用性测试。

    页面是否美观;

    功能是否都可以使用;

    页面速度快不快;

    页面元素加载是否耗费网络流量;

    能不能第三方登陆;

    为什么不使用手机验证码登陆;

    输入框能否可以以Tab键切换。

     

     

    如何回答京东购物车功能怎么进行测试?

     

    1.功能测试

    a)、未登录时:

    将商品加入购物车,页面跳转到登录页面,登录成功后购物车数量增加。

    b)、登录后:

    所有链接是否跳转正确;

    商品是否可以成功加入购物车;

    没有限购要求的商品,添加数量能不能超过库存数;

    购物车商品总数是否有限制;

    商品总数统计是否正确;

    全选功能是否可用;

    删除功能是否可用;

    删除功能是否有提示;

    价格总计是否正确;

    商品文字太长时是否显示完整;

    购物车中下架的商品是否有标识,是否还能支付;

    新加入购物车商品排序(添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品);

    是否支持快TAB、ENTER等快捷键;

    商品删除后商品总数是否减少;

    收藏功能是否可用;

    账号退出后,购物车添加的内容是否还在;

    购物车结算功能是否可用。

    限购商品按照规则购买完成后,还能不能再次添加购物车并购买;

    2.兼容性测试

    BS架构:不同浏览器测试,比如:IE,火狐,谷歌,360这些。

    APP:在主流的不同类型,不同分辨率,不同操作系统的手机上测试,华为,vivo,oppo等

    3.用户体验测试

    删除商品是否有提示;

    是否支持快捷键功能;

    是否有回到顶部的功能;

    商品过多时结算按钮是否可以浮动显示;

    购物车有多个商品时,能不能只对单个商品结算;

    界面布局、排版是否合理;

    文字是否显示清晰;

    不同卖家的商品是否区分明显。

    4.性能测试

    打开购物车页面要多长时间

     

     

    支付流程测试

    功能测试。

    用等价类和边界值,判断支付的金额;

    如果没有登陆能否支付,支付成功后是否可以正常跳转;

    支付方式是否支持扫码支付,第三方平台支付(支付包,云网等),语音支付,指纹支付;

    支付时是否需要身份验证,支付后有无手机短信提示,是否可以找他人代付;

    用边界值法有无支付额度限制,余额不足时有无提示,支付时是否是动态加密支付;

    待支付状态:订单是否可以正常支付;是否可以取消;有相同订单是否可以支付两次;

    是否可以扫码支付,输入错误的密码会怎样显示,有无错误次数限制;

    若支持扫码支付,二维码是否支持支付包和微信扫码,若两人同时扫描怎么处理;

    有无最小支付金额限制,无意义的支付金额0,重复支付如何处理;

    如果支付包含优惠金额,该怎么处理优惠额度;

     

    性能测试 

    弱网,无网时是否可以支付;

    退款到账时间,耗电量的多少;

    带负载情况下的响应时间和吞吐率,在某个时间段内同时访问系统的用户数量 ;

     

    压力测试

    多人同时付款;

    界面测试;

    支付界面有无错别字,排版是否合理,颜色搭配是否合理;

     

    兼容性测试

    是否可以跨平台,不同电脑机型下显示有无区别;

    安全性测试;

    若支付不成功是否原路退款,若支付成功,有无支付信息提示;

    用fiddler抓包尝试修改价格,对订单金额有无效验;

    直接输入需要权限的页面地址可用访问;

     

    接口测试

    第三方平台支付 

     

     

     

    对于有系统大量并发访问,你会如何做测试,有什么建议

    参考回答:

    如何做高并发系统的测试,一般而言,整体的测试策略是:先针对部分系统进行性能测试及压力测试,得到各部分的峰值处理性能,再模拟整体流程测试,重点测试整体业务流程以及业务预期负荷,着重测试以下几点:

    1、不同省份,不同运营商CDN节点性能,可采用典型压力测试方案

    2、核心机房BGP网络带宽,此部分重点在于测试各运行商的BGP网络可靠性,实际速率,一般采用smokeping,lxChariot等工具

    3、各类硬件设备性能,一般采用专业的网络设备测试工具

    4、各类服务器并发性能,分布式处理能力,可采用压力测试方案工具

    5、业务系统性能,采用业务系统压力测试方案

    6、数据库处理性能,这部分需要结合业务系统进行测试,以获取核心业务场景下的数据库的TPS/QPS,

    7、如果有支付功能,需要进行支付渠道接口及分流测试,此部分相对而言可能是最大的瓶颈所在,此外还涉及备份方案,容灾方案,业务降级方案的测试。

     

    请对这个系统做出测试用例:一个系统,多个摄像头,抓拍车牌,识别车牌,上传网上,网上展示

    参考回答:

    功能:

    1.每个摄像头都能抓拍车牌;

    2.每个摄像头抓拍到的车牌能正常交给系统处理;

    3.系统能够正确识别车牌;

    4.系统能够将识别出的车牌上传;

    5.上传至网络的车牌能够正常展示出来;

    一、功能测试

    1.使用正常的车牌,保持车牌静止,检查每个摄像头是否能抓拍车牌;

    2.使用类似非车牌的写有字的纸板,检查每个摄像头是否抓拍;

    3.使用正常的车牌,保持车牌较高速移动,检查每个摄像头是否能抓拍车牌;

    4.在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理,如临时断电、断网后能否正常将数据交给系统;

    5.使用抓拍到的正常的车牌,交由系统处理,检查系统能否识别车牌;

    6.使用非车牌的其他图片,交由系统处理,检查系统能否识别;

    7.在多种情况下检查系统能否将正常识别出的车牌进行上传,如临时断电、断网后未上传数据是否能继续上传;

    8.构造非车牌的其他内容的数据,检查系统能否将异常内容进行上传;

    9.检查上传至网络的车牌能否正常展示出来;

    10.上传非车牌的其他内容的数据,检查能否正常显示出来。

    二、性能测试

    1.同时向一个摄像头展示多个静止的车牌,检查摄像头能否抓拍到多个车牌;

    2.同时向一个摄像头展示多个较高速运动的车牌,检查摄像头能否抓拍到多个车牌;

    3.抓拍后,检查系统识别车牌的时间是否在需求要求的时间内;

    4.模拟大量抓拍照片同时交由系统处理,检查一定压力下系统能否正常识别车牌;

    5.模拟大量车牌同时上传,检查一定压力下能否上传成功。

    三、安全性测试

    1.检查是否能够通过给车牌加装饰物等方法,使摄像头无法抓拍或抓拍后系统无法正常识别车牌。

     

     

    请你说一说PC网络故障,以及如何排除障碍

    参考回答:

    (1)首先是排除接触故障,即确保你的网线是可以正常使用的。然后禁用网卡后再启用,排除偶然故障。打开网络和共享中心窗口,单击窗口左上侧“更改适配器设置”右击其中的“本地连接“或”无线网络连接”,单击快捷菜单中的“禁用”命令,即可禁用所选网络。接下来重启网络,只需右击后单击启用即可。

    (2)使用ipconfig查看计算机的上网参数

    1、单击“开始|所有程序|附件|命令提示符“,打开命令提示符窗口

    2、输入ipconfig,按Enter确认,可以看到机器的配置信息,输入ipconfig/all,可以看到IP地址和网卡物理地址等相关网络详细信息。

    (3)使用ping命令测试网络的连通性,定位故障范围

    在命令提示符窗口中输入”ping 127.0.0.1“,数据显示本机分别发送和接受了4个数据包,丢包率为零,可以判断本机网络协议工作正常,如显示”请求超时“,则表明本机网卡的安装或TCP/IP协议有问题,接下来就应该检查网卡和TCP/IP协议,卸载后重装即可。

    (4)ping本机IP

    在确认127.0.0.1地址能被ping通的情况下,继续使用ping命令测试本机的IP地址能否被ping通,如不能,说明本机的网卡驱动程序不正确,或者网卡与网线之间连接有故障,也有可能是本地的路由表面收到了破坏,此时应检查本机网卡的状态是否为已连接,网络参数是否设置正确,如果正确可是不能ping通,就应该重新安装网卡驱动程序。丢失率为零,可以判断网卡安装配置没有问题,工作正常。

    (5)ping网关

    网关地址能被ping通的话,表明本机网络连接以及正常,如果命令不成功,可能是网关设备自身存在问题,也可能是本机上网参数设置有误,检查网络参数。

     

     

    微信红包

    功能

    1.在红包钱数,和红包个数的输入框中只能输入数字

    2.红包里最多和最少可以输入的钱数  200  0.01

    3.拼手气红包最多可以发多少个红包  100

    3.1超过最大拼手气红包的个数是否有提醒

    4.当红包钱数超过最大范围是不是有对应的提示

    5.当发送的红包个数超过最大范围是不是有提示

    6.当余额不足时,红包发送失败

    7.在红包描述里是否可以输入汉字,英文,符号,表情,纯数字,汉字英语符号,

    7.1是否可以输入它们的混合搭配

    8.输入红包钱数是不是只能输入数字

    9.红包描述里许多能有多少个字符   10个

    10.红包描述,金额,红包个数框里是否支持复制粘贴操作

    12.红包描述里的表情可以删除

    13.发送的红包别人是否可以领取

    13.1发的红包自己可不可以领取   2人

    14. 24小时内没有领取的红包是否可以退回到原来的账户

    14.1  超过24小时没有领取的红包,是否还可以领取

    15.用户是否可以多次抢一个红包

    16.发红包的人是否还可以抢红包   多人

    17.红包的金额里的小数位数是否有限制

    18.可以按返回键,取消发红包

    19. 断网时,无法抢红包

    20.可不可以自己选择支付方式

    21.余额不足时,会不会自动匹配支付方式

    22.在发红包界面能否看到以前的收发红包的记录

    23.红包记录里的信息与实际收发红包记录是否匹配

    24.支付时可以密码支付也可以指纹支付

    25.如果直接输入小数点,那么小数点之前应该有个0

    26.支付成功后,退回聊天界面

    27.发红包金额和收到的红包金额应该匹配

    28.是否可以连续多次发红包

    29.输入钱数为0,"塞钱进红包"置灰

     

    性能

    1.弱网时抢红包,发红包时间

    2.不同网速时抢红包,发红包的时间

    3.发红包和收红包成功后的跳转时间

    4.收发红包的耗电量

    5.退款到账的时间

     

    兼容

    1.苹果,安卓是否都可以发送红包

    2.电脑端可以抢微信红包

     

    界面

    1.发红包界面没有错别字

    2.抢完红包界面没有错别字

    3.发红包和收红包界面排版合理,

    4.发红包和收到红包界面颜色搭配合理

     

    安全

    1.对方微信号异地登录,是否会有提醒   2人

    2.红包被领取以后,发送红包人的金额会减少,收红包金额会增加

    3.发送红包失败,余额和银行卡里的钱数不会少

    4.红包发送成功,是否会收到微信支付的通知

     

    易用性(有点重复)

    1.红包描述,可以通过语音输入

    2.可以指纹支付也可以密码支付

     

     

    微信发朋友圈点赞

    参考回答:

    功能测试:

    点赞某条朋友圈,验证是否成功

    接口测试:

    点赞朋友圈,验证朋友能否收到提示信息

    性能测试

    点赞朋友圈,是否在规定时间显示结果,是否在规定时间在朋友手机上进行提示

    兼容性测试

    在不同的终端比如ipad,手机上点赞朋友圈,验证是否成功

     

     

    如何对淘宝搜索框进行测试

    参考回答:

    一, 功能测试

    1. 输入关键字,查看: 返回结果是否准确,返回的文本长度需限制

    1.1输入可查到结果的正常关键字、词、语句,检索到的内容、链接正确性;

    1.2输入不可查到结果的关键字、词、语句;

    1.3输入一些特殊的内容,如空、特殊符、标点符、极限值等,可引入等价类划分的方法等;

    2. 结果显示:标题,卖家,销售量,单行/多行,是否有图片

    3. 结果排序:价格 销量 评价 综合

    4.返回结果庞大时,限制第一页的现实量,需支持翻页

    5. 多选项搜索:关键字 品牌 产地 价格区间 是否天猫 是否全国购

    6. 是否支持模糊搜索,支持通配符的查询

    7, 网速慢的情况下的搜索

    8. 搜索结果为空的情况

    9. 未登录情况和登录情况下的搜索(登录情况下 存储用户搜索的关键字/搜索习惯)

    二.性能测试:

    1压力测试:在不同发用户数压力下的表现(评价指标如响应时间等)

    2负载测试:看极限能承载多大的用户量同时正常使用

    3稳定性测试:常规压力下能保持多久持续稳定运行

    4内存测试:有无内存泄漏现象

    5大数据量测试:如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来,看表现如何等等。

    三. 易用性:交互界面的设计是否便于、易于使用

    1依据不同的查询结果会有相关的人性化提示,查不到时告知?查到时统计条数并告知?有疑似输入条件错误时提示可能正确的输入项等等处理;

    2查询出的结果罗列有序,如按点击率或其他排序规则,确保每次查询出的结果位置按规则列示方便定位,显示字体、字号、色彩便于识别等等;

    3标题查询、全文检索、模糊查询、容错查询、多关键字组织查询(空格间格开)等实用的检索方式是否正常?

    4输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到,有否快照等快捷查看方式等人性化设计?

    四. 兼容性

    1WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用

    2IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下、各种显示分辨率条件下的应用

    3SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试

    4简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试

    5IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试

    6与各相关的监控程序的兼容性测试,如输入法、杀毒、监控、防火墙等工具同时使用

    五. 安全性

    1被删除、加密、授权的数据,不允许被SQL注入等攻击方式查出来的,是否有安全控制设计;

    2录入一些数据库查询的保留字符,如单引号、%等等,造成查询SQL拼接出的语句产生漏洞,如可以查出所有数据等等,这方面要有一些黑客攻击的思想并引入一些工具和技术,如爬网等。

    3通过白盒测试技术,检查一下在程序设计上是否存在安全方面的隐患;

    4对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制;

     

     

     

     

    就linux下的CP命令设计测试用例。

    功能

     

    拷贝的文件

    1)大小:0k, 1k, 10k, 100k, 1000k…

    2)类型:二进制文件、文本文件、mp3、avi、压缩文件…

     

    文件源目录

    1)文件中包含各种类型的文件

    2)目录深度为0,1,2,3…

     

    文件目标目录

    1)目标目录中存在与源文件同名同类型的文件

    2)目标目录中存在与源文件同名不同类型的文件

    3)目标目录中存在与源文件不同名同类型的文件

    4)目标目录中存在与源文件不同名不同类型的文件

     

    异常

     

    参数异常

    1)包含特殊字符

    2)参数长度超过限制

    3)源目录不存在

    4)目标目录不存在

     

    文件异常

    1)文件没有拷贝权限

    2)非法的文件格式和内容

     

    存储介质异常

    1)存储介质由损坏

    2)拷贝前存储介质已满

    3)拷贝中存储介质存满

     

    执行过程异常

    1)拷贝过程中删除源文件

    2)拷贝过程中删除目标文件

     

    性能

    1)拷贝大文件

    2)拷贝源目录中存在大量小文件

    3)跨文件系统拷贝

    4)跨存储介质拷贝

    5)并发执行拷贝

     

    关注性能点:拷贝完成时间,CPU,内存,磁盘IO

     

     

     

    请问如果用户点击微博的关注图标但是app上面没有反应,应该怎么排查这个问题

    • 是否手机出现故障,是否手机缓存过多造成内存不够用
    • 是否手机网络连接不稳定(弱网/无网),若是,有无网络差提示
    • 是否手机内存溢出(关注人数达上限否)
    • 是否是版本问题或者是安装包问题(更新系统,重新安装安装包)

     

    现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

    标题:这一组只有一个记录,其内容为输出成绩报告的名字。

    试卷各题标准答案记录:每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。

     

    每个学生的答卷描述:该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。

    学生人数不超过200,试题数不超过999。

    程序的输出有4个报告:

        a)按学号排列的成绩单,列出每个学生的成绩、名次。

        b)按学生成绩排序的成绩单。

        c)平均分数及标准偏差的报告。

        d)试题分析报告。按试题号排序,列出各题学生答对的百分比。

    分别考虑输入条件和输出条件,以及边界条件。给出右表所示的输入条件及相应的测试用例。

     

     

     

    三、基础知识点

    什么是桩模块?什么是驱动模块?

    桩模块:被测模块调用模块

    驱动模块 调用被测模块

     

    什么是扇入?什么是扇出?

    扇入:被调次数,扇出:调其它模块数目

     

    8020原则:在需求分析开始到集成测试阶段引入测试手段,能发现所有缺陷的80%,系统测试阶段发现16%,在运行维护阶段经过长时间大量运行软件后,能够发现4%。起源于经济学。

     

    什么是耦合?什么是内聚

    耦合:对一个软件结构内各个模块之间互连程度的度量。

    内聚:一个模块内各个元素彼此结合的紧密程度。强内聚,松耦合。

     

    缺陷严重程度

    致命(Fatal)、严重(Critical)、一般(Major)、较小(Minor)。

     

    缺陷优先级

    立即解决P1、高优先级P2、正常排队P3、低优先级P4。

     

    缺陷状态

    打开(open)、修正(fixed)、重新打开(reopen)、关闭(closed)、重复(Duplicate)、推迟(Deferred)、保留(On hold)、不修复(wontfix)。

     

    简单的软件缺陷生命周期:

    发现(new)-打开-修复-关闭。

     

    复杂的软件缺陷生命周期:

    新建-打开-Bug审查(设计需要修改/延期/关闭)-关闭。

       新建-打开-是否清楚,可再现(不能再现缺少信息返回到打开状态)-修正-关闭。

     

    什么是在线用户数?什么是并发用户数

    在线用户数:

    用户同时在一定时间段的在线数量

    并发用户数:

    某一时刻同时向服务器发送请求的用户数

     

     

    分布式软件架构分为

    B/S架构(浏览器、web版)       C/S架构:客户端(先进行安装)

     

    测试人员的能力

    搭建环境的能力(配置JDK、数据库、Tomcat/Apace、程序放相应路径下、检查配置是否成功‚数据库管理和设置ƒ程序设计C++④测试方法论⑤工具的使用能力(QC\QTP\LR\Bugfree)

     

    简述负载测试与压力测试的区别。

    参考答案:

     

    压力测试(Stress Testing)

    压力测试的主要任务就是获取系统正确运行的极限,检查系统在瞬间峰值负荷下正确执行的能力。例如,对服务器做压力测试时就可以增加并发操作的用户数量;或者不停地向服务器发送请求;或一次性向服务器发送特别大的数据等。看看服务器保持正常运行所能达到的最大状态。人们通常使用测试工具来完成压力测试,如模拟上万个用户从终端同时登录,这是压力测试中常常使用的方法。

     

    负载测试(Volume Testing)

    用于检查系统在使用大量数据的时候正确工作的能力,即检验系统的能力最高能达到什么程度。例如,对于信息检索系统,让它使用频率达到最大;对于多个终端的分时系统,让它所有的终端都开动。在使整个系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。

     

    软件缺陷管理工具有哪些

    答:   QC ALM BugFree jira Mantis 禅道

     

    弱网测试

     

     

     

    四、智力题

    一,5只猫 五分钟捉5只老鼠 请问100分钟捉100只老鼠需要多少只猫?

    答案:5只

    二,圆桌,两个人,轮流放硬币,不能重叠,半径为1,某一方不能放下去,则为输。问先手赢 后手赢

    答案:先手赢,圆桌对称,先手先放,后手都可以找对称位置,除了圆心

    三,3升的杯子一个,5升的杯子一个,杯子不规则形状 问怎么得到4升的水 水无限多

    答案:略

    四,晚上有四个人过桥,一次只能过两个人,但是只有一只手电筒,四个人过桥时间分别是1,2,5,8,求最短过桥时间

    答案:甲乙,甲回,丙丁,乙回,甲乙,15分钟

    五,有十张扑克牌,每次可以只出一张,也可以只出两张,要出完有多少种出法

    答案:89 F(9)=N F(8)=P F(10)=F(8)+F(9) F(1)=1 F(2)=2

    六,井盖为什么是圆的

    答案:用料少,受压均匀,成本低

    七,两个盲人各买了一白一黑两双袜子,不小心弄混了,问他们自己怎么分成刚好每人一白一黑

    答案:袜子是连在一起的

    八, 烧一根不均匀的绳子,从头烧到尾总共需要1个小时,问如何用烧绳子的方法来确定15分钟?

    答案:烧两根,一根点两头,一根点一头,烧完,剩下的把另一投点了,烧完,看重合点

    九,海盗分金,五人,过半同意,否则喂鱼,问1方案?

    答案:45,5反对,4喂鱼,所3(100,0,0),故2(98,0,1,1),故1(97,0,1,2,0)

    十,岔路口,通往1,2,两人,一人必说谎,一人永真话,怎么去1

    答案:问一人,另一人会回答那条路去1,回答答案必假

    十一,果冻,有黄色、绿色、红色三种,闭眼抓同种颜色两个,抓取多少个,可确定有两个同色果冻?

    答案:根据抽屉原理,4个

    十二,下水道为什么是圆的

    答案:方便人员进出,井盖不容易掉落,不易如棱角磨损节约材料,保护车辆 和行人的安全

    十三,一共100个球,两人轮流拿,每人每次最多拿5个,最后一个拿的人赢;如果我先拿,怎么拿一定会赢?

    答案:每次拿的球总数控制为6;第一次拿4个;

    十四,有120g面粉,现有一个天平和一个2g的砝码以及一个7g的砝码,最少称几次可以将面粉分为70g与50g

    答案:4次,第一次120g=111g+9g  第二次111g=93g+18g  第三次93g=57g+36g  第四次50g=57g-7g  70g=7g+36g+18g+9g

    十五,扔鸡蛋不碎问题(腾讯校招面试题)?

    答案:14次

    十六,智力题:一千瓶中有一瓶毒药 十只小白鼠找出这瓶毒药

    答案:2^10=1024,小白鼠编号1-10,瓶子编号1-1000,把瓶子的编号转变为二进制数,第几位1,就给第几个小白鼠喝

     

     

     

    第二篇测试面试总结---->测试面试二

    参考资料:

     

    https://www.nowcoder.com/ta/review-test

    https://zhaiyujia.blog.csdn.net/article/details/81604085

    https://blog.csdn.net/weixin_30363263/article/details/80110247?utm_medium=distribute.pc_relevant.none-task-blog-title-2&spm=1001.2101.3001.4242

    https://my.oschina.net/u/4296112/blog/3569084

    https://bbs.huaweicloud.com/blogs/172015

    https://zhuanlan.zhihu.com/p/122493284

    https://blog.csdn.net/weixin_44264744/article/details/104948526?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3.control#%E4%B8%89%EF%BC%8C%E6%8E%A5%E5%8F%A3%E6%B5%8B%E8%AF%95Jmeter%2CFiddler

     

    展开全文
  • 软件测试笔试面试题目完全汇总

    万次阅读 多人点赞 2019-03-06 13:29:37
    1、软件测试的流程 2、web测试和APP测试的区别 仅仅从功能测试的层面上来讲的话,在流程和功能测试上是没有区别的。那么区别在哪里呢? 由于载体不一样,所以系统测试和一些细节可能会不一样。 那么我们就要先...
  • 软件测试面试题(含答案)

    万次阅读 多人点赞 2021-03-01 15:15:38
    软件测试面试题(含答案)
  • 公司要求招一名自动化测试,能力要求不高,1年左右自动化经验+部分性能经验即可,让我出一份题,我就百度+公司项目遇到的问题,出了一份,出题整体思路是:接口自动化问题+性能问题+规划的ui、app自动化+整体质量...
  • 给软件测试新手的忠告

    千次阅读 2013-09-04 18:31:13
    一直以来都是在学习一项事物时,由于自己的记性不好,所以经常会写一些记忆帮助文档,但回顾过去写一些总结性的文档还是第一次,先简单的回顾一下吧,也好缕缕自己的思路。 一、菜鸟必备: 大多的新手入职,...
  • 赢在测试2:中国软件测试专家访谈录(品专家足迹 悟测试真谛 本书已在台湾发行) 蔡为东 著 ISBN 978-7-121-20066-3 2013年5月出版 定价:59.00元 280页 16开 编辑推荐 一线IT企业一线...
  • 测试开发笔记

    万次阅读 多人点赞 2019-11-14 17:11:58
    测试开发笔记 第一章 测试基础 7 什么是软件测试: 7 ★软件测试的目的、意义:(怎么做好软件测试) 7 3.软件生命周期: 7 第二章 测试过程 8 1.测试模型 8 H模型: 8 V模型 9 2.内部测试 10 3外部测试: 10 验收...
  • 软件测试之Web测试

    千次阅读 多人点赞 2015-01-15 14:26:14
    1、Web测试中相关的设置与查看方法  2、Web测试中截屏与录制屏幕操作过程  3、界面测试、功能测试、表单测试的验证要点 一、Web测试的特点  基于Web应用测试的特点是用户通过计算机中安装的浏览器就可以访问...
  • 测试开发需要学习的知识结构

    万次阅读 多人点赞 2018-04-12 10:40:58
    努力成为一个优秀的测试开发从业者,加油!... - 假装在测试的回答 - 知乎白盒与黑盒测试什么区分1、黑盒测试 黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检...
  • :把每一台要安装app的ios设备的UDID号复制出来,加入到开发环境,编译好app后发给用户,让用户把ios设备连线到电脑,将收到的app拖到itunes,然后和ios设备同步安装。这些步骤在一个开发者看来再简单不过的操作,...
  • 作为一个测试如何快速熟悉项目

    千次阅读 2020-09-06 21:10:10
    (what)对于测试来说,从产品的角度去思考熟悉产品对于快速熟悉测试系统的业务流程是很有必要的。 (why)在如今敏捷开发及迭代快速开发模式下。对测试的效率有着越来越高的要求,因此可以做以下操作: 工作第一...
  • 软件测试面试常见问题:测试是什么,分为哪几个阶段, 测试工程师具备什么素质,黑盒白盒, app和web端测试的区别 ...
  • 4验收测试工件齐全(测试计划,测试用例,测试日志,测试通知单,测试分析报告) 20、测试设计员的职责有:B ①制定测试计划 ②设计测试用例 ③设计测试过程、脚本 ④评估测试活动 A.①④ B.②③ C.①③ D.以上全...
  • 软件测试——测试流程重要性

    千次阅读 2017-08-29 16:50:40
    千锋教育软件测试:论测试流程的重要性 千锋教育的王晓军老师曾经说过,测试人员作为产品质量控制的最后一环,应当是以完善作品而非完成工作为目标。因此,不论是测试时的工作态度还是百岁在测试左右的测试流程,都...
  • Web测试经验分享

    千次阅读 2019-09-01 10:05:04
    文章目录1、Web功能测试思路2、Web安全性测试思路3、Web性能测试思路4、Web兼容性测试思路5、Web易用性测试思路6、网站的搜索功能怎么测试?7、缺陷报告怎么写 1、Web功能测试思路 检查网站里面的链接...
  • 软件测试的生命周期&测试流程

    千次阅读 多人点赞 2019-04-29 21:47:16
    包括:计划(开发方与需求方讨论)、需求分析、设计、编码、测试(单元测试、集成测试、系统测试、验收测试)、运行维护、淘汰升级等 1、可行性研究及计划 开发方和需求方共同讨论,确定软件的开发目的及可行性,...
  • Microsoft程序员测试

    千次阅读 2004-10-29 18:01:00
    原创:onefi http://www.frontfree.net/2003年6月1...(个别题目答案有多种,文本仅代表作者的思路,如有高见欢迎和我交流onefi@frontfree.net)每道题的后面会给出一个时间。这个时间是我做出该题所用的时间。(注意
  • 2019 Python接口自动化测试框架实战开发(一)

    万次阅读 多人点赞 2019-06-28 15:55:25
    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家!...整个项目分为四个部分:接口基础丶接口开发丶Unittest与接口测试结合以及接口自动化框架从设计到开发 接口基础包括:H...
  •  办法一:把每一台要安装app的ios设备的UDID号复制出来,加入到开发环境,编译好app后发给用户,让用户把ios设备连线到电脑,将收到的app拖到itunes,然后和ios设备同步安装。这些步骤在一个开发者看来再简单不过的...
  • 软件测试面试题整理

    千次阅读 2013-05-07 21:49:39
    软件测试面试题整理 一般面试官都会问到你是怎样... 4 执行用例:进行功能测试,接口测试,容错测试,界面测试,安全测试,初始化测试,文档测试,可用性测试,性能测试,负载测试,稳定性测试,恢复测试,配
  • Android单元测试学习总结

    千次阅读 2019-04-22 08:53:22
    本地单元测试(Junit Test), 本地单元测试是纯java代码的测试,只运行在本地电脑的JVM环境上,不依赖于Android框架的任何api, 因此执行速度快,效率较高,但是无法测试Android相关的代码。 Android单元测试(Android...
  • 软件测试面试题

    千次阅读 多人点赞 2020-12-28 18:43:36
    目录: 1.B/S架构和C/S架构区别 ...3.POST与GET区别 4.Cookie和Session的区别与联系 1.B/S架构和C/S架构区别 ## 1.B/S架构和C/S架构区别 ...3.POST与GET区别 ...8.单元测试与集成测试的侧重点 9.系统测试范围
  • 从部门到部门的申请调动,此刻我已经坐在了软件测试部门的办公室里。一个月半的学习和目前刚完成第一个定制项目的测试完成,突发奇想写篇博客记录。写博客,应该会坚持了,从手写到码字,从纸质到博文,从懒于学习...
  • 例如:USB接口,电脑里的数据可以看成是内容数据,而U盘里的数据可以看成是外部数据,那么USB接口的作用就是:电脑和U盘交互数据,也就是使电脑内部的数据能够和外部的U盘交换数据。 例如:微信的提现和充值,就...
  • 对于测试的基本知识,可以查看软件测试相关书籍 ...测试流程方面:从最开始的分析需求开始,逐步地跟着项目走完整个测试流程,包括纯手工测试,包含了自动化的测试流程,包含了性能测试测试流程...
  • 测试开发面试题

    千次阅读 2020-03-31 23:32:21
    功能测试用例的设计 举例: (一).我想要回家,让你给我买一张票,然后设计测试用例 答案: 1.确定需求(回家回哪,需要什么票,买什么时候的票) 2.开始测试 2.1功能测试(我去买票(买火车票,飞机票),买到...
  • 软件测试——基础练习(期末复习)

    万次阅读 多人点赞 2020-06-28 20:28:54
    软件测试基础 1、测试是为了验证软件已正确地实现了用户的要求。错 2、测试人员说:“没有可运行的程序,我无法进行测试工作”。错 3、在软件开发过程中,若能推迟暴露其中的错误,则为修复和改进错误所花费的代价就...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 36,791
精华内容 14,716
关键字:

新思路电脑测试