面试题—测试篇

一、需求分析

• 提取测试点：思维导图（全方位、系统的思考和描述）
• 功能需求：用户提出的功能是否满足
• 非功能需求：性能需求、稳定性需求、安全性需求、异常场景、易用性需求

二、产品质量六大属性

• 1、功能：正常值、边界值、异常值、多个操作顺序执行、多个操作交互执行
• 2、性能：性能测试是能接受的响应时间内的并发数，压力测试是超过性能指标时系统不崩溃的临界值
• 3、稳定性：监控软件检测系统长时间运行（CPU、内存）、稳定性环境（多用户同时进行多个正常操作和异常操作）
• 4、安全性：身份认证、授权控制、日志审计、敏感数据加密、隐私与合规性、敏感词
• 5、异常测试：断电、断网、弱网（wifi、2/3/4G、低带宽、高延时、高丢包、网络切换；测试目标：加载速度；）
• 6、易用性：用户体验

三、测试用例设计方法

1、流程类：路径分析法（流程图法）

覆盖方式	含义	特点
语句覆盖和分支覆盖	覆盖系统中所有判定和过程的最小路径集合	覆盖程度弱
全覆盖	所有可能路径（分支与语句的全排列）	100%覆盖、但用例条数太多
最小线性无关覆盖	找出最小线性无关路径集合：条件数+1（图论里面的原理）	保证流程图中每个路径片段至少被执行一次

2、参数类：输入输出表法

3、数据类：等价类、边界值

测试思维：有错推定、发散思维（探索性测试）

四、接口自动化和持续集成

1、需要注意的点包括两方面：用例（参考功能用例设计）、代码（参考工程代码的业务性要求）

2、自动化测试框架：python+robotframework、rf进行测试用例管理、测试用例用python编写

3、持续集成工具：jenkeins

• 怎么执行git仓库代码：源码管理选择git并配置git仓库地址、配置sshkey
• 构建触发器定时任务：在Build periodically中通过五颗星语法进行配置（比如：H 9,17 * * *，表示每天9点和17点进行构建）
• jenkins怎么调用python或者robot代码：安装相应插件就可以了

五、安全性

1、安全测试项：漏洞扫描、病毒扫描、端口扫描、防攻击

1）防攻击1---身份认证

• 服务交互：跨可信域的服务间、可信网络的服务之间、客户端与服务间交互
• 认证过程：身份凭证加密、防重放、防爆破、认证错误模糊化
• 用户账户：账户规范、密码规范、密码强度、

2）权限控制：业务权限控制、系统权限控制、关键操作二次鉴权

3）用户日志审计：日志存储时长、日志敏感信息、日志内容规范、运维日志、用户日志、syslog

4）敏感数据加密：音视频、配置文件、密码文件、密钥文件

5）隐私：隐私合规

六、可靠性测试

• 断电：恢复供电后功能正常
• 断网：恢复网络后功能正常
• 重启：重启功能正常
• CPU负载90%：业务操作存在卡顿，但功能正常，不会崩溃
• 内存负载90%：业务操作存在卡顿，但功能正常，不会崩溃

七、性能

1、性能需求分析思路

性能需求分析往往是性能测试中的第一步，做好性能需求分析我们才能知道性能测试需要去测些什么，继而去做好性能测试，来提高产品质量。

1）性能分析相关人员

• 测试人员：要从需求文档中提炼出性能测试需求，从需求中深刻理解产品，了解行业内该类产品的性能参数，找出需求文档中遗漏的性能参数
• 产品经理：应尽可能在需求文档中给出产品的性能参数，产品经理往往都是和用户接触最多的人测，测试人员可以向产品经理了解用户对产品的使用习惯，经常使用的功能和用户扎堆的场景等等
• 客户：产品开发前期，测试一般是接触不到用户的，如果有条件，测试人员应深入客户当中，了解客户对产品的性能需求，了解用户使用系统时的规律。如果没有接触客户的条件，也要间接的通过产品经理去了解这些
• 开发人员：测试应向开发人员了解哪些功能容易产生性能瓶颈，哪些业务会产生大量数据，性能测试场景操作会调用哪些接口，调用的接口是否有依赖关系

2）性能需求分析checklist

当需求文档中没有给出性能需求时，我们该如何去找性能测试点呢？可以根据下面的checklist去分析找出性能测试点

• 系统核心功能有哪些：核心功能往往是大量用户使用的功能，容易产生并发请求。
• 用户高频使用的场景什么，操作步骤是什么样的？：高频率使用的功能也是容易造成性能瓶颈的地方，如12306抢票时的车票查询界面频繁刷新，电商平台的秒杀活动，人们在一次请求不成功后会不断的重复请求，这样就会造成大量的并发请求，这也是我们性能重点测试的地方
• 用户扎堆的场景：很多业务用户喜欢扎堆处理，比如财务月结，这样就会导致对系统的高并发请求，可能产生性能瓶颈
• 用户活跃时间：这个和用户扎堆场景有些类似，不同的是要分析出用户的活动具体时间和时长，这也是影响系统性能的重要条件，如某部门上班时间为8：30、上班后员工会首先登陆系统前5min是公告查看高峰阶段、早7点到9点是道路车辆行驶高峰，会产生大量过车数据。
• 并发时容易出错的场景：容易出错的场景测试似乎不容易发现，可能需要研发给出这种场景或后续测试时发现这种场景
• 容易受带宽限制的场景：容易受带宽影响的一般是需要传输大文件的场景，例如查看实时视频，查看录像回放
• 产生大量业务数据的操作场景：对系统造成性能瓶颈的不一定是用户并发的场景，也可以是设备产生的大量数据，例如卡口设备产生的大量过车数据或流量数据

3）性能测试参数

通过上面的方法我们已经拿到了性能测试点，但还需要知道具体的参数才能做性能测试，性能测试参数要从两个方面考虑

• 哪些因素会影响性能测试结果
• 性能测试需要达到什么样的结果

下面是常见的影响性能测试结果的因素

• 系统组网方式：单产品测试时往往不需要考虑组网的方式，但项目中组网方式往往不同，这时我们需要了解清楚项目的组网方式，测试环境严格按现场环境搭建
• 系统的硬件配置：理想情况下我们性能测试应使用产品的标准服务器，但由于服务器是紧缺资源，完全使用标准服务器很难实现，但一定要保证性能测试服务器的配置和标准服务器配置一致
• 用户量及业务占比：一般性能测试是要给出我们目标用户量的，如果没给出就要做容量测试，逐步增加用户量找出系统的最大容量，系统操作中，不同的业务操作会对资源进行抢占，所以确认业务占比也是非常重要的，业务占比应根据生产环境中的配比给出
• 预埋数据量：预埋多少数据量也是至关重要的，一万的数据量和一千万的数据量中查询响应时间肯定是不一样的，所以一定要明确预埋的数据量级别

2、性能测试常见指标

并发数、业务成功率、响应时间、cpu使用率、内存使用率

3、确定硬件信息

• CPU：lscpu命令查看cpu信息、cpu个数=物理cpu个数*每个物理cpu的核数*每个核的线程数*复用比、
• 内存：free命令内存信息
• 查看cpu和内存使用情况：top命令、load average、%cpu（其中us表示用户使用时间占比）、每个进程的使用情况、RES表示进程使用内存情况、%CPU、%MEM

4、性能测试工具

• 工作原理：将请求并发发送到目标服务器并收集来自目标服务器的响应，对响应数据进行统计，这些统计数据通过图形或表格展示出来。
• 线程组：并发线程数量；采样器：什么协议的请求
• 常见监听报告：聚合报告（表哥）、查看结果树（单请求的信息）、图形结果（折线图）
• 分布式负载压测：单机压力不够时使用master/slave模式进行分布式压测，master将压测脚本发送到slave后slave执行压测脚本

5、性能瓶颈定位思路

1）整体思路：整体瓶颈（前端-网络-后端）->  后端瓶颈(应用程序瓶颈-中间件瓶颈-数据库瓶颈)

6、性能优化思路

• CPU：应用程序运行在内存中，所以性能开销一般是CPU闲置导致，增加多线程提高CPU利用率是最快的提升性能的方法。
• 内存：减少链表等需要内存寻址的操作
• 网络：避免在for循环中建立网络连接
• 磁盘：避免在for循环中等待磁盘IO、数据库可以（索引：避免全盘扫描；优化sql：避免频繁进行IO交互；分页技术：）

中间件性能优化：中间件大多为第三方产品，提高硬件设备性能是唯一的办法（建立集群（增加机器数量）、使用多核CPU、增加内存、使用千兆网卡和网线、使用固态硬盘等）