为解决域名泛滥、升级成本高、流量管理困难、需要web服务格外封装等问题，中间件组计划提供一套中心化网关用于解决以上业务痛点。
一、测试方案
- 计划从业务功能、高可用、性能，这3大方向切入，进行测试点拆分、测试用例的编写；
- 开发与测试均介入测试流程，开发主要负责提测前主流程自测，并在提测后分担部分需要通过debug进行测试的用例；
- 测试周期为2周左右；
二、测试难点
- 黑盒测试无法确保网关的高可用性，至少需要进行灰盒测试，从内部实现逻辑中拆分测试点；
- 需要考虑db、zk对网关的影响；
- 需要获取内存缓存的数据进行一致性的校验；
- 实际使用场景较复杂，用例难以覆盖到所有场景。
三、测试细节
1、功能
- 测试左移：参与方案评审，了解业务逻辑、实现逻辑、库表关系、外部依赖等，勇于提出自己的质疑与疑问，将不清楚的疑点都弄清楚；
- 保持怀疑：拆分测试点时，每步逻辑操作都对前置操作与产物不信任，且可以再开发提供的逻辑图上继续细分；
- 数据闭环：校验数据流转链路中每一节的数据一致性；
- 大胆提出小心求证：先大胆提出异常场景，再考虑如何处理与预期结果。不要内心想当然的认为某些异常场景不可能出现，实际使用的场景远比我们想象的复杂；
- 追根究底：明确每一个BUG的根因，时常可以从中获得启发，挖掘出新的测试点或同类的BUG。
2、高可用
- 无状态性：网关自身无状态，遇到峰值流量，可快速横向扩容；
- 容量规划：压测探知网关性能瓶颈，根据业务流量计算出网关集群容量，防止被流量峰值打崩；
- 慢请求熔断：创建默认的Sentinel 熔断规则，防止下游服务过慢，请求积压，拖垮网关；
- 独立性：数据会缓存到网关内存中，对db、zk均为弱依赖，外部依赖异常时，不影响网关当前业务运行；
- 原子性：关键步骤异常，需要对网关启动或者发布流程进行阻断&回滚，避免产生脏数据影响后续的操作或将残缺的业务&数据发布成功；
- 防网络抖动：异步定时任务，轮询刷新缓存；
- 异常处理：除了业务异常外，还需要考虑对关键数据缺失、数据重复的处理，并添加相应的告警与日志
- 可恢复性：对数据进行灾备，遇到数据丢失的情况可快速恢复；
3、性能
主要关注指标有RT、QPS、CPU、内存、GC、线程、Network I/O
压测的场景有：
- 性能瓶颈：找到网关单POD性能瓶颈。用于网关容量的计算，压测过程中可对性能进行探索性调优；
- 负载运行：保持80%以上的负载，持续运行12~72小时；
- 下游慢请求：下游RT=2000ms，找到该场景下网关的瓶颈，并且对熔断的效果进行验证。