测试基础概念方法

测试主要包含哪些

  一般从功能测试(正常业务流程/异常流程) 性能测试 兼容性测试 安全性测试 易用性测试 ui界面测试几个方面来设计

软件的开发测试流程

  1. 需求分析和测试计划：测试团队与开发人员一起分析和理解软件的需求，并制定测试策略和计划。根据需求文档测试用例，明确测试范围和目标。
  2. 单元测试：在开发人员完成代码编写之后，会进行单元测试。单元测试是针对软件中的最小功能单元（如函数或模块）进行的测试，验证每个单元的功能是否正常运行。
  3. 组件测试：当各个单元通过了单元测试后，它们将被组合成更大的组件进行测试。组件测试主要关注不同组件之间的接口和交互是否正确，并确保组件的功能正确性。
  4. 系统集成测试：在组件测试完成后，将不同的组件集成到一个完整的系统中进行测试。系统集成测试旨在验证系统内部各个组件之间的协作和交互是否正常。
  5. 验收测试：一旦系统集成测试通过，将进行验收测试。验收测试由最终用户、客户或产品所有者执行，以确认系统是否满足预期的业务需求和用户期望。
  6. 性能测试：性能测试旨在评估软件在各种负载和压力情况下的性能表现，包括响应时间、吞吐量和资源利用率等指标。这种测试可以帮助确定系统的性能瓶颈，并为优化提供反馈和指导。
  7. 安全测试：安全测试是对软件系统的安全性进行评估的过程，目的是发现潜在的漏洞和安全风险，并采取适当的措施加以修复和防范。
  8. 发布和维护：一旦软件通过了所有测试阶段，并经过了相关方的批准，就可以发布到生产环境中。在发布后，会持续进行维护和支持，包括修复漏洞、处理问题和提供新功能等。

测试的流程

  需求：分析需求；
  测试点：针对需求设计测试点；
  用例：针对测试点编写用例；
  执行：根据用例执行测试；
  缺陷：针对缺陷进行管理；
  报告：总结测试报告；

测试用例

1.用例:用户使用的案例
2.目的:保证测试点正确执行
3.格式:八大要素
①用例编号（区分用例的唯一标识符） ②用例标题 ③项目模块 ④前置条件
⑤优先级（P0-P4,P0最高） ⑥操作步骤 ⑦测试数据 ⑧预期结果

白盒测试

  白盒测试也称为结构测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为穷举路径测试检查不出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有:
  1. 保证一个模块中的所有独立路径至少被测试一次；
  2. 所有逻辑值均需要测试真（true）和假（false）两种情况；
  3. 检查程序的内部数据结构，保证其结构的有效性；
  4. 在上下边界及可操作范围内运行所有循环。

白盒测试的优点：
  全面性高：白盒测试可以深入了解软件的内部结构和实现细节，可以覆盖更多的路径和情况，从而发现更多的错误和缺陷。
  提供代码质量反馈：白盒测试可以评估代码的质量，发现潜在的编程错误、逻辑错误和代码覆盖不足等问题。
白盒测试的缺点：
  需要开发技能：白盒测试需要对软件的内部结构和实现有一定的了解，测试人员需要具备一定的开发技能和知识。
   认知偏差：由于测试人员已经知道软件的内部实现细节，可能会导致测试人员对待测试的方式存在偏见，可能无法全面考虑用户的需求和行为。

黑盒测试

  黑盒测试也称功能测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
  “黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
  常见的黑盒测试测试方法为等价类设计方法，边界值设计方法，判定表设计方法，场景法设计方法。

黑盒测试的优点：
  独立性强：黑盒测试关注于软件的功能和需求，独立于内部代码实现。测试人员不需要了解软件的内部结构和实现细节。
  用户导向：黑盒测试更加关注用户的需求和期望，以用户的角度进行测试，验证软件是否符合预期的功能和行为。
黑盒测试的缺点：
  难以发现内部错误：由于黑盒测试无法直接观察和理解软件内部的工作原理，因此很难发现与内部逻辑相关的错误和缺陷。
  覆盖率有限：黑盒测试主要基于功能需求进行设计，可能无法覆盖所有可能出现的路径和情况。
  可能忽略边界条件：黑盒测试容易忽视一些边界条件和异常情况，导致潜在的问题未被发现。

等价类设计方法

说明：将测试数据中具有某种共同特征的数据集合，进行划分。
分类：
有效等价类:满足需求的数据集合
无效等价类:不满足需求的数据集合
步骤：
  1.明确需求
  2.确定有效和无效等价类
  3.提取数据编写测试用例
应用场景: 需要有大量数据测试输入，但是没法穷举测试的场景。

例子：要求未满18岁，禁止入内！
分类：
  有效等价类：>=18
  无效等价类：<=18
测试数据：17、18、19

边界值设计方法

说明：选取正好等于，刚好大于，刚好小于边界的值作为测试数据。

  上点:边界上的点(正好等于) 红色
  离点:距离上点最近的点(刚好大于、刚好小于) 黄色
  内点:范围内的点(区间范围内的数据) 蓝点
步骤：
  1.明确需求
  2.确定有效和无效等价类
  3.确定边界范围值
  4.提取数据编写测试用例
应用场景:
  1.有边界范围的输入框类测试
  2.大小、尺寸、重量、最大、最小、至多、至少等修饰词语

例子：
标题长度大于0，小于等于30个字符，即0<标题长度 <=30
步骤：
  1.明确需求(0.30]
  2.确定有效和无效等价类
  3.确定边界值，上点:0，30离点:-1，1，29，31内点:10
  4.提取数据编写用例

判定表法

定义:是一种以表格形式表达多条件逻辑判断的工具
判定表规则：
1.判定表中贯穿条件项和动作项的一列就是一条规则
2.假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则
组成:
  条件桩:列出问题中的所有条件，列出条件的次序无关紧要。
  动作桩:列出问题中可能采取的操作，操作的排列顺席没有约束
  条件项:列出条件对应的取值，所有可能情况下的真假值。
  动作项:列出条件项的、各种取值情况下应该采取的动作结果。
步骤：
1.明确需求
2.画出判定表
  1)、列出条件桩和动作桩
  2)、填写条件项，对条件进行全组合
  3)、根据条件项的组合确定动作项
  4)、简化、合并相似规则(有相同的动作)
3.根据规则编写测试用例

使用场景：有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系

例子：
验证若用户欠费或者关机，则不允许主被叫功能

场景法（流程图法）

说明：是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例
意义:平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试
使用场景:根据实际的应用场景，来测试业务用例。

缺陷

定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug
缺陷的判定标准：
  少功能，软件未实现需求(规格)说明书中明确要求的功能。
  功能错误，软件出现了需求(规格)说明书中指明不应该出现的错误。
  多功能，软件实现的功能超出需求(规格)说明书指明的范围。
  隐形功能错误，软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求。
  不易使用，软件难以理解,不易使用,运行缓慢,用户体验不好。
缺陷类型: 功能错误、界面错误、兼容性、易用性、数据、架构、改进建议
缺陷格式：缺陷ID、缺陷标题、缺陷状态、严重程度、优先级、所模块缺陷描述、附件
缺陷跟踪流程：
  提交缺陷(测试)->分配缺陷(缺陷提谁)->处理缺陷(开发)->回归测试(测试)->关闭缺陷(测试)
缺陷注意事项：可重复、规范性、唯一性

禅道（缺陷管理工具）

使用流程：
  用例管理: 管理用例->创建用例->评审用例->执行用例
  缺陷管理: 管理缺陷->缺陷创建->缺陷跟踪->缺陷验证
缺陷描述重点: 缺陷标题、严重程度、优先级、缺陷描述

抓包

说明: 通过工具抓取前端与后端的通信内容。
为什么要抓包？
  功能测试时跳过ui界面验证，验证后端程序处理能力。
(如:请求支付100元，通过抓包修改请求价格0.1元，查看后端程序是否能正常处理)
  分析前端bug还是后端bug。
(如:ui显示数据错误，提交bug时需要指定提交人，那是提交给前端开发还是后端开发呢?)
  弱网测试
(如:app应用模拟4G、3G网络)
  接口测试时，缺乏接口描述文档，需要抓包获取。
(如:查看支付宝请求信息)

项目实战-注册

需求:
1、账号:必填，11位手机号进行注册
2、验证码:必填，系统生成4位验证码
3、用户名:可以为空，4~16位字符串(可以重复)
4、密码:必填，6~12位，由(字母、数字)组成，允许含特殊符号

项目实战-登录

新的业务已经换成了输入手机号和验证码登录了

项目实战-搜索

1、使用业务名称搜索，支持(模糊匹配)，文字最多16个字符
2、为空时返回所有符合业务
3、搜索业务结果超过15个，分页显示
4、一次搜索多个关键字以逗号(,)或空格区分

项目实战-添加业务

1、未登录不可添加业务到收藏夹
2、在商品详情页中添加收藏夹
3、点击编辑可切换编辑状态，点击完成从编辑状态切换到非编辑状态
4、在编辑状态中可以通过+、-修改业务办理数量

5、在编辑状态可以删除单个业务或所有业务
6、非编辑状态下显示结业按钮;
7、编辑状态下显示删除按钮;
8、数量改变同时自动计算业务总金额
9、收藏夹中业务支持全选和单选

接口测试

  银行业务系统提供了一个API 接口，用于用户进行转账操作。接口的 URL 为 /transfer，请求方法为 POST，接收 JSON 格式的请求体，包括转出账户、转入账户和转账金额等信息。对这个接口进行测试，并确保其功能正常。
测试用例设计：
  测试目标：验证转账操作接口的功能和正确性。
  测试数据：准备不同的测试数据，包括有效的转出账户、转入账户和转账金额，以及各种异常情况下的测试数据，如不存在的账户、不合法的金额等。
  预期结果：定义每个测试用例的预期结果，包括成功转账时返回的状态码、响应体的格式和内容，以及各种异常情况下的错误提示和状态码。
测试步骤：
  准备测试环境：搭建测试环境，包括银行业务系统和测试工具。
  发送请求：使用测试工具发送转账请求，包括各种正常和异常情况下的测试数据。
  验证响应：对接收到的响应进行验证，包括状态码、响应体的格式和内容等。
  记录结果：记录每个测试用例的执行结果，包括是否通过、失败原因等。
JSON 断言的应用：
  验证响应格式：使用 JSON 断言验证响应体的格式是否符合预期，例如检查响应体是否包含指定的字段和数据类型。
  验证转账金额：使用 JSON 断言验证转账金额是否正确，例如检查转账后的账户余额是否与转账前相符。
  处理异常情况：使用 JSON 断言处理异常情况，例如检查当转出账户不存在或余额不足时，接口是否能够返回正确的错误提示和状态码。
执行测试用例 ：按照设计的测试用例执行测试，对接口的各种功能和情况进行验证。
生成测试报告 ：根据测试结果生成测试报告，包括测试用例的执行情况、通过率、失败原因等信息，以便开发人员进行问题排查和修复。
后续还有一个转账压测我看过，但是想不起来了。

性能测试的相关指标

压力测试：压力测试是通过将系统推到其极限来评估其性能的测试过程。这种测试可以确定系统在超出正常工作负载的情况下的表现，并验证系统在负载过大或资源不足的情况下的稳定性。
负载测试：负载测试是在预期工作负载下评估系统性能的过程。这包括确定系统在正常和高负载下的响应时间、吞吐量和资源利用率等指标。
响应时间（Response Time，RT）响应时间是从发送请求到接收到系统响应之间的时间间隔。较低的响应时间表示系统更具响应能力。
吞吐量：吞吐量是单位时间内系统处理的请求或事务的数量。高吞吐量表示系统具有较高的处理能力。
性能指标：这些是用于衡量系统性能的指标，例如响应时间、吞吐量、并发用户数、CPU 和内存利用率等。
并发测试：并发测试是评估系统在多个同时活动用户或请求下的性能的过程。这种测试有助于确定系统处理并发请求时的性能和资源利用情况。
容量规划：容量规划是根据性能测试结果来预测系统未来需要的资源，并制定相应的扩展计划，以确保系统能够满足未来的工作负载需求。
性能测试工具：这些是用于执行性能测试的软件工具，例如JMeter，它们提供了执行测试、收集性能指标和生成报告的功能。
性能测试报告：性能测试报告记录了测试的结果、分析和建议，为项目团队和利益相关者提供了对系统性能的全面了解，以便做出决策和改进。
并发用户：在性能测试工具中，一般称为虚拟用户（Virtual User，简称VU），指的是现实系统中操作业务的用户。
TPS：Transaction Per Second，每秒事务数，是衡量系统性能的一个非常重要的指标。
RPS：Request Per Second，每秒请求数。适合用于容量规划和作为限流管控的参考依据。

性能测试

1.性能测试流程

  性能需求分析
  性能方案设计
  业务建模
  脚本优化执行测试
  收集性能数据结果分析
  性能测试报告

2. 性能需求分析

项目管理系统业务:登录 注册 搜索
需要压测的业务满足条件:核心，用户量，与外部接口对接…
经过分析，确认需要压测的业务:登录
性能指标:
  非硬件:50%line<1秒，90%line<1秒，TPS，事务成功率100%(响应时间几十毫秒到几百毫秒)
  硬件:CPU内存<=70%

3.性能方案设计

单业务: 登录
基准: 30min 2w
登录综合业务稳定性测试: 7*24小时
经过分析，项目管理系统只做单业务的压测(登录)
性能场景:
  1秒启动所有的线程，压测5min，观察性能指标（压测是逐渐摸索性能）

4. 业务建模 脚本优化

性能场景:
  1秒启动所有的线程(200个)压测5min，观察性能指标
  1秒启动所有的线程(500个)压测5min，观察性能指标
  引用数据库中找到的数据对应（txt）进行测试

5.执行测试 收集性能数据

结果：

6.结果分析
  性能测试报告服务器瓶颈300个线程
结论:CPU配置过低，建议升级CPU使用率过高，mysqld服务占比太高

7.性能调优

  Mysql的占比过高，我们首先去检查Mysql的慢查询日志，发现没有超过1秒的查询语句，然后我们查询mysql当前运行的进程。

发现是sql语句主要是对其中的username进行判别，我们尝试添加索引，结果变好

印象最深的BUG

用户的电脑登录客户端，然后进行登录之后就卡退了，连续几次都不行，联系我们进行反馈？
解决的流程：首先是检查网络没问题，对应的系统和版本在本地测试没问题，在线上环境测试也没问题，找不同的同学环境测试也没问题，多数客户相同的系统和版本也没问题，就一个用户反馈，跟开发联系查了 N 久代码，看各种服务端日志也没有问题，最后看客户端日志，最后发现，居然是用户那有一条 “OutOfMemoryError” 的错误，客户端的内存满了。被领导表扬了，并且跟开发认可，后面我反馈bug的死后他们给的回复很快。

实习时的测试流程

我们的话，首先会参与需求评审会议,产品经理会介绍产品业务及功能细节。需求会议之后我们老大会制定测试计划。之后我们会按照计划先进行用例的编写，用例编写完成后进行测试用例的评审。等开发产品编译完毕，提测后，我们测试组就介入测试。先进行预测，再进入到正式的测试测试过程中发现的缺陷，全部提交到缺陷管理平台，并对bug进行跟踪，进行回归测试，直至缺陷率满足用户需求。这里一般测试3轮到5轮。测试结束后，对测试结果进行分析，编写测试报告之后就是运维发布上线。上线后，关注线上产品是否正常运行。

新项目测试

拿到项目后，先熟悉需求、原型图，了解被测功能和各个功能的业务逻辑支持哪些平台，有哪些不同的应用场景，是否需要考虑到稳定性、性能等等针对以上需要测试的内容进行大概的测试规划，然后逐个细化去设计测试用例。整个过程中存在疑问的及时跟开发产品沟通确认。拿到被测软件后，按照用例执行测试，提交bug，并有效进行回归测试完成bug跟踪测试完毕后，及时汇报测试结果，输出测试报告。