测试面试题
上一篇 / 下一篇 2020-10-08 16:28:58 / 个人分类:面试题
给你一个全新的软件,你就是负责人,你怎么去开展测试工作
参考回答:
第一步:需求分析:我会对这个全新的软件需求进行全面分析,主要的分析点有:1.软件的版本需求合理性,是否可测试;2.项目人员配置(遇到什么问题找谁,有多少人投入测试,测试环境,硬件,软件);3.要测试的软件的主流程,异常流程,测试重点;4。项目整体规划(发布时间
第二步:指定测试策略、测试计划和bug定义标准,这一步主要是针对需求,在已有的和可协调到的资源上做出具体的,可执行的计划,这个阶段的输出是测试计划。测试计划中明确包含测试范围,测试策略,比如功能测试,性能测试,自动化测试,可用性测试,云测,mokey等
第三步:按计划执行,编写测试用例,(编写测试用例的方法:等价类,边界值,错误猜测法,因果图,正交分解法等等)(编写测试用例需要注意的点,用例区分等级,特殊场景考虑:为空(接口空、数据空)、加载超时、网络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断;如果是PC,要注意浏览器(IE,chrome,火狐,苹果的),操作系统(xp,win7,win8,win10,linux,mac)的兼容,如果是手机,注意手机的品牌,操作系统,android版本,手机屏幕尺寸,手机网络等等场景),写完用例,如果有条件,就要评审测试用例
第四步:执行用例,补充场景,记录bug,回归bug(注意开发提测的需求需要冒烟测试通过)
第五步:功能合入,回归测试(各个功能点测试通过之后,再合入)
第六步:提交验收(回归测试通过之后,提交给验收人员进行验收)
第七步:发布上线(全新的软件,先是小范围内测,观察线上数据(如:crash,用户反馈,运营数据等)如果有产品认为严重的问题,则需要修复后重发,符合预期才能扩大发布)
如果你发现了bug但是开发不认为是bug,怎么办
首先找证据支持我说这个是bug,(比如需求文档这么写的,竞品这么做的等等),如果找不到足够的证据支持你的观点,那就将问题升级到小组内讨论,一级一级的上升,直到PM或者项目经理拍板定义
,你觉得bug需要修改,很紧急,但是开发没时间,怎么办
这个你需要先把这个问题说清楚,问题影响范围有多大,然后给PM或者项目经理还有拉上开发一起评审,说明这个问题遗留的风险,如果PM和项目经理接受这个风险,那就可以发布,否则必须修改了才能发布
即使他们接受了,发布之后,也要注意线上的表现,并知会出来
如果线上这个问题表现超过预期,那么就要要求发布hotfix
面试题:如何测试登录模块
**登录在软件测试中是基础,但也会有漏测的情况出现,尤其是对于普通账户密码登录的情况,需要考虑账户密码的长度限制、字符类型、匹配判断等等。
目前市场上常用的登录方式也有很多,账密登录里又支持邮箱、账号、手机号登录。对于同时支持多种登录方式,测试时除了考虑每种方式是否能够登录成功以外,特别需要考虑不同登录方式的优先级、对于用户习惯登录方式的设置和记忆、各种登录方式之间的切换、不同设备的不同方式登录等等。
今天我与大家一起对登录方式及测试重点进行梳理,主要关注一些特殊点,以及容易出现漏测的情况。
下面说一下测试点
功能测试
输入正确的用户名和密码登录成功
输入错误的用户名密码登录失败
用户名正确,密码错误,是否提示输入密码错误?
用户名错误,密码正常,是否提示输入用户名错误?
用户名和密码都错误,是否有相应提示?
用户名密码为空时,是否有相应提示?
如果用户未**,提示请先**,然后进行登录
已经注销的用户登录失败,提示信息友好?
密码框是否**显示?
用户名是否支持中文、特殊字符?
用户名是否有长度限制?
密码是否支持中文,特殊字符?
密码是否有长度限制?
密码是否区分大小写?
密码为一些简单常用字符串时,是否提示修改?如:123456
密码存储方式?是否**?
登录功能是否需要输入验证码?
验证码有效时间?
验证码输入错误,登录失败,提示信息是否友好?
输入过期的验证能否登录成功?
验证码是否容易识别?
验证码换一张功能是否可用?点击验证码图片是否可以更换验证码?
用户体系:比如系统分普通用户、高级用户,不同用户登录系统后可的权限不同。
如果使用第三方账号(QQ,微博账号)登录,那么第三方账号与本系统的账号体系对应关系如何保存?首次登录需要极权等
界面测试
布局是否合理、美观,输入框是否对齐
风格和提示信息用语是否符合语境
登录页面显示是否正常?文字和图片能否正常显示,相应的提示信息是否正确,按钮的设置和排列是否正常
页面默认焦点是否定位在用户名的输入框中
首次登录时相应的输入框是否为空?或者如果有默认文案,当点击输入框时默认方案是否消失?
相应的按钮如登录、重置等,是否可用;页面的前进、后退、刷新按钮是否可用?
快捷键Tab,Esc,Enter 等,能否控制使用
兼容性测试:不同浏览器,不同操作系统,不同分辨率下界面是否正常
性能测试
单用户登录系统的响应时间是否符合"3-5-8"原则
用户数在临界点时并发登录是否还能符合"3-5-8"原则
压力:大量并发用户登录,系统的响应时间是多少?系统会出现宕机、内存泄露、cpu饱和、无法登录吗?
稳定性: 系统能否处理并发用户数在临界点以内连续登录N个时的场景?
安全性测试
1.登录成功后生成的Cookie,是否是httponly (否则容易被脚本盗取)
2.用户名和密码是否通过**的方式,发送给Web服务器
3.用户名和密码的验证,应该是前端验证+服务器端验证, 而不能单单是在客户端用javascript验证
4.用户名和密码的输入框,无SQL 注入攻击风险
5.用户名和密码的的输入框,不能输入脚本 (防止XSS攻击)
6.错误登录的次数限制(防止暴力破解)
7.验证码不能被轻易破解、欺骗
兼容性测试
1.主流的浏览器下能否显示正常
2.不同的操作系统是否能正常工作
3.移动设备上是否正常工作
4.不同的分辨率
易用性测试
1.根据场景,考试是否提供记住用户名密码、自动登录的功能
2.输入账号后,回车登录
连续输入3次或以上错误密码,用记是否被锁一定时间(如:15分钟)?时间内不允许登录,超出时间点是否可以继续登录。
其他测试
用户session过期后,重新登录是否还能重新返回这前session过期的页面?
用户名和密码输入框是事支持键盘快捷键?如:撤销、复制、粘贴等等
是否允许同名用户同时登录进行操作?考虑web和app同时登录
手机登录时,是否先判断网络可用?
手机登录时,是否先判断app存在新版本?
是否支持单点登录?
是否有埋点接口
http和https的区别
HTTPS和HTTP的区别主要如下:
1、https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
2、http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl**传输协议。
3、http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
4、http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行**传输、身份认证的网络协议,比http协议安全。
扩展资料:
HTTP:是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此**的详细内容就需要SSL。
HTTPS协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。
支付模块的测试
链接:https://blog.csdn.net/jiangbqing/article/details/61917979
正常流程:
正常使用支付宝、微信、银行卡(目前使用最多的第三方支付方式)支付(正常金额的支付),功能是否正常。
异常流程:
1、支付账号和密码错误,系统如何处理;
2、余额不足,系统如何处理;
3、取消支付,系统如何处理;
4、重复支付,系统如何处理;
5、微信或支付宝账号未登录时支付,系统如何处理;
6、手机上没有支付宝APP时选择支付宝支付,系统如何处理;
7、支付期间突然断网,系统如何处理;
8、取消支付后再次支付,系统如何处理;
9、金额上:最小值金额的支付,最大值金额的支付,错误金额的支付(如金额格式的错误、不允许使用的货币等等);
如何设计一个好的测试case
链接:http://www.sohu.com/a/247756141_165433
“好的”测试用例一定是一个完备的集合,它能够覆盖所有等价类以及各种边界值,而跟能否发现缺陷无关。
一个“好的”测试用例,必须具备以下三个特征。
1.整体完备性:“好的”测试用例一定是一个完备的整体,是有效测试用例组成的集合,能够完全覆盖测试需求。
2.等价类划分的准确性:指的是对于每个等价类都能保证只要其中一个输入测试通过,其他输入也一定测试通过。
3.等价类集合的完备性:需要保证所有可能的边界值和边界条件都已经正确识别。
做到了以上三点,就可以肯定测试是充分且完备的,即做到了完整的测试需求覆盖。
一,检查标准
1.准确性(Accurate)
测试覆盖了描述部分需要测试的内容。
2.经济性(Economical)
测试用例没有冗余的步骤
3.可重复性(Repeatable)
测试用例应该是独立一致的,不管任何人执行,结果都一致。
4.可追踪(Traceable)
测试用例应该追溯到具体需求。
5.自我清理(Self cleaning)
测试结束后,恢复到原有干净的状态,不应该对原有系统造成影响。
6 结构化和可测试性(Structure and testability)
测试用例应该是结构化。一般可以根据一个横向维度,对测试用例进行功能模块的划分;同时纵向维度上可以根据测试类别对测试用例进行纵向结构的划分。
测试同时应该是可测试性的。对于无法执行的测试用例是没有意义的。
7.规范性
命名 + 编号
目的
测试方法
环境, 数据, 前提,权限。
步骤, 期望结果。
清理数据,还原系统。
这里其实包含一个测试用例的组成部分:
命名, 编号(一般会结合功能进行命名)
目的描述
测试类型(该测试用例属于功能测试,性能测试,单元测试,系统测试等等)
环境
测试数据
前提
步骤
期望结果
实际结果
测试结果(通过还是失败)
一般来说测试用例,不会说明备份系统,还原系统的步骤,这两个步骤一般都会由自动化脚本自动执行。
8.简洁性
不超过15步。
执行时间不要超过20分钟。这两点其实是希望测试用例的规模比较小,粒度不要太大。这点在大型系统不太适用。
这里给出了一个测试用例编写的指导规范。尽量简洁,精悍。
9.完整性
自动化脚本应该包含必要的注释,包括,目的,输入,预期结果。
如果可能,提供不同的前置条件下的测试。
测试用例应该尽量完整,包含自动化脚本。
10.有效性
测试用例是否符合商业案例?
11.独立性
测试用例应该保持独立性,一个测试用例最好是能独立运行,不依赖于其他的测试用例的输出结果。出于结构的考虑,有些特殊测试用例设计本身就是作为setup来设计的,这个除外。
二, 测试用例的配置管理
采用命名和编号规范归档。
用例版本是否与当前被测试软件版本一致(对应)。测试用例最好有版本控制
包含用例需要的相应测试对象,如特定数据库。
存档阅读。
存档时按角色控制访问方式
当网络备份时存档。
离线归档。
压力测试,负载测试和性能测试关系?
链接:http://www.51testing.com/html/06/n-3721106.html
性能测试是动力,负载测试载重,压力测试强度
压力测试stresstest:是在一定的负荷条件下,长时间连续运行系统给系统性能造成的影响。
负载测试Loadtest:在一定的工作负荷下,给系统造成的负荷及系统响应的时间。
软件测试风险分析
测试计划都包括什么?
- 概述 1.1 编写目的 1.2 项目背景 1.3 项目质量目标 1.4 预期读者 1.5 参考资料
- 测试环境 2.1 系统架构 2.2 软硬件环境要求 2.3 测试环境部署图
- 测试规划 3.1 测试范围 3.2 测试工具 3.3 人员、角色及职责
- 测试策略 4.1 系统框测试 4.2 业务流程测试 4.3 功能点测试 4.4 UI界面测试 4.5 性能测试 4.6 兼容性测试 4.7 安全测试
- 测试进度安排
- 工作汇报
web测试和手机测试有什么区别
WEB测试和App测试从流程上来说,没有区别。都需要经历测试计划方案,用例设计,测试执行,缺陷管理,测试报告等相关活动。从技术上来说,WEB测试和APP测试其测试类型也基本相似,都需要进行功能测试、性能测试、安全性测试、GUI测试等测试类型。
他们的主要区别在于具体测试的细节和方法有区别,比如:性能测试,在WEB测试只需要测试响应时间这个要素,在App测试中还需要考虑流量测试和耗电量测试。
兼容性测试:在WEB端是兼容浏览器,在App端兼容的是手机设备。而且相对应的兼容性测试工具也不相同,WEB因为是测试兼容浏览器,所以需要使用不同的浏览器进行兼容性测试(常见的是兼容IE6,IE8,chrome,firefox)如果是手机端,那么就需要兼容不同品牌,不同分辨率,不同android版本甚至不同操作系统的兼容。(常见的兼容方式是兼容市场占用率前N位的手机即可),有时候也可以使用到兼容性测试工具,但WEB兼容性工具多用IETester等工具,而App兼容性测试会使用Testin这样的商业工具也可以做测试。
安装测试:WEB测试基本上没有客户端层面的安装测试,但是App测试是存在客户端层面的安装测试,那么就具备相关的测试点。
还有,App测试基于手机设备,还有一些手机设备的专项测试。如交叉事件测试,操作类型测试,网络测试(弱网测试,网络切换)
交叉事件测试:就是在操作某个软件的时候,来电话、来短信,电量不足提示等外部事件。
操作类型测试:如横屏测试,手势测试
网络测试:包含弱网和网络切换测试。需要测试弱网所造成的用户体验,重点要考虑回退和刷新是否会造成二次提交。弱网络的模拟,据说可以用360wifi实现设置。
TAG: