微服务开发实战微服务架构与应用

微服务实战测试之理论篇

2017-01-15  本文已影响1520人  老瓦在霸都

目录

测试的重要性尽人皆知,这里从做点小小的总结

测试的考量

1. 测试的时机

不是东西做出来再测,而是测好了东西才能出来 各个大小公司,独立的测试团队都在削减人员,不是测试不重要,而是需要全员从一开始就要做测试, 全过程测试, 早期注重单元测试和组件测试, 后期注重集成测试和端到端测试。在一个迭代尽量做一个相对完整的功能, 及时做集成, 而不是最后再一起做集成测试

(个人以为独立专业的测试团队还是很有必要的, 自己测自己写的东西, 很难发现意想不到的问题)

2. 测试的效率

讲究有效性,稳定性和性能,一定要自动化,跨越多个组件的端到端测试必须有,可是不宜多,而且应该是聚焦在于功能性,无需过度测试,有必要才测, 代码对测试友好, 也就是易于测试。 测试要讲究有效性,稳定性和性能。

从思维定势的角度来看, 单元测试可以自己做, 组件测试和集成测试最好换位思考, 结对测试或交由测试专家来做

3. 测试的度量

测试要有覆盖率,哪怕仅作参考 性能测试更要有数据,比如 CPS TPS QPS 最耗时间的函数等在测试过程中收集到的度量数据

4. 测试的对象

测试到底测什么?
测试目的要明确, 检查点是先定义好. 哪些值, 状态, 还是行为要检查?
测试范围更要定义清楚, 单元,组件,系统内部还是端到端的用户操作?

测试的分类





测试的模式

Mike Clifton 曾经总结过测试的若干模式, 可以参看原文, 回头找时间翻译一下

Pass/Fail Patterns 通过/失败测试模式

Data Driven Test Patterns 数据驱动测试模式

Data Transaction Patterns 数据处理事务测试模式

Collection Management Patterns 集合管理测试模式

Performance Patterns 性能测试模式

Process Patterns 流程处理测试模式

Simulation Patterns 仿真测试模式

Multithreading Patterns 多线程测试模式

Stress-Test Patterns 压力测试模式

Presentation Layer Patterns 展现层测试模式

测试金字塔

Test pyramid

因为越往上测试的实现和维护成本就越高, 测试速度也越慢, 所以提倡多写单元测试, 少写端到端的测试, 少写不等于不写, 上层的测试着重测一些主要的路径, 不需要面面俱到, 不然费时费力

单元测试的原则

有本书单元测试之道总结了若干单元测试的原则, 先来回顾一下

Pragmatic Unit Testing by Andrew Hunt and David Thomas

FIRST 原则

参见 https://github.com/ghsukumar/SFDC_Best_Practices/wiki/F.I.R.S.T-Principles-of-Unit-Testing (ottinger, langr)

Right-BICEP 测试原则

英文 中文
Right - Are the results right? 结果是否正确?
B - are all the boundary conditions correct? 所有的边界条件测试结果正确吗
I - can you check the inverse relationships? 有没有检查反向关系
C - can you cross-check results using other means? 能不能用其他方法交叉检查结果?
E - can you force error conditions to happen? 能不能强制错误情况发生?
P - are performance characteristics within bounds? 性能特性在不在允许范围之内?

CORRECT 检查原则

英文 中文
C - Conformance - does the value conform to an expected format? 一致性 - 值是否符合预期的格式?
O - Ordering - is the set of values ordered or unordered as appropriate? 排序 - 值的集合是否根据需要进行排序或无序?
R - Range - is the value within reasonable minimum and maximum values? 范围 - 值是否在合理的最小值和最大值范围之内?
R - Reference - does the code reference anything external that isn't under direct control of the code itself? 引用 - 代码是否引用了不受代码本身直接控制的外部依赖?
E - Existence - does the value exist (e.g. is not null, non-zero, present in a set)? 存在 - 值是否存在(例如,不为null,非零,是否存在于集合中)?
C - Cardinality - are there exactly enough values? 基数 - 是否有足够的值?
T - Time (absolute and relative) - is everything happening in order? At the right time? In time? 时间(绝对和相对) - 一切事件是否有序? 是否在正确的时间? 是否及时?

测试相关框架与库

林林总总, 不胜枚举, C++的googletest, gmock, Java的 Junit, TestNG, Mockito, PowerMock, JavaScript 的 Qunit, Python 的 unittest, Lua 的 luaunit, 等等

其实他们都是脱胎于 JUnit , 使用起来也是大同小异

测试的策略

测试要分类,分组,而且要能快速定位和诊断测试的失败之处

在开始系统级测试之前, 最好能列一个测试矩阵 Test matrix 把所有已知条件, 场景和输入, 或变化的因子列出来, 以免遗漏

Components Scenario IE7 IE8 IE9 IE10 IE11 Edge Chrome Firefox Opera
Portal Login pass pass pass pass pass pass pass pass pass

测试用例的组织

Given-When-Then

BDD 说明 示例
Given 先决条件 广告部定制了企业的服务电话语音为最近一次促销活动广告
When 行为或事件 用户拔打 800 服务电话
Then 期待的变化或结果 欢迎声后听到最近一次促销广告

测试的过程

测试四步法

Four Phase Test

测试是个大题目, 未尽之言, 在下面两篇总结中详述

参考资料

上一篇下一篇

猜你喜欢

热点阅读