答:测试是无处不在的,撇开软件,从生活来看比如买回来一个东西,会去检查质量问题,考试交卷前会检查等其实这都是在测试,目的就是为了发现错误,避免影响应用体验。回到程序中,测试是产品上线的最后一道把关,如果测试工作做得到位,就能避免很多的问题,像复工后钉钉系统短崩、12306高峰期买票老进不去,这其实就是性能做的不够好,测试人员在性能测试时也没测出来它的饱和值,所以说,测试在软件中是非常必要的,可以找出软件中存在的问题。
答:在平时的不断积累中,我掌握了测试的基本理论,编写测试用例的方法、常用的测试模型、测试工具的简单使用,比如loadrunner、selenium、禅道等,还有一些简单的测试框架
兴趣很重要啊,这个参考一名优秀的测试人员应该具备哪些技能,主要从性格、能力、逆向思维、耐性等方面展开来讲
测试和研发:两者在工作职责、难易程度、技能要求等方面都有所不同。测试主要职责是找出程序中存在的问题,相对开发来说广度大专业度低,技能要求更广泛,像测试手段以及测试工具使用代码走读、业务和架构分析以及用户需求方面都要有所掌握。研发的主要职责是实现产品的功能,相对测试来说广度低专业度高,专业技能要求也更高。工作环境基本类似、在敏捷开发下,两者的压力也差不多。
测试和测开:功能性测试主要是手工的去执行写好的测试用例,验证实际输出和预期结果是否一致。而测试开发是把手工要做的活编写成自动化测试脚本,代替手工测试的这个过程。
答:总的来讲,程序没有实现用户的合理需求时就说明有bug。规格说明书时,一般产品都会有规格说明书,在规格说明书合理且正确的情况下,这时要是程序和规格说明书不符就是bug;
一条bug记录最基本应该包含bug编号、bug所属模块和版本、bug的优先级、具体的问题描述还有预期行为的描述、bug的级别、还有它的发现日期以及谁发现的、修改日期怎么修改的谁修改的,以及回归结果等,有多个bug同时存在时应该条理化,必要时可以有错误截图和日志,帮助开发人员清晰的定位bug;
新发现一个bug提交到平台还没指派给开发时它的状态是new,分派给开发以后状态就变成了open。 如果开发直接认为这个bug不需要修改,就变成了rejected,要是开发觉得可以延迟修改,就是dalayed。要是直接修改的话,修改完就是fixed,测试回归通过以后就是closed,不通过在reopen。
答:开发认为这不是bug,可能是需求不明确,我和开发产生了歧义,可以找产品经理确认一下需求,然后再决定要不要修改。也有可能是我把bug描述不清,这个时候我会像开发解释我确定它是bug的依据是什么,站在用户的角度去评判看会不会影响使用体验,如果开发依然认为这不是bug,可以发起bug评审,像项目评审同行评审和用户评审。同时也要提升自己的业务能力,尽可能的附上bug相对应的解决方案。
像字体大小显示、图片有不明显色差、
答:首先看bug的等级,如果是影响使用的功能性bug,必须得辛苦开发人员及时修改,如果是不影响功能的建议性的bug,时间允许的话尽量完善后在上线,要是时间不允许,可以先上线,因为现在产品迭代更新比较快,可以再下一次的版本中进行修复。
研发的生命周期首先是对问题进行定义规划,讨论产品可行性,在进行需求分析,根据需求分析的结果对整个系统进行软件设计,比如数据库设计框架设计,设计完成以后就可以开始进行程序编码了,然后进行软件测试发现bug并加以纠正,最后进行长期的运行维护,主要包括纠错性维护和改进型维护。
测试的生命周期(我觉得流程也是这,不知道认识有偏差没):先进行需求分析得出测试需求,测试计划阶段根据需求编写测试计划,测试设计主要搭建测试用例框架编写具体的测试用例,测试执行阶段就是拿自己写的测试用例去执行,最后是测试评估编写具体的测试报告。
答:自动化测试包括功能自动化、性能自动化、安全自动化。我们平常说的指功能自动化,就是把手工测试用例转化成脚本实现,主要是为了把人从重复的活动中解放出来,主要用于回归测试,出错率低。而非自动化测试就是手工去测试,执行效率慢,量大的时候容易出错,两者不可相互替代,他们是相辅相成的。
答:应包括测试背景、测试范围、测试环境、测试方法、测试结果说明还有质量或风险评估。
黑盒测试就是功能性测试,比较简单,不关心程序的内部实现,从用户角度很容易理解,只看输出结果和预期的是否一致,它的主要测试方法有等价类边界值、因果图、错误推测,它的优点是执行起来比较快,不关心内部细节,缺点是很多程序路径都没有被测试到,这就会存在隐藏问题,测试用例不清晰的话,测试很难执行。
白盒测试是结构性测试,需要去关注程序的源代码和它的内部逻辑结构,主要测试方法包括代码检查、程序编译、路径覆盖、逻辑覆盖、循环覆盖、静态结构分析等,它能仔细考虑软件的实现,对代码的测试比较彻底,能揭示隐藏在代码中的错误,因为测试基于代码,只能知道开发人员实现的对不对,而不能得知设计是否正确,系统庞大时测试成本机会很高。
答:主要包括白盒测试(逻辑覆盖、循环覆盖、基本路径覆盖)和黑盒测试(等价类、边界值、错误推测法、因果图法、场景法、状态图、随机测试)
答:系统在一定性能下平稳运行72小时,在bug提交平台里不存在一般级别以上的bug,普通bug数量不超过3个,bug的修复率在90%以上,项目经理和测试经理签字通过了这个版本。
答:测试用例的要素包括测试编号、模块名称、编写人和编写日期、操作说明、输入数据以及预期结果。好的测试用例是一个完备的集体,能够完全覆盖测试要求、等价类的划分也要准确。
答:敏捷开发是当下很流行的一种开发模式,主要特点是周期短迭代快,Scrum是当下比较常用的一种方式,它主要包括三个角色,product owner是产品经理,负责整理和讲解use story(用户故事),制定这一期迭代要完成的任务,scrum master是项目经理,负责召开各种会议,成员在会议里回答任务进度和所遇到的问题,team是研发团队,由不同技能的成员组成,共同完成每一次迭代。
常开的会议包括四个,迭代计划会议主要是讨论这一期迭代应该完成哪些目标、每日例会主要是团队成员回答任务进度还有今天要完成什么、演示会议就是迭代完成后相关人员演示迭代的成果、回顾会议是对本期迭代进行总结并制定改进计划。
开发模型有瀑布模型、螺旋模型、增量迭代、敏捷开发;瀑布模型是线性进行的,适用于需求稳定或者公司已有类似产品的项目,它强调开发的阶段性,缺点是不能适应后期需求的多变性,发现缺陷也比较晚造成修复成本太高;螺旋模型是一个渐进式模型,它适合规模庞大、复杂度高风险高的项目,强调每个开发阶段的质量,因为它引入了非常严格的风险识别,这就需要大量人员和资金的投入,影响项目的进度;增量和迭代目的是减少项目风险;现在大部分公司都用的是敏捷开发模型,主要特点是周期短迭代快,Scrum是当下比较常用的一种方式,它主要包括三个角色,product owner是产品经理,负责整理和讲解use story(用户故事),制定这一期迭代要完成的任务,scrum master是项目经理;
测试模型有四种,vwhx,常用的有v模型和w模型,v模型以编码为分界点,明确的标注了测试过程中存在的不同测试类型,开发阶段和测试阶段有明确的对应关系;但它仅仅把测试过程放在需求分析、系统设计之后的一个阶段,忽视了测试对需求的分析和验证;w模型由两个v模型组成,代表了开发和测试两条线并行;测试的对象不仅仅是程序,需求设计同样也要测试,有利于尽早全面的发现问题;但需求、设计、编码等活动被视为是串行的,测试和开发活动也保持着一种线性的前后关系,上一阶段完全解除,才可正式开始下一阶段的工作不能够很好的支持迭代的开发模型,,无法支持敏捷开发模式;
我认为一个优秀的测试人员首先应该对测试有很浓厚的兴趣,对待工作有很强的责任感和压力感;思维方面应该不走寻常路,从逆向去发现问题;同时也应该具备一定的开发能力和文字功底,保证写出来的测试用例清晰可行;也应有很好的沟通能力,和周围的同时能很好地交流
我先点赞为敬,你们看着办哈