软件测试_面试宝典

对于测试的心得:

态度:态度比能力重要，思虑周全，细心耐心，良好的沟通能力

学习能力也很重要

测试理论:

1. 测试流程
   1. 了解需求
      • 产品经理》需求文档（包含该产品的用户群体、产品目标、产品功能等内容）》测试和开发
      • 澄清会议（需求评审）
        1. 与会人员:产品经理、开发、测试、项目经理
        2. 会议目的：
           1. 需求是否可实现（开发）
           2. 需求是否可测试（测试关注）
           3. 使测试和开发对需求的理解一致

 

3）会议结束：完善需求文档

1. 1. 测试准备
      • 测试计划
        1. 一般由组长编写，半天
        2. 内容：测试任务，测试的策略和方法，测试资源，测试进度，人员安排，测试的交互件
      • 测试用例
        1. 组长分配任务》组员编写测试用例
        2. Xmind提取测试点》编写测试用例》用例评审》修改用例
        3. 测试用例编写规则：8大要素
        4. 用例评审
           1. 与会人员：产品经理、开发、测试、项目经理
           2. 会议目的
              1. 完善补充用例，提升用例覆盖度
              2. 修改错误用例
              3. 再次使得开发和测试对需求的理解达到一致
           3. 会议结束：完善需求文档
      • 测试数据
   2. 执行测试
      • 开始将代码部署到测试环境》提测
      • 测试开始
        1. 冒烟测试：不通过则打回，通过则转测
        2. 测试集
           1. 一轮测试：全量/新功能模块的全量
           2. 二轮测试：主流程，新功能模块，bug较多模块，bug复测
           3. 三轮测试:主流程、新功能、bug复测
2. 你提交的bug,开发不认可怎么办？
   1. 自我检讨-自己去看需求文档，看是不是自己理解有误
   2. 保存好相关日志、截图和视频、跟开发沟通
   3. 第三方-产品经理/项目经理，反应

Linux系统一般是怎么用的？

1. 发现bug,查看日志定位问题
   1. s-发现了bug
   2. t-定位问题
   3. a-看日志
      • 需要日志的路径
        1. 默认-log目录下
        2. 其他-开发可能指定位置存放目录，为了安全（问开发路径）
      • 日志看什么
        1. 日志类型
           1. 普通-打印所用日志内容-access_log20200610
           2. 特殊-专门保存错误的日志文件 error_log
        2. 日志日期
           1. 很多项目，每天都会生成一个日志access_log20200610(昨天的日志)
           2. 没有日期的就是今天的日志access_log（今天的日志）
      • 怎么看
        1. 文件查看命令
           1. cat, head,tail, more, less:tail -200 access_log 查看access_log日志中后200行内容
           2. 注意：测试的过程中，其他人也在测试，也会打印日志掺杂在一起（先停一下） tail -f -200 access_log 动态查看日志
        2. 重定向文件，去查看日志，导入至windows查看
      • 日志看什么内容
        1. 关键字 error, exception, fatal
           1. error-一般是代码错误，语法错误
           2. exception-系统出现了故障，如空指针异常，没有定义的类
           3. fatal -致命
        2. 非关键字，可能是逻辑错误-只能根据时间点去查找对应的日志
      • 日志看完了
        1. 能看懂，知道问题在哪里，我们就直接定位问题给开发
        2. 看不懂，那就在提交bug时，截图，日志文件提交到bug单里面

 

1. 1. r-找出相关日志文件，定位问题
2. 系统出现了故障
   1. S-系统出现了故障，eg测试过程中：环境访问不了，报错或者很卡的情况（内存、CPU、磁盘）
   2. T-定位问题
   3. A-查看服务器，资源使用情况
      • 查看服务是否启动
        1. ps -ef | grep httpd进程名
      • 服务启动了，但还是用不了
        1. 端口是否被占用 netstat -an grep 80
      • 很卡很慢
        1. 查看服务器资源使用情况
        2. top查看资源的使用情况
        3. free -m查看内存的使用情况
        4. df-查看磁盘的使用情况
        5. 重启服务、关闭一些资源（运维做）
   4. R-定位到问题
3. 性能监控，监控服务器资源
   1. S-性能测试的时候
   2. T-监控服务器资源
   3. A-监控服务器资源的使用情况
      • 可以用命令-top,free -m, df
      • 可以利用nmon工具，监控资源（可生成图表）
   4. R-了解并记录服务器资源使用情况

 

数据库怎么用？

1. 测试前-准备测试数据
   1. S-用例已写好，知晓需准备哪些测试数据
   2. T-准备数据
   3. A-导出、制造数据
      • 连接数据库
        1. 数据库的类型
        2. 知道数据库的地址，IP或域名，端口号，（默认3306，很多公司会更改为其他端口号），用户名，密码
        3. 下载连接数据库的工具
      • 操作数据库:前提条件，要知道查看表，表结果是什么》找开发要数据字典或类似的文档
        1. 问开发，对应的是哪张表
        2. 了解到数据库以后，看单词的意思，去猜测表的内容
        3. 造数据
           1. insert into新增数据
           2. update 修改原有数据
   4. R-准备数据完成
2. 测试过程中-检查测试结果
   1. S-测试过程中检查数据是否正确；出问题的时候，再去检查
   2. T-检查数据是否正确
   3. A-核对数据
      • 和之前的类似
   4. R-确保测试质量；排除是否为数据的问题
3. 性能测试-准备大量的测试数据（若自己掌握较差，不讲性能相关可忽略）
   1. S-需要做性能测试的时候
   2. T-准备大量测试数据
   3. ......和上面的还是一样（省略）

 

网络协议

1. 请求的方式有什么
   1. 常用:get post
   2. 不常用: delete put hean option
2. get和post的区别
   1. 长度 get长度受限 post无长度限制
   2. 格式 get只接受ascii码 post无格式限制
   3. 参数位置:get参数写在URL之中 post参数写在请求正文中
   4. 请求次数：get只发送一次 post发送两次（1.请求头相关信息 2.发送请求正文）（部分浏览器发送两次）
   5. 安全：post比get更安全
3. HTTP协议包含了哪些内容
   1. 请求信息
      • 请求行-请求方式，请求地址，HTTP版本
      • 请求头-host:主机，server:服务器版本信息，
      • 请求正文--data
   2. 返回信息
      • 状态行-HTTP版本、状态码、状态信息
      • 响应头-和请求头一样
      • 响应正文-data
4. HTTP常见状态码
   1. 1xx:需要继续发送请求
   2. 2xx：成功 200
   3. 3xx 需要重定向 302(临时移动) 301（永久移动）
   4. 4xx 客户端请求数据有误 400（服务器理解不了请求的语法） 404：服务器找不到请求的网页
   5. 5xx 服务端相应错误 500f服务器内存错误，无法完成请求；504 服务器作为网关或者代理，没有及时从上游服务器接受到请求

接口测试怎么测?

1. 后端开发与数据层开发完成以后，可以开始接口测试
2. 测试逻辑层与数据层、确认业务是否能正常使用

1. 具体怎么做

1. 接口文档
   1. 接口URL地址，请求参数，请求方式，返回结果
   2. 接口文档格式，HTML或word
2. 接口分析
   1. 只测试接口是否能够跑通：只需要考虑正常场景
   2. 接口场景需要全面覆盖
      • 正常场景
        1. 申请借款模块：
        2. 判定表的方式-每个条件组合，测试结果是否正确
        3. 参数格式的校验、等价类、边界值等等
        4. 参数定义的int类型，传输的是int类型
        5. 参数定义的是string类型，传输数据，正常得是string,但是在开发框架里面，输入int类型，也会被强行转成string类型
      • 异常场景
        1. 少一个必填参数
        2. 多一个参数
3. 接口用例
4. 执行
   1. 选择工具执行：
      • Jmeter(主流）
        1. 打开jMeter(1.找到bat文件运行 2.cmd输入jmeter)
        2. 新建线程组
        3. 新建HTTP请求
           1. 请求方式-get,post
           2. 请求参数-表单格式，json格式，xml格式
      • requests
      • postman（主流）
      • swagger
      • soupui
      • 在线测试工具
5. 检查对应的结果
   1. JMeter-建立监听器，查看结果树
   2. requests print出来，打印结果
   3. 检查返回结果是否正确
   4. 检查逻辑结果，保存的数据是否正确

R-完成对逻辑层和数据层的检查测试

给你一个新的接口，怎么设计用例

1. 拿到接口文档，需要开始设计用例
2. 编写用例

1. 怎么做
   1. 分析接口
      1. 只测试接口是否能够跑通：只需要考虑正常场景
      2. 接口场景需要全面覆盖
         1. 正常场景：
            1. 参数的约束-长度、必选项、数据类型
            2. 业务场景-正确/错误业务场景、异常场景
            3. 组合场景-互相依赖；相互排斥
            4. 对于不理解的参数/返回值不理解，问开发
         2. 异常场景：
            1. 少一个必填参数
            2. 多一个参数

R-编写用例完成

接口自动化测试

1. 环境切换-版本迭代，都可以先运行自动化脚本
2. 完成接口自动化的任务

1. 具体怎么做
   1. 数据参数化
      1. 运行脚本时，不需要修改参数、变量值、以此来降低维护成本
      2. 函数参数化
      3. 列表、字典、变量、csv文件
   2. 动态关联

接口之间有内在联系时，前面接口的返回参数是后面接口的请求参数

1. 1. 断言
      1. 添加一个自动检查
      2. assert断言
         1. 判断接口的返回结果
         2. 数据库断言，查看数据库里是否包含生成的数据
   2. Jmeter
      1. 打开jmeter
      2. 新建线程组
      3. 新建HTTP请求
         1. 参数化-用户名、密码、host地址...
         2. 动态关联
            1. 登录接口
               1. 提取登录后的cookie值
               2. 建立全局变量 参数定义
               3. 建立beanshell后置处理器，setProperty函数，定义全局变量
            2. 充值接口
               1. 添加一个cookie管理器
               2. _p函数（函数助手）
         3. 断言-响应断言，大小断言，时间断言，自由断言

R-完成对逻辑层和数据层的检查测试

性能测试

之前没接触过，但是知道是用Jmeter去做的，接触不多，会做一点

1. 每个公司的要求不一样
2. 压测产品的性能情况
   1. 找出性能问题；性能测试报告-性能是否达标

1. 具体怎么做
   1. 性能需求
      1. 性能指标
         1. 并发用户数 通过公式去计算/指定
         2. 响应时间 不同模块要求不一样
         3. 平均响应时间 80%用户的响应时间
         4. 吞吐量 吞吐率 80%以上
         5. 事务成功率
      2. 资源指标
         1. CPU内存 内存 使用率就控制在75%以下
         2. 网络、磁盘
   2. 制定性能测试计划
      1. 全部测试-一个星期可以完成

1天编写用例、1天准备环境、2天执行用例、1天测试报告与分析

1. 1. 1. 部分测试-1-2天就能完成（具体问题具体分析）
   2. 性能测试用例
      1. 单个业务场景的测试
      2. 混合场景的测试
      3. 负数测试，不断加压
   3. 准备环境
      1. 设备
         1. 服务器
         2. 压测机-选择一台比较干净的机器
      2. 编写性能测试脚本
         1. 参数化
         2. 断言
         3. 动态关联
         4. 模拟用户的操作
      3. 测试数据
         1. 需要模拟大量用户操作，需要提前准备大量的测试数据
   4. 压测
      1. 监控服务器资源 在脚本运行之前打开
      2. 运行脚本
         1. 单个场景压测-一般运行在15-30分钟，并发用户数在原有基础上添加10%-20%
         2. 混合场景压测-运行30-60分钟
         3. 负数测试-没有时间限制，找出系统的瓶颈，什么时候会崩溃
   5. 测试报告与结果分析（1天）
      1. 测试资源
      2. 测试设计-计划
      3. 结果分析
      4. 测试结论
      5. 优化和建议
      6. 测试通过的标准
   6. 调优
      1. 响应时间过长
         1. 资源使用率太高
         2. 中间件线程组太大
         3. 数据库-数据数、索引，SQL优化、索引命中率、sleep等待时间过长、临时表空间
         4. 代码质量问题
         5. 网络问题
      2. 资源使用率不足
         1. 资源数不够
         2. 带宽间距
         3. 中间件连接数
         4. 数据库的问题
         5. 代码质量

 

R-找到系统瓶颈，完成性能测试，得出性能结果

安全测试:自己做过，做的次数少，不多

1. 怎么做安全测试
   1. S-功能测试结束后（跟公司要求有关）
   2. T-测试软件是否存在安全隐患
   3. A-具体怎么做
      • SQL注入/XSS脚本攻击
      • 数据加密
        1. 前端-关键信息进行加密显示
        2. 传输过程中-加密/篡改
        3. 后端-日志/数据库中，关键信息是否有加密
      • 权限控制

需要权限的界面，铜鼓URL直接访问

1. 1. R-检查软件信息安全是否达标
2. 白盒测试怎么做
   1. 静态扫描-直接检查代码
   2. 动态检查
      • 语句覆盖-覆盖所有代码
      • 判定覆盖-覆盖每个判定条件
      • 条件覆盖-每个条件
      • 判定/条件覆盖
      • 组合覆盖，条件之间的组合场景
      • 路径覆盖，流程分析
3. 集成测试怎么做
   1. S-迭代产品，自动化用例编写完成
   2. T-定时测试（杀虫剂的原理）
   3. A-具体怎么做
      • 搭建环境
        1. 安装-Jenkins/ant/jmeter/svn（或其他代码管理工具）
        2. 连接jmeter与ant
      • 构建任务
        1. 配置定时
   4. R-减轻测试压力，确保测试质量