测试面试题

上一篇 / 下一篇  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 编写目的 1.2 项目背景 1.3 项目质量目标 1.4 预期读者 1.5 参考资料
  2. 测试环境 2.1 系统架构 2.2 软硬件环境要求 2.3 测试环境部署图
  3. 测试规划 3.1 测试范围 3.2 测试工具 3.3 人员、角色及职责
  4. 测试策略 4.1 系统框测试 4.2 业务流程测试 4.3 功能点测试 4.4 UI界面测试 4.5 性能测试 4.6 兼容性测试 4.7 安全测试
  5. 测试进度安排
  6. 工作汇报

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:

引用 删除 214080406   /   2021-01-07 16:20:55
5
 

评分:0

我来说两句

日历

« 2024-02-29  
    123
45678910
11121314151617
18192021222324
2526272829  

数据统计

  • 访问量: 234427
  • 日志数: 108
  • 图片数: 2
  • 文件数: 1
  • 建立时间: 2012-03-19
  • 更新时间: 2021-06-21

RSS订阅

Open Toolbar