测试基础-面试

一、软件测试基础

1. 软测、软件质量

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

测试分为功能测试和非功能测试：
功能测试：
正常功能、异常功能、边界测试、界面测试、接口测试、安全测试、错误处理测试等
非功能测试：

1. 性能测试：测试软件的性能表现，考量软件运行的如何。
   （1）压力测试：系统已经达到饱和程度时，测试系统是否会出现崩溃等
   （2）负载测试：通过对被测试系统不断的加压，直到超过预定的指标或者部分资源已经达到了一种饱和状态不能再加压为止，为了寻找系统最大的负载能力
   （3）容量测试：寻找软件系统某项指标（如最大并发用户数、数据库记录数、最大负载、工作量等）的极限值
   （4）并发测：通过模拟用户并发访问，测试多用户同时访问同一应用、模块或数据，观察系统是否存在死锁、系统处理速度明显下降等性能问题
   （5）可靠性测试（稳定性、健壮性）：当系统在一定的业务压力下，让系统持续运行一段时间，观察系统是否达到要求的稳定性。
   （6）配置测试：通过调整系统软/硬件环境，了解不同环境对系统性能的影响，从而找到系统的最优配置
2. 安全性测试、恢复性测试、兼容性测试、可用性测试

软件质量可分解成六个要素：
3. 功能性：用户要求的功能是否全部实现了。
4. 可靠性：在规定的时间和条件下，软件所能维持它的性能水平的程度。
5. 易使用性：用户在学习、操作、准备输入和理解输出时，是否是需要作出很多的努力，就是说看用户在使用本软件时是否方便。
6. 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。
7. 可维修性：环境改变或软件错误发生时，进行相应修改所做的努力程度。
8. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。

3.测试报告组成

1. 概述：包括项目背景、需求分析
2. 测试时间、测试环境
3. 测试过程：评审记录、测试范围、测试用例
4. 功能实现清单：列出是否已经按照测试计划实现功能
5. 缺陷统计：测试缺陷统计；测试用例执行情况统计
6. 测试统计情况：（1）资源统计（2）执行情况（3）问题统计（4）问题列表（5）遗留的问题
7. 测试总结：测试结论（是否通过）（2）测试内容、测试用例的覆盖程度、bug的解决程度
8. 测试风险

2.如何写测试用例

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

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

基于需求的测试方法

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

3.黑盒测试

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

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

1. 黑盒测试主要试图发现以下错误：
   功能不正确或遗漏；界面错误；输入或输出错误；数据库访问错误；性能错误；初始化和终止错误。
2. 常用的黑盒测试方法：
   等价类划分法；边界值分析法；因果图分析法；场景法；
3. 正交实验设计法：（正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平 的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。）
   判断表驱动分析法；错误推测法；功能图分析法。
4. 等价类划分：
   等价类划分法是把所有可能的输入数据，划分为若干子集，从每个子集中选取少量具有代表性的数据作为测试用例。
   例子：验证码（4位），高于，低于四位的为一类，非数字为一类，数字为一类，4位为一类。

测试用例边界

通常边界值分析法 是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
常见的边界值
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. 验收测试确定软件的实现是否满足用户需要或合同的要求。

优点：

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

缺点：

1. 不适合需求变化频繁的程序；
2. 发现错误时间较晚；
3. 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试；

w模型

W模型流程：
用户需求–需求分析与系统设计–概要设计–详细设计
–编码–单元测试–集成测试–验收测试–
单元测试设计–集成测试设计–系统测试设计–验收测试设计
–集成–实施–交付
W模型是为解决V模型的缺陷而产生，增加了软件开发阶段中应同步进行的验证的确认活动
特点：测试的对象不仅是程序，需求、设计等同样要测试，开发与测试同步
优点：可以尽早的发现错误，降低风险，减少成本，提高质量
缺点
12. 不能适应用户需求变化频繁的项目；
13. 需求、设计、编码等活动被视为串型的；
14. 测试和开发活动也保持这一种线性的前后关系，上一阶段完全结束，才可以正式开始下一个阶段工作；
15. 无法支持敏捷开发模式；
16. 对于当前软件开发复杂多变的情况，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、安全性测试

安全性测试的工具又有很多，其中以AppScan最为全面，他几乎涵盖了所有安全测试的问题，并且能够生成一个安全测试报告。

1. 跨网站脚本攻击：通过脚本语言的缺陷模拟合法用户，控制其账户，盗窃敏感数据
2. 注入攻击：通过构造查询对数据库、LDAP和其他系统进行非法查询
3. 恶意文件执行：在服务器上执行Shell 命令Execute，获取控制权
4. 伪造跨站点请求：发起Blind 请求，模拟合法用户，要求转账等请求
5. 不安全对象引用：不安全对象的引入，访问敏感文件和资源，WEB应用返回敏感文件内容
6. 被破坏的认证和Session管理：验证Session token 保护措施，防止盗窃session
7. Session的失效时间限制：Session的失效时间设置是否过长，会造成访问风险
8. 不安全的木马存储：过于简单的加密技术导致黑客破解编密码，隐秘信息被盗窃，验证其数据加密
9. 不安全的通讯：敏感信息在不安全通道中以非加密方式传送， 敏感信息被盗窃，验证其通讯的安全性
10. URL访问限制失效：验证是否通过恶意手段访问非授权的资源链接，强行访问一些登陆网页，窃取敏感信息
11. 信息泄露和不正确错误处理测试：恶意系统检测，防止黑客用获取WEB站点的具体信息的攻击手段获取详细系统信息
12. 注册与登录测试：验证系统先注册后登录、验证登录用户名和密码匹配校验，密码长度及尝试登录次数，防止 非法用户登录
13. 超时限制：验证WEB应用系统需要有是否超时的限制，当用户长时间不做任何操作的时候，需要重新登录才能使用
14. 日志文件：验证服务器上日志是否正常工作，所有事务处理是否被记录
15. 目录文件：验证WEB服务器目录访问权限，或者每个目录访问时有index.htm，防止 WEB 服务器处理不适当，将整个WEB目录暴露
16. 身份验证：验证调用者身份、数据库身份、验证是否明确服务账户要求、是否强制式试用账户管理措施
17. 授权：验证如何向最终用户授权、如何在数据库中授权应用程序，确定访问系统资源权限
18. 会话：验证如何交换会话标识符、是否限制会话生存期、如何确保会话存储状态安全
19. 配置管理：验证是否支持远程管理、是否保证配置存储安全、是否隔离管理员特权
20. 备份与恢复：为了防止系统意外崩溃造成的数据丢失，验证备份与恢复功能正常实现、备份与恢复方式是否满足Web系统安全性要求
21. 数据库关键数据是否进行加密存储，是否在网络中传递敏感数据
22. 在登录或注册功能中是否有验证码存在，防止恶意大批量注册登录的攻击
23. Cookie文件是否进行了加密存储，防止盗用cookie内容
24. 密码强度提醒：建议对密码的规则进行加强设置
25. 密码内容禁止拷贝粘贴

二、测试用例

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

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

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

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

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

3. 杯子检测

1. 功能
   （1）水倒水杯容量的一半
   （2）水倒规定的安全线
   （4）水杯容量刻度与其他水杯一致
   （5）盖子拧紧水倒不出来
   （6）烫手验证