软件测试
文章平均质量分 68
多测师111
这个作者很懒,什么都没留下…
展开
-
测试工作的开展思路
② 软件测试位于软件开发生命周期的末端,如果依靠测试人员来发现所有的bug来保证质量的话,那么风险就会后置,导致问题修复的成本增加,同时也增加了修复问题带来新问题的风险,因为在项目末端是不可能投入过多的成本来进行那怕接近全面覆盖的测也正因为如此,我们是无法决定一个软件产品质量的好坏的,只有PM设计出产品需求,RD编码完成,我们才能够通过我们的工作,促进PM、RD改进他们的产品、系统,从而达到产品、系统的高质量。我们进行测试设计的依据是对于软件产品需求的全面和深入分析,但是需求决不全是软件测试的依据。原创 2023-03-14 10:10:08 · 566 阅读 · 0 评论 -
探索测试的一些总结
1)探索性测试与脚本化测试的主要区别:1)探索性测试将更多更高的认知水平的工作放在测试执行,而脚本化测试则更关注测试设计;13)探索性测试过程中的一个重要挑战是如何设计测试用例(尽管不一定是脚本化的,也可能是在测试执行的时候进行测试设计),例如:从测试技术到测试用例、从失效模式到测试用例、从风险列表到测试用例、从测试思想到测试用例。探索性测试的设计不是为了控制,而是为了指导你的测试。9)不同的测试对象和测试目标,需要不同的测试策略和测试技术,而这将得到不同的测试用例、不同的测试文档与不同的测试结果。原创 2023-03-10 10:11:35 · 249 阅读 · 0 评论 -
可复用测试用例描述要素
测试用例的输入、操作、预期结果和评估标准、前提条件是测试用例不可少的要素,但对于可复用测试用例而言,这是不够的。17)附件:对测试用例附加的一些描述信息,可任意表示,例如文本、图像、模型、与测试用例有关的一些文档,方便测试人员进一步理解测试用例。5)测试阶段:被测软件所处的测试阶段,包括单元测试、部件测试、配置项测试、系统测试,或者单元测试、集成测试、确认测试、系统测试。7)测试类型:有功能测试、性能测试、安全测试、用户界面测试、接口测试、安装测试等,可选择多项。lO)软件编码:描述被测软件的编码语言。原创 2023-03-09 10:54:37 · 471 阅读 · 0 评论 -
如何提高软件测试执行力
例如在一个测试的case中,有70%的时间花费在沟通上,不但不能保证充裕的测试时间,而且有理由相信沟通的方式有问题。这点可能在测试新人中,体现的较为明显,在执行老人写的TC的时候,没有很严格的准备前置条件中的数据,用无效的测试数据,执行的测试用例当然也是无效的。在发现一个缺陷的时候,有些时候,开发的同学会给出一些解释,来说明提出的是一个无效缺陷,那么这个时候,作为测试人员必须要有一定的分析能力。高效执行就是有目标,有计划,通过有效的方法,策略让要做的事情高质量,高效率的得到落实,并最终达成目标。原创 2023-03-08 10:41:05 · 445 阅读 · 0 评论 -
测试按方向的分类
②负载测试:系统在极限工作条件下,最多能持续多久——可能发生内存泄漏/溢出,导致整个软件崩溃 (例如在软件的运行过程中,用户产生的数据在不断地堆积,没有更多地内存存放,超出了容量的范围,就溢出了)①APP:又分为Android测试(测试不同的系统,不同的分辨率,不同的屏幕,不同的品牌)和iOS测试(iOS系统互相兼容且保持一致,一般不用做测试)按方向来分,主要分为功能测试、性能测试、安全测试三大类,其他的还有一些细小的划分,例如兼容性测试,易用性测试,稳定性测试,UI界面测试等。原创 2023-03-07 09:59:53 · 301 阅读 · 0 评论 -
处理回归BUG最佳实践
肯定地说,回归测试非常消耗人力。从管理层的角度来看,很多人认为大部分的回归测试消耗的资源毫无意义,因为回归测试很难有等量的回报。所以在前期测试规划时候一定要留有足够的时间完成基本的测试,确定影响范围,及时跟进需求的变更。对于退出标准,在完成测试周期之前,应满足条件,例如执行所有测试并且不保留任何未解决的BUG。测试的某些阶段经常被忽略,不幸的是,回归测试首当其冲,最易被忽略。测试人员在保障质量前提下第一时间完成现有的工作,它将为提供高质量的重要依靠,一旦发生延期,很可能会导致整个流程产生更多的不确定性。原创 2023-03-06 10:07:16 · 200 阅读 · 0 评论 -
精准测试对于覆盖率技术的全新诠释
而自动化测试,天生的脚本开发特性以及复杂的控制特性,对绝大部分普通测试工程师来讲,这方面处于明显的劣势。精准测试因为不改变原有的测试流程,这使得它在手工或者自动化测试中都能使用,例如:精准测试产生的数字化测试数据对整个自动化测试过程可以进行深入跟踪和分析,精准测试的分析降低了自动化测试人为的干预度,使得自动化测试更加智能。5、最大的问题在于普通开源产品必须面对代码进行覆盖率的统计,而绝大部分场合测试工程师是不具备拿到代码的权限的。精准测试和手工、自动化测试的关系,以及各自对测试行业的导向。原创 2023-03-03 14:54:21 · 463 阅读 · 0 评论 -
测试开发工程师的概念怎么来的?
首先是人工的测试需要去做,第二个是自动化的测试要去做,第三个,专项的测试也要去做,之后是什么呢,测试的左移,对研发质量要提前发现一些问题,同时上线之后的产品要进行质量的监控,发现一些线上用户的崩溃问题,了解所有的业务场景。原创 2023-03-03 10:04:00 · 313 阅读 · 0 评论 -
测试结束参考标准
对于测试“覆盖率”的原则,个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求,包括行业隐性需求、功能需求和性能需求等等,只要测试用例执行的覆盖率达到100%,基本上测试就可以结束。大多数情况下,每个项目从开始就要编写开发和测试的Schedule,相应的在测试计划中也会对应每个里程碑,对测试进度和测试结束点做一个限制,一般来说都要和项目组成员(开发,管理,测试,市场,销售人员)达成共识,团队集体同意后制定一个标准结束点。我们可以通过缺陷的趋势图线的走向,来定测试是否可以结束,这也是一个判定标准。原创 2023-03-02 09:58:12 · 381 阅读 · 0 评论 -
web测试的基本流程
(2)包含系统的哪些模块哪些方面(功能、性能、数据)、测试范围、测试环境 、测试工具 、测试数据、测试方法 、测试人力资源安排、测试进度安排、测试输出 、风险分析 、硬件环境、软件环境、借助到的一些测试浏览器兼容性工具、自动化测试工具、性能测试工具。(3)黑盒测试、白盒测试、冒烟测试、验收测试、包含哪些文档、报告等、一般有:测试计划、测试方案、系统评测报告、缺陷报告等、系统上线后可能会出现的问题,一些现在尚未解决的bug,各种使用环境可能出现的问题等;10)后续的版本迭代测试,注意做好回归测试;原创 2023-03-01 10:02:03 · 2756 阅读 · 0 评论 -
故障注入技术在软件测试中的应用
为了准确地利用故障注入技术对软件容错进行评测,利用“动态生成一静态存储一动态触发”的故障注入模型,结合软件测试的特点,在保证评测准确性的前提下,解决了容错机制导致的故障需求复杂、故障生成困难等问题,实现了一个较为理想的故障注入测试方法在软件测试中的应用。故障注入是指按照选定的故障模型, 用人工的方法有意识地产生故障并施加于特定的目标系统中,以加速该系统的错误和失效的发生,同时采集系统对所注入故障的反应信息,并对回收信息进行分析,从而提供有关结果的过程。主要从控制容错性和数据容错性两个方面进行软件的评估。原创 2023-02-28 10:13:58 · 529 阅读 · 0 评论 -
测试报告踩坑的点
裁剪的要特别明确出来:由于各种原因,原来计划的功能或者需求没有得到实现,被裁剪的功能要特别的明确标注出来,让大家清楚的知道最终上线的是哪些内容。避免因为信息不对称引发误解。测试报告作为测试人员的核心输出项,是体现自己工作价值的重要承载工具,需要我们认真对待,所以我们要重视测试报告的输出,那么在编写测试报告的时候,我们有哪些点需要注意的呢?测试风险:在测试过程中遇的考虑到的风险,上线后可能发生的风险,如果你知道,请明确出来,让团队各角色(研发、产品、部门负责人等)根据你的风险分析,一起来决定是否发布版本。原创 2023-02-27 10:02:40 · 334 阅读 · 0 评论 -
复杂场景的接口测试
测试异步调用的业务逻辑复杂性:因为异步 API 通常发生在一些比较慢的操作上,比如数据库 I/O、消息队列 I/O 等,此时测试往往需要去验证数据库中的值、消息队列中的值等,这就需要测试代码具有访问和操作数据库或者消息队列的能力。背景:API 之间是存在依赖关系的,比如你的被测对象是 API A,但是 API A 的内部调用了 API B,此时如果由于某种原因,API B 在被测环境中处于不可用状态,那么 API A 的测试就会受到影响。存在的情况:存在后一个API需要使用前一个API返回结果的情况;原创 2023-02-24 09:59:50 · 393 阅读 · 0 评论 -
测试中的四大板块
验收测试是唯——个客户真正参与其中或者客户能够理解的测试,通常是由使用系统的用户或客户来进行,同时系统的其他利益相关者也可能参与其中。系统测试阶段要完成软件的各个方面的测试内容,系统测试的策略包括:功能测试、性能测试、安全性测试、恢复性测试、兼容性测试等等。与在开发环境中进行的系统测试不同,验收测试是在客户的真实操作环境中进行,但如经用户同意,也可以在公司内模拟用户环境进行。集成测试是把单独的软件模块结合在一起作为整体接受测试,其目标是利用已通过单元测试的构件建立设计中描述的程序结构。原创 2023-02-23 10:06:21 · 412 阅读 · 0 评论 -
做主管如何规范测试团队
很多时候没有需求评审,测试同学连业务是谁都不知道,经常是基于开发的讲解进行测试,写不写测试用例也是看自己习惯了,开发同学也不清楚测试同学要测什么,毕竟也没有时间进行测试用例评审(也没有人负责安排)。开发完了就跟测试同学说一声,有这么个需求,这个需求今晚/这周上线,你测一下,好像测试是个很随意的工作,并且每个任务给过来都说是紧急需求,测试时间也是不够的,导致测试非常被动。而想要提升效率,应该是先文档化,将知识沉淀下来,然后是脚本化,将重复性的工作自动化,最后是结合基础脚本实现平台化。原创 2023-02-22 14:11:43 · 962 阅读 · 0 评论 -
性能测试的二八原则
实际上,登录请求数分布是一个正态分布,最高峰时肯定比4.1/秒更高,高峰段实际上完成了80%的业务量,却只花了20%的时间。所谓2-8原则,即80%的bug多发生在软件的20%的模块。------> 软件测试执行过程中需要将时间倾斜在重要模块的测试用例中,从而使测试更加有效,发现bug。-----> 站在用户角度,并非研发实现的角度,正确地选择重要模块作为测试重点,从而不偏离方向。-----> 设计用例时需要将时间花倾斜在复杂的20%核心模块上,从而设计更高效的测试用例。原创 2023-02-21 09:52:23 · 806 阅读 · 0 评论 -
测试人员如何运用好OKR
试试画图的方法,这个方法屡试不爽,例如遇到人生难题,经常会在书写本上列出两列:源动力、阻力,如果源动力大于阻力,就去行动,如果阻力大于行动力,再分析阻力是什么,我能否解决,解决不了,那我就放弃。我认为狼性文化的创业公司用KPI激励比较好,有情怀的公司,OKR是个不错的选择,不同的管理哲学,有不同的管理方法,没有对错,没有好坏,就像两个人相爱,只有合适不合适。去年公司从KPI换OKR之后,我也有一段抓瞎的过程,然后自己找了两本书看,一本是《OKR工作法》,一本是《这就是OKR》,算是有一些经验可以分享。原创 2023-02-20 14:10:23 · 663 阅读 · 0 评论 -
功能测试怎么学
这是我们针对于软件测试它的一些基础功能测试所要学习的一个路线,从基础知识到测试策划到测试设计到测试执行到总结,那不管怎么学习都要记得动手实战最重要,实践比我们学习一些知识更重要,用一些适用的项目来进行真正的测试实践,比如你可以用支付宝、微信、淘宝等等来模拟你的测试实战,来帮助他们用例设计以及发现问题。到了执行阶段,其实并不是简单的说写好了用例就是来执行的,在执行过程中一定伴随着测试用例的修改,接下来就是发现缺陷,缺陷管理的流程,缺陷跟踪分析的步骤,除了这些我们还要学习易用性测试和兼容性测试这些方面的测试。原创 2023-02-17 09:58:19 · 120 阅读 · 0 评论 -
单元测试的优势
单元测试是针对代码单元的独立测试,核心是“独立”,优势来源也是这种独立性,而所面临的不足也正是因为其独立性:既然是“独立”,就难以测试与其他代码和依赖环境的相互关系。单元测试的优势,正是系统测试的不足,单元测试的不足,又恰是系统测试的优势。不能将单元测试当做解决所有问题的万金油,而需理解其优势与不足,扬长避短,与系统测试相辅相成,实现测试的最大效益。由于单元测试是由在集成之前测试单个代码的开发人员执行的,这样可以很早地发现问题,并在不影响其他代码片段的情况下解决问题。单元测试可以提高代码的质量。原创 2023-02-16 09:56:27 · 834 阅读 · 0 评论 -
测试用例设计工作中的应用
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图〔逻辑模型〕. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.边界值分析方法是对等价类划分方法的补充。原创 2023-02-15 10:45:46 · 671 阅读 · 0 评论 -
软件测试之优秀的产品质量评估模型的特征
虽然最终能达到90%的测试覆盖目标,但是没有被测试到的10%那部分情况如何,是否真的不需要测试,可能会有哪些风险,对我们来说都是“未知”的。如果我们将这个问题从评估引申到目标的层面,如果我们在制订目标的时候,考虑的不仅仅是指标,而能包含一些如“对重要特性,要达到100%的测试覆盖”“测试方法要包含语句覆盖、判断覆盖、路径覆盖”等的描述,以此作为要达到的质量目标,不仅能解决上述的问题,还能更好地帮助我们确定要进行的测试活动。第一,这些指标覆盖的维度可能不全,我们可能遗漏掉了一些重要的考察项。原创 2023-02-14 10:03:10 · 370 阅读 · 0 评论 -
验收测试分类
在开发该软件的公司内部由该公司内部人员测试的称为: Alpha 测试, Alpha 测试主要看有没有功能缺失或系统错误, Alpha 测试完后一般不会有大问题了。简单来说,阿尔法测试主要是测试人员在开发环境下的测试,贝塔测试是在实际环境中的测试,或者公司内部人员在模拟真实环境中的测试。· 该版本相对于α 版已有了很大的改进,消除了严重的错误, 但还是存在着一些缺陷,需要经过大规模的发布测试来进一步消除。然后把软件拿给用户测试,称为: beta 测试, 主要是看用户对软件外观、使用方便等的反应。原创 2023-02-13 10:02:10 · 480 阅读 · 0 评论 -
软件测试之测试意义
测试人员跟踪需求、验证质量、提交缺陷的同时也促进了开发人员技术的提升,在这个过程中牵扯到项目流程管理的问题,一个优秀的测试在这个过程中会建立一套完成的体系来提高整个团队的工作效率从而来降低开发成本进而把控产品质量,但需明确的是,软件的质量不只是测试人员来把关,最终质量好坏是整个团队的结果。测试是不可穷尽的,测试人员不可能发现系统中所有的缺陷,每个版本发布前也不可能保证所有已知的缺陷都会得到修复,所以反复测试是为了发现更多的缺陷,预防风险。4)一个成功的测试是发现了至今未发现的错误的测试。原创 2023-02-10 09:59:21 · 556 阅读 · 0 评论 -
软件测试之测试数据
测试数据的创建可以完全依赖于 API 调用,当创建测试数据的内部逻辑有变更时,由于此时 API 内部的实现逻辑也会由开发人员同步更新,所以我们依旧可以通过调用 API 来得到逻辑变更后的测试数据,而这个过程对使用来说是完全透明的。容易出现数据不完整的情况,比如一个业务操作,实际上在一张主表和一张附表中插入了记录,但是基于数据库操作的数据创建可能只在主表中插入了记录,这种错误一般都会比较隐蔽,往往只在一些特定的操作下才会发生异常。可以保证创建的测试数据的准确性,原因是使用了和GUI操作同样的API调用。原创 2023-02-09 10:25:23 · 668 阅读 · 0 评论 -
哪类人群适合从事软件测试工作
测试人员发现了问题,就要报bug,bug描述的清晰与否与这个bug是否能够顺利被解决有很大关系,一个bug,有人说了10行的文字也讲不明白,有人一句话就能描述清晰,这个就是表达能力的体现。不得不说的是,测试工作是一个繁琐的工作,需要我们对一个产品不断的进行重复的使用,有的时候过程是比较枯燥的。喜欢在程序中去找寻漏洞、错误的人,软件测试的岗位简直就是为这部分人量身打造的,俗话说,兴趣是最好的老师,如果喜欢测试便会更加愿意自发的为此花费时间,学习吸收效率也会极高。4、认真,细心,不怕麻烦。原创 2023-02-08 10:05:18 · 328 阅读 · 0 评论 -
软件研发流程类型
瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用瀑布模型结构化的分析与设计方法将逻辑实现与物理实现分开。缺点:要有专业的架构师(架构师的职责),当功能与功能之间联系太过紧密的话,不太使用rup模型,比如登录与注册的联系;迭代:指增量开发过程中,各模块的开发是反复进行的,并不是完成了某个模块后就终止该模块的开发转而开发下一个模块,可能还要对之前开发的模块不断完善,增加新功能。增量:软件开发过程中,先开发主要功能模块,再开发次要功能模块,逐步完善,最终开发出符合需求的软件产品。原创 2023-02-07 09:58:32 · 370 阅读 · 0 评论 -
自动化测试建设的难点
而在执行层,执行者有可能是测试背景有不错代码能力的工程师,按理说能补足上面提到的缺陷,但是毕竟不在一个维度,看得到局部,但缺少一些全局视角。我目前直接负责整个公司的质量体系,我的主管也充分授权,但即便这样的情况下,我依然觉得这些横向的测试架构组的产出不容易穿透到业务测试组中:双方考核目标差异、业务条线压力等都行成了厚实的壁垒,阻挡着自动化体系的落地。在版本高速迭代的并且具有敏捷开发能力的互联网公司里,这些流程不合理、资源不足的现象都是合理的,你得承认、接受,并做出妥协,但不要质疑自动化、不要放弃持续建设。原创 2023-02-06 10:05:11 · 352 阅读 · 0 评论 -
解读测试能力素质模型
P7对技术的理解更加成熟,在解决问题的时候,也不仅只考虑技术手段,而是要系统的分析,全面考虑各种方案的可行性,制定出最优的解决方案,下面的例子可以很好的说明。简单的说,P5可以很自信的站在PM面前,说,我认为现在的质量不合格,因为......,现在不能发布,并且PM也认可。P6对被测软件的结构和相关的开发技术有深入的了解,因此P6在提Bug的时候,定位非常准确,还可以分析出Bug的原因,也能发现一些深层次的Bug,开发工程师与P6测试工程师合作时,会感觉非常high。这么说有点抽象,举两个例子说明。原创 2023-02-04 09:55:58 · 2152 阅读 · 2 评论 -
为什么不进行穷举测试?
3)减少测试资源后,最简单的方法是限制样本的规模。规模减少可能出现采样错误,多样化的样本发现的问题可能会超过大样本发现的问题。当然还有在不同配置下进行测试,不同制造商、不同驱动程序、不同操作系统、测试执行的顺序、不同的内存等等。由于我们无法测试所有可能性,任何实际的测试集(测试用例)都是某种程度的样本——代表整个可能测试集合的一个部分或片段。本章主要介绍不对所有可能性进行测试的原因,对于经理和测试人员,都应该了解测试是一种采样过程,需要了解采样给测试所带来的风险。1、可进行测试的数目是无限的。原创 2023-02-03 10:30:50 · 369 阅读 · 0 评论 -
iOS单元测试怎么写 ?
边界条件数据,比如值类型数据的最大值、最小值、DBNull,或者是方法中所使用的条件边界,例如a>100那么100就变成了这个数据的边界。执行单元测试,就是为了证明这段代码的行为和我们期望的一致,比如测试一些功能是否正常,接口是否能正常,特别在一些大的项目,以防止程序被误改或引起新的问题。程序单元是应用的最小可测试部件。单元测试的原则之一就在于我们用来测试的代码要求功能很单一,这其实与良好的代码设计的思想是非常相符的。网络数据层方法的测试,数据接口一般不会太多,这里的测试可以保证接口的正常。原创 2023-02-02 10:10:35 · 219 阅读 · 0 评论 -
软件测试之冒烟测试须知
上面已经提及,冒烟测试并非深入测试,所以我们的重点放在正向的流程验证,保障主流业务场景可测,更深入的测试放在冒烟测试通过以后。此时,冒烟测试的重点可能是系统的核心功能或流程,每次发版基本都会涉及改动,所以冒烟测试自动化脚本也要及时更新。一般冒烟测试过程中发现的问题,都是阻塞性问题,会影响测试进度的推进,所以测试过程中一定要注重问题的解决时效。冒烟测试可以引入自动化,常用于版本发布场景,在进行全量测试前,可以先构建一轮冒烟测试。3、测试:开发提测后,测试根据冒烟用例进行测试验证。冒烟测试只能手工测试吗?原创 2023-02-01 10:23:27 · 477 阅读 · 0 评论 -
测试开发中的虫剂悖论
在制定测试策略时,可以考虑多样化,组合型的测试策略,例如自动化测试+探索测试,确定性测试+随机Fuzzing,从而实现优势互补和效益最大化。对于测试用例,其实也类似。只有经常主动去更新测试策略和用例,堵住漏洞,提升覆盖,我们才能弥补用例有效性衰减的损失,让测试整体有效性保持在一定的水平。bug类似于害虫,用例类似于农药,重复使用固定的一批测试用例,能发现的bug就越来越少,遗漏的bug就会越来越多。例如,在采用基于风险的测试策略时,哪个模块,哪个环节风险大,我们就应该将测试资源朝这个模块,这个环节倾斜。原创 2023-01-31 10:49:58 · 1369 阅读 · 0 评论 -
测试人员提高业务掌握度的方案
每个组出一套卷子,涵盖业务模块的理解、问题的排查、业务架构的绘制和说明等等。由测试人员为责任人,自己尝试去了解本项目的各模块详情,各模块的作用,本身就是对业务的一种深入学习和掌握。测试人员除了掌握测试相关技术,比如测试流程、测试用例编写思路、自动化脚本的编写、维护之外,还需要对自己所测试的具体业务进行学习和掌握。对各组模块划是有梳理的,方便测试人员了解缺陷的各个业务模块名称,以及每个模块大致起到的作用,模块的负责人。只有这样,才能去涉及灰盒、白盒测试,在测试执行过程中,提高自己分析、定位问题的能力提升。原创 2023-01-30 09:55:53 · 312 阅读 · 0 评论 -
移动应用测试流程
测试人员根据测试用例进行测试,在完成一轮测试后,将测试过程发现的bug提交到项目管理工具上,如jira,redmine,bugzilla, testdirecor等。参加软件功能设计,在软件编码之前,在仍有可能大的设计变更的时候,积极参加软件的计划阶段,这会帮助我们了解正被考虑的折衷和权衡从而了解客户需要的产品的雏形。在此阶段内,可以进行测试用例的设计,因为在设计测试用例过程中,更加容易掌握整个应用的流程功能,并且还能将设计图上模糊或不合理的纠出来,从而进一步明确需求。功能测试侧重于一个模块的测试。原创 2023-01-29 10:17:15 · 2010 阅读 · 0 评论 -
系统测试的具体测试类型
系统测试:是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统,作为基于整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。(8)可靠性测试:在真实的或仿真的环境中,为做出软件可靠性估计而对软件进行的功能(其输入覆盖和环境覆盖一般大于普通的功能测试)(9)恢复性测试:对有恢复或重置功能的软件的每一类导致恢复或重置的情况,逐一进行的测试。原创 2023-01-09 10:10:02 · 1112 阅读 · 0 评论 -
软件测试之维护性测试
5)易测试性:系统建立测试准则,通过测试 执行来确定测试准则被满足的有效性和效率的程度,是否易于选择检测点编写测试用例、软件的功能或配置被修改后,验证是否可对修改之处进行测试。4)易修改性:系统可以被有效地、有效率地修改,且不会引入缺陷或降低现有产品质量的程度,可从扩充系统应用、软件版本更新时的数据操作、系统参数配置、用户权限配置。维护性测试用于评估系统能够被预期的维护人员修改的有效性和效率的程度,可从模块化、可重用性、易分析性、易修改性、易测试性、易维护性。系统参数配置:是否陈述软件支持系统参数配置。原创 2023-01-07 10:09:13 · 1898 阅读 · 1 评论 -
软件测试之沟通技巧
6、问题快速升级机制(超过1天仍无法解决的需要告知所有干系人,因什么原因导致无法解决,预期解决时间是什么时候),自己无法解决,快速反馈到对应关系人处,对方仍无法解决,反馈到领导,由领导协商解决。3、莫要想当然,问题要一次描述清楚,对方是否能理解你描述的,对方是否有时间参考你前后聊天记录,对方是否为你本次沟通第一责任人都是关系问题解决进度的影响因素,一次描述清楚是必要原则。5、没有形成闭环,导致问题搁置,比如对方答复你后,你没有回复收到,或者你处理完后没有通知三方,导致对方认为问题没有解决。原创 2023-01-06 09:53:29 · 259 阅读 · 0 评论 -
测试的准入准出
测试的准入住处是指什么情况下可以开始当前版本的测试工作,什么情况下可以结束当前版本的测试工作。有时,在测试过程中可能会出现一些意外情况导致测试工作暂停,这个暂停并不是上述所说的测试结束,而是非正常的。(1)测试人员进行冒烟测试时发现重大缺陷,导致测试无法正常进行,需要暂停并返回开发。(3)测试项目通过基本的冒烟测试,界面上的功能均已经实现,符合设计规定的功能。(2)测试人员进行冒烟测试时发现Bug过多,可以申请暂停测试,返回开发。(4)如果测试人员有其它优先级更高的任务,可以申请暂停测试。原创 2023-01-05 10:08:40 · 538 阅读 · 0 评论 -
回归测试用例选择方法
譬如说第一轮测试需要花上10天跑用例,那么到后期就没那么长的时间,可能就是1~2天的测试时间,在后期有时候一天就有一个新版本,这时候就要求 测试人员能快速的进行一轮回归测试。2、一般的软件测试流程是后期快速迭代的,bug在后期是快速收敛的,debug和测试的周期也是越来越短,频率是越来越高,根据微软的统计,按照他们的经验,一般 开发人员解决3~4个bug会衍生出一个新的bug,这就是必须作回归测试的原因。②新修改的功能的关联功能,就是有耦合的部分,这个一般最好咨询一下开发人员。②哪些功能是用户最常用的?原创 2023-01-04 10:08:10 · 184 阅读 · 0 评论 -
明确接口测试自动化需要的功能
举个例子,我们通过设备信息查询接口查询到当前天猫精灵音箱的设备信息,该接口会返回一个 UUID,接下来我们要通过用户信息查询接口去查询当前设备绑定的用户信息,此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。日志包含执行的具体执行接口、请求方式、请求参数、返回值、校验接口、请求时间、耗时等关键信息,日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题,二来是发现 bug 时方便向开发反馈提供数据,开发可以从触发时间以及参数等信息快速定位到问题所在。原创 2023-01-03 16:19:01 · 161 阅读 · 0 评论