测试流程

先根据客户需求文档提取功能模块，然后编写测试计划，提取测试点，设计测试用例，用例评审之后执行用例，提交bug，编写测试报告.

项目流程

首先进行用户需求分析，做好测试计划后，设计测试用例，用例评审，等到开发，获取版本包，然后进入测试的流程阶段。
系统测试计划设计和测试用例的编写以及评审，执行测试用例进行功能测试对Bug进行管理和跟踪、提交缺陷、对测试工作进行总结。

B/S架构的系统从哪些点去测

功能：链接测试、导航菜单、页面的跳转、表单测试、数据测试、业务逻辑测试;
兼容性：跟客户确认其常会用的浏览器，再加上IE、火狐和谷歌等进行兼容性的测试;
界面：字体颜色大小、图标和字段间距等;
性能：连接速度、负载测试、压力测试;
安全性：权限控制、链接封装、日志记录的测试、登陆密文、修改密码后重新登陆、登陆失效时间。

测B/S架构的系统和C/S架构的系统有哪些地方不一样的？ Web系统测试要从哪些点去测?

B/S为浏览器/服务器架构。通过浏览器访问；使用方便；访问速率相对较慢；更易维护更新，只需更新服务器数据；安全性相对较低。
C/S为客户端/服务器架构。需下载客户端应用程序；由于要下载并安装客户端才能使用，相对来说不易使用；由于有部分数据存储在客户端，所以访问速率相对较快；维护更新较为复杂；安全性更高，平台更兼容。
Web系统属于B/S架构，
功能测试（链接测试，表单测试，页面跳转测试，导航菜单测试，数据测试，业务逻辑测试，功能校验等）
兼容性测试（不同的浏览器，不同的平台）
安全性测试点（登陆次数校验，密码密文显示方式，验证码，登陆状态失效测试，权限测试，链接封装，日志记录等）
界面测试，易用性测试等

测试工具简述

缺陷管理工具 bugfree 禅道 版本管理工具 SVN
性能测试工具 loadrunner 接口测试工具 postman

性能测试流程

需求分析—编写测试计划—设计测试用例—维护脚本—执行脚本—分析结果—性能调优

性能测试指标

并发用户数，吞吐量，响应时间，资源利用率，tps与hps，交易成功率

什么是内存溢出？

通俗理解就是内存不够，运用程序需要的内存远远超出了你主机内安装的内存所承受的大小，就叫内存溢出

什么是内存泄露？

指由于疏忽或错误造成程序未能释放已经不再使用的内存，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果

测试中有用到过数据库吗？为什么会用到数据库？举个例子？

大数据的情况下，要去数据库验证数据 报表 查询 导入 导出
有用到过，查看大型数据的完整和正确性时需要用到数据库进行对比。

当你提交bug给开发，开发不认同，怎么处理？

（这个问题会有多种问法，答案要结合需求来答，一：需求不明确的怎么答？ 二：需求明确怎么回答？）是bug就要报
需求不明确，先找开发和产品经理一起讨论确认需求，需求确认好了就按需求来，需求没有确认好，就让产品和客户继续沟通
需求明确，就按需求和开发说，如果开发还是不按需求来，就找产品经理

网络的7层协议是哪7层？ ftp这个工作在哪一层？

应用层 ftp http telnet dns
表示层
会话层
传输层 tcp udp
网络层 ip 路由器 防火墙
数据链路层 交换机 网卡
物理层 集线器

UDP&TCP有什么区别？ QQ采用哪种协议？

QQ属于TCP协议
UDP:不可靠的，无连接的协议，传输效率高
TCP:可靠的，面向连接的协议，传输效率低

TCP/IP四层是？

应用层 传输层 internet层
网络接入层 ARP RARP

http页面返回值的含义

200 成功
400 请求错误
401 无法解析此请求
403 禁止访问
404 找不到网页
500 服务器错误
502 网关错误
503 服务器不可用

常见协议端口号

FTP21 SSH22 telnet23 dns53 http80 https443 Tomcat8080 orcale1521 mysql 3306

在测试中发现一个界面很丑，这个问题是否严重？是否可以放过？

不严重，主要看需求，如果需求就是如此那就没什么问题，其次看具体情况，如果项目马上就要上线，可能会因为对界面进行修改会产生更加严重的问题，所以一般都会采取放过。

 数据库查询中什么是左连接，什么是右连接？

left join right join左连接：左右两张表按某个列进行关联查找，左连接以左边的表为基础表，基础表中的数据全部查找出来，右边的表如果有和左边的表条件相符的数据就查找出来，如果条件不相符就用Null显示。 右连接刚好相反。

什么是触发器？什么是存储过程？

触发器：通过事件来触发运行的，主要是没有人工干预的情况下来完成复杂度高一些的约束条件，从而保证数据库的完整性和一致性。
存储过程：在大型的数据库中，一组为了完成特定功能的SQL语句集，经编译后存储在编译过程中，用户通过指定存储过程的名字并给出参数来执行它。

这有一个小糖块，怎么去测？

需求测试: 查看小糖块使用说明书
界面测试: 查看外观
功能度：打开糖包看是不是空包糖；糖能不能被吃到
安全性：糖块有没有毒或细菌
可靠性：糖块从不同高度落下的损坏程度
可移植性：糖块在不同的地方、温度等环境下是否都可以正常食用
兼容性：糖块是否能够拥有橘子味、薄荷味、酒精味、汽油味等
易用性：糖块是否咯牙、是否有防脏糖包等措施、是否方便食用
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透糖块

测试报告，测试方案以及测试原则

测试报告：人力投入，用例覆盖情况，bug的分类及数量统计，遗留bug情况，测试风险，测试对象评估，测试结论，测试结果分析，测试总结。
测试方案：① 测试策略 ② 测试资源 ③ 测试进度计划 ④ 风险管理 ⑤ 质量标准
测试原则：
A 所有软件测试都应追溯到用户需求
B 尽早的和不断的进行测试
C 完全测试时不可能的，测试需要终止
D 无法显示软件潜在的缺陷
E 注意群集现象
F 避免检查自己的程序
G 避免测试的随意性

测试计划内容&测试策略及测试范围

内容：背景，目标，范围，方式，进度安排，测试组织，测试执行中开始与结束的标准，测试计划的审批与更改方式，测试相关的风险

策略：容量测试 安全性测试 稳定性测试 安装测试 卸载测试 易用性测试 配置测试 文档测试 可靠性测试 强度测试 性能测试 功能测试 兼容性测试 负载测试 压力测试 数据库测试 分布测试 故障恢复测试

如何做测试需求分析?

首先是将软件开发需求中具有可测试性的需求或特征提取出来，形成原始需求
然后将原始测试需求细化或者分解
最后进行需求评审

测试活动的生命周期

需求分析—编写测试计划—设计用例设计—执行用例，提交bug—编写测试报告