测试与调试的区别
- 测试是由测试人员进行，主要目标是发现、报告和跟踪缺陷。
- 调试是由开发人员进行，主要目标是定位缺陷位置，分析缺陷原因，修复缺陷。 软件测试的含义 使用人工或自动手段来运行或测定某个系统的过程，目的在于检验是否满足规定的需求或弄清预期结果与实际结果之间的差别。 软件测试的原则
- 测试应该尽早介入。
- 测试都应追溯到用户需求。
- 程序员应该避免检查自己的程序。
- 测试用例应考虑到合法的输入和不合法的输入以及各种边界条件。
- 二八原则，测试发现的错误中80%很可能出现与20%的模块中。
- 对错误结果要进行一个确认过程。
- 制定严格的测试计划。
- 完全测试是不可能的，测试需要终止。
- 妥善保存测试过程中的所有文档。 测试左移和测试右移模型
- 测试左移，本质上是借助工具和测试手段更早地发现问题和预防问题。 i. 需求：对需求、架构和设计模型的测试。 ii. 开发：着重增加对单元、组件和服务层对测试。 iii. 持续测试：自动化测试。
- 测试右移，对测试来说，版本上线后需要持续关注线上监控和与预警，及时发现问题并跟进解决，将影响范围降到最低。 i. 灰度发布：新版本线上测试。 ii. 监控：合理的性能监测、数据监控和预警机制。 iii. 用户反馈：线上问题处理、跟踪机制。 什么是功能、性能、兼容性 • 功能代表一个软件能做什么。 • 性能反应软件运行的速度或效率、占用资源的多少等指标。 • 兼容性表示一个软件与其运行环境的依赖程度，包括与硬件、操作平台、其他软件的依赖。 测试的分类
- 按测试执行阶段划分 i. 单元测试：完成最小的模块验证工作。 ii. 集成测试：通过测试发现与模块接口有关的问题。 iii. 系统测试：基于系统整体的黑盒类测试，应覆盖系统所有联合的部件。 iv. 回归测试：发生修改后重新测试先前的测试用例以保证修改的正确性。 v. 验收测试：根据测试计划和结果对系统进行测试和验收。 a. Alpha测试：由用户在开发者的场所进行的，一个受控的环境中进行。 b. Beat测试：用户在一个或多个用户场所进行，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。
- 按测试技术划分 i. 白盒测试：结构测试或逻辑驱动测试，针对被测单元内部是如何进行工作的测试。 ii. 黑盒测试：功能测试或数据驱动测试，已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。 iii. 灰盒测试：综合测试的方法，将白盒和黑盒结合在一起，构成一种无缝测试技术。
- 按测试对象是否运行划分（白盒） i. 动态测试：需要执行代码，通过运行程序找到问题。 ii. 静态测试：不用运行代码，通过人工进行测试。
- 按不同的测试手段划分 i. 手工测试 ii. 自动化测试
- 按测试包含的内容划分 i. 功能测试 ii. 界面测试 iii. 安全测试 iv. 兼容性测试 v. 易用性测试 vi. 性能测试 vii. 压力测试 viii. 负载测试 ix. 恢复测试
- 其他测试 i. 冒烟测试 ii. 探索性测试 iii. 自由测试 黑盒测试与白盒测试区别
- 黑盒测试：把测试对象当作一个黑盒子，测试人员完全不知道程序逻辑结构和内部特性，只能依据程序的需求说明书来检查程序的功能是否满足它的功能需求。 i. 优点 a. 不需要了解程序内部的代码与实现。 b. 与软件的内部实现无关。 c. 从用户角度出发，知道用户会用到哪些功能，遇到哪些问题。 d. 基于软件开发文档，知道实现了文档的哪些功能。 e. 方便做软件自动化测试。 ii. 缺点 a. 测试覆盖率低，大概只能达到总代码量的30%。 b. 自动化测试的复用性低。
- 白盒测试：把测试对象当作一个透明盒子，允许测试人员利用程序结构，逻辑结构以及相关信息，设计或选择测试用例，对程序所有的逻辑进行测试。 i. 优点 a. 帮助测试人员增大代码的覆盖率，提升代码质量。 ii. 缺点 a. 程序运行时会有不同的路径，不可能测试所有路径，可能会漏掉一些功能需求。 完整的测试应该由哪些阶段组成？
- 测试需求分析阶段：阅读、理解需求文档，参与需求评审会。
- 测试计划阶段：编写测试计划，一般由测试负责人编写，参加测试计划评审。
- 测试设计阶段：编写测试用例，参考需求文档，及时和开发、产品经理沟通，完成后会进行评审。
- 测试执行阶段：前后台对接完成后，执行冒烟测试，通过后执行测试用例进入正式测试，经过第一轮、第二轮的版本迭代测试，遇到bug提交到管理平台，并对bug进行跟踪，每一轮提交一份阶段性的测试报告，测试结束。
- 测试评估阶段：给出测试报告，开展系统级别的性能测试和安全测试并提交性能测试报告和安全测试报告，确认是否可以上线。 测试计划包含的内容
- 测试项目说明
- 测试文档：测试依据、测试条件、测试用例
- 测试范围：新增需求+全功能回归
- 测试策略：制定测试整体策略、所使用的测试技术和方法
- 重点事项：优先级为high的
- 计划测试资源：人员以及安排的工作日
- 测试方法：功能测试？性能测试
- 测试出口：发布时间 一个bug（缺陷）的生命周期 提交->确认->分配->修复->验证->关闭 软件测试类型有哪些？如：水杯测试用例
- 功能性：水杯漏不漏水，水能不能喝到。
- 可靠性：杯子从不同高度掉落下来的损坏程度。
- 易用性：是否烫手，是否有防滑措施，是否方便饮用。
- 可移植性：杯子在不同地方、温度、环境下，是否可以正常使用。
- 界面测试：杯子的外观。
- 安全性：杯子是否有毒。
- 兼容性：是否容纳多种液体。
- 效率性
- 疲劳测试：将水杯盛满水放24小时检查泄漏情况。
- 压力测试：用根针并在针上面不断加重量，看压强多大时会穿透。 测试用例通常包括什么内容？
- 用例编号
- 测试项目
- 操作标题
- 重要程度
- 预置条件
- 输入数据
- 操作步骤
- 预期结果
- 实际结果 哪些测试管理工具
- 禅道
- testlink
- testcenter
- jira 测试用例设计方法
- 等价划分法 i. 有效等价类，如：有效的红包，0.01-200，数字 ii. 无效等价类，如：无效的红包，小于0.01，大于200，小数点后超出2位的值，非数字。
- 边界值分析法 i. 正好等于，刚刚大于、刚刚小于边界的值作为测试数据。0和负数是特殊值。 ii. 如红包的边界值：0、0.01、199.99、200、200.01，负数
- 场景法 i. 通过场景描述业务流程、业务逻辑，代码实现逻辑，设计用例来遍历场景，验证系统功能正确性。 ii. 画出流程图，使用场景法。
- 错误推测法：基于经验、知识、直觉推测程序中所有可能存在的各种错误。
- 因果图法：一个界面中，多个控件，这些控件存在约束关系或组合关系，且输出依赖于输入条件。
- 判定表法：适用于逻辑判断复杂的场景，通过穷举条件获得结果，对结果进行优化合并，得到一个判断清晰的判定表。 测试用例方法的选择
- 进行等价类划分，主要输入条件的划分，提高测试效率最有效的方法。
- 任何情况下都必须使用边界值分析法，这种方法设计出的测试用例发现程序错误的能力最强，切记不要穷举测试。
- 用错误推测法追加测试用例，需要经验总结。
- 对照程序逻辑，检查已经设计出的测试用例的逻辑覆盖程度，如果没有达到覆盖标准，应当再补充足够测试用例。 用例评审的流程
- 准备测试用例。
- 提前发布评审通知，参与人员：项目经理、测试负责人、测试人员、产品经理、开发人员、开发经理。
- 召开会议评审。
- 评审结束后，给出测试用例评审报告到相关人员。 测试分为几轮，然后每轮都测试哪些内容？ • 第一轮测试：要覆盖所有测试用例。所有功能都要跑一遍。 • 第二轮测试：重点功能的测试。还要把第一轮测试发现的问题，根据开发修改完成的结果，进行验证。 • 最后一轮是回归测试：验证所有bug是否都修改完毕。 上线的标准是什么？
- 所有功能点（需求）都被用例覆盖到了。
- 所有用例执行过至少两遍。
- 所有发现的bug被修复并验证，做过回归测试了。
- 不能修复或重现的bug已经记录了。
- bug通过率在95%以上，严重级别bug通过率100%。
- 接口、安全、性能、稳定性达到要求。
- 产品验收通过。 如何编写测试用例，根据什么来编写？ 根据需求文档（需求说明书、原型图、之前的产品、竞品）编写用例（UI、功能、兼容性、安全、性能、稳定性易用性），用到的方法（等价划分法、边界值法、场景法、判定表法）。 工具：表格、testlink、禅道。 bug缺陷等级划分
- 致命（一级bug）：主流程无法跑通，系统无法运行，主要功能模块无法使用。
- 严重（二级bug）：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
- 一般（三级bug）：界面、性能缺陷。
- 提示（四级bug）：易用性及建设性问题。 如何进行接口测试？
- 拿到接口规范和文档。
- 设计接口数据格式。
- 发送数据格式。
- 返回数据格式。
- 了解接口实现逻辑，进行逻辑覆盖。
- 接口能并发执行吗？采用工具或者写代码来验证。 接口测试常用测试点
- 功能测试
- 逻辑业务测试
- 异常测试： i. 参数异常：关键字参数，参数为空，多，少参数，错误参数。 ii. 数据异常：关键字数据，数据为空，长度不一致。错误数据。
- 安全性测试
- 性能测试 接口测试质量评估标准是什么？
- 接口表现与接口文档的一致性。
- 请求参数：必选和非必选、长度、字符类型、为空、缺失、组合、重复。
- 返回参数：正常和异常。
- 性能：1000以内并发时小于3秒。 为什么要做接口测试？
- 可以发现很多页面上操作发现不了的bug。
- 检查系统的异常处理能力。
- 检查系统的安全性、稳定性。
- 前端随便变，接口测好了，后端不用变。 接口怎么测试？
- 通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
- 参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
- 接口安全： i. 绕过验证：比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证。 ii. 绕过身份授权：比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功。 iii. 参数是否加密：比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
- 异常验证：不按照接口文档上的要求输入参数。 接口安全
- 给每套产品，分配一个独立的appkey。(如：app_lin3hong5cun4)
- 获取token：用户登录时，服务端接收手机号、或第三方Openid，根据token = md5(Appkey+手机号/Openid+timestamp)计算token。 将键值对token-user_id存于Redis，并设置该键的生存时间（如：1天）
- 接口检验： （1）用户验证：使用token查redis。若token存在表明安全，将键值中的user_id用于查询业务。若token不存在，则是伪装用户，或者过期token。返回错误码，重新获取token （2）签名验证：使用规则计算sign，若与接口返回的sign一致，表示参数安全，可以继续执行业务。若不一致，表示参数被改，该次请求无效，返回错误码。 （3）验证时效性：若接口中的timestamp与系统时间相差太大，可能是攻击，直接返回错误码。 接口测试中需要注意的测试点
- 接口中返回了图片地址，要手工进行图片验证。
- 接口完成查询功能的时候，数据返回的排序显示。
- 接口测试的时候，关注参数的默认值，必填项。 怎么做接口自动化 会根据接口文档设计接口用例，然后利用python的requests库实现接口请求，利用Excel来管理测试数据。并在代码当中利用unittest测试框架实现接口用例的断言处理。 自动化测试框架分层
- Common层，公共方法封装层。
- Conf层，存放配置文件、全局变量。
- Log层，为生成的日志文件。
- Report层,存放生成的测试报告文件夹。
- TestCases层，执行用例脚本。
- TestData层，存放excel数据文件。
- run_all.py为总执行文件。 Jacoco基本概念 • 行覆盖率：度量被测程序的每行代码是否被执行，判断标准行中是否至少有一个指令被执行。 • 类覆盖率：度量计算class类文件是否被执行。 • 分支覆盖率：度量if和switch语句的分支覆盖情况，计算一个方法里面的总分支数，确定执行和不执行的 分支数量。 • 方法覆盖率：度量被测程序的方法执行情况，是否执行取决于方法中是否有至少一个指令被执行。 Web测试和App测试的区别 Web 测试和移动应用测试的共同点在于：都要覆盖接口、功能、兼容、性能、稳定和安全的测试。 差异点在于：兼容考虑的范围不一样，web重在PC系统和浏览器。移动重在机型分辨率和系统版本。 另外移动用户要考虑手机特性相关的影响，网络、冲突、耗电和流量。
- 监测不同 i. Web测试：需监测响应时间、CPU、Memory。 ii. App测试：除web项外，还需监测GPU、流量、电量等。
- 更新不同 i. Web测试：只需更新服务器端，客户端就会同步更新。 ii. App测试：需要手动更新客户端。
- 兼容方面 i. Web测试：基于浏览器不同的内核进行测试。 ii. App测试：系统分为Android、IOS测试，不同的分辨率、屏幕尺寸。
- 界面操作：手机端测试，需注意手势、横竖屏切换，多点触控。
- 权限测试：某个App是否可以获取该权限，如是否可以访问通讯录、相册等。 App测试中IOS和Android的区别
- 分辨率测试：Android端有20多种，IOS较少。
- 手机操作系统：Android较多，IOS较少且不能降级，只能单向升级。
- 操作习惯：Android的back键是否被重写，测试点back键后的反馈是否正确。应用数据从内存移动到SD卡后能否正常运行。
- push消息测试：Android点击home键，程序后台运行时，这个时候推送消息是否可以正常被推送，以及点击后唤醒应用到前台点击消息是否可以正常跳转。IOS点击home键关闭程序和屏幕锁屏的情况下，消息推送是否是正常的。
- 安装和卸载的测试：Android的下载和安装的平台和工具和渠道比较多，IOS主要有App Store，ITunes。 App闪退原因
- 缓存垃圾过多。
- 运行的程序过多导致内存不足。
- 应用版本兼容问题。
- 检查App的sdk和手机的系统是否兼容。 App启动方式 • 冷启动：指App被后台杀掉进程后，在这个状态打开App。 • 热启动：指App没有被后台杀掉，仍然在后台运行，再次打开这个App。 App测试范围
- 功能测试 i. UI方面 ii. 程序功能方面
- 稳定性测试
- 适配测试 i. 分辨率方面：客户端支持1024 * 768、1280 * 720、1920 * 1080等。 ii. 手机交互方面 iii. 不同版本系统：安卓包括5.0、6.0、7.0、8.0、9.0版本等，IOS包括IOS11、IOS12、IOS13、IOS14。 iv. 不同厂家定制系统：例如：小米手机、华为的输入法。市场是主流的系统及厂家不同型号的支持。
- 性能测试：偏重客户端启动速度，CPU，内存，流量，电量，界面切换速度以及客户端在不同网络环境下相应速度等。通过Android监控软件获取数据。
- 安全测试：检测App的用户授权级别，数据泄漏，非法授权访问等，对APP的输入有效性校验，认证，授权，敏感数据存储，数据加密等方面进行检测。
- 关联性测试：主要测试客户端与PC端的交互，客户端处理完成后，PC端与客户端数据一致。
- 异常性测试：主要包含了断网、断电、服务器异常等情况下，客户端能否正常处理，保证数据正确性。
- 交互异常性测试：客户端作为手机特性测试，包括被打扰情况下，如来电、短信、低电量、切换网络测试等，还要注意手机端硬件上，如：待机，插拔数据线、耳机等操作不会影响客户端。
- push消息推送，IOS有APNs服务器来负责消息的推送，安卓手机通过第三方推送服务器来推送消息通知，如腾讯信鸽，极光推送： i. APP在后台运行时，应能正常接收消息。 ii. 设备锁屏状态下，应能正常接收消息。 iii. 设备网络断开后再次建立连接时，应能正常接收消息。 iv. 设置不接收该APP通知消息时，应不再收到push消息。
- 安装测试 i. 正常情况下： a. 正常安装测试，检测是否安装成功。 b. APP版本覆盖测试。 c. 回退版本测试。 d. 在不同型号、系统、屏幕大小、分辨率上的手机进行安装。 e. 安装完成后，能否正常启动APP。 f. 安装完成后，重启手机能否正常启动APP。 ii. 异常情况下： a. 安装时内存不足。 b. 安装过程中的意外情况（强行断电、断网、来电，查看信息）等等。 c. 能否取消安装。
- 卸载测试 i. 正常情况下： a. 用自带的卸载程序进行卸载，检查是否卸载干净。 b. 用第三方工具，检查是否卸载干净。 c. 不同系统、硬件环境、网络环境下进行卸载。 d. 卸载后再次安装，是否正常使用。 ii. 异常情况下： a. 卸载中出现异常情况下能否恢复（比如手机关机、内存不足、没电等），程序是否还能运行。 b. 卸载后是否有残留，是否能够再次进行安装。 c. 是否可以取消卸载，软件恢复使用。
- 升级测试 i. 更新版本需要提示用户。 ii. 考虑是否进行强制升级。 a. 软件存在严重缺陷。 b. 软件不能向下兼容。 iii. 是否能够跨版本升级。 iv. 断点续传。
- 用户体验 i. 界面的美观。 ii. 保持登录。 iii. 页面层级关系在4层左右。
- 边界测试 i. 电量不足。 ii. 内存不足。
- 权限测试 i. 摄像头权限。 ii. 相册权限。 iii. 位置权限。 iv. 通讯录权限。 App图片测试
- 上传图片-拍照 i. 点击拍照是否直接跳转到拍照页面。 ii. 拍照后点击完成，可以上传。 iii. 拍照后图片正常显示。 iv. 上传图片的最大限制。 v. 超过上传图片张数是否可以继续上传。 vi. 拍照的手机权限设置。
- 上传图片-从相册中上传 i. 点击相册进入相册页面。 ii. 选择相册中的图片可以上传。 iii. 是否可以一次选择多张图片。 iv. 上传图片的最大限制。 v. 超过上传图片张数是否可以继续上传。 vi. 上传图片后是否可以正常显示。 vii. 是否只能上传.jpg/.png/.jpeg格式。
- 删除（修改）图片 i. 可以删除当前的图片。 ii. 删除图片有上传按钮，并且点击上传可以正常上传。 iii. 删除图片后重新上传的图片显示的是最新的图片。 iv. 遇到多张图片时，删除所有图片，再上传图片是否正常。 v. 删除所有图片，点击提交信息是否可以正常提交。
- 图片展示 i. 在App上查看数据展示页面 a. 记录页图片是否显示。 b. 记录页图片是否清晰。 c. 记录页图片是否被放大或缩小。 d. 记录页图片是否被剪裁。 e. 记录页查看图片是否可以放大或缩小。 f. 记录页显示的图片是否与上传的图片一致。 g. 上传多张图片，张数是否正常、图片相互之间是否重叠或数量不对。 ii. 在数据后台展示 a. 图片是否显示。 b. 数据后台显示的图片是否与上传的图片一致。 c. 图片是否清晰。 d. 图片是否被剪裁。 e. 图片是否被放大或缩小。 f. 图片是否可以放大或缩小。
- 弱网或断网 i. 弱网时图片可以加载出来 a. 加载图片需要的时间。 ii. 弱网时图片加载失败 a. 加载失败是否有提示。 b. 加载失败是否提供默认图片。 c. 加载失败是否一直转圈。 d. 图片加载失败时操作页面会不会崩溃。 e. 很多图片时，只加载出部分，后面的图片如何处理。 iii. 断网时查看图片 a. 没有网络图片是否显示。 b. 有图片缓存时，图片是否正常显示。 c. 没有缓存图片不显示，是否有提示。 d. 没有缓存图片不显示，是否有默认图片。 如何确定系统能够承载的最大用户数？ 通过负载测试，不断增加用户数，随着用户数的增加，各项性能指标也会相应产生变化。 如果出现了性能拐点，比如，当用户数达到某个数量级时，响应时间突然增长，那么这个拐点处对应的用户数就是系统能承载的最大用户数。 性能测试前期准备工作
- 了解本次性能测试的目的
- 性能指标标准
- 测试机配置测试
- 服务器配置测试
- 了解有几台服务器
- 编写性能测试用例
- 搭建性能测试环境 性能测试的分类
- 压力测试：模拟用户在同一时间段，对服务器发送大量的请求，以此来查看服务器的性能指标。
- 负载测试：模拟用户持续不断的访问某一个接口或某一页面，以此来查看服务器的最大承受能力。
- 稳定性测试：找出服务器最大的负载值，在最大负载值的压力下持续长时间的运转，以此查看服务器的稳定性。
- 故障转移和恢复测试 并发和在线？综合场景测试？ • 并发：所有用户在同一时刻对被测系统执行操作。 • 在线：所有用户在同一时间内对被测系统执行操作。 • 综合场景测试：多个场景，如：500用户，100用户提交数据，200查询，200浏览网页。 性能测试关注的指标
- 吞吐量，在单次业务中，客户端和服务器端进行的数据交互总量。
- 吞吐率，吞吐量除以传输时间，一般以“字节数/秒”，“请求数/秒”等单位衡量。
- TPS，每秒事物数，指每秒系统能够处理的交易或事物的数量。
- QPS，每秒查询率，QPS=并发量/平均响应时间。
- 响应时间，响应时间=服务器处理请求时间+等待时间 i. 1秒内算优秀 ii. 3秒内算良好 iii. 5秒内算较好 iv. 7秒内算及格 v. 7秒以上不及格
- CPU占用率，不能大于70%-80%
- 内存占用率，不能超过75%
- 最大并发用户数
- 每秒点击次数
- 错误的请求数，控制在0%
- 网络延迟时间
- TOP响应时间，将所有请求的响应时间先从大到小排序，计算指定比例的请求都是小于某个时间。 i. Tp90（90%响应时间），90%的请求耗时都低于某个时间 ii. Tp95（95%响应时间），95%的请求耗时都低于某个时间 iii. Tp99（99%响应时间），99%的请求耗时都低于某个时间 常用的性能测试
- 后端性能测试 i. 包括并发用户数、响应时间和系统吞吐量外，还应该包括各类资源的使用率，如系统级别的 CPU 占用率、内存使用率、磁盘 I/O 和网络 I/O 等，后端性能测试的场景设计主要包括一下两种方式： ii. 基于性能需求目标的测试验证。 iii. 探索系统的容量，并验证系统容量的可扩展性。 iv. 响应时间和吞吐量的关系： v. 响应时间越短，单位时间内的吞吐量越大；响应时间越长，单位时间内的吞吐量越小。
- 前端性能测试 i. 前端性能关注的是浏览器端的页面渲染时间、资源加载顺序、请求数量、前端缓存使用情况、资源压缩等内容，最典型也是最重要的规则： ii. 减少HTTP请求次数。 iii. 减少DNS查询次数。 iv. 避免页面跳转。 v. 使用内容分发网络（CDN）。 vi. Gzip压缩传输文件。 压测中为什么TPS上不去的原因
- 网络带宽 o 在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
- 连接池 o 可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
- 垃圾回收机制 o 从常见的应用服务器来说，比如Tomcat，因为JAVA的堆栈内存是动态分配，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
- 数据库配置 o 高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引或没有主从分离，读写分离等。就会导致数据库事务处理过慢，影响到TPS。
- 通信连接机制 o 串行、并行、长连接、管道连接等，不同的连接情况下，也间接会对TPS造成影响。
- 硬件资源 o 包括CPU（配置、使用率）、内存（占用率等）、磁盘（I/O、页交换等）。
- 压力机 o 比如JMETER，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
- 压测脚本 o 比如，在进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足，也会影响到测试结果。
- 业务逻辑 o 业务解藕度较低，较为复杂，整个事务处理线被拉长导致的问题。
- 系统架构 o 比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。 有验证码的功能，怎么做性能测试 • 将验证码暂时屏蔽，完成性能测试后，再恢复。 • 使用万能验证码。 测试不可逆的操作，如删除订单接口
- 关注接口测试的返回值是否正常。
- 关注数据库中的订单数据是否被删除。
- 关注删除记录表是否新增相关删除记录。 登录的测试用例
- 输入正确的用户名和密码，验证是否成功登录。
- 输入正确的用户名和不正确的密码，验证是否成功登录，并提示相应信息。
- 输入不正确的用户名和密码，验证是否成功登录，并提示相应信息。
- 使用未激活的用户登录，验证是否登录失败。
- 使用被停用的用户登录，验证是否登录失败。
- 在用户名和密码正确的情况下，输入正确的验证码，验证是否登录成功。
- 在用户名和密码错误的情况下，输入错误的验证码，验证是否登录失败，且提示相应信息。
- 用户名和密码是否大小写敏感。
- 密码框是否加密显示。
- 验证码是否会刷新。
- 验证码时效性，需要分别时效性内和时效性外验证码的有效性。
- 不同级别的用户，登录系统后权限是否正确。
- 用户名和密码是否支持特殊字符和中文。
- 如果手机号+验证码登录，验证码是否有时间限制，手机是否能获取验证码。
- 不同浏览器下，验证登录页面的显示以及功能正确性。
- 不同移动设备终端的不同浏览器下，验证登录页面显示以及功能的正确性。
- 不同分辨率的界面下，验证登录页面的显示以及功能正确性。
- 用户的密码后台存储是否加密。
- 用户密码在网络传输过程中是否加密。
- 用户名和密码输入框分别输入“SQL注入攻击”字符串，验证系统的返回页面。
- 用户名和密码输入框分别输入“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改。
- 连续多次登录失败时，系统是否会阻止后续的尝试以应对暴力破解。
- 同一用户在同一终端的多种浏览器上登录，验证是否具有互斥性。
- 同一用户先后在多台终端的浏览器上登录，验证是否具有互斥性。
- 是否可以使用登录的API发送登录请求，并绕开验证码校验。
- 截取的token信息，是否可以在其他终端上直接使用，token过期时间校验。
- 打开登录页面需要几秒。
- 输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒。
- 能支持多少个用户同时登录。
- 输入用户名，密码后按回车，是否可以登录。 微信点赞的测试用例
- 是否可以点赞。
- 是否可以取消点赞。
- 多次点赞是什么情况。
- 多人点赞顺序是否按照时间顺序排列。
- 点赞后是否显示头像和名称。
- 点赞后是否能进行评论。
- 点赞后退出再进入时是否还存在点赞消息。
- 点赞后相同好友是否收到点赞信息。
- 相同好友收到的点赞信息是否按照时间排列。
- 相同好友的点赞是否显示头像和名称。
- 弱网点赞。
- 网络断开是否可以点赞。
- 用户点赞后多长时间可以看到点赞成功，和取消时间。 支付的分类
- 支付方式 i. 信用卡支付。 ii. 储蓄卡支付。 iii. 网银支付。 iv. 第三方支付。 v. 余额支付。
- 支付品牌 i. 银行品牌 a. 工商。 b. 农业。 c. 招商。 d. 其他银行。 ii. 第三方支付品牌 a. 支付宝支付。 b. 微信支付。 c. 京东支付。 d. 其他等。
- 支付通道 i. 第三方通道。 ii. 银行通道。
- 支付产品 i. 信用卡快捷产品。 ii. 鉴权产品。 iii. 其他等。
- 消费模式 i. 直接支付金额，如淘宝，京东等购物网站，或会员服务。 ii. 充值购买虚拟币，在应用中使用虚拟币进行消费。 支付功能测试点
- 功能方面 i. 正常完成支付的流程。 ii. 支付中断后继续支付的流程。 iii. 支付中断后结束支付的流程。 iv. 单订单支付的流程。 v. 多订单合并支付的流程。 vi. 余额不足。 vii. 未绑定银行卡。 viii. 密码错误。 ix. 密码错误次数过多。 x. 多次点击支付功能，会不会支付多次。 xi. 有优惠券、折扣、促销价进行结算金额是否正确。 xii. 不同终端上支付：包括PC端支付、手机端的支付、PAD的支付。 xiii. 不同支付方式：银行卡网银支付、支付宝支付、微信支付等。 xiv. 支付失败后，再次支付。
- 性能方面 i. 多个用户并发支付能否成功。 ii. 支付的响应时间。 iii. 弱网状态下的支付情况。
- 安全性方面 i. 篡改订单信息、金额等能否支付完成。
- 界面方面 i. 点击付款按钮，是否有提示。 ii. 取消付款，是否有提示。 iii. UI界面是否整洁，对齐。
- 兼容性方面 i. BS架构：是否兼容不同的浏览器。 ii. APP：不同类型、不同分辨率、不同操作系统的手机是否兼容。 直播相关测试
- 功能相关 i. 直播未开始时的样式。 ii. 直播中的展示。 iii. 直播结束后的样式。 iv. 直播被中断的样式。 v. 直播缓存loading的样式。 vi. 直播其他未知异常时的样式。 vii. 帧率。 viii. 清晰度切换。 ix. 画面是否同步，音质是否失真。 x. 移动网络、WiFi播放。 xi. 移动网络且WiFi能自动缓冲加载，WiFi切换移动网络会弹出流量消耗确认框。 xii. 前后台切换、锁屏、断网、暂停恢复等中断行为，观察是否会重连。 xiii. 横竖屏切换是否能正常播放视频。 xiv. 弱网环境下是否能正常播放视频。
- 性能相关 i. 单接口压测、并发。 ii. 流量损耗。 iii. 带宽压力。 iv. 稳定性。 v. 内存占用情况。 vi. 异常恢复速度。 vii. 多接口依赖是否能正常相应。
- 兼容性相关 i. 分辨率。 ii. 多个客户端是否能正常播放。
- 安全相关 i. 鉴黄。 直播的流程
- 推流端即主播客户端：采集、编码、推流。
- 服务端处理：转码、录制、截图、鉴黄。
- 播放器即观众客户端：拉流、解码、渲染。 弱网测试
- 弱网功能测试：WiFi、4G、3G、2G丢包延迟情况。
- 网络切换测试 i. WiFi -> 2G/3G/4G ii. 2G/3G/4G -> WiFi iii. WiFi -> 无网 iv. 2G/3G/4G -> 无网 v. 强WiFi -> 弱WiFi vi. 无网 -> 有网
- 无网测试 i. 断网功能测试。 ii. 本地数据存储。 iii. 断网重连。
- 弱网用户体验测试 i. 响应时间。 ii. 页面展示。 iii. loading页面 iv. 超时机制。 v. 重连机制。 测试环境定义
- DEV 研发环境
- SIT 内测环境
- UAT 用户验收测试环境
- PET 性能测试环境
- SIM 预上线环境
- PRD/PROD 正式/生产环境 ISO/OSI七层模型
- 应用层：各种应用软件，包括Web应用。
- 表示层：数据格式标示，基本压缩加密功能。
- 会话层：控制应用程序之间会话能力，如不同软件数据分发给不同软件。
- 传输层：端到端传输数据的基本功能，如TCP、UDP。
- 网络层：定义IP地址遍址，定义路由功能，如不同设备的数据转发。
- 数据链路层：定义数据的基本格式，如何传输，如何标示，如网卡MAC地址。
- 物理层：底层数据传输，如网线、网卡标准。 TCP和UDP区别
- TCP面向连接；UDP是无连接。
- TCP可靠传输，使用流量控制和拥塞控制；UDP不可靠传输，不使用流量控制和拥塞控制。
- TCP只能是一对一通信；UDP支持一对一，一对多，多对一和多对多交互通信。
- TCP是面向字节流的传输方式；UDP是面向报文的传输方式。
- TCP首部开销最小20字节，最大60字节；UDP首部开销仅8字节
- TCP适用于要求可靠传输的应用，例如文件传输；UDP适用于实时应用，例如IP电话，视频会议，直播等。 虽然UDP并没有TCP传输来的准确，但是也能在很多实时性要求高的地方有所作为。 对数据准确性要求高，速度可以相对较慢的场景中，可以选用TCP。 TCP四、五层模型
- 应用层
- 传输层
- 网络层
- 网络接口层（五层模型会把网络接口层拆分为数据链路层和物理层） 网络七层模型是一个标准，而非实现。 网络四层模型是一个实现的应用模型。 网络四层模型由七层模型简化合并而来。 http协议三大风险
- 窃听/嗅探风险：第三方可以截获通信数据。
- 数据篡改风险：第三方获取到通信数据后，会进行恶意修改。
- 身份伪造风险：第三方可以冒充他人身份参与通信。 浏览器的一个请求从发送到返回都经历了什么
- 地址解析; 在浏览器中输入 URL，浏览器会从中分解出协议名、主机名、端口、对象路径等部分
- 封装 HTTP 请求数据包
- 浏览器获取主机 IP 地址，建立 TCP 链接（TCP 的三次握手）
- TCP 链接建立后发送 HTTP 请求 请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和可内容。
- 服务器接到请求后，给予相应的响应信息 其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容
- 服务器断开 TCP 连接 TCP三次握手
- 第一次握手是在建立连接，客户端发送连接请求报文段，把标有SYN的数据包发给服务器端。
- 第二次握手是服务器端收到客户端的SYN的报文段，同时发送标有SYN/ACK的数据包。
- 第三次握手是客户端收到服务器端的SYN/ACK的数据包后，向服务器端发送标有ACK的数据包 为什么是三次握手
- 第一次握手：客户端发包，服务端收到了。服务端得出结论：客户端的发送功能、服务端的接收功能都是正常的。
- 第二次握手：服务端发包，客户端收到了。客户端得出结论：服务端的发送、接收功能，客户端发送、接收功能都是正常的。但此时服务端不能确认客户端的接收功能是否正常。
- 第三次握手：客户端发包，服务端收到了。服务端得出结论：客户端和服务端的发送、接收功能都是正常的。 TCP四次挥手
- 第一次挥手：客户端设置seq和ACK，向服务器发送一个FIN=1的报文段。此时，客户端进入FIN_WAIT状态，表示客户端没有数据要发送给服务器端了。
- 第二次挥手：服务器端收到客户端发送的FIN报文段，向客户端回了一个ACK报文段。
- 第三次挥手：服务器端向客户端发送FIN报文段，请求关闭连接，同时服务器端进入LAST_ACK状态。
- 第四次挥手：客户端收到服务器端发送的FIN报文段后，向服务器端发送ACK报文段，然后客户端进入TIME_WAIT状态。服务器端收到客户端的ACK报文段后，就关闭连接。客户端等待2MSL后依然没有收到回复，则说明服务器端已经正常关闭，客户端就关闭连接了。 为什么连接的时候是三次握手，关闭时候却是四次挥手？
- 当服务器端收到客户端的SYN请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的，所以建立连接只需要三次握手。
- 关闭连接时，客户端发出FIN报文段，只是表示客户端告诉服务器端数据已经发送完毕了。当服务器端收到FIN报文并返回ACK报文段时，表示它已经知道客户端没有数据发送了，但是服务器端还可以发送数据到客户端，所以服务器端不会立即关闭连接，直到服务器端把数据也发送完毕。当服务器端也发送了FIN报文后，表示服务器端也没有数据要发送了，然后就中断这次TCP连接。 TCP慢启动
- TCP协议为了做到效率与可靠性的统一，设计了一个慢启动机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率。如果不丢包，就加快发送速度。如果丢包，就降低发送速度。
- 刚开始通信的时候，发送方一次性发送10个数据包，然后停下来，等待接收方的确认，再继续发送。
- 默认情况下，接收方每收到两个TCP数据包，就要发送一个确认消息。确认消息简称为ACK。 断点续传和断点下载的原理
- 断点续传是由服务器告诉客户端已经上传的相应位置，然后客户端再将文件指针移动到相应的文件位置，最后再通过输入流的方式将文件剩余部分传输给服务器。
- 断点下载是由客户端告诉服务器已经下载的大小，并且放到HTTP请求头信息中的Rang：bytes属性中。然后服务器会将指针移动到相应的文件位置继续读取，把文件返回给客户端。为了提高性能，也可以多线程下载，给每个线程分配固定的字节的文件，分别去读取文件，当所有线程下载结束后，将每个线程下载的文件按顺序拼接成一个完整的文件，返回给客户端。 常见安全测试的验证点
- 业务逻辑漏洞 i. 金额数据、商品数量篡改。 ii. 最大数限制修改。 iii. 修改金额，如无后端校验情况下，0.01元买到了价值100元的商品。
- 登录与身份验证 i. 用户名与密码不一致时进行校验，无法登录。 ii. 验证码未限制一次性使用。 iii. 验证码可无限次获取--造成短信轰炸。 iv. 密码有提示--生日+身份证后几位等。 v. 修改密码时校验原密码--新密码与原密码不可一致。 vi. 流水号有规律--其余用户可根据此规律遍历获取数据。 vii. 重复注册与登录--同一个用户名注册多次和重复登录。 viii. 缺少账号密码锁定机制--无限次重试。 ix. 密码强度--大小写and特殊字符and长度。
- 越权测试 i. 手动更改URL的参数访问无权访问的页面。 ii. 拿到更高权限人员的账号和密码，通过接口调用等方式进行操作。 iii. 人员权限和数据权限思虑周全--总部和省区权限不同等。
- 文件上传与下载 i. 文件上传次数不做校验，使得恶意上传，沾满资源池。 ii. 文件的类型和大小不做限制。 iii. 任意文件均可上传下载，导致有木马病毒等。 iv. 可以通过../../等方式跳转到其他目录获取相关重要文件。 v. 不登录系统，可以输入文件URL直接下载。
- 敏感信息 i. 数据库/日志/提示等泄漏。 ii. 人员的邮箱电话等信息--如数据库加密，页面脱敏 iii. 使用HTTPS密文传输，非HTTP明文传输。
- SQL注入 i. GET型注入。 ii. POST型注入。 iii. COOKIE型注入。 iv. 登录认证型注入。
- 重要数据 i. 重要文件附加水印。 短信验证码接口防护手段
- 增加前端验证码。
- 对单个手机号请求限制。
- 对单个IP请求限制。
- 对手机号真实性限制。
- 对传输参数进行加密限制。 如何安全的传输用户的密码？
- https协议： https = http + SSL/TLS，SSL/TlS是传输层加密协议，它提供内容加密、身份认证、数据完整性校验，以解决数据传输的安全性问题。
- 对称加密算法：加密和解密使用相同密钥的加密算法。
- 非对称加密算法：非对称加密算法需要两个密钥（公开密钥和私有密钥）。公钥与私钥是成对存在的，如果使用公钥对数据加密，只有对应的私钥才能解密。 如何安全的存储用户的密码
- MD5摘要算法。
- MD5+盐摘要算法 i. 在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为加盐。 ii. 不能在代码中写死盐，且盐需要有一定的长度。 iii. 每一个密码都有独立的盐，并且盐要长一点，比如超过20位。 iv. 最好是随机的值。 Web安全原则
- 黑名单、白名单原则 i. 白名单方案指的是给安全的资源授权。 ii. 黑名单方案指的是禁用不安全的资源。 iii. 应该优先使用白名单方案，因为黑名单通常统计不全所有的不安全资源。 iv. 如：XSS攻击的方式非常多，可以通过script、css、image标签等，尽管将这些标签都加入黑名单，也不能保证其他的标签都没有XSS的攻击隐患。
- 最小权限原则 i. 只授予必要的权限，不要过度授权，减少出错机会。 ii. 如：普通权限的Linux用户只能操作 ～ 文件夹下的目录，如果有人想删库跑路，在执行 rm -rf / 时，就会提示无权限。
- 纵深防御原则 i. 类似“木桶理论”，安全水平取决于最短的那块板。 ii. 即：不要留下短板，黑客往往可以利用短板为突破口，挖掘更大的漏洞。
- 数据与代码分离原则 i. 当用户数据被当成代码执行时，混淆了数据和代码的边界，从而导致安全问题。 ii. 如：XSS就是利用这一点去攻击的。
- 不可预测性原则 i. 这条原则是为了提高攻击门槛，有效防止基于篡改、伪造的攻击。 ii. 如：数据库中使用uuid代替number型的自增主键，可以避免ID被攻击者猜到，从而进行批量操作。 iii. token也是利用不可预测性，攻击者无法构造token也就无法进行攻击。 运营商劫持方式：
- DNS劫持：输入一个Google的网址，出来的是百度的页面。
- HTTP劫持：DNS解析的域名的IP地址不变，当运营商发现是HTTP请求时，会在里面插入一些奇怪的广告。
- HTTPS劫持：代理也有客户的证书和私钥，或者客户端与代理认证的时候不校验合法性，即可通过代理来与服务端进行数据交互。 DNS劫持
- 本地DNS劫持：攻击者通过某些手段使用用户的计算机感染病毒，或者恶意软件后，恶意修改本地DNS配置，比如修改本地hosts文件，缓存等。
- 路由DNS劫持：很多用户默认路由器的默认密码，攻击者可以侵入到路由管理员账号中，修改路由器的默认配置。
- 攻击DNS服务器：直接攻击DNS服务器，例如对DNS服务器进行DDOS攻击，使DNS服务器宕机，出现异常请求，还可以利用某些手段感染DNS服务器的缓存，使返回的用户的是恶意的IP地址。 XSS分类
- 反射型XSS：攻击者诱使用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。
- 存储型XSS： 会把用户输入的数据 "存储" 在服务器端，当浏览器请求数据时，脚本从服务器上传回并执行。
- 基于DOM型：通过恶意脚本修改页面的 DOM 结构，是纯粹发生在客户端的攻击。 XSS攻击影响
- 识别用户UA。
- 识别用户浏览器扩展。
- 识别用户浏览过的网站。
- 获取用户真实IP。
- 盗取Cookie。
- XSS钓鱼。 防范XSS攻击
- 转义输入输出的内容，对于引号、尖括号、斜杠进行转义。
- Web程序在设置Cookie时，将其属性设置为HttpOnly，保护用户Cookie信息。 CSRF CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。 防范CSRF攻击 1.对Cookie设置SameSite属性。表示Cookie不随着跨域请求发送，可以减少CSRF的攻击。
- 在HTTP请求中加入一个随机产生的token，并在服务器建立一个拦截器来验证这个token。 CSRF攻击与XSS攻击的区别
- CSRF攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户登录状态来实施攻击。
- CSRF攻击成本也比XSS低，用户每天都要访问大量网页，无法确认每一个网页的合法性，从用户角度来说，无法彻底防止CSRF攻击。 点击劫持 攻击者使用一个或多个透明的iframe 覆盖在一个正常的网页上，然后诱使用户在该网页上进行操作，当用户在不知情的情况下点击透明的iframe 页面时，用户的操作已经被劫持到攻击者事先设计好的恶意按钮或链接上。 URL跳转漏洞 服务端未对传入的跳转url变量进行检查和控制，可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。 命令（代码）注入 用户输入被当作命令/代码执行。用户输入经过拼接等操作后被传入一些函数被当作系统命令、代码执行。 SQL注入分类
- 报错注入。
- Union注入。
- 时间盲注。
- 布尔盲注。
- 堆叠注入。 防范SQL注入
- 权限最小化：严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害。
- 字符转义：对进入数据库的特殊字符（'，"，，<，>，&，*，; 等）进行转义处理，或编码转换。
- 检测数据：后端可以利用正则等手段判断数据的输入是否符合预期。这个也在很大程度上阻止了SQL注入攻击。 防范文件上传漏洞
- 文件扩展名检测。
- 文件重命名。
- 文件目录设置不可执行权限。
- 设置单独域名的文件服务器。 越权
- 登录权限越权 i. 登录时长失效，用户还可以继续进行操作。 ii. 退出登录后，token依然有效。 iii. A用户用B用户的登录权限做一系列业务操作。
- 业务逻辑越权 i. 业务状态越权：新创建的订单，已付款的订单，已发货的订单，已收货的订单，已收货的订单，已完成的订单，已评价的订单，进行付款操作测试。 ii. 业务终结越权：已实名认证成功，再次实名认证、再次实名认证其他身份证。 iii. 业务上下层越权：已实名认证，进入提现业务，数据库改状态为未实名认证，体现检测。 iv. 业务资源占用越权：A身份被A用户占用，B用户绑定A身份进行检测。
- 垂直越权 i. 垂直越权指的是一个低级别攻击者尝试访问高级别用户的资源。
- 水平越权 i. 水平越权指的是攻击者尝试访问与他拥有相同权限的用户的资源。
- 终结越权 i. 用户被拉黑，登录，提现操作。 ii. 用户被拉黑，用户相关数据展示、计算、处理等。 数据脱敏
- 静态数据脱敏：主要用于将数据抽离生产环境并进行分发和共享的数据使用场景，例如将生产数据库重的数据脱敏后存到测试库中，供开发、测试使用。
- 动态数据脱敏：主要用于直接访问生产数据的数据使用场景，例如客服人员通过应用查询用户信息等。 数据写入重放
- 以一个论坛的发帖举例，利用抓包工具抓取论坛发帖的请求过程，并通过该工具重放过程，会发现帖子列表出现了两条一样的帖子，这就是被重放攻击了。
- 防重设计： i. 客户端在请求中添加两个参数： a. 添加一个随机不重复的字符串参数，比如uuid，至于怎么让他不重复,可以考虑拼接时间戳,md5随机数等。 b. 添加一个请求时间的参数，如request_time值就是发送请求时的时间戳。 ii. 服务端接收到请求之后： a. 去缓存里中查找uuid这个参数对应的值是否存在。 b. 如果不存在：就把这个uuid的值保存到缓存中, 记录这个请求。 c. 如果已存在：存在那就证明,已经请求过一次了, 就不处理这个请求了。 Charles抓取HTTPS原理
- 客户端向服务器发起HTTPS请求。
- Charles拦截客户端的请求，伪装成客户端向服务器进行请求。
- 服务器像“客户端”（实际上是Charles）返回服务器的CA证书。
- Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Charles拿到了服务器证书的公钥）
- 客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称密钥，用Charles的公钥加密，发送给“服务器”（Charles）
- Charles拦截客户端的响应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Charles拿到了对称密钥）
- 服务器用自己的私钥解密对称密钥，向“客户端”（Charles）发送响应。
- Charles拦截服务器的响应，替换成自己的证书后发送给客户端。
- 至此，连接建立，Charles拿到了服务器证书的公钥和客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了。
Charles过滤网络请求
- 在主面板的左下方可以找到“Filter”输入栏，可以筛选网络请求。
- 在顶部菜单栏选择“Proxy”->“Recording Settings”。选择“include”，点击“Add”按钮，设置协议、端口、路径、参数。 Charles模拟弱网环境
- 在顶部菜单栏选择“Proxy”->“Throttle Settings”。在弹出的面板上设置网络请求的参数（上行、下行、带宽、利用率、可靠性等等信息）。 Charles修改网络请求
- 在选中需要修改编辑的网络请求，对应的右上角看到有个“钢笔”的按钮，点击后可以对网络请求进行编辑，编辑好后在右下角找到“Execute”按钮，进行执行网络请求。 Charles单接口压力测试
- 在选中的网络请求->右键->选择“Repeat Advanced”->在弹出的面板中设置总共的迭代次数（Iterations）、并发数（Concurrency）->点击“OK”。 Jmeter参数化
- 配置元件——CSV数据文件配置。 i. 适用于大量测试数据的使用。
- 前置处理器——用户参数。 i. 适用于少量测试数据时。
- 测试计划——用户定义的变量。 i. 适用于常量配置。 Jmeter关联
- 后置处理器——xpath关联，在返回值为HTML或XML格式时使用。
- 后置处理器——json提取器，在返回值为json格式时使用。
- 后置处理器——正则表达式提取器，适用于任何返回值形式。 Jmeter集合点
- 集合数最好能被线程组中的线程数整除。
- 集合时间最好大于等于线程组中的启动时间。 Jmeter生成报告
- -n 设置命令行模式。
- -t 要运行的JMeter测试脚本文件。
- -l 指定记录结果文件路径。
- -e 设置测试完成后生成测试报表。
- -o 指定测试报表生成的文件夹路径。
- -H 指定代理服务器域名或IP。
- -P 指定代理服务器端口号。
- 示例：jmeter -n -t /Users/likunlong/Downloads/test111.jmx -l /Users/likunlong/Downloads/test111.jtl -e -o /Users/likunlong/Downloads/test111.html selenium原理
- 运行selenium脚本，它会向web service中发送一个http请求。
- 浏览器驱动中的web service会根据这个请求生成对应的js脚本，因为不同的浏览器，相同的操作生成的js脚本会不同，因此不同的浏览器要有不同的驱动。
- js脚本驱动浏览器，产生各种操作，并返回给web service
- web service将结果通过http相应的形式返回给客户端。 selenium启动多个浏览器
- 启动Chrome——webdriver.Chrome()
- 启动Firefox——webdriver.Firefox()
- 启动IE——webdriver.ie() selenium常用API
- find_element_by_id()
- find_element_by_name()
- find_element_by_class_name()
- find_element_by_tag_name()
- find_element_by_link_text()
- find_element_by_partial_link_text()
- find_element_by_xpath()
- find_element_by_css_selector()
- 等待方法：implicitly_wait() 怎么验证元素是enable/disabled/checked状态
- 分别通过isEnable(),isSelected(),isDisplayed()三个方法进行判断。 如何实现文件上传？
- 定位元素后，直接使用send_keys()方法设置就行，参数为需要上传文件的路径。 selenium的三种等待方式
- 强制等待，如time.sleep(2)
- 隐式等待imlicitlyWait会在指定时间范围内不断的查找元素，直到找到元素或超时，特点是必须等待整个页面加载完成。
- 显式等待WebDriverWait通常是自定义的一个函数代码，这段代码用来等待某个元素加载完成，再继续执行后续的代码。 遇到frame框架页面怎么处理？
- 先用driver.switch_to.frame()跳转到frame中。
- 再操作页面元素。
- 操作完成后使用driver.swith_to.default_content()跳转出来。 如何切换句柄
- 先获取所有窗口句柄，然后使用switch_to.window()切换到指定窗口。 验证复选框按钮是否被选中
- 可以使用元素的isSelected()方法，如果返回true则说明被选中，false表明未被选中。 如何模拟浏览器的前进和后退、刷新操作
- driver.navigate().back(); //后退
- driver.navigate().forword(); //前进
- driver.navigate().efresh(); //刷新 关闭浏览器中quit和close区别
- close是关闭当前聚焦的tab页面。
- quit是关闭全部浏览器tab页面，并退出浏览器session。 如果一个元素无法定位，一般考虑哪些方面？
- 页面加载元素过慢，增加等待时间。
- 页面有frame框架，需要先跳转入frame框架再定位。
- 可能该元素是动态元素，可以使用部分元素定位或通过父节点或兄弟节点定位。
- 可能识别了元素，但是不能操作，比如元素不可用，不可写等。 SQLMap参数命令 • -v 输出级别（0-6）。 • -u 或 -url 目标URL地址。 • -m 从文本文件中解析目标。 • -r 从文件载入HTTP请求。 • --method=<http方法> 指定使用的http方法。 • --data=<post数据> 提交post数据。 • --param-del 指定请求数据的分隔符。 • --cookie <cookie键值对>添加cookie请求头。 • --headers <http请求头字段和字段值> 添加http请求头。 • --threads= 设定线程数。 • --level=LEVEL 执行测试的等级（1-5，默认为1）。 • --risk=RISK 执行测试的风险（0-3，默认为1）。 • --users 枚举数据库管理系统用户。 • --passwords 枚举数据库管理系统用户密码哈希。 • --dbs 枚举数据库管理系统数据库。 • --tables 枚举的DBMS数据库中的表。 • --columns 枚举DBMS数据库表列。 • --dump 转储数据库表项。 • -D 指定数据库。 • -T 指定数据表。 开发为什么要转行做测试？ 开发要求的是一个知识的深度，而测试要求的是一个知识的广度，所以我希望自己以后做测试，能够让我自己知识涉猎更加广泛一点。而且我有开发经验，对Linux系统还有数据库更加熟悉，并且也能够更加的认识到软件底层实现的业务逻辑，从而更加容易定位问题，也更加容易发现bug。 口述公司的测试流程 我们公司的话，首先会参与需求评审会议，产品经理会介绍产品业务及功能细节。需求会议之后，我们老大会制定测试计划。之后我们会按照计划先进行用例的编写，用例编写完成后进行测试用例的评审。等开发产品完毕，提测后，我们测试就会介入测试。先进行冒烟测试，再进入到正式的测试。测试过程中发现的bug，全部提交到bug管理平台，并对bug进行跟踪，进行回归测试，直至不存在严重bug，满足用户需求。这里一般测试3-5轮。测试结束后，对测试结果进行分析，编写测试报告。之后就是运维发布上线。上线后，关注线上产品是否正常运行，进行常规的维护性测试。 提了个bug，但开发认为不是，怎么办？ 首先确认开发环境是否跟自己测试环境一致，确认在测试环境能重现，如果确认是缺陷跟开发保持有效的沟通。严重级别较高的bug，对应需求文档、测试出现的bug截图跟开发说明，更有说服力。如果开发依然不接收bug，需要找产品介入。级别较低的建设性bug，可以先记录到bug平台，先保留，有时间再进行集中跟进。 对于复现率不高的bug怎么处理？ 首先对于偶现bug的提交。只要是出现的bug都要记录到bug管理平台。bug出现的步骤、环境、账号等信息尽量描述清楚。包括操作系统、浏览器版本、app写明机型型号。附带问题截图及日志截图，且标题注明偶现的。 提交后对于bug的跟踪。每一轮回归测试，都会尽可能去重现这个bug。多轮回归测试中仍然不能重现的话，会依据这个bug的严重程度决定是否继续跟踪。如果严重程度低，一般就关闭。如果严重程度高，在上线前需要开发一起协助复现，如果依然复现不了，记录到bug平台后续版本再跟进。 一个新项目，怎么开展测试？ 拿到项目后，先熟悉需求、原型图、了解被测功能和各个功能的业务逻辑。支持哪些平台，有哪些不同的应用场景，是否需要考虑稳定性、性能等。 针对以上需要测试的内容进行大概的测试规划，然后逐个细化设计测试用例。整个过程中存在疑问及时跟开发产品沟通确认。拿到被测软件后，按照用例执行测试，提交bug，并有效进行回归测试完成bug跟踪。测试完毕后，及时汇报测试结果。 作为一名软件测试工程师，应该要具备什么素质？ 硬技能方面，第一计算机知识，包括操作系统、数据库、通讯协议原理，熟悉至少一门编程语言。第二软件测试知识，包括各种理论，测试方法，测试用例编写，bug跟踪流程，软件质量评估等。第三产品业务分析能力，熟悉所测产品的一些隐藏需求或功能。 软技能方面，像沟通能力、做事严谨耐心、富有责任心，另外还要善于自我总结、自我学习的能力。 你未来3~5年的职业规划是怎么样的？ 我之前的公司做的项目是金融类业务，比较多的是功能和接口测试。如果有幸入职咱们公司，1年内先做好本职工作、积累业务知识。2-3年内希望能完成公司项目的自动化架构，实现自动化测试。目前我已经开始在研究学习python及编写自动化测试脚本。 你还有什么问题想问？ • 技术面 o 想了解下咱们公司的主要项目，目前正在做的项目？ o 如果有幸入职的话，想清楚我主要负责哪一部分的工作？ o 想清楚咱们公司的开发团队、测试团队的人员构成？ • 人事面 o 想了解下咱们公司的企业文化？ o 如果入职了，想问下有新员工入职培训，像公司介绍、规章制度及岗位职责这种吗？
