软件测试思维导向图

这是一篇关于软件测试思维导向图的思维导图

软件测试

• 按主要测试技术划分
  • 黑盒测试
  • 白盒测试
  • 灰盒测试
• 按测试包含的内容划分
  • 功能测试（测试业务逻辑）（核心）
  • 界面测试
  • 安全测试（高级类型、sql注入、网站安全等）
  • 兼容性测试（浏览器兼容、软件不同版本之间）
  • 易用性测试（人性化，难以上手问题、舒适、使用习惯、参考成熟产品）
  • 性能测试（并发测试。压力测试、稳定性、负载测试）
• 其他测试
  • 回归测试
  • 冒烟测试（先走软件主流程，再走详细功能）
  • 探索性测试/自由测试（测试思维）
• 按不同手段划分
  • 手工测试（点点点）
  • 自动化测试（Python）
• 按测试阶段划分
  • 单元测试
    • 主要测试程序代码，为的是确保各单元模块被正确的编译，不如有具体到模块的测试，也有具体到类、函数、方法的测试等 ---开发自测（白盒测试）
  • 集成测试
    • 单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递
  • 系统测试
    • 把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其功能等是否和用户需求相符合，在系统中运行是否存在漏洞等
  • 验收测试
    • 主要就是用户在拿到软件时，在使用现场，根据前边提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的（可能是用户、产品或者领导来测）
  • α测试
    • 类似游戏内测
  • β测试
    • beta版本
• 按测试对象是否运行划分
  • 动态测试
  • 静态测试（文档检查、代码走查）
• Bug等级
  • 致命错误（blocker）1级
    • 常规操作引起的系统崩溃、死机、死循环、闪退
    • 造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
    • 涉及金钱计算（公司巨大损失）
    • 阻断性测试，所有测试工作进行不下去（冒烟测试）
    • 权限问题（例如爱奇艺会员，没买会员可以看收费视频）
  • 严重错误（critical）2级
    • 重要功能不能实现
    • 错误的波及面广，影响到其他重要功能正常实现
    • 非常规操作导致的程序崩溃、死机、死循环、闪退
    • 外观（界面）难以接受的缺陷
    • 密码明文显示（前端处理）
  • 一般错误（major）3级
    • 次要功能不能正常实现
    • 操作界面错误（包括数据窗口内列名定义、含义不一致）
    • 查询错误，数据错误显示
    • 简单的输入限制未放在前端进行控制
    • 删除操作未给出提示（友好型）
  • 细微错误（minor）4级
    • 界面不规范
    • 辅助说明描述不清楚
    • 提示窗口文字未采用行业术语
    • 界面存在文字错误
  • 改进建议（enhancement）5级
    • 可以提高产品质量的建议，包括新需求和对需求的改进
• 常见的缺陷管理平台
  • 禅道（zentao）、bugzilla、jira、bugfree、Readmine、easybug（在线网站类型）、Mantis、QC、TD
• bug的生命周期（管理流程）（重点）
  • 生命周期中一般缺陷状态：发现→新建（提bug）→指派→已解决→待验→关闭→正常
  • 1、发现bug
  • 2、new（新建）
    • （提bug者或测试老大）指派（发开或开发老大） → 测试跟进
  • 3、重复bug（duplicated）
    • （BUG-ID：233），要求开发备注一下重复bug号（ID：122）→ 测试确认
  • 4、不是缺陷（invalid）
    • 可能需求理解不一致，分析需求从用户角度出发找证据说服开发 → 开发还是不予解决则找产品（项目经理）解决
    • 是bug则开发修复，不是则测试不纠结，但要留好证据（邮件截图，备注bug）
  • 5、无法复现（un-reproduced）
    • 确认一下测试环境再复现出来，帮助开发复现
    • 测试和开发都无法复现的话，尝试跟踪3-5个版本（测试10次+）
  • 6、不予解决（wonfixed）
    • bug级别低（UI层面，enhancement-bug） → 说服开发 → 产品确认不修改bug，记得备注留证据，关闭bug
  • 7、延期（delayed）
    • 可能是建议性bug（feature/enhancement） → 推送到下一版本需求 → 上线前修改bug会影响比较大（性价比考虑）
• 软件生命周期
  • 是软件开始研制到最终被废弃不用所经历的各个阶段
• 生命周期模型
  • 瀑布型生命周期模型（最旧的）（定义及规划 → 需求分析 → 设计 → 编码 → 测试 → 运行维护）
  • V模型：开发和测试同时进行的方式
  • 敏捷开发模型（最新的）
• 软件测试的基本流程（重点）
  • 测试需求分析阶段
    • 阅读需求，理解需求，主要就是对业务的学习，分析需求点。参与需求评审会议
  • 测试计划阶段
    • 编写测试计划，参考软件需求规格说明书、项目总体计划，内容包括测试范围（来自需求文档）、进度的安排，人力物力的粉配，整体测试策略的制定，和风险的评估与规避措施有一个制定，一般由测试负责人编写，当然我们可能也会参与相关的评审工作
  • 测试设计阶段
    • 主要任务是编写测试用例，会参考需求文档（原型图）、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通。用力编写完成后会进行评审
  • 测试执行阶段
    • 首先搭建测试环境，执行预测（冒烟），以判定当前版本可测与否，如果预测通过，正式进入系统测试（2-4轮），遇到问题提交Bug到缺陷管理平台，并对Bug进行跟踪，直到被测软件达到测试需求要求，没有重大Bug，测试结束。（完善测试用例）
  • 测试评估阶段
    • 出测试报告，对整个测试的过程和版本质量做一个详细的评估（剩余Bug数量/严重程度，测试用例的覆盖率）。确认是否可以上线。
  • UAT测试阶段
    • 部署到UAT测试环境，由产品或者领导来验证功能

中心主题