针对软件的集成测试和系统测试,需要超越单元测试之外的框架及工具支持。
测试环境就是被测系统,最好能自动获取环境配置信息,为自动化测试提供执行依赖,尽量减少手动配置
一键完成所有测试,通常是遥远的理想
记录每一次执行的过程,可以重复执行,执行成功的,执行失败的,设置成定时任务
有些任务是耗时的,不要等待,只需稍后来这里看一下执行结果,日志和报告
我们设置了哪些定时执行的任务、重复执行的任务
这些任务具体什么时间运行,最近一次是什么时间运行的,下一次什么时间运行
运行的结果如何,日志和报告查看
是否需要暂停或删除
有些任务的运行需要关注机器或系统的某些参数指标
定义这些指标(如果没有),赋予ID,在测试计划中引入这些ID,监控它们
不用担心指标太多,测试计划的 post-step 会清理掉它们
多个测试任务可以共用同一个监控ID,同一个测试系统,指标都是一样的
新增告警,在所有的监控中选择你的指标,给出阈值,不要做甩手掌柜,意外本非意外
测试的时候没有异常,不代表永远没有异常,异常并非偶然,我们可以模拟、构造它们
定义异常脚本(如果没有),赋予ID,在测试计划中引入这些ID,可以在监控中看它们是否生效
不用担心异常影响后续测试,测试计划的 post-step 会恢复它们
多个测试任务不可以共用同一个异常,不建议异常注入下同时执行有干扰的测试任务
每个版本都有可能引起性能的波动,有必要考察下性能是否波动太大
可以自定义业务的基准,也可以引入业界通用的基准测试
通过系统的"上传测试数据"的功能,会保存每次的基准测试信息,作为对比依据
多个基准,用ID分辨它们
想找到系统在特定测试场景下的最优表现,需要不断调优
设定输入参数的变化范围,变更步长,多个参数的变更方式
告诉系统不要关注的监控指标,告警阈值
让系统自动的跑多次,并记录下指标的变化情况,甚至给出参数变化与指标的拟合曲线,得出系统最优的参考配置
对于一个系统的调优,也应该是一个经验逐步积累的过程,最好能记录下过程数据
用例,执行、缺陷、回归,所有的数据都值得被收集记录
数据不是结论、结果;其背后反应出的信息才是真正的价值所在
用例的变更情况,反应出前期投入、测试设计的质量
测试执行,反应出测试过程的规范程度,测试投入的成本
缺陷的多维度分析,反馈出整体质量,模块质量,潜在风险等
有的结论指导后续版本运作改进,有的结论指导版本后续运营的关注重点
版本的最终测试结论,是否可以发布
测试的内容及结果
测试的分析与结论
上线、运营的指导与建议
遗留的问题与后续的运作改进
UniRobot RobotFramework Web UI.
UniRobot 开发指南
如果你什么想法,欢迎和 charisma 交流
项目源码: github