软件测试流程分享解说.pptx

软件测试流程分享 目 录 整体流程 各阶段质量评审方式和标准 Bug分布 CodeReview 单元测试 测试用例设计 功能测试 性能测试 异常测试 1. 整体流程 测试沟通 沟通纪要 测试设计 测试设计文档 测试执行 测试报告 （时间轴） 测试介入 线上检查 2. 各阶段质量评审方式和标准 阶段 评审方式 通过标准 启动 MRD需求设计评审 项目相关人员达成一致，预判能实现项目目标。 编码阶段 CodeReview代码走查 核心模块和逻辑复杂模块走查。 单元测试 由程序开发人员完成 函数覆盖率90% 行覆盖率80% 分支覆盖率60% 全面测试阶段 集成测试 性能测试 异常测试 场景化测试 与开发人员共同review确认达成项目设计目标。 预上线阶段 线上监控 设计灾备、预案 小流量上线 确认稳定性。 上线 线上回归测试 逻辑BUG 代码做了错误的事情， 例如条件语句写错，变量未赋值等 衔接BUG 对象之间衔接时候出现错误， 例如接口之间传递参数出错等 渲染BUG 能够用眼睛看出来的错误，出现在UI 例如页面布局与MRD不一致 逻辑 衔接 渲染 出现概率 高 中 低 发现难度 难 一般 容易 修复代价 高 中 低 最理想的测试方法 单元测试 接口测试 系统测试 3. Bug分布 DAO DataService PageService Action 模板 ST，针对渲染和衔接BUG http请求 http应答 3. Bug分布 并非所有的类都要做UT 4. CodeReview 何时进行 开发人员每次提交代码前，都应通过本地单测并将代码提交team间及测试人员Review，Reveiw通过后才能入库。 优点 保持项目整体代码风格一致 团队间互相熟悉代码 提前发现错误 CodeReview 要点 遵守代码规范，保持项目整体代码风格一致 逻辑错误 异常条件考虑不足 5. 单元测试 单元测试开发原则 短：一般在10行以内 平：基本上都是顺序执行，没有分支语句，没有循环语句 快：一个用例执行时间在毫秒级别 一致性：测试用例多次执行，结果一致 原子性：测试用例的执行结果，要么是PASS，要么是FAIL 独立性：测试用例之间独立，即测试用例的执行顺序不影响结果 单元测试架构工具 c++单测框架：Gtest c++覆盖率分析：Lcov python单测框架：unittest,nose java单测框架：Junit java覆盖率分析：cobertura 6. 测试用例设计 输入 细化的测试需求 测试的方法 相关的资源 输出 完成测试需求的数据设计 完成测试步骤 完成测试预期 可选：标识别用例的优先级 可选：和测试需求绑定 用例间的执行顺序 测试分类： 功能测试 性能测试 异常测试 6.1 功能测试 对产品的各功能进行验证，检查产品是否达到用户要求的功能。 构造输入（正常/异常） 测试数据（正常数据） 配置文件（正常配置） 测试环境（正常环境） 测试步骤 针对系统功能进行验证 检查输出 数据：正确性、新旧diff 功能：正确性 针对namespace、database 的增删改查功能的系统测试。 测试输入 测试数据：系统对外部数据没有强依赖，测试使用数据可以进行构造 测试环境：单点server、后台数据库 系统配置：使用线上配置 测试步骤 针对namespace、database的增删改查，及交叉功能应用常用测试设计方法进行测试设计。 测试输出 检查增删改查的功能是否实现，数据是否正确。 6.1 功能测试 – 举例 6.2 性能测试 - 基本概念 CPU IO 内存 带宽 成功率 超时率 响应时间 并发用户数 资源指标 产品指标 资源指标与硬件消耗直接相关。 本质反映的是成本问题。 产品指标与场景需求直接相关。 本质反映的是效果问题。 6.2 性能测试 – 关键指标 14 step1 分析对象设计原理 确认资源消耗类型 确认具体关注指标 性能测试场景设计 架构部署方案设计 性能预期设计（稳定、极限） 压力方案设计 step2 step3 step4 step5 环境、数据与工具选择 环境（超时、线程、日志、硬件资源等） 数据（大小、读写方式、cache机制） 工具选择（线程池、连接方式、通信方式、压力增加方式） 执行方案 执行轮次优化（对比方案） 结果指标分析 指标组合判断 性能指标评估 瓶颈判断 优化方案设计 6.2 性能测试 – 测试方案设计 6.2 性能测试 – 举例 消息发送平台接口测试 测试目的： 测试线上单台机器消息发送接口的发送能力 （系统入口接受外部请求的能力） ? 期望值： 系统入口：2000QP