2023年度软件测试主管面试题,菁选2篇.docx
-
资源ID:94223847
资源大小:13.13KB
全文页数:3页
- 资源格式: DOCX
下载积分:15金币
快捷下载
会员登录下载
微信登录下载
三方登录下载:
微信扫一扫登录
友情提示
2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
|
2023年度软件测试主管面试题,菁选2篇.docx
2023年度软件测试主管面试题,菁选2篇 1、如何理解强度测试? 参考答案: 强度测试是为了确定系统在最差工作环境的工作力量,也可能是用于验证在标准工作压力下的各种资源的最下限指标。 它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统力量到达的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源缺乏的状况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境. 强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大最小*均)以及挨次指标等 强度测试需要对系统的构造熟识,针对系统的特征设计强度测试的方法 2、如何理解压力、负载、性能测试测试? 参考答案: 性能测试是一个较大的范围,实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。 压力测试是对效劳器的稳定性以及负载力量等方面的测试,是一种很*常的测试。增大访问系统的用户数量、或者几个用户进展大数据量操作都是压力测试。而负载测试是压力相对较大的测试,主要是测试系统在一种或者集中极限条件下的相应力量,是性能测试的重要局部。100个用户对系统进展连续半个小时的访问可以看作压力测试,那么连续访问8个小时就可以认为负载测试,1000个用户连续访问系统1个小时也可以看作是负载测试。 实际上压力测试和负载测试没有明显的区分。测试人员应当站在关注整体性能的高度上来对系统进展测试。 3、什么是系统瓶颈? 参考答案: 瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面力量不能满意用户的特定业务要求,“特定”是指瓶颈会在某些条件下会消失,由于究竟大多数系统在投入前。 严格的从技术角度讲,全部的系统都会有瓶颈,由于大多数系统的资源配置不是协调的,例如CPU使用率刚好到达100%时,内存也正好耗尽的系统不是许多见。因此我们争论系统瓶颈要从应用的角度争论:关键是看系统能否满意用户需求。在用户极限使用系统的状况下,系统的响应仍旧正常,我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。 因此我们测试系统瓶颈主要是实现下面两个目的: -发觉“外表”的瓶颈。主要是模拟用户的操作,找出用户极限使用系统时的瓶颈,然后解决瓶颈,这是性能测试的根本目标。 -发觉潜在的瓶颈并解决,保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时,系统能够适应变化。满意用户目前需求的系统不是最好的,我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化,或者通过简洁扩展系统就可以适应新的变化。 软件测试主管面试题2 1、文档测试主要包含什么内容? 参考答案: 在国内软件开发治理中,文档治理几乎是最弱的一项,因而在测试工作中特殊简单忽视文档测试也就缺乏为奇了。要想给用户供应完整的产品,文档测试是必不行少的。文档测试一般注意下面几个方面: 文档的完整性:主要是测试文档内容的全面性与完整性,从总体上把握文档的质量。例如用户手册应当包括软件的全部功能模块。 描述与软件实际状况的全都性:主要测试软件文档与软件实际的全都程度。例如用户手册根本完整后,我们还要留意用户手册与实际功能描述是否全都。由于文档往往跟不上软件版本的更新速度。 易理解性:主要是检查文档对关键、重要的操作有无图文说明,文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明确定是不够的,应当附有图表使说明更为直观和明白。 文档中供应操作的实例:这项检查内容主要针对用户手册。对主要功能和关键操作供应的应用实例是否丰富,供应的实例描述是否具体。只有简洁的图文说明,而无实例的用户手册看起来就像是软件界面的简洁拷贝,对于用户来说,实际上没有什么帮忙。 印刷与包装质量:主要是检查软件文档的商品化程度。有些用户手册是简洁打印、装订而成,过于粗糙,不易于用户保存。优秀的文档例如用户手册和技术白皮书,应供应商品化包装,并且印刷精致。 2、功能测试用例需要具体到什么程度才是合格的? 参考答案: 这个问题也是测试工程师常常问的问题。有人主见测试用例具体到每个步骤执行什么都要写出来,目的是即使一个不了解系统的新手都可以根据测试用例来执行工作。主见这类写法的人还可以举出例子:欧美、日本等软件外包文档都是这样做的。 另外一种观点就是主见写的粗些,类似于编写测试大纲。主见这种观点的人是由于软件开发需求治理不标准,变动非常频繁,因而不能根据欧美的高标准来编写测试用例。这样的测试用例简单维护,可以让测试执行人员有更大的发挥空间。 实际上,软件测试用例的具体程度首先要以掩盖到测试点为根本要求。举个例子:“用户登陆系统”的测试用例可以不写出详细的执行数据,但是至少要写出五种以上状况(),假如只用一句话掩盖了这个功能是不合格的测试用例。掩盖功能点不是指列出功能点,而是要写出功能点的各个方面(假如组合状况较多时可以采纳等价划分)。 另一个影响测试用例的就是组织的开发力量和测试对象特点。假如开发力气比拟落后,编写较具体的测试用例是不现实的,由于根本没有那么大的资源投入,固然这种状况很随着团队的进展而渐渐有所改善。测试对象特点重点是指测试对象在进度、本钱等方面的要求,假如进度较紧急的状况下,是根本没有时间写出高质量的测试用例的,甚至有些时候测试工作只是一种帮助工作,因而不编写测试用例。 因此,测试用例的编写要依据测试对象特点、团队的执行力量等各个方面综合起来打算编写策略。最终要留意的“是测试人员肯定不能埋怨,力争在不断提高测试用例编写水*的同时,不断地提高自身力量。