软件测试之安全生产

 程序作为一项工程，在上线之时也是经历广大人民群众的考验之时。如何保障程序顺利、平稳、有效运行历来是各个项目的重点方向，本人仅以测试人员角度去分析如何确保安全生产。

在我们看来，项目采用确保安全生产的常规方法有以下：
1、生产隔离，将测试环境、生产环境进行隔离，避免人为导致误操作。
2、生产权限最小化，将服务器、相关配置等环境信息仅仅释放给有权限的人。
3、生产密码安全管理，密码复杂，密文，不唯一等。
4、代码权限管理，合并分支专人专责处理。
5、程序热备、主从等功能均有。
测试需要侧重点：
1、程序是否有漏洞、是否存在盗刷可能，比如不登录就能查询到用户个人信息。
2、重点接口校验机制，比如涉及到钱、积分相关的引入token等校验。
3、程序是否有明显逻辑问题，是否可以通过多个接口组合来达到非法下单目的。
4、接口出入参是否遵循操作类接口严入；查询类接口严入严出等规则。
5、程序是否有缓存机制。
6、程序是否有防并发等功能。
7、程序是否有Nginx、kong等负载机制。
8、程序是否有放穿透等功能。
9、程序是否支持高并发压测。
10、程序是否支持稳定性压测。
11、程序是否支持灰度升级、部署等功能。
12、程序中间件、连接数、是否使用合理。
13、程序日志级别、日志打印是否打印完善。
14、程序是否有完善监控机制。

以上关注点任何一点拿出来都是一项复杂工作，作为测试，应该对以上都有涉猎，并且在实际工作中用经验去完善产品。

记一次生产问题疑似攻击分析：
生产问题背景：
1、周四早上九点我方中心A接收到大量请求来自于接口a，每分钟10W+，触发程序预警值，于是登录生产环境巡检日志，发现针对同一入参在调用a接口时存在，重复调用情况(判断重复调用是根据业务场景，a接口仅需在登录和下单时调用，但日志中a接口在1min内调用数十次)，
于是初步判断：
1、疑似攻击。
2、调用方逻辑问题。
因a接口提供给多个友商，且友商服务部署在同一服务器网段内，因此只能协调友商排查来源。

不幸的是
10点，我方中心日志不在打印，因业务量大，出现日志积压，导致日志采集出现问题，日志采集程序down掉。

万幸的是
程序正常，仅仅不打日志而已，但作为多方协同的项目，日志就是自证清白的保命符。

因此
我方运维人员介入解决日志采集慢问题。本人继续排查请求来源。

首先为了排查业务来源是否为攻击，采用如下办法：
1、检查请求发起方，发现所有请求均来自于友商服务器号段，因此，排除黑客直接调用我方中心接口情况。
2、根据日志关键字协调友商进行友商一侧日志排查，未发现调用日志，于是乎问题有点僵局。
3、继续分析我方日志，检查所有业务日志，排查10W+每分钟的请求集中在哪几个接口，并且此接口业务是否均成功，最后排查到a接口调用量大，但是成功率在99%（此处1%失败主要是我方a接口依赖外部三方系统进行查询，三方系统有自己的风控限制，因请求量大，触发三方规则）。
4、于是从a接口日志中抽查，发现多个请求均有短时间密集调用情况。
5、从服务来源为友商来看，结合友商提供日志、及前期友商的表现大胆猜测友商日志打印不对，需要排查代码。
6、通知友商测试负责人应从代码角度排查、且提供调用我方a接口的业务场景。
7、友商测试负责人没有接触过代码，需要借助开发人员，因此时间校久。
8、于当日下午2点，在友商不能排查到为何重复调用情况下，开辟其他方向，使用自己手机号在友商业务页面进行操作。
9、凭着敏感度，在10min 后，在友商的一个页面进行查询业务后会短时间多次调用我方a。
10、到此石锤，非黑客攻击，为业务逻辑问题，于是升级问题到我方项目经理处，并通知对方项目经理。
11、至此，排除攻击后，需要等友商优化，分析事情首站结束。

补救措施
1、我方于当日下午对a及a周边接口进行优化上线，保留必须的调用三方日志，其余日志改为error级别。
2、排查问题过程中发现其他接口异常打印日志输出不完美，不利于排查问题，一并优化。
3、运维团队扩容日志采集程序。

后续
友商在次日被客户投诉，浏览页面22S被无故下单27笔。

后记
本周六，写下此文章，仅做纪念那些需要大海捞针进行分析过程的美好经历。
另，从本人角度如何避免上述问题再次发生。
1、首先压测不充分，因上线前测试环境多人在用不具备稳定性压测条件，只能在晚上进行压测，一般只能连续压测五六个小时，最长一次稳定性测试60小时，属于项目初期版本压测，历经多个迭代后，不能完美模拟真实生产。
2、压测过程中出现过日志积压现象，虽然有进行多次日志优化，但是积压问题没有引起重视，因为实际生产中，多个中心共用的情况下，日志采集程序的资源是大大不够的，后续稳定性测试。
3、需要等比例进行压测，实际生产中会扩容，而且服务器性能等指标均不同，需要仔细设计等比例压测分析。