非功能需求测试
功能需求:指应用程序中定义的业务逻辑.
非功能需求:是相对于功能需求而言的,它主要指非应用程序中定义的业务逻辑,一般指容量,吞吐量,性能等测试.
性能:指处理单一失误所花时间的一种度量;
吞吐量:系统在一定时间内处理事务的数量,通常它受限于某个瓶颈;
容量:在一定的负载下,当每个单独请求的响应时间维持在可接受范围内时,该系统能承受的最大吞吐量;
实际非功能需求并不是都需要进行测试,而是根据应用情况,在项目开始时就考虑哪些非功能需求是至关重要的,然后找到对应的测试方法来衡量这个需求,在流水线适当的位置进行这项测试.
解决什么问题
对于应用运行需求是否是功能性需求是人为定义的,这就造成一些应用直接依赖的例如安全性,稳定性,性能,容量等需求前期会造成忽视,这会造成没有实际用户使用时,应用运行正常,实际使用中就问题不断.而非功能需求测试就是针对这些内容的测试.用于从整个应用的维度来测试这些指标,实现应用应有的价值.
怎么做
- 非功能需求的管理.因为非功能需求会跨需求边界,如果一开始没有较好的考虑,后续出问题再处理就会变的比较棘手.具体处理方式:
- 创建一些具体任务来管理非功能需求
- 如果必要,加入非功能需求的验收条件
- 如何为容量编程.在找到解决方案之前,必须要先找到问题的根源.实际容量可能存在两种极端情况:1是假设后期可以解决所有问题;2超前进行防御性设计.这都会让代码变的不可控.实际策略如下:
- 选择适合的架构.注意进程,网络边界,I/O
- 使用正确的编程模式
- 保证代码简单清晰
- 选择适当的数据结构和算法
- 注意线程问题.核心问题应该是单线程处理
- 创建一些自动化测试来断言期望的容量级别
- 使用调测工具发现问题,解决问题
- 使用真实的容量数据做度量
- 容量度量.实际有两种方式:模拟真实使用场景,测量容量情况;通过系统中具体操作的技术基准来判断容量;度量测试分类:
- 扩展性测试:随着服务器数,服务或线程的增加,单个请求的响应时间和并发用户数的支持的变化;
- 持久性测试:长时间运行服务,通过一段时间的操作,是否有性能上变化.主要是内存泄漏或稳定性问题;
- 吞吐量测试:系统每秒处理多少事务,消息或页面点击;
- 负载测试:系统负载增加到或超过生产环境时,系统的容量如何?
- 如何定义容量测试的成功和失败?把目标设定为得到稳定可重现的结果,降低测试无关任务影响;获取目标后,基于这个标准逐渐提高验收标准,探索成功标准范围,最后定义容量测试成功值.
- 容量测试环境.尽量和生产环境一致,这样便于发现环境问题;如果不一致要找到环境间的差异基准,便于对比;或者可以缩小环境规模来部分验证;
- 自动化容量测试.因为容量测试比较脆弱,较小的配置修改可能就会造成容量测试失败.所以容量测试满足下面的要求:
- 测试具体的场景.指标和功能都有明确;
- 预定成功阈值
- 尽量缩短测试时间
- 在变更面去更健壮.避免因应用频繁修改而返工
- 组合成大规模的复杂场景.
- 可重复
- 自动化容量测试方式.容量测试的目标有两个:1是创建生产环境负载;2是选择典型非正常负载状态的场景.它的测试方式是通过录制交互操作,进行回放来模拟实际操作,发现系统容量情况.具体切入点如下:
- UI.测试UI和后端交互的场景.最明显且面向功能的切入点.但它不太稳定.测试方式:1找到中间记录和切入点;2定义独立的UI客户端测试,它只与后端系统的桩替身版本进行交互.
- 某个服务或公共API.用于测试提供公共API而不是图形界面的应用程序上.
- 底层API.
- 部署流水线中集成容量测试.容量测试应该作为部署流水线单独的一个阶段.原因如下:
- 容量测试对于运行环境有要求,如果运行在非类生产环境中会实去价值
- 容量测试可能运行时间很长,这会影响其他阶段的反馈
- 验收测试之后很多质量保障活动和容量测试可并行执行
- 容量测试的执行频率较低,并不是每次构建都需要容量测试