[开发测试]测试基础-面试

一、软件测试基础

1. 什么是软测，有哪些测试类型

软件测试是为了发现错误而执行程序的过程。

测试分为功能测试和非功能测试：
非功能测试又可以分为性能测试、压力测试、容量测试、 健壮性测试、安全性测试、可靠性测试、恢复性测试、备份测试、协议测试、兼容性测试、可用 性测试、配置测试、GUI 测试。

2.如何写测试用例

测试用例是为了实施测试而向被测试的系统提供一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素

1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2、如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的 bug 情况
3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行 逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4、找到需求相关的一些特性，补充测试用例
5、根据自己的经验分析遗漏的测试场景
6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7、书写格式一定要清晰

基于需求的测试方法

1. 等价类
2. 边界值
3. 因果图：适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况
4. 正交排列：目的：减少用例数目，用尽量少的用例覆盖输入的两两组合
5. 场景设计法
6. 错误猜测法

3.黑盒测试

黑盒测试也叫功能测试，测试的时候，在完全不考虑程序内部结构和特性的情况下，测试人员在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当的接受数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方式查出程序中的所有错误。但是实际上测试情况有无穷多个，因此不仅要测试所有的合法输入，还应该尽可能的测试那些不合法的输入。

黑盒测试主要试图发现以下错误：
功能不正确或遗漏；界面错误；输入或输出错误；数据库访问错误；性能错误；初始化和终止错误。
常用的黑盒测试方法：
等价类划分法；边界值分析法；因果图分析法；场景法；
正交实验设计法：（正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平 的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。）
判断表驱动分析法；错误推测法；功能图分析法。

1.测试用例边界

通常边界值分析法 是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
常见的边界值
1)对 16-bit 的整数而言 32767 和 -32768 是边界
2)屏幕上光标在最左上、最右下位置
3)报表的第一行和最后一行
4)数组元素的第一个和最后一个
5)循环的第 0 次、第 1 次和倒数第 2 次、最后一次

4. 白盒测试

白盒测试也叫结构测试，是针对程序内部单元是如何进行工作的测试。他根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序的内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试法，但即使每条路径都测试过了，仍然有可能存在错误。因为穷举路径测试无法检查出程序本身是否违反了设计规范，且穷举路径测试不可能检查出程序是否因为遗漏路径而出错；白盒测试无法发现与数据相关的错误。

白盒测试需要遵循的规则：
1.保证一个模块中的独立路径至少被测试了一次；
2.所有逻辑值均需要测试true或者false两种情况；
3.检查程序的内部数据结构，保证其结构的有效性；
4.在上下边界及可操作范围内运行所有循环。

常用的白盒测试方法：
逻辑覆盖法，基本路径法，符号测试，错误驱动测试。
静态测试：
不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：
需要执行代码，通过运行程序查找问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

条件覆盖

白盒测试中的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试，其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖六种。
发现错误能力由弱到强：
1.语句覆盖每条语句至少执行一次；
2.判定覆盖每个判定的每个分支至少执行一次；
3.条件覆盖每个判定的每个条件应取到各种可能的值；
4.判定/条件覆盖同时满足判定覆盖和条件覆盖；
5.条件组合覆盖每个判定中格条件的每一种组合至少出现一次；
6.路径覆盖使程序中每一条可能的路径至少执行一次。

5.测试步骤

1. 单元测试
   完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测设，及早的发现和解决不易显现的错误。
2. 集成测试
   通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造在一个设计中所描述的程序结构，应当避免一次性的集成（除开软件规模很小），而采用增量集成。
   自顶而下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行，逐渐把各个模块结合起来。在把附属于主控制模块的那些模块组装到程序结构中去时，可以使用深度优先的策略或者广度优先的策略。
   自底而上集成：把低层模块组合成实现某个特定的软件
3. 系统测试
   系统测试是基于系统整体需求说明书的黑盒类测试，应该覆盖系统所有联合的部件。系统测试需要验证系统是否满足了需求规格的定义，找出与需求规格不相符的地方。系统测试的对象不仅包括需要测试的产品系统的软件、还要包括软件所依赖的硬件、外设甚至包括某些数据、某些支持软件和接口。
4. 回归测试
   回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。回归测试的目的是保证修复好了的缺陷不会再次出现。
5. 验收测试
   独立测试人员根据测试计划和结果对系统进行测试和验收，它让系统用户决定是否接受系统。它是一项确定产品是否满足合同和用户规定需求的测试，验收测试包括alpha测试和beta测试。
   Alpha测试：是由用户在开发者的环境下进行的，在一个受控的环境下进行。
   Beta测试：由软件的最终用户在一个或者多个场所中进行，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终软件。

6.V模型和W模型

v模型

V模型测试流程：
需求分析–概要设计–详细设计–软件编码
--单元测试–集成测试–系统测试–验收测试，
目的是改进软件开发的效率和效果，是瀑布模型的变种

软件测试V模型指出：

1. 单元和集成测试应检测程序的执行是否满足软件设计的要求；
2. 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
3. 验收测试确定软件的实现是否满足用户需要或合同的要求。

优点：
4. 明确地标注了测试过程中存在的不同测试类型；
5. 清楚的描述了这些测试阶段和开发过程期间个阶段的对应关系；

缺点：
6. 不适合需求变化频繁的程序；
7. 发现错误时间较晚；
8. 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试；
9.
w模型

W模型流程：
用户需求–需求分析与系统设计–概要设计–详细设计
–编码–单元测试–集成测试–验收测试–
单元测试设计–集成测试设计–系统测试设计–验收测试设计
–集成–实施–交付

W模型是为解决V模型的缺陷而产生，增加了软件开发阶段中应同步进行的验证的确认活动

特点：测试的对象不仅是程序，需求、设计等同样要测试，开发与测试同步

优点：可以尽早的发现错误，降低风险，减少成本，提高质量

缺点

1. 不能适应用户需求变化频繁的项目；
2. 需求、设计、编码等活动被视为串型的；
3. 测试和开发活动也保持这一种线性的前后关系，上一阶段完全结束，才可以正式开始下一个阶段工作；
4. 无法支持敏捷开发模式；
5. 对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑；

7.BUG生命周期

生命周期中BUG状态：新建–>指派–>已解决–>待验–>关闭

1. 发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
2. 如果待验的BUG在验证时没有解决好，我们需要重新打开–指派—已解决—待验，循环这个过程。

8.BUG优先级

1. 致命的（Fatal）：
   造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等
2. 严重错误（critical）：
   系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
3. 一般错误（major）：
   次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
4. 较小错误（Minor）：
   使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚

9.web 测试和 app 测试的不同点

1. 系统架构方面：
   web 项目，一般都是 b/s 架构，基于浏览器的
   app 项目，则是 c/s 的，必须要有客户端，用户需要安装客户端。
   web 测试只要更新了服务器端，客户端就会同步会更新。App 项目则需要客户端和服务器都 更新。
2. 性能方面:
   web 页面主要会关注响应时间 ；app 则还需要关心流量、电量、CPU、GPU、Memory 这些。
   它们服务端的性能没区别，都是一台服务器。
3. 兼容方面：
   web 是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容
   app 测试则要看分辨率，屏幕尺寸，还要看设备系统。
   web 测试是基于浏览器的所以不必考虑安装卸载。 而 app 是客户端的，则必须测试安装、更新、卸载。
4. 除了常规的安装、更新、卸载还要考虑 到异常场景。包括安装时的中断、弱网、安装后删除安装文件 。 此外 APP 还有一些专项测试：如网络、适配性。

10.是否做过压力测试

1. 首先对要测试的系统进行分析，明确需要对哪一部分做压力测试，比如秒杀，支付
2. 如何进行施压
   第一种：可以通过写脚本产生压力机器人对服务器进行发包收报操作
   第二种：借助一些压力测试工具比如 Jmeter,LoadRunner
3. 如何进行正确的施压
   需要用压力测试工具或者其他方法录制脚本，模拟用户的操作
4. 设计多大的压力比较合适？
   需要明确压力测试限制的数量，即用户并发量
5. 如何通过这些数据来定位性能问题
   通过测试可以得到吞吐量，平均响应时间等数据，这个数据的背后是整个后台处理逻辑综合作用的结果，这时候就可以先关注系统的 CPU，内存，然后对比吞吐量，平均响应时间达到瓶颈 时这些数据的情况，然后就能确认性能问题是系统的哪一块造成的

11.性能测试的指标

一、性能测试常用指标：
从外部看

1. 吞吐量：每秒钟系统能够处理的请求数，任务数
2. 响应时间：服务处理一个请求或一个任务的耗时
3. 错误率：一批请求中结果出错的请求所占比例

从服务器的角度看，性能测试关注 CPU，内存，服务器负载，网络，磁盘I/Ｏ
二、对登录功能做性能测试

1. 单用户登陆的响应界面是否符合预期
2. 单用户登陆时后台请求数量是否过多
3. 高并发场景下用户登录的响应界面是否符合预期
4. 高并发场景下服务端的监控指标是否符合预期
5. 高集合点并发场景下是否存在资源死锁和不合理的资源等待
6. 长时间大量用户连续登录和登出， 服务器端是否存在内存泄漏

三、怎么测出可同时处理的最大请求数量：
可以采用性能测试工具(WeTest 服务器性能)，该工具是腾讯 wetest 团队出品，使用起来很 简单方便，但测试功能相当强大，能提供 10w+以上的并发量，定位性能拐点，测出服务器模型 最大并发

12.对于有系统大量并发访问，你会如何做测试，有什么建议

如何做高并发系统的测试，一般而言，整体的测试策略是：
先针对部分系统进行性能测试及压力测试，得到各部分的峰值处理性能，再模拟整体流程测试，重点测试整体业务流程以及业务预期负荷.
着重测试以下几点：

1. 不同省份，不同运营商 CDN 节点性能，可采用典型压力测试方案
2. 核心机房 BGP 网络带宽，此部分重点在于测试各运行商的 BGP 网络可靠性，实际速率， 一般采用 smokeping,lxChariot 等工具
3. 各类硬件设备性能，一般采用专业的网络设备测试工具
4. 各类服务器并发性能，分布式处理能力，可采用压力测试方案工具
5. 业务系统性能，采用业务系统压力测试方案
6. 数据库处理性能，这部分需要结合业务系统进行测试，以获取核心业务场景下的数据库 的 TPS/QPS，
7. 如果有支付功能，需要进行支付渠道接口及分流测试，此部分相对而言可能是最大的瓶 颈所在，此外还涉及备份方案，容灾方案，业务降级方案的测试。

二、测试用例

1. 请问你怎么测试网络协议

协议测试包括四种类型的测试

1. 一致性测试：检测协议实现本身与协议规范的符合程度
2. 互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力
3. 性能测试：检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度
4. 健壮性测试：检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断

2.请你对朋友圈点赞功能进行测试

1. 是否可以正常点赞和取消；
2. 点赞的人是否在可见分组里
3. 点赞状态是否能即时更新显示；
4. 点赞状态，共同好友是否可见；
5. 性能检测: 网速快慢对其影响；
6. 点赞显示的是否正确，一行几个；
7. 点赞是否按时间进行排序，头像对应的是否正确；
8. 是否能在消息列表中显示点赞人的昵称、
9. 不同手机，系统显示界面如何； 备注；
10. 可扩展性测试，点赞后是否能发表评论；
11. 是否在未登录时可查看被点赞的信息。

3. 杯子检测

1. 功能
   （1）水倒水杯容量的一半
   （2）水倒规定的安全线
   （4）水杯容量刻度与其他水杯一致
   （5）盖子拧紧水倒不出来
   （6）烫手验证
2. 性能
   （1）使用最大次数或时间
   （2）掉地上不易损坏
   （3）盖子拧到什么程度水倒不出来
   （4）保温时间长
   （5）杯子的耐热性
   （6）杯子的耐寒性
   （7）长时间放置水不会漏
   （8）杯子上放置重物达到什么程度杯子会被损坏
3. 界面
   （1）外观完整、美观
   （2）大小与设计一样（高、宽、容量、直径）
   （3）拿着舒服
   （4）材质与设计一样
   （5）杯子上的图案掉落
   （6）图案遇水溶解
4. 安全
   （1）杯子使用的材质毒或细菌的验证
   （2）高温材质释放毒性
   （3）低温材质释放毒性
5. 易用性
   （1）倒水方便
   （2）喝水方便
   （3）携带方便
   （4）使用简单，容易操作
   （5）防滑措施
6. 兼容性
   （1）杯子能够容纳果汁、白水、酒精、汽油等。
7. 震动测试
   （1）杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
8. 可移植性
   （1）杯子在不同地方、温度环境下都可以正常使用。

4.如何对淘宝搜索框进行测试

一. 功能测试

1. 输入关键字，查看: 返回结果是否准确，返回的文本长度需限制
   1.1 输入可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；
   1.2 输入不可查到结果的关键字、词、语句；
   1.3 输入一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等；
2. 结果显示：标题，卖家，销售量，单行/多行，是否有图片
3. 结果排序：价格 销量 评价 综合
4. 返回结果庞大时，限制第一页的现实量，需支持翻页
5. 多选项搜索：关键字 品牌 产地 价格区间 是否天猫 是否全国购
6. 是否支持模糊搜索，支持通配符的查询
7. 网速慢的情况下的搜索
8. 搜索结果为空的情况
9. 未登录情况和登录情况下的搜索（登录情况下 存储用户搜索的关键字/搜索习惯）

二、性能测试

1. 压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）
2. 负载测试：看极限能承载多大的用户量同时正常使用
3. 稳定性测试：常规压力下能保持多久持续稳定运行
4. 内存测试：有无内存泄漏现象
5. 大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来， 看表现如何等等。

三. 易用性：交互界面的设计是否便于、易于使用

1. 依据不同的查询结果会有相关的人性化提示: 查不到时告知？查到时统计条数并告知？有 疑似输入条件错误时提示可能正确的输入项等等处理；
2. 查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则 列示方便定位，显示字体、字号、色彩便于识别等等；
3. 标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的 检索方式是否正常？
4. 输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到，有否快照等快捷查 看方式等人性化设计？

四. 兼容性

1. windows /Linux等各类操作系统下及各版本条件下的应用
2. IE/FIREFOX/GOOGLE/360/QQ 等各类浏览器下及各版本条件下、各种显示分辨率条件下的应 用
3. SQL/ORACLE/DB2/MYSQL 等各类数据库存储情况下的兼容性测试
4. 简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
5. IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
6. 与各相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用

五. 安全性

1. 被删除、加密、授权的数据，不允许被 SQL 注入等攻击方式查出来的，是否有安全控制设 计；
2. 录入一些数据库查询的保留字符，如单引号、%等等，造成查询 SQL 拼接出的语句产生漏 洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网 等。
3. 通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患
4. 对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制；

5.如何测试登陆界面

一、功能测试

1. 输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
2. 输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
3. 登录成功后能否能否跳转到正确的页面
4. 用户名和密码，如果太短或者太长，应该怎么处理
5. 用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
6. 记住用户名的功能
7. 登陆失败后，不能记录密码的功能
8. 用户名和密码前后有空格的处理
9. 密码是否非明文显示显示，使用星号圆点等符号代替。
10. 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者）， 刷新或换一个按钮是否好用
11. 登录页面中的注册、忘记密码，登出用另一帐号登陆等 链接是否正确
12. 输入密码的时候，大写键盘开启的时候要有提示信息
13. 什么都不输入，点击提交按钮，检查提示信息。

二、界面测试

1. 布局是否合理，testbox 和按钮是否整齐。
2. testbox 和按钮的长度，高度是否复合要求。
3. 界面的设计风格是否与 UI 的设计风格统一。
4. 界面中的文字简洁易懂，没有错别字。

三、性能测试

1. 打开登录页面，需要的时间是否在需求要求的时间内。
2. 输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
3. 模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。

四、安全性测试

1. 登录成功后生成的 Cookie，是否是 httponly (否则容易被脚本盗取)。
2. 用户名和密码是否通过加密的方式，发送给 Web 服务器。
3. 用户名和密码的验证，应该是用服务器端验证，而不能单单是在客户端用 javascript 验 证。
4. 用户名和密码的输入框，应该屏蔽 SQL 注入攻击。
5. 用户名和密码的的输入框，应该禁止输入脚本 （防止 XSS 攻击）。
6. 防止暴力破解，检测是否有错误登陆的次数限制。
7. 是否支持多用户在同一机器上登录。
8. 同一用户能否在多台机器上登录

五、可用性测试

1. 是否可以全用键盘操作，是否有快捷键。
2. 输入用户名，密码后按回车，是否可以登陆。
3. 输入框能否可以以 Tab 键切换。

六、兼容性测试

1. 不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2. 同种浏览器不同版本下能否显示正常且功能正常。
3. 不同的平台是否能正常工作，比如 Windows, Mac。
4. 移动设备上是否正常工作，比如 Iphone, Andriod。
5. 不同的分辨率下显示是否正常。

七、本地化测试

1. 不同语言环境下，页面的显示是否正确