精华内容
下载资源
问答
  • 2020-11-24 20:30:53

    1. 提测质量差

    问题描述:第一个提测版本差,有些均未通过冒烟测试
      问题分析
      A. 版本提测质量差,但基于发布时间已在,因此,在提测差时就开始测试
      提测质量差的点:- 基于上每项功能的完成度都不高 - 有些功能均未实现 -
      B. 新的团队,团队处于磨合期
      C. 在提测时,对提测要求不明确,在时间点到后,匆忙提测
      解决方式:
      明确版本提测要求,并且开发得到了足够的时间。

    2. 版本控制

    问题描述:
      最初阶段,每天出一个版本,基于新版本测试,记录每个版本上测试的功能。版本过于频繁,质量把控不好
      问题分析:
      A. 基于版本提测质量差,而且每天出一个版本,差上加差,
      B. 虽然记录每个版本上测试的功能,但仍然无法把控当前版本的质量状况。
      解决方式:暂停每天发布一个版本
      前期:将全功能版本作为下一个版本发布目标,但由于一些功能并没有完成,因而,全功能版本分成了好几个阶段
      后期:以测试一轮周期,发布最新版本

    3. 功能反复

    问题描述:在上一个版本是OK的功能,在新版本中功能失常
      功能反复分两点:一是大功能反复, 二是小功能(如:某个bug)反复
      问题分析:
      大功能反复:情况主要发生成项目前期和中期
      A. 功能未完成,在完善功能时,未考虑到与该功能相关的点
      B. 在提测之后,发现一些问题,导致了整个模块重构,重构后导致了问题的反复
      小功能反复:这个情况主要发生在项目中后期
      A. 因为项目里的部分开发是外援的,在项目中期时,会撤出了团队,新接手的人员,对代码不熟悉,在修改bug时,经常出来顾此失彼
      B. 开发小一在修改代码时,动到了小二的代码,导致了小二出了问题
      解决方式:
      对大功能反复,是这么处理:冒烟测试由开发来完成,冒烟通过后,再交由测试
      对小功能反复 ,没有有效的处理方式,测试这边可以做的是,加强测试,这个问题,在发布前夕好了很多,但问题仍然存在

    4. 需求不明确,前后不一致

    问题描述:需求不明确,特别在一些边界,各端统一上
      问题分析:
      A. 交互文档经历6任交互,最后一任交互只参与两个模块的定义,现任交互对于以往交互了解不够深入
      B. 产品提测时,交互验证不足
      解决方式:
      由于项目已提测,因此在整个周期里,对于交互需求方面的疑问直接找相关人员去确认。
      在后期的小版本中,我们把这类问题尽量控制在提测之前(详见小版本里的改进与问题)

    另外一些测试过程中遇到的问题和沟通方式

    从一开始,测试就要关注需求。
    往往在讨论设计时,开发和需求很容易忽略了测试成员,他们潜意识里觉得这不关测试什么事。可是,测试也要熟悉业务,熟悉功能,熟悉各种设计,而且测试需要站在用户的角度来去考量他们的设计是否有不合理的地方,并提出自己的建议。这些工作,测试成员需要主动,积极参加,多提建设性意见,这样可能会让开发慢慢发现测试成员的重要性。 其次,沟通最频繁应该还是关于bug的讨论。下面列出几个遇到的沟通问题,及我的解决办法。
    1、这个bug我这边重现不了
    解决办法
    Bug应该简明扼要,重点突出。
    如果描述存在歧义,一定要总结并尽快改进。有时会遇到概率性的bug,要告诉开发概率是多少,尽可能多的提供重现的条件。 在复现问题时,希望能大致判断几个问题点,然后和测试人员沟通下,需要如何捕获信息,捕获那类信息?是不是提供debug版本进行复现,或者根据预判的点增加打印信息版本进行复现?
    2、这个不是代码问题,需求这么定义的
    解决办法
    需求也是人定的,如果觉得有异议,
    可以找需求人员询问清楚,为什么这样定义,把自己的想法告诉他们,看他们怎么决定。如果被需求说服了当然是最好的,如果自己还是不同意需求的看法,需求又不同意我的提议,那只能听他的,毕竟权力在他那里。但是我们可以保留交流的记录,证明曾经在这里发生过歧义。
    3、这块是别人负责的,我负责的部分没有问题
    解决办法
    如果bug是由开发的项目经理来分发到程序员,那就是项目经理来面对这样的问题,而不是测试。当然,项目经理当然有项目经理的处理办法。可是,测试遇到这样的问题怎么办呢,把负责相关内容的开发都邀请到一个讨论组里,让他们自己讨论,这样更清楚,不必在测试这里中转。如果他们都觉得代码没问题,而我也有强有力的截图和真相,那就只有上交给上级领导,让他们来决定怎么解决。

    4、有问题吗?(也就是开发不认为这是个问题)
    解决办法
    测试人员一定比开发要敏感,对bug
    的容忍度也要低一些。特别是一些不符合用户习惯的bug
    ,开发总觉得无大碍。比如,一个列表默认的宽度太小了,导致初次打开,有一些内容被隐藏在后面,但是这个宽度可以手动调节。开发觉得问题很小,不影响功能,而且也有解决办法,所以不认为是bug。这个时候,就要发挥测试的本事了,嘴甜一点,说说好话,态度柔和一些。因为既然是小问题,解决起来一定不难,耐心地催开发的改过来就好。催一次不行催两次,记住态度一定要好。
    5、用户不会像你这样操作的!
    解决办法
    用户怎么操作,谁都预料不到。我们不可能覆盖所有可能性,但是大多数用户会出现的操作,
    我们当然要测试。慢慢地把开发从代码的世界里带出来,带到用户的世界里,让他换个角度思考问题,毕竟软件开发不是为了实现功能,是要满足用户需求的。如果最后还是没能说服他,第一向上级反映,第二做好沟通的记录,将来备份在测试报告里。 总结起来,测试在工作上要主动询问,态度上不能轻易妥协,习惯上要善于记录细节,方法上软硬兼施。

    更多相关内容
  • 在测试过程中,我们是如何去定位前后端问题的?

    万次阅读 多人点赞 2020-08-08 00:51:15
    我们做web端测试时,难免会遇到这样的一个情况:出现的bug,不知道是前端还是后端,这篇就为大家简单介绍几种比较好用的方法吧 场景: 清晰的记得那天是项目要上线,但是由于某种原因,页面可以打开,但是点击...

    我们在做web端测试时,难免会遇到这样的一个情况:出现的bug,不知道是前端还是后端,这篇就为大家简单介绍几种比较好用的方法吧

    场景:

    清晰的记得那天是项目要上线,但是由于某种原因,页面可以打开,但是在点击任意链接后,没有实现该功能,且还会抛出异常提示?
    此时,作为测试的我们,应该是要协助开发去定位问题:

    1、可以通过谷歌浏览器中的开发者工具来定位问题

    打开F12 或是谷歌浏览器右上角的三个小点,开启开发者工具

    在这里插入图片描述
    2、在开发中工具中,选择Network

    在这里插入图片描述
    3、刷新当前页面,并对有问题的地方进行点击,Network会抓取当前的页面的内容

    在这里插入图片描述
    在这里,有返回接口,也有些其他的数据,在这里,我们重点观察有问题的哪些地方

    比如页面中有一个下拉框,但是没有数据,那么我们可以通过接口测试来判断:

    <1>先ping下ip,看是否存在超时的现象,如果超时了,那么就可以初步的认定为是服务端的问题

    在这里插入图片描述
    ps:这里是拿的百度做的实验哦~

    <2>如果接口可以跑通并返回了正确的数据,那么服务端这边是没有问题的,有可能是前端没有绑定好该字段

    <3>如果接口不可以跑通,那么可以去找下服务端的问题,超时、异常等情况,还要考虑到是否有中间件的问题

    4、用开发者工具做接口详细步骤:

    <1> 在Network下,点击 view source 来露出headers请求入参

    在这里插入图片描述

    露出请求参数:
    在这里插入图片描述

    此时,可以打开接口测试工具,将这些请求参数复制下来,并粘贴到工具中

    添加一个http请求:
    在这里插入图片描述

    添加一个信息头管理器:
    在这里插入图片描述
    因为参数很多,我们并不知道哪些是必传参数,还是不必传参,所以这里全都拿过来

    最后添加一个察看结果树:

    在这里插入图片描述
    请求是成功的,但是出现了乱码,大家可以去修改下jmeter的编码配置

    <1>打开jmeter的bin目录,找到jmeter.properties文件

    在这里插入图片描述
    文本方式打开,搜索sampleresult.default.encoding=ISO-8859-1改为sampleresult.default.encoding=utf-8 去掉最前端的注释#

    在这里插入图片描述
    再次跑下接口:
    在这里插入图片描述
    4、还可以在Network中看到页面响应时长

    在这里插入图片描述

    如有问题,请在博客下方留言,小友定当知无不尽~

    展开全文
  • 软件各行各业的日益普及,软件质量问题引起的不良后果越来越严重,软件质量的重要性日益凸显。软件测试作为保证软件产品质量最直接、最有效的手段,越来越多的企业和用户认识到软件测试的重要性。 作为软件开发...

     软件在各行各业的日益普及,软件质量问题引起的不良后果越来越严重,软件质量的重要性日益凸显。软件测试作为保证软件产品质量最直接、最有效的手段,越来越多的企业和用户认识到软件测试的重要性。

    作为软件开发环节的一部分,软件测试的风险是显而易见的,软件测试项目风险管理是一种特殊的项目风险管理形式。若能够进行风险管理,重视风险评估,制定积极的风险应对计划,就能最大程度地避免风险或减少因风险而造成的损失。

    正式投入市场之前,软件需要经过技术人员的反复测试。如软件有任何质量问题,以便技术员追查问题根源,并及时消除;如没有任何质量问题,经过技术人员的检验,才能真正做到“防患于未然”,这也是企业和个人使用软件测试的重要意义。

    1.软件测试环节的质量管理

    在软件开发的环节中,软件的质量管理是非常重要的,技术人员从开发初期到投入使用的整个环节都要对软件进行反复的测试,一旦发现任何质量问题,就及时采取相应的措施加以改进,从而保证广大用户在使用软件的环节中,无论是软件的功能还是性能,都能获得更加完美的应用体验。

    但在软件测试环节中,广大技术人员对质量管理的重视程度很高,只有加强软件的质量管理,才能保证产品符合标准的验收要求。但从当前软件测试工作的进展来看,多数技术人员虽然明确了软件测试工作具备的重要性,但对于如何有效提高软件的质量却没有提及。

    近几年来,随着软件测试研究工作的广泛开展,广大软件测试工作者凭借自己多年的工作经验,形成了一套固有的工作模式,在测试环节中充分考虑了以下几项重点内容:

    一,是所开发的软件是否符合用户的要求,在读取数据信息时,用户能否正确理解相关数据信息,在修复系统漏洞的环节中是否容易操作。

    二,软件的系统界面是否简洁,用户在操作过程中是否需要设置其它快捷功能。

    第三,软件在定期更新的环节中,存储的需求是否合理,是否真的做到了为广大用户量身定做。软件生命周期中各阶段的文件是否完整、存储是否恰当、所有文件配置是否规范、配置管理是否合理、员工进行软件测试需要根据客户的需求,作为参考,从对方的角度来看待产品,想象客户会怎样使用产品,在使用环节中可能遇到哪些问题。

    在软件测试质量管理方面也要进行软件质量保证,对开发的软件分阶段进行科学的评审,根据评审结果制定相应的计划,将软件划分为若干阶段,根据各阶段所呈现的特点制定评审要求。在软件开发环节中,工作人员需要为每个环节制定规范,无论是文档还是编程程序都要满足相应的规范要求,要求软件测试人员做好质量评估报告,内容丰富详细,评估整个软件测试环节,对软件测试存在的不足提出有效改进建议。

    2软件测试环节中的风险管理程序

    2.1风险确认

    要帮助广大的软件测试人员轻松地应对风险,在拥有更多专门行业知识的同时,也要有足够的风险应对能力,这就要求技术员尽早识别软件测试环节中的风险,以便充分地“防患于未然”。

    从软件开发之日起,技术人员就建立风险识别体系,对其应用环节制定相应的策略,明确软件使用环节中潜在的威胁因素,制定基于项目特点的多样化风险识别方法。目前,市场上已有的风险识别方法有四种方法:风险计划法、独立评估法、核对表和头脑风暴法。

    2.2风险分析

    软体测试环节中,技术人员需要识别潜在风险的种类和重要性,这就是风险分析的环节。一般来说,风险等级按从轻到重分为五类:非常低、低、中、高和很高。在软件使用环节中,技术员采用常规的定量或定性方法来评估潜在的风险程度。

    与定量分析相比,大多数技术人员更倾向于采用定性的风险分析方法,这是因为定性分析比定量分析更容易操作。但有些技术经验丰富的技术人员更善于运用定量分析和定性分析相结合的分析方法,通过定量分析来感知风险水平,并与已建立的标准值相比较,然后计算出其风险概率与标准值的乘积,如果计算所得结果超出既定的标准要求,说明在软件测试环节中潜在的风险较高,此时技术人员需要采取相应的预防措施来应对。

    2.3风险控制

    技术员在控制风险发生的环节中,涉及到的环节很多,主要分为以下五个环节:

    第一,是降低风险,如果风险发生的可能性相对较低,那么风险发生的程度也相对较小。因此,技术人员可以通过降低风险发生的可能性,将风险控制在可承受范围内,从而降低风险的程度。

    第二,风险应变能力。只要技术员发现风险存在,就应采取相应的措施,以减少其对软件使用事故的影响。

    第三,风险转嫁问题。有时,软件测试环节中遇到的风险并非由软件本身带来,而是由第三方传递,因此,技术人员可以在风险可知的环节中,充分利用这个环节,将风险转移给第三方。

    第四,风险评估。一旦技术员确定了风险存在,首先要做的就是对风险进行准确的评估,把风险的等级控制在确定的范围之内。如果由于技术员的疏忽或系统的安全漏洞而导致风险的发生,如果事先防范不当,或者采取措施不力,只好积极地应对风险。

    第五,为保证数据在传输环节中的安全性,外包技术人员在进行测试时,必须将各种端口、软件版本、电子邮件信箱等信息合并起来,并且在传输环节中利用虚拟网络地址对传输的数据信息进行加密处理。

    3结论

    总之,为了保证软件在市场上得到更多用户的青睐和信赖,在软件开发的环节中需要经过多次反复的测试,在经过层层把关的软件质量保证措施的有效性。如今,面对千变万化的大千世界,软件的种类层出不穷,这不禁让广大的网络用户感到苦恼。

    因此,对所用软件提出了更高的要求,不仅要杜绝流氓软件的出现,而且要为广大用户提供良好的体验。对此,广大软件开发人员对软件测试工作给予了高度重视。阐述了在软件测试环节中进行的质量管理,明确了软件测试环节质量管理的重要性和主要内容,然后从风险识别、风险分析、风险控制三个方面对软件测试环节中的风险管理环节进行了分析。

    在软件开发之初,通过对以上三个环节的分析,帮助广大的技术人员加强了对软件风险的分析,并采取相应的防范措施控制风险,使广大的软件开发商在市场竞争中处于有利的地位,为广大网络用户提供更多的情感体验。

    看了这篇内容后,坚信以下两件事,也会对你的自我提升有一定的帮助:

    1、点赞,让更多人能看到,同时你的认可也会鼓励我创作更多优质内容。

    2、要让自己变得更强:想想,假如你是要在测试这个行业长期做下去,你的工作经验和测试技术是绝对不够的,你需要提升,你需要丰富你的技术栈!还等什么!


    最后:【可能给你带来帮助的教程】

    这一些资料,对做【软件测试】的朋友而言应该是较为完整了,这类学习资料也陪伴我走过了最艰难的路程,希望也可以帮助到你!万事要尽早,尤其是技术行业,一定要提升技术功底。

     

     

    展开全文
  • 谈谈测试过程中常见的几个问题

    千次阅读 2015-04-23 03:37:49
    今天总结小编在测试过程中经常遇到的几个方面与大家分享一下。 1.测试执行方面 测试过程中,我们常常会担心测试不够全面,覆盖不全。因为我们知道测试不足(没有覆盖到足够的度)极有可能带来严重的...

    相信大家在测试工作过程中一定遇到许许多多的问题,而且每个人的问题都不太一样。今天总结小编在测试过程中经常遇到的几个方面与大家分享一下。


    1.测试执行方面

    测试过程中,我们常常会担心测试不够全面,覆盖不全。因为我们知道测试不足(没有覆盖到足够的度)极有可能带来严重的后果,但过多的测试就能够在解决这个问题的同时不带来弊端吗?显然不是的。设计测试用例本意是为了规避测试的随意性,让我们测试时既不多测也没有少测。

    很多测试行业的前辈或同事都会在总结测试的时候分析出在测试过程中有些功能可以不需要测试得那么详细,有些用例存在的意义很小(甚至是冗余)。将容易的、明显的模块/功能进行详细的测试而复杂的功能没有得到充分测试,这属于明显的资源分布不均,会带来严重的浪费。

    在测试用例设计的过程中也存在过多的执行的现象。比如为了覆盖一个功能点,有人就会在设计测试用例的时候持有“宁可多,不可少”的观念,就算是存在着大量重复的测试用例,也不进行删除和精简。比如同样都是测试“地区短信黑名单不拦截联系人发来的短信”功能,那么测试一个联系人发来一条“晚上一起吃饭吧?”和发来一条“周末一起打球吧?”的短信,就是一种重复。还有一种测试用例设计中得过多执行现象是,在用例设计过程中写过多的重复(冗余)用例,评审的时候再进行删除,这也是不可取的。

    在测试过程中,这样的过多测试,我们多少都会碰到,这样的重复测试对我们的能力提升和行为优化是没有帮助的,因此在测试过程中我们应该留意,主动去克服这些问题。


    2.测试范围方面

    对于测试人员来说,漏测风险是难免会存在,这让所有的测试人员都感到不安。有时候就会出现因为怕承担责任就去做超出测试范围的事情,无形中加大了测试的工作量,而不是去按照开发的功能实现去分析测试边界、测试重点。

    比如有的时候,开发只是去修改了一个模块中得一个很小的功能点的实现逻辑(甚至是改动了UI上面的布局,更甚至只是替换了UI资源文件),这个时候不去与开发确认修改范围,而对整个模块进行功能的测试就是一种超出范围的测试。这样的超出范围的测试,也是一种测试能力不够优秀的表现,而且这也不是 一个追求卓越的测试人员应有的态度。 这种情况下,我们应该及时的去了解开发的实现思路与修改逻辑,对测试范围进行一个评估,最终得到一个合理的测试范围。


    3.测试文档方面

    一个优秀的测试团队,一定存在着许许多多凝聚了许多人智慧的文档。也一定会有更多的人编写更多的文档。在编写文档的时候,首先要明白所编写的文档的作用,不顾文档编写初衷也是不可取的。文档最重要的作用一方面是保证信息传递的有效性、便捷性,保证文档在查看过程中信息不失真;另一方面是对既有的测试经验的一种总结和传承。如果文档在辛苦编写后再无查看,那么该文档就失去了存在的意义。对于许多技术岗位上得同学来说,可文档可能是一件不太招人喜欢的任务,但是文档的整理和编写对于一个优秀的测试人员来说确实必不可少的一项基本能力。而且对于项目中经验的积累和传承,对于工作任务的传达都具有十分重要的意义。

    但是,并不是所有的文档就是越详细越好,比如一项文档的面向对象是一个工作经验一年以上的项目组成员,那么给他一份包含了详细测试步骤、具体操作、甚至每一步都带有截图和标注的文档反而是一种过度的行为。再有比如在测试执行过程中,有时候需要记录测试的执行。一份包含所有过程、步骤、截图、风险的详细文档有时候也不是必须的,而且还有可能降低执行的效率。


    4.沟通方面

    相信大家一定见过这样的场景:同一个办公室里或者隔着几道工位的同事,经常会因为一个可能三两句话就说完的事情而在QQ(或其它通讯工具)上聊半天。这种不合理沟通方法,很大程度上降低了工作的效率,而且也不利于同事之间沟通上的了解。

    沟通方面还存在一种不同角色间的问题。各方面的进度(可能会给测试带来Delay压力)的推进中,有一种不主动去推进,而是等待进度反馈的现象。假如前面的角色进度都正常的话,整理进度对测试的压力影响不大;但是若前面的角色进度存在着阻塞或者其他情况的Delay,那么测试的工作往往会收到很大的影响。项目上的排期需要重新制定,测试任务的展开也会出现混乱。倘若上线的时间是定死的,那么测试的压力就会非常大,风险也会非常大。

    因此沟通上面,能够尽量的完成当面沟通,及时推进,把可能的突发情况尽可能早的发现并暴露出来,让各方面都有提前准备,对于测试方面,甚至是各方面的工作都是百利无害的。


    5. 问题发现与创新

    任何的工作都是在前人工作的经验的基础上展开的,从而进入到一片带有自己色彩的天地。测试工作也不例外。(当一个新人)在进入到一项测试工作中时,往往发现该团队的工作模式,流程文档,例行产出等都已经存在着成熟的规范或者约定。而这些约定也并不一定是完整的,甚至有时候随着时代的不同,可能也不见得正确(比如传统PC软件的测试到移动APP的测试)。这个时候有的人可能处于对既有流程的尊重,或者对前辈同事的尊重,而不敢提出自己创新的观点和看法。这个其实从长远来看,对项目和团队也是不利的。

    比如我们现在的QWERTY键盘布局,是机械打字机时代为了解决打字过快而造成卡键问题而发明的,它最初的目的是为了最大程度上降低打字的速度。除去商业和制造业上的一些原因不谈,如今大部分人对这种键盘模式采取的是适应的态度。但这种键盘布局对于打字速度的提升和打字时手指的受力方面存在着极大的不合理。因此才会有DVORAK和MALT这两种按键布局方案的产生。

    测试工作中,也应该有这种创新的思路和对问题的发现能力。并积极的思索和提出解决方案。



    原文链接

    如需转载该篇文章,请注明来自“搜狗测试”


    展开全文
  • 在测试过程中,如何去定位一个bug(面试题) 首先我们要去定位发现这个bug的来源是属于前端还是后端,我们可以使用fidder进行抓包分析,访问数据的是否抓取请求数据,比对请求数据是否正确,服务器响应时我们...
  • 测试中遇到的bug总结

    万次阅读 多人点赞 2018-09-13 11:35:07
    面试的时候,会经常被问到你测试中遇到的bug,说出印象最深的。只有平时思考,多总结遇到的bug,不断提升自己的level,自然能从容面对面试官的“废物测试”。 1、输入框为空/最大值判断;为空、最大值显示  设计时...
  • 测试过程中印象最深刻的bug?| 万能回答必杀技

    千次阅读 多人点赞 2021-12-09 11:33:18
    描述印象最深的bug,结合现象...原因分析:通过再次成功药品的操作日志发现,实际用户点击删除后,前端会给后端传回name要品名,实际有可能有多个重复的药名,但是开发代码写的删除逻辑是,按照name药品名的对
  • 一、测试过程中主要涉及的文档及其内容 二、测试计划 2.1 测试计划概念 2.2 测试计划作用 2.3测试计划主要内容 一、测试过程中主要涉及的文档及其内容 软件测试过程中主要涉及的文档及其内容 文档名 作用 ...
  • 测试过程管理

    千次阅读 2018-05-10 13:23:25
    测试过程管理介绍的内容包括:测试演化、测试设计、测试执行、测试监控。测试演化软件测试应该是软件研发全生命周期的测试,包括软件需求测试、软件设计测试、单元测试、集成测试、接口测试、系统测试、用户验收测试...
  • 2021年软件测试面试题大全

    万次阅读 多人点赞 2020-11-30 15:16:59
    简述测试流程: 1、阅读相关技术文档(如产品PRD、UI设计、产品流程图等)。 2、参加需求评审会议。 3、根据最终确定的需求文档编写测试计划。...补充测试用例设计过程: 根据需求得出测试需求 设计测试
  • 测试】性能测试工具LoadRunner的基本使用流程

    万次阅读 多人点赞 2020-06-24 12:16:57
    功能:LoadRunner是一种适用于许多软件体系架构的自动负载测试工具,从用户关注的响应时间、吞吐量,并发用户和性能计数器等方面来衡量系统的性能表现,辅助用户进行系统性能的优化。 组成:LoadRunner主要包括三个...
  • 使用风险、优先级、测试环境和数据依赖以及限制条件来制定测试执行的进度,该进度针对测试目标、测试策略和测试计划是完整和一致的。 使用可追溯性来监督测试进展与测试目标、测试策略和测试
  • 软件测试管理——测试的风险分析

    千次阅读 2016-07-14 13:43:54
    作为一名测试管理人员必须平时的工作,分析这些风险的类别,并且想出对策尽最大程度的降低这些风险。1.软件需求的风险主要表现以下的几个方面:■需求变更风险,项目的后期用户总是不停的提出需求变更从而...
  • 所以,这就要求的你平时工作中遇到bug时试着自己去定位,定位bug的过程远比你的单纯的执行测试用例有“价值”(自我技能提高的价值),定位bug的过程中你需要掌握和运用更多知识。 另外,建议你平时养成总结的好...
  • RAD(Rap Application Development,快速应用开发)模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,所以又称软件测试的V模型。 阶段步骤 V模型大体可以划分为以下几个不同的阶段步骤:需求分析、...
  • 软件测试中遇到的比较印象深刻的问题: 项目名称是某幼儿园报名网站,首先我介绍一下这个项目,这个项目是用来给某地区的家长抢报幼儿园名额而服务的,毕竟有的幼儿园人气比较火爆,因此会出现人多名额少的情况,...
  • 一个完整系统的测试过程

    万次阅读 多人点赞 2016-05-23 21:54:14
    需求审查主要是我们对需求文档的理解,并熟透整个系统的每个功能和流程,对后期所有的测试建立思路,后续的工作基本依照需求进行操作,所以需求审查是一个很重要的一步。 对于初次进行需求审查,我采用我以前文章的...
  • 测试过程分为哪些阶段

    万次阅读 2019-08-15 21:53:50
    软件测试分为四个阶段: 单元测试阶段、集成测试阶段,系统测试阶段,验收测试阶段。 1、单元测试阶段:单元测试是以最小单位的测试、也是最初期的测试阶段、一般是以一个函数方法窗口、一...逐渐组装的过程中会出现...
  • 性能测试过程及模型构建

    千次阅读 2017-10-30 21:02:47
    性能测试过程中,建模实际上可分为两个过程,性能测试过程和模型构建过程,性能测试过程主要完成对系统进行性能测试,并搜集相应的测试结果,形成测试过程文档;模型构建主要是根据搜集到的性能测试需求和生产系统...
  • 软件测试的风险分析与解决办法

    万次阅读 2018-05-22 11:24:27
    作为一名测试管理人员必须平时的工作,分析这些风险的类别,并且找出对策尽最大程度的降低这些风险。一:软件需求的风险主要表现以下的几个方面:1.软件需求本身不清晰或者开发商对产品的需求特性理解不准确有...
  • 一个系统测试的完整过程

    万次阅读 多人点赞 2018-11-23 19:28:09
    需求审查主要是我们对需求文档的理解,并熟透整个系统的每个功能和流程,对后期所有的测试建立思路,后续的工作基本依照需求进行操作,所以需求审查是一个很重要的一步。  对于初次进行需求审查,我采用我以前文章...
  • 软件测试学习笔记(三)软件测试过程

    万次阅读 多人点赞 2016-11-30 10:05:03
    软件测试的集中测试过程简介
  • 完整的系统测试过程

    千次阅读 2019-01-24 18:30:50
    为了更清晰的知道系统测试过程,先写一些测试方面的概念: 1、软件测试分为四个阶段:单元测试、集成测试、系统测试、验收测试。 (1)单元测试:测试函数,依据LLD,一般开发人员完成,属于白盒测试。 (2)集成...
  • 相信大家工作中面试过程中经常被问到,让你印象最深刻的一个bug是什么,这是一个开放性的题目,并没有标准答案,每个人接触过的系统都不一样,遇到过的问题也不一样,可能面试官只是想看...
  • 软件测试风险评估分析

    千次阅读 2019-09-21 15:55:28
    众所周知,软件测试是把控软件质量的重要防线,但软件测试过程中也会存在潜在的风险。 软件测试的风险是指软件测试过程出现的或潜在的问题。 造成的原因主要是: 测试计划不充分 测试方法有误 测试过程偏离,...
  • 软件测试中遇到的缺陷等

    千次阅读 2021-09-22 16:20:09
    软件测试中遇到的缺陷等 缺陷:就是软件或程序存在的某种破坏正常运行能力的问题,错误,或者是隐藏的功能缺陷,软件缺陷的属性包括缺陷标识 缺陷类型,缺陷严重程度,缺陷优先级,缺陷来源,缺陷原因等 缺陷产生...
  • 前言:前几天用jmeter做性能测试的时候,遇到一个响应时间长的性能问题,简单总结一下,分享给大家,希望能给大家性能测试过程中类似问题提供一个性能问题分析定位的思路。 现象如下图,响应时间很长,达到了18...
  • 2. 测试过程 3. 测试方法分类 4. 黑盒测试 (1)黑盒测试概述 (2)等价类划分方法 (3)边界值方法 5. 白盒测试 (1)白盒测试概述 (2)白盒测试的覆盖标准 (3)基本路径法 (4)循环测试法 (5)...
  • 单元测试过程

    千次阅读 2018-09-18 17:37:18
    单元测试 测试四部曲 1. 初始化数据 2. 执行要测试的业务 3. 验证测试的数据 4. 清理数据 class NowstagramTest(unittest.TestCase): def setUp(self): app.config['TESTING'] = True self.app...
  •   软件测试过程,是指一个软件的测试过程,而不是软件测试的过程,这里要注意与软件测试基础流程区分开来。软件测试过程分为单元测试、集成测试、系统测试和验收测试。    ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,360,114
精华内容 944,045
关键字:

在测试过程中