软件根本
1.测试人员在测试中的任务是什么？
1.尽大概早的找出系统中的bug；
2.避免软件开发过程中缺陷的出现；
3.衡量软件的品格，保证系统的质量；
4.关注用户的需求，并保证系统符适用户需求。
总的目标是：确保软件的质量
2.测试用例评审的流程是什么
1.测试用例是否按照公司定义的模板进行编写的；
2.测试用例的自己的描述是否清晰，是否存在二义性；
3.测试用例内容是否正确，是否与需求目标相同等；
4.测试用例的盼望结果是否确定、唯一的；
5.操纵步骤应与描述是否相同等；
6.测试用例是否覆盖了所有的需求；
7.测试设计是否存在冗余性；
8.测试用例是否具有可实行性；
9.是否从用户层面来设计用户利用场景和业务流程的测试用例；
10.场景测试用例是否覆盖最负载的业务流程；
11.用例设计是否包含了正面、反面的用例；
12.对于由系统主动生成的输出项是否注明白生成规则；
13.用例应包含对中心和后台数据的检查；
14.测试用例应有正确的名称和编号；
15.测试用例应标注有实行的优先级；
16.测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；
17.每个测试用例步骤应<=15 step；
18.主动化测试脚本必须带有注释（注释应包括：目的、输入、盼望结果等）；
3.bug不能复现怎么办
A.起首思量环境问题，看是否能够还原原来的环境
B.尽量追念发生问题时的复现步骤，不要遗漏任何一个细节，按照步骤的组合尝试复现
C.与开发人员配合，让开发人员对相应的代码检查，看是否通过代码层面检查出问题
D.保留发生bug时的log，附加到提交的Bug中，盼望可以通过log中找到一些蛛丝马迹。
E.进行多次测试 更换设备进行测试
4.什么是Http协议，请求方法是什么？，以及Http协议与Https协议的区别？
Http协议又叫超文本传输协议，是定义了一个客户端到服务器请求与应答的尺度，分别为请求头与响应头。
请求方法是：get请求与post请求。
HTTPS协议是以安全为目标的HTTP通道，简称Http的安全版。
- get请求常用在获取数据 post常用在发送数据
- get安全性没有post安全性高，因为参数直接暴露在url上
- get请求会被浏览器主动缓存，post不会除非手动设置
- get请求参数受长度限定，post没有限定
200：请求发送乐成。
302：代表重定向。
400：客户端发送的请求语法错误。
401：请问的页面没有授权。
403：没有权限访问这个页面。
404：没有这个页面。
500：服务器内部非常。
501：当前不能处理客户端的请求。
504：服务器端超时，没返回结果。
5.web测试和App测试的区别
系统架构方面：
1.web项目，一样平常都是b/s架构，基于浏览器的
app项目，则是c/s的，必须要有客户端，用户需要安装客户端。
2.web测试只要更新了服务器端，客户端就会同步会更新。
App项目则需要客户端和服务器都更新。
性能方面:
3.web页面主要会关注响应时间
4.app则还需要关心流量、电量、CPU、GPU、Memory这些。它们服务端的性能没区别，都是一台服务器。
兼容方面：
5.web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容
6.app测试则要看分辨率，屏幕尺寸，还要看设备系统。
安装 更新 卸载
7.web测试是基于浏览器的所以不必思量安装卸载。
8.app是客户端的，则必须测试安装、更新、卸载。除了通例的安装、更新、卸载还要思量到非常场景。包括安装时的中断、弱网、安装后删除安装文件别的APP还有一些专项测试：如网络、适配性。。。
主动化测试
9.Web大多用的selenium webdriver
10.app是appium
6.当你参加评审时，你的评审原则是什么
起首要从正确性，同等性，可行性，须要性，可跟踪性，分配优先级，可测性，可修改性思量：
正确性：每一条需求都必须正确的陈述其要开发的功能。
同等性：必须与其他软件需求或高层需求不相矛盾。
可行性：其每一项需求都必须是已系统和环境的权能和限定范围可以来实行的。
须要性：每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回潮至某项客户的输入。
可测性：每项需求都能通过设计测试用例或其他的验证方法来进行测试。
可修改性：每项需求只应在SRS中出现一次，这样更改会轻易保持同等性。
可跟踪性：在每项软件需求与它的根源与设计元素，源代码，测试用例之间建立起链接，而这种可跟踪性要求每项需求都必须以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的陈述。
分配优先级：应当对所有的需求分配优先级，如把所有需求都看作同样紧张，那么项目管理者在开发或节省预算或调度中丧失控制自由度、
7.Android手机和IOS手机,系统有什么区别
A.运行机制差异:IOS采取的是沙盒运行机制,安卓采取的是虚拟机运行机制
B.两者后台制度差异:IOS中任何第三方程序都不能在后台运行,安卓中任何程序都能在后台运行,直到没有内存才会关闭
C.IOS中用于UI指令权限最高,安卓中数据处理指令权限最高
8.软件质量的特性是什么
A.功能性：软件需求要满足用户表现大概稳式的功能。
B.易用性：软件易于学习和上手利用
C.可靠性：软件必须实现需求当中指明的详细功能。
D.服从性：类似于软件的功能。
E.可维护性：需求软件具有将某个功能修复之后继承利用的功能。
9.开发环境和测试环境的区别
开发环境：是在编码阶段，一样平常我们的代码基本上都是在开发环境中，不会再生产与测试环境，如操纵系统，web服务器，语言环境，php,数据库等等。
测试环境：项目完成后，找Bug,以及修改Bug。生产环境：项目数据前后端已经疏通，摆设到阿里云上有客户去利用以及访问，网络正常运行就好了。
10.写好测试用例的关键/写好用例要关注的维度
1.覆盖用户的需求
2.从用户利用场景出发，思量用户的各种正常和非常的利用场景；
3.用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4.用例各个要素要齐全，步骤应该充足详细，轻易被别的测试工程师读懂，并能顺利实行
5.做好用例评审，及时更新测试用例。
11.软件测试的流程
第一步先立项 也就是确定项目——接着是产品阐明书 也就是PRD——需求文档——需求评审（需求人员下发 有：开发人员，测试人员，经理）——开发 开发环境-详细的概要设计-进行编码-进行自己测试。
——测试的环境
——测试的计划：用例 评审 时间估计 资源申请 人员的分配-编写测试的用例-用例评审
——进行提测（就是提交测试）
——冒烟测试（假如没有冒烟测试，则该组件就通过测试，在软件中，冒烟测试这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程）
——其次是功能测试（功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到 用户要求的功能）
——回归测试（回归测试就是修改了旧代码以后，重新测试以确认修改没有引入新的错误或导致其他代码出现错误）
——验收测试（它是技术测试的最后一个阶段，也是交付测试）
——最后是上线（将开发完的系统，放到真的运营环境中进行利用和测试）
了解用户需求--》参考需求规格阐明书--》测试计划（人力物力时间进度的安排）--》编写测试用例--》评审用例--》搭建环境--》测试包安排猜测（冒烟测试）-正式测试-bug-测试竣事出陈诉--》版本上线--》面向用户
12.请描述一下v模型
13.假如一个问题认为是bug 但开发说不是 你怎么处理
1.bug重现 在开发的前面重新操纵一遍给他看 确定各人看到的都是同一个现象
2.校队需求 看是否是同一版本的需求 假如不是同个版本 那就确定哪一方需求是最新的
3.假如需求同等 双方意见还达不到同等 那就找产品经理确认
4.开会讨论决定 找相关人员决定终极的决定
14.请描述一下W模型图
15.web测试的方法有哪些
16.App测试的方法有哪些
17.你在项目中最经典的bug是什么
1.兼容性问题，在IE浏览器提交按钮可以点击，到了谷歌，火狐就不能了
2.字段的值表现不是想要的结果，或没有表现。（开发从库表取值有误）
3.提交数据之后，状态没有转变为已提交。（代码没有正确获取库表中记录状态改变的状态码）
4.修改暗码，新暗码与旧暗码同等也能乐成，没有做新旧暗码的校验。
18.为什么要进行抓包
A.有些时候公司没有尺度的接口文档，测试人员只能抓包来获取接口测试。
B.抓包可以迅速找到请求，通过抓包可以查看整个请求的过程，以及响应时间，还可以分辨前台与后台Bug.
C.通过抓包，可以查看是否有敏感信息，如（用户暗码，个人账户信息等数据）
D.可以通过抓包进行测试，拦截请求，修改请求数据，查看对应的响应结果，抓包自己就是接口的一部分。
19.项目上线的尺度是什么
（1）紧急、严重级别错误修复率应达到100%
（2）普通级别错误修复率应达到95%以上
（3）优化级别错误修复率应达到60%以上
（4）Abcd级别的bug，ad不能有，c完成30%，d类达到100%
（5）用例覆盖率、实行率100%
20.代码的版本管理用什么工具 上传和合并代码 SVN Git介绍
git长途分支
git clone 克隆地址
cd 进入文件夹
git branch test 创建分支
git branch -v 查看
git checkout -b test分支名 切换
git add . 提交
git commit -m "add 提交"
git push 将本地修改的推送到长途服务器中
拉取最新代码 git pull origin develop
git push origin develop
git 提交失败 就这样
git fetch origin dev //获取长途dev分支的修改 git merge origin dev // 合并长途dev分支 git pull origin dev // 更新本地的代码
//退出 esc ：q
查看修改的文件
查看差异地方 git diff
21.怎么判定一个bug是前端照旧后端bug
1.像界面排位等问题都是前端 直接找前端
2.像报服务器非常问题 一样平常都是后端 也有大概是前端传参有误
3.接口调用错误 直接找前端
4.返回值正确 表现错误 直接找前端
假如还不能定位问题 就把前端和后端拉个群 把问题爆出来 然后由他们讨论
前端bug | 后端bug |
| | 界面相关 | 业务逻辑相关 |
| | 结构相关 | 性能相关 |
| | 兼容性相关 | 数据相关 |
| | 交互相关 | 安全性相关
22.给你一个网站，你应该怎样测试？
① 起首，查找需求阐明、网站设计 m 等相关文档，分析测试需求。制定测试计划，确定测试范围和测试战略，一样平常包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
② 设计测试用例：功能性测试可以包括，但不限于以下几个方面：链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。
③ 功能的测试：多媒体元素是否可以正确加载和表现。多语言支持是否能够正确表现选择的语言等。
④ 界面测试可以包括但不限于以下几个方面：页面是否风格统一，美观；页面结构是否公道，重点内容和热点内容是否突出；控件是否正常利用；对于必须但为安装的空间，是否提供主动下载并安装的功能;文字检查
⑤ 性能测试一样平常从以下两个方面思量：压力测试；负载测试；强度测试 数据库测试要详细决定是否需要开展。数据库一样平常需要思量连结性，对数据的存取操纵，数据内容的验证等方面。
⑥ 安全性测试：1 基本的登录功能的检查 2 是否存在溢出错误，导致系统瓦解大概权限泄露 3 相关开发语言的常见安全性问题检查，比方 SQL 注入等。4 假如需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，大概获取支持
⑦ 兼容性测试，根据需求阐明的内容，确定支持的平台组合：浏览器的兼容性；操纵系统的兼容性；软件平台的兼容性；数据库的兼容性 开展测试，并记录缺陷。公道的安排调整测试进度，提前获取测试所需的资源，建立管理体系（比方，需求变动、风险、配置、测试文档、缺陷陈诉、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。
23.三次握手的过程
1.第一次，客户端发送请求到服务器，服务器知道客户端发送，自己接收 正常
2.第二次，服务器发给客户端，客户端知道自己发送，接收正常，服务器接收正常、发送正常
3.第三次，客户端发送给服务器：服务器知道客户端发送，接收正常，自己接收，发送也正常
24.四次挥手的过程
第一次：客户端请求断开
第二次：服务器确认客户端的断开请求
第三次：服务器请求断开
第四次：客户端确认服务器的断开
25.上线之后出现bug怎么解决
评估bug的影响范围，检查bug是否业务核心环节的功能问题，检查bug是否涉及到个人信息 紫金财产等
影响小的bug，出现的场景呜呜操纵结合日志 让开发人员修复bug 保证bug解决
影响大的bug，无法确定可以通过回滚版本的方式，大概将功能降级或关闭
26.经常复现的bug怎么解决
评估bug的紧张性以及对项目的影响 ，假如影响小，就记录下来继承追踪
影响大的话 尽量复现当时bug出现的场景、环境、数据，大概让开发代码走查 大概就是反馈给夺目经理
总结履历,分析问题发生的缘故原由，避免下次出现同样的问题
27.测试总结
测试用例方法
等价类划分法（将测试的范围划分成几个互不相交的子集）
边界值分析法（选出的测试用例，应选取恰好即是、刚刚大于、刚刚小于边界的值）
错误推测法（在测试程序时，人们可以根据履历或直觉推测程序中大概存在的各种错误）
判定表法（适合于逻辑判定复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判定清晰的战略）
正交实验法（在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例）
测试陈诉
测试配景阐明 范围阐明 环境阐明 方法阐明 结果与缺陷分析 测试结论和建议 质量和风险评估 后期优化问题
测试用例模板
用例编号 所属模块 用例标题 优先级 前提条件 操纵步骤 测试数据 预期结果 预期结果
接口测试用例模板
用例标识 标题 模块 优先级 描述 前置条件 请求范例 请求参数 范例 操纵步骤 预期结果
缺陷陈诉模板
缺陷编号 用例编号 缺陷范例 严重级别 优先级 缺陷状态 测试阶段 可重现性 bug缘故原由 缺陷描述 预期结果 实际结果 重现步骤 测试环境
28.网络的七层模型
*应用层 *-> *表现层 *-> *会话层 *(统称应用层)、 *传输层 *(提供端对端的接口)、 *网络 **层 *（为数据包选择路由）、 *链路层 *(单一链路通信的方法，由底层网络定义 的协议)、 *物理层 *（看得到，摸得到的，介质）
应用层协议：http、SMTP、DNP,FTP协议
传输层协议：TCP、UDP
网络层：IP
网络层-传输层：TCP IP
29.Charles抓包原理
1.客户端向服务器发起HTTPS请求
2.Charles拦截客户端的请求，伪装成客户端向服务器进行请求
3.服务器向“客户端”（实际上是Charles）返回服务器的CA证书
4.Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。
5.客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称，用Charles的公钥加密，发送给“服务器”（Charles）
6.Charles拦截客户端的响应，用自己的私钥解密对称(Charles拿到了对称)，然后用服务器证书公钥加密，发送给服务器。
7.服务器用自己的私钥解密对称，向“客户端”（Charles）发送响应
8.Charles拦截服务器的响应，替换成自己的证书后发送给客户端
9.至此，连接建立，Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称**，之后就可以解密大概修改加密的报文了
30.搭建过什么环境 搭建工作环境是怎样搭建的
测试环境操纵系统用Linux，通常测试环境包括JDK环境，Tomcat环境和MySQL环境
JDK安装:
1.安装jdk假如有自带，先卸载再装，
2.把包复制/usr/local
3.解压，
4.配置环境变量
5.检查java是否安装乐成java -version
Tomcat安装:
1.安装tomcat，
2.把下载的tomcat包复制/usr/local，
3.解压，
4.在tomcat/bin目录实行startup.sh文件
5.启动服务
6.在浏览器中连接：IP:8080，
7.假如连接不上，但tomcat又是表现启动OK，检查firewall，路径为 /etc/sysconfig/iptables，将8080端口开启，
8.重启服务
Mysql数据库：
mysql安装比力简单，可以利用源码安装，也可以利用yum在线安装，在这里简单地介绍一下yum在线安装 用yum在线安装
1.rpm -qa|grep mysql --检查linux是否有存在的mysql
2.假如有mysql,卸载 rpm -e --nodeps mysql
3.安装 yum install mysql-server mysql mysql-dev -y
4.安装乐成后，启动服务 service mysqld start service 服务名 restart/start
5.直接输入mysql 进入到数据库。
随着docker的发展 变成了docker+Jenkins进行的一个连续集成的摆设 测试环境一样平常都是由运维去搭建
31.接口测试是怎样做的
1.获取接口规范
2.设计接口测试功能用例（主要从用户角度触出发看接口可否实现业务需求）
3.各种入参验证（非常情况包括输入参数个数不对，范例不对 可选/必选）
4.接口返回值各种验证（符合接口文档需求）
5.发现问题 该报bug报bug 该跟踪状态的跟踪状态
32.在浏览器中输入url后发生了什么
一共分为五部 ：
1.是dns剖析获取ip地址
2.建立tcp链接
3.发送请求数据
4.服务器返回数据
5.浏览器进行渲染
33.接口测试检查点有哪些
1.服务器的日志
2.数据库的落库
3.服务端的业务逻辑
34.测试一个C/S 客户端时，需要思量的因素
C/S架构：C是指客户端（Client），S是指服务端（Server），比方：谈天软件、qq、wechat等。
BS架构：是指浏览器和服务端的一种架构，比方：常用的浏览器，百度、谷歌。
只包含B：后端中的与前端交互的部分（接口文档等）
只包含S：后端中的与数据库交互的部分（进行数据库的一些操纵）
1.安装/卸载
1.安装包的完整性 安装包的大小是否达到要求 表现基本信息是否正确 步骤是否明确 内容是否公道
2.首次安装
1.是否与其他已安装的软件辩论
2.各种杀毒软件（卡巴 瑞星 360）对安装程度的影响
3.安装目录的思量（中英文字符，长度，空目录 根目录 修改目录 默认目录）
4.干净环境下可否正常完成安装
5.安装后快速启动 桌面 开始程序内里的快捷方式情况等
6.360一键智能安装是否能正常完成
7.安装的程序是否带有插件
2.1再次安装
1.在已经安装该软件的情况下 再次进行安装 表现是否正常（好比提示是否升级）
2.卸载后再次安装是否正常完成
2.2升级安装
1.在线升级时 是否能公道处理网络中断的情况 2.升级包升级时 思量软件正在利用时是否运行进行升级 升级过程中是否正确 3.升级完成后 软件启动是否正常
3.卸载
1.卸载时是否要退出客户端（退出和不退出都要思量），下载后的表现 不退出卸载 是否能乐成 不乐成 是否有相应提示等
2.是否能在控制面板内里卸载
3.是否自带卸载工具 卸载可否乐成
4.借助其他工具卸载可否乐成
5.卸载是否完全卸载干净 包括快捷方式 注册表信息等
4.界面及用户体验
（1）界面美观及控件样式是否符适用户的常用习惯
（2）程序所有可点击地方是否可以进行操纵，菜单、按钮、超链接（文字颜色以及 是否能正常链接）、文字等
（3）还需要思量在差异表现器上的表现，各种比例和分辨率下的表现情况
5.窗口
（1）窗口的缩放（双击的最大最小，点击按钮的最大最小，关闭）、拖动（开 多个窗口拖动）任务栏（左键单击和右键单击的操纵）、托盘区、任务管理 器操纵。一样平常客户端软件，开着窗口在桌面上移动的时候，cpu占用都比力 高，这个性能需要控制在某个符合的范围内。
（2）多窗口的操纵是否公道，需要思量窗口的模态性，好比有模态窗口的时候， 进行其他的操纵，以及模态窗口的重绘等
6.提示信息
（1）各种操尴尬刁难应的正确、错误类提示信息是否正确
（2）界面文字提示是否友好、易懂、简练
（3）操纵流程是否清晰，用户知道自己每步都是在做什么，即操纵提示是否清晰明白
（4）有错误类信息，不要利用代码类文字，思量到用户群体的情况，还要区分中英文（用哪个更好）
7.键盘鼠标操纵
（1）快捷键操纵是否正常，是否与其他软件的快捷键辩论等
（2）鼠标拖放表现是否正常，是否影响操纵
（3）鼠标右键功能是否正常公道
8.详细功能
（1）是否所有可操纵的功能都能按需求实现（如：登岸退出，信息传输功能，备份功 能，系统设置功能，搜索功能，界面模板更新，信息增编削功能等）
（2）对于功能块的无效操纵和极端操纵是否都有公道的处理（如：无效的输入字符， 超长的字符长度，脚本注入等）
（3）操纵界面是否即时动态刷新
（4）假如有托盘图标，需要思量托盘图标的表现状态，是否能表现，操纵是否正常等
（5）各类控件的表现和操纵是否正常，如下拉列表、日历控件等
9.文件传输功能
（1）需要思量不传输文件、传输文件内容为空（大小为0KB，边界值思量）、文件内容包含特 殊字符、文件名字符
（2）传输文件的格式
（3）涉及到网络传输，和端口有关系的，要思量模拟一下端口错误，封端口的操纵
（4）发送文件时，思量本地文件，还要思量ftp，http上的文件
（5）需要思量磁盘空间不敷的情况
（6）正在利用的文件是否是独占状态
（7）涉及到文件生存时，需要思量文件生存的范例、名称的默认给出
（8）文件拖动类的思量
（9）涉及到文件写入读取的，需要思量移动设备，好比U盘、硬盘、ftp等
（10）是否超过最大容量、流量限定
10.兼容测试
（1）差异语言系统上的利用区别，在控制面板的区域和语言选项内里进行设置，管 理选项卡里更改系统区域设置。比方中文系统，英文系统，韩语系统等。
（2）差异操纵系统上利用的区别（winXP，Vista，Win7，Win2000，Win2003， Win2008,32位和64位系统）
（3）同一个系统的差异系统用户操纵（管理员和非管理员）
（4）需要思量计算机休眠，待机后在启动软件的表现情况，各种杀毒软件对软件的 影响。瑞星、卡巴、360等（杀毒软件对一些文件范例、端口等有监控，需要考 虑。大概由于软件利用某些端口而被杀毒软件阻止而导致不能正常利用）
11.性能测试
（1）并发负载问题
（2）差异网络环境的信息传输性能，丢包率
（3）同等网络环境下，差异并发数场景下，信息传输性能，丢包率
（4）大数据量的测试
35.一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别
一个客户端，三百个用户
只有一个客户端，三百个用户肯定不能同时进行操纵，假设每次一人操纵客户端对服务器施压，服务器承受的压力小但连续时间长
三百个客户端，三百个用户
假设三百个客户端同时进行操尴尬刁难服务器施压，就要求服务器带宽能够承受三百人同时在线操纵，且服务器短时间内承受压力大但连续时间短
36.你对测试最大的兴趣在那边
感觉这是一个有挑衅性的工作；
测试是一个履历行业，工作越久越能感觉到做好测试的难度和乐趣，
通过自己的工作，能使软件产品越来越美满，从中领会到乐趣。
最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们假如需要可以自行免费领取【保证100%免费】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战堆栈，这个堆栈也陪伴上万个测试工程师们走过最艰难的路程，盼望也能帮助到你！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
