加油 !!!
🔥 谈谈对测试的理解
- 我认为测试是发现并及时解决问题:包括功能、性能、用户体验❤️等方面的验证 …
- 通过提前定位并修复缺陷,可以减少未来维护成本、保障软件质量、提升用户满意度❤️ …
- 我了解的测试方法有:功能测试、性能测试、安全性测试❤️ …
- 我了解的测试工具有:Postman(API测试)、Selenium(Web应⽤集成测试)等
🔥 测开需要掌握的知识技能 / ❄️软能力
- 编程技能:如 python,可编写自动化测试脚本和工具等
- 测试方法、工具和框架:
- 🔥 基本的测试方法有:
- 【不同方面】功能测试、性能测试、安全性测试
- 【不同方案】黑盒测试 (功能测试)、白盒测试 (结构测试)
- 黑盒测试方法:等价类划分、边界值分析、因果图法、状态转换测试、错误猜测等
- 白盒测试方法:语句覆盖、条件覆盖、分支覆盖、循环覆盖、路径覆盖等
- 【不同规模】单元测试、集成测试(增量集成、大爆炸集成)、系统测试
- 单元测试用
PyTest
、JUnit
等工具 - 集成测试用
Postman
(API测试)、Selenium
(Web应⽤集成测试)等工具
- 单元测试用
- 【不同阶段】回归测试、验收测试(Alpha 测试和 Beta 测试)
- Alpha测试:由⽤户在开发者的场所来进⾏的,在⼀个受控的环境中进⾏
- Beta测试:由最终⽤户在⽤户场所来进⾏的最终测试,开发者通常不在现场
- 🔥 基本的测试方法有:
- ❄️【本职-测试前】需求分析能力:针对具体的对象,设计有效的测试计划和用例等
- ❄️【本职-测试时】认真观察、注意细节;善于发现并解决问题
- ❄️【团队】沟通能力:和产品经理、开发团队的合作
- ❄️【长期】学习能力:不断学习新的测试知识
🔥软件质量的六个特征
- 功能性:表示软件能够提供满⾜明确和隐含需求的功能。它涉及适⽤性、准确性、互操作性、安全性和符合性。
- 可靠性:指软件在特定条件下持续正常运⾏的能⼒。包括成熟度、容错性、恢复能⼒等。
- 效率:指软件在特定条件下对系统资源的有效使⽤。这涉及时间效率和资源效率。
- 易⽤性:软件的界⾯和功能对⽤户是否友好,是否易于理解、学习、使⽤和吸引⽤户。包括可理解性、易学性、操作性、吸引⼒和⽤户界⾯的适⽤性。
- 可维护性:指在必要时能够有效地进⾏修正和改进软件的能⼒。这包括模块化、可重⽤性、分析性、修改性和测试性。
- 可移植性(Portability):表示软件能够从⼀个环境迁移到另⼀个环境的能⼒。包括适应性、安装性、共存性和更换性
🔥测试的基本流程及材料 📃 输出
- 需求分析
- 制定【测试计划 📃】:明确测试的范围、⽅法、资源分配、时间表和⽬标
- 设计【测试⽤例 📃】:基于测试计划,设计详细的测试⽤例
- 覆盖所有功能点,包括正常情况和边界情况的测试
- 覆盖性能测试:评估系统的响应时间、稳定性和扩展性
- 并进行测试⽤例评审
- 搭建和配置适合的测试环境,执⾏测试⽤例
- 编写【测试脚本 📃】
- 记录测试结果(找 bug)并形成【错误报告 📃】 (包括错误描述(影响和严重程度等)、重现步骤等)
- 保留【测试环境配置文档 📃】
- 保留【测试执行日志 📃】:包括测试用例及其对应的执行结果
- 报告给开发团队
- 编写【测试报告 📃】:总结测试结果,包括测试覆盖率、发现的和未解决的问题
- 项⽬上线后,根据反馈进⾏复盘和总结
除上述对于测试用例的基本测试外:
- 回归测试:每当代码发⽣更改后,执⾏回归测试以确保新的更改没有破坏现有的功能
- 预⽣产环境测试:部署项⽬到预⽣产环境,在预⽣产环境测试
🔥 什么是等价类划分和边界值法
- 等价类划分: 将系统的输⼊域划分为若⼲部分,从每个部分选取少量代表性数据进⾏测试。难点在于正确理解需求,正确定义等价类
有效
等价类:符合
规格说明的输⼊条件,验证系统的正确性
⽆效
等价类:不符合
规格说明的输⼊条件,验证系统的健壮性
- 边界值法:软件错误往往发⽣在输⼊或输出范围的
边缘
,所以边界值分析专注于测试输⼊数据
的边界
条件,⽽不是中间值,包括- 正常边界值(最⼤、最⼩值)和异常边界值(最⼤值+1、最⼩值-1)
🔥 性能测试关注哪些指标
- TPS:每秒事务数,代表了性能的好坏,TPS越⾼,性能越好
- 平均响应时间:请求的平均消耗时间,时间越短,性能越好
- 并发数:同时向服务端发起请求的虚拟⽤户数,在不同的⼯具⾥可以⽤多个进程/线程来实现
- 错误率:失败的请求⽐例
🔥 测试用例一般包含哪些内容:
- 基础信息:用例 ID、描述 (测什么) 及对应功能模块 (测哪个模块)
- 操作信息:测试环境 (软硬件配置)、前置条件 (什么环境条件下测)、测试步骤、测试输入及预期结果
- 结果信息:实际测试结果,及与预期结果的对比分析
🔥 Bug 的生命周期:
new
(测试人员与项目负责人沟通,确认发现 bug) - assigned
(开发组负责人指派给开发人员处理) or pending reject
(开发人员不认为是 bug,和测试人员确认后变为 rejected
) - open
(开发人员开始处理) - fixed
(开发人员已修复,负责人返还给测试组) - pending reset
(待再测试) - reset
(测试组负责人指派给测试人员处理) - closed
(测试人员测试通过) or reopen
(不通过)