测试用例设计系统

针对各种场景,采用各种模型进行测试用例设计,从而自动生成文本测试用例,甚至是半自动对测试用例。

测试执行只是系统测试工作的核心部分,还有其它,必须有

  • 用例是测试执行的核心,时刻在左边,手工和自动化用例统一管理,它们只是执行上的区别
  • 测试环境的信息应该是自动获取的,如果你将测试工具箱放在了测试环境上
  • 手动的任务、定时执行的任务都应该被合理管理
  • 监控告警应该紧随任务出生、入死,不要永驻,不要僵尸
  • 异常需要考虑、性能不能降低、最好得到最优配置组合
  • 分析测试的过程、分析项目的运作,每次都有收获,每次都有改进
  • 君欲善其事,必先利其器,出门看病要带工具箱,不能只有针头和药水

    测试执行的默认设定

  • 当前测试的是什么系统,版本号是多少
  • 在什么机器上测试,机器、系统的配置是什么样的
  • 如果是分布式环境,拓扑信息如何、组件状态是否健康.
  • 环境对测试的影响就像环境对人的影响一样大,只是人的环境难以自动获取

    一步一个脚印,每一步都掷地有声

  • 记录每一次执行的过程,可以重复执行,执行成功的,执行失败的,设置成定时任务
  • 有些任务是耗时的,不要等待,只需稍后来这里看一下执行结果,日志和报告
  • 一键完成所有测试,通常是遥远的理想

    每天和机器打交道,尽可能让机器帮我们做更多的事

  • 我们设置了哪些定时执行的任务、重复执行的任务
  • 这些任务具体什么时间运行,最近一次是什么时间运行的,下一次什么时间运行
  • 运行的结果如何,日志和报告查看
  • 是否需要暂停或删除
  • 自动化测试是测试过程中最美的体验,使用工具使人类进步

    有些任务的运行需要关注机器或系统的某些参数指标

  • 定义这些指标(如果没有),赋予ID,在测试计划中引入这些ID,监控它们
  • 不用担心指标太多,测试计划的 post-step 会清理掉它们
  • 多个测试任务可以共用同一个监控ID,同一个测试系统,指标都是一样的
  • 新增告警,在所有的监控中选择你的指标,给出阈值,不要做甩手掌柜,意外本非意外
  • 多一双眼睛,多一种真相

    异常并非偶然,我们可以模拟、构造它们

  • 定义异常脚本(如果没有),赋予ID,在测试计划中引入这些ID,可以在监控中看它们是否生效
  • 不用担心异常影响后续测试,测试计划的 post-step 会恢复它们
  • 多个测试任务不可以共用同一个异常,不建议异常注入下同时执行有干扰的测试任务
  • 万物无好坏,事事无异常

    每个版本都有可能引起性能的波动,有必要考察下性能是否波动太大

  • 可以自定义业务的基准,也可以引入业界通用的基准测试
  • 通过系统的"上传测试数据"的功能,会保存每次的基准测试信息,作为对比依据
  • 多个基准,用ID分辨它们
  • 版本有基准,做人有底线

    想找到系统在特定测试场景下的最优表现,需要不断调优

  • 设定输入参数的变化范围,变更步长,多个参数的变更方式
  • 告诉系统不要关注的监控指标,告警阈值
  • 让系统自动的跑多次,并记录下指标的变化情况,甚至给出参数变化与指标的拟合曲线,得出系统最优的参考配置
  • 对于一个系统的调优,也应该是一个经验逐步积累的过程,最好能记录下过程数据
  • 一切皆有可能

    测试不仅要完成任务,还要评估结果

  • 用例,执行、缺陷、回归,所有的数据都值得被收集记录
  • 数据不是结论、结果;其背后反应出的信息才是真正的价值所在
  • 用例的变更情况,反应出前期投入、测试设计的质量
  • 测试执行,反应出测试过程的规范程度,测试投入的成本
  • 缺陷的多维度分析,反馈出整体质量,模块质量,潜在风险等
  • 有的结论指导后续版本运作改进,有的结论指导版本后续运营的关注重点
  • 透过现象,发现本质,踏踏实实

    测试的结论与分析总结

  • 版本的最终测试结论,是否可以发布
  • 测试的内容及结果
  • 测试的分析与结论
  • 上线、运营的指导与建议
  • 遗留的问题与后续的运作改进
  • 有始有终

    工具要成套,扩展很必要

  • 测试过程中可能用到各种外部工具,放在这个盒子里,减少各种查找、输入的时间
  • 测试数据的构造工具
  • 编解码的对比工具
  • 复杂结构的格式化工具
  • ... ...
  • 它山之石,可以攻玉

    简单上手指南

    UniRobot 开发指南

    如果你什么想法,欢迎和 charisma 交流

    项目源码: github