软件测试52讲

https://www.cnblogs.com/tsingke/p/8604871.html
网络协议分层的理解

自定义网络协议更加安全和轻便

实模式没有权限分级，用户程序和OS同一权限，容易直接修改系统程序或其他用户程序
保护模式寄存器存的不再是段基址，而是索引，是对GDT（全局描述表）或LDT的映射,
虚拟8086模式是运行在保护模式中的实模式，为了在32位保护模式下执行纯16位程序

---

①
ABC（AI，大数据，云）技术浪潮，对人的测开能力要求很高

测试需要有开发的思维，相反也是。测开属于统筹任务

测试三大方法——

等价类划分：如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
如测试合不合格：0~59的整数和60 ~100的整数是两个等价区间，浮点数不是

边界值分析-1，0，1，59，60，61，99，100，101。

错误推断取决于经验和个人能力，一般企业有常见漏洞知识库做checkList

登录测试用例：
输入已注册的用户名和正确的密码，验证是否登录成功；
输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。

有经验加上以下测试用例：
用户名和密码是否大小写敏感；
页面上的密码框是否加密显示；
后台系统创建的用户第一次登录成功时，是否提示修改密码；
忘记用户名和忘记密码的功能是否可用；
前端页面是否根据设计要求限制用户名和密码长度；
页面默认焦点是否定位在用户名的输入框中；
如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
刷新页面是否会刷新验证码；
如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
快捷键 Tab 和 Enter 等，是否可以正常使用。

---

但上面都是显示功能性需求，还有隐式功能性需求
主要包括：安全，性能，兼容性

安全性测试用例包括：

用户密码后台存储是否加密；
用户密码在网络传输过程中是否加密；
密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
密码输入框是否不支持复制和粘贴；
密码输入框内输入的密码是否都可以在页面源码模式下被查看；
用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

性能压力测试用例包括:

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

兼容性测试用例包括：

不同浏览器下，验证登录页面的显示以及功能正确性；
相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
不同分辨率的界面下，验证登录页面的显示以及功能正确性。

---

②
如何设计——
业务需求，软件功能需求，测试需求，测试用例

③单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。

单元测试的输入数据：
被测试函数的输入参数；

被测试函数内部需要读取的全局静态变量；

被测试函数内部需要读取的成员变量；

函数内部调用子函数获得的数据；

函数内部调用子函数改写的数据；

嵌入式系统中，在中断调用时改写的数据；

输出：
被测试函数的返回值；

被测试函数的输出参数；

被测试函数所改写的成员变量；

被测试函数所改写的全局变量；

被测试函数中进行的文件更新；

被测试函数中进行的数据库更新；

被测试函数中进行的消息队列更新

驱动代码/mock代码/桩代码

Mock 代码和桩代码非常类似，都是用来代替真实代码的临时代码，起到隔离和补齐的作用。但是很多人，甚至是具有多年单元测试经验的开发工程师，也很难说清这二者的区别。

在我看来，Mock 代码和桩代码的本质区别是：测试期待结果的验证（Assert and Expectiation）。（无法通过桩代码直接模拟系统底层函数的调用）

桩代码的验证在驱动代码中，mock的验证在mock函数中
桩代码更注重被测函数执行路径，mock更注重执行细节

单元测试两个概念：测试通过率和代码覆盖率
Java单元测试框架：Junit和Test NG

–
④自动化测试
维护自动化测试用例成本高于节省的测试成本时，不需要自动化测试

只有当开发完成的测试用例的有效执行次数大于等于 5 次时，才能收回自动化测试的成本。

什么样的项目适合AUTO测试：

1. 需求稳定
2. 产品周期长，回归测试多
3. 高并发测试，7*24h的性能稳定测试
   开发人员要预留可测试性接口，如登录避开验证码

---

⑤哪些自动化测试技术

自动生成框架代码，输入数据（空指针和非空指针），桩代码

到了集成测试时必须抽桩，且更注重不同模块数据的传递

SOAP API和REST API
前者安全性更高，WS security，后者支持多种格式不止XML，占带宽更少，有缓存速度更快

目前最流行的 API 自动测试框架是 REST Assured和HttpRunner

web端GUI自动测试：selenium
移动端：appnium

---

⑥测试覆盖率
主要指代码覆盖率：判定覆盖，条件覆盖
只有单元测试对代码覆盖率有较高的要求
JaCoCo代码覆盖率工具
源代码注入和字节码注入，一般是后者，使用ASM技术。动态生成类或者增强既有类的功能

根据注入发生的时间点，字节码注入又可以分为两大模式：On-The-Fly 注入模式和 Offline 注入模式

前者开发自定义的类装载器（Class Loader）实现类装载策略
后者在测试运行前就已经通过 ASM 将探针插入了 class 文件。它适用于不支持 Java Agent 的运行环境，以及无法使用自定义类装载器的场景。

–
⑦缺陷报告
标题，概述，影响，环境配置（OS，软件本身版本，浏览器版本，集群配置参数和中间件配置），前置条件（如已完成登录状态出现的BUG）

变通方案
根原因分析：Root cause analyse

–
⑧测试计划
测试范围：要测什么

测试策略：先测什么后测什么，重点

• 功能
• 兼容性
• 性能

测试资源：谁来测，在哪个环境测
测试进度
测试风险预估

–
⑨
策略设计能力
用例设计能力：高效发现缺陷。不仅需要深入理解被测软件的业务需求和目标用户的使用习惯，还要熟悉软件的具体设计和运行环境，包括技术架构、缓存机制、中间件技术、第三方服务集成等等。
缺陷发现能力

测开要加上：测试架构部署和生产架构部署
要能够站在测试架构师的高度，识别出测试基础架构的需求和提高效率的应用场景

–
⑩需要了解Docker 和 Kubernetes Jenkins AntD

大型互联网企业，通常还会考虑建立自己的测试执行私有云。最典型的就是，基于 Appium + Selenium Grid，搭建移动终端设备的测试执行私有云

–
十一.如何设计测试策略
传统的软件：由底向上，单元，API，GUI测试
单元：白盒测试，投入大，一般开发自己完成（大头）
API：灰盒测试，一般用代码覆盖率指导测试用例的设计

互联网产品的 GUI 测试通常采用“手工为主，自动化为辅“

而API是大头，原因：开发测试用例效率高，稳定性高

单元测试采用“分而治之”的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试

---

十二：GUI测试从0到1
chrome driver是selenium和chrome的通信渠道
selenium 1.0也就是selenium rc server和client library,通过js获取页面元素，执行操作
（其中有http server模块欺骗浏览器，避开同源策略）
rc分为selenium core和proxy，laucher（注入前两块）
cl就是调用RC的代码

selenium2.0 是web driver，典型的CS模式
webdriver可以看作浏览器的原生组件

---

十三：测试数据和操作的解耦（可读性和可维护性）
数据驱动思想，将CSV文件中的数据传递给脚本
模块化思想，相同的操作封装函数，传参为需要的数据

页面对象模型（页面为单位封装控件和操作）：用类名.X.Y的形式
定义好Y（定位元素），Z为实际方法

---

十四五：GUI自动化测试

创建测试数据：

• API调用
• 数据库操作（手动查找设计文档找SQL或者先做一遍GUI测试，从数据库监控工具看创建了哪些SQL）

对于相对稳定的测试数据，用Out of box(提前准备)
一次性使用，或经常要改，用On the fly

---

十六 页面对象自动生成（自动化你的自动化）

GUI测试数据自动生成

无头浏览器：速度更快（无需CSS及渲染，也是缺点不适合验证页面布局），简化测试环境搭建（selenium集群）
缺点：不能完全模拟用户真实行为

chrome＋puppter是最好的无头浏览器方案

---

十七：GUI测试稳定性

• 随机弹框 异常 场景恢复模式
• 延迟 retry机制（步骤，页面，流程级别）
• 控件属性变化 模糊匹配
• AB 测试 识别出那种，提供对应处理

---

十八 GUI测试报告

扩展 Selenium 原本的操作函数；

在相关的 Hook 操作中调用 screenshot 函数。

---

十九
优先选业务关键路径和Happy Path
写页面对象类，封装业务流程脚本，构造模块测试用例

---

二十 移动端测试
hybrid app:外部是native container,里面包着 web
需要移动端web支持web driver

格外注意的：

1. 流量多
2. 耗电大
3. 崩溃异常
4. 弱网环境
5. 无法顺利安装卸载
6. ANR：程序不响应

所以有了

1. 手工 中断性测试（接到电话，低电量，网络切换）
2. 自动化云测平台 兼容性测试（机型，分辨率，网络，语言）
3. 耗电性测试（安装，升级，后台，业务进行）
4. facebook的ATC工具 弱网环境（隧道，地铁，地下车库）
5. 边界环境（内存，储存被占特别大，飞行模式和时区切换，不具有权限的时候）

---

二十一：Appnium
DesiredCapabilities dc=new DC();
dc.setCapabilities(MobileCapabilityType.X,value of x);
mobileDriver.get(“url”)
Assert.assertEquals(mobileDriver.getTitle(),“true title”,“mismatch information”);

集成 TestNG组织测试用例（Java的测试框架，需要一个testng.xml文件）和Java-Client（java和appium的桥梁）

Appium原理：分为Client Server 设备端
Server接受请求，和移动设备的代理工具打交道，工具根据WebDriver协议，解析要进行的操作，调用移动端原生测试框架(XCUI test和UIautomator)，完成测试

---

二十二：cURL和PostMan
一般API测试：准备测试数据，发出request,收到response

POSTMAN步骤：

1. 发起API调用
2. 添加结果验证snippets
3. 保存测试用例 save as到Collections
4. 点击code,测试代码生成，用于CI/CD

多个API协调完成时，获取请求序列，可以抓包

异步API检测，一个是否成功（检查返回值和后台线程是否创建），一个是否逻辑正确

第三方API：MOCK SERVER模拟

---

二十三
基于界面的工具难以：批量集成CI/CD

于是有了newman+postman，new是一个命令行 工具，可以执行postman的测试用例（只适合单个调用）

大厂为了自己的需求，会基于 Rest-Assured 封装了全新的 API 测试框架。

方便在API调用前后做额外工作：如数据准备。现场清理

输入为postman中collection的json文件，输出为带assert的自动化代码

向后兼容性，request和reponse都不能被改变。但也不可能所有都写assert,
方法是在API测试框架引入内建，非关系型数据库，记录每次调用的request和reponse组合。每次都和已有的做差异检测。（建立白名单列表，把动态参数排除在外）

---

二十四 微服务下的API测试
单模块：
灵活性差
扩展性差
稳定性差

对于测试，用例数量巨大。
所以推出基于 消费者契约的API测试

在被经常调用的service T设置代理，所有经过的request和reponse记录成json文件

代理就是微服务中的网关