暴力测试Service

服务Service生命周期探究

为了更好地了接服务Service的生命周期,采用暴力测试,一下会多次启动服务,绑定服务,不按常理走!
1个服务==>CoreService
2个活动==> FirstActivity和SecondActivity
这里写图片描述 这里写图片描述

测试1: 先启动,再绑定

启动FirstActivity

第1步:startService

第2步:bindService

第3步:多次bindService
多次绑定服务,没有打印,说明生命周期没走
第4步:多次startService

可以看到多次启动服务,只执行onStartCommand和onStart方法,注意startId是自增的!

点击跳转启动SecondActivity

第5步:,执行startService

第6步:bindService

如果已经Activity有绑定过了(未解绑),其它Activity在绑定只会执行onServiceConnected
第7步:退出SecondActivity

@Override
    protected void onDestroy() {
        super.onDestroy();
        unbindService(conn);
    }

退出时,解除绑定,没有打印,说明没有触发onServiceDisconnected
第7步:退出FirstActivity(第一个绑定的)
同样unbindService(conn)解除绑定


测试2: 先绑定,再启动

启动FirstActivity

第1步:bindService

第2步:startService

第3步:多次bindService
多次绑定服务,没有打印,说明生命周期没走
第4步: 同测试1#

点击跳转启动SecondActivity

第5步:同测试1#
第6步:同测试1#
第7步:退出FirstActivity(第一个绑定的)
同样unbindService(conn)解除绑定

这一步跟测试1是同样的结果,但是如果只有绑定而从没启动过服务,那结果还是一样吗?那放到测试3吧!


如果你绑定了服务,但是Activity退出的时候却没有unbindService,那么会抛个异常:

E/ActivityThread: Activity shone.mpchart.SecondActivity has leaked ServiceConnection shone.mpchart.SecondActivity$1@3a0389e1 that was originally bound here
              android.app.ServiceConnectionLeaked: Activity shone.mpchart.SecondActivity has leaked ServiceConnection shone.mpchart.SecondActivity$1@3a0389e1 that was originally bound here
      ...  

测试3: 只绑定,不启动

启动FirstActivity

第1步:bindService

第2步:退出,unbindService

所以跟测试1#比较,发现先绑定,如果后面再startService,那么unbindService的时候,不会触发onDestroy

测试4: 不管先绑定,再启动或者先启动,再绑定
这种是特殊情况
中间加入一个停止服务的步骤

mService.stopService(new Intent(FirstActivity.this, CoreService.class));

调了停止方法,服务却没有走任何生命周期,但是退出的时候

这里跟测试1#和测试2#对比一下,仅仅调了一下stopService,则退出的时候,解除绑定同样会服务退出!

<think> 嗯,用户想了解写给运维的测试验证点。这个问题很有意思,因为运维和测试的交集经常被忽视。用户引用的材料里提到了测试类型划分(单元/集成/系统测试)、运维工作范畴、以及具体的技术片段(sed命令优化SSH配置),这些都需要整合起来思考。 用户可能是个测试工程师,需要给运维同事写验证文档,或者是个运维人员想自查系统稳定性。从引用[2]强调"大型业务系统运维"和"强悍体魄"来看,用户的环境估计是高压生产环境,容错率低。 核心是要区分"运维测试"和"给运维的测试":前者是运维人员自己做的测试(如部署验证),后者是测试团队为运维系统设计的用例。用户问的显然是后者。引用[1]里的黑盒白盒方法论可以迁移过来——运维系统本身就该当黑盒测,但某些场景(如自动化脚本)又需要白盒视角。 具体验证点得分层设计: 基础层必须覆盖配置管理(引用[3]的sed改配置就是典型案例)、服务状态、备份恢复。比如改完SSH配置不验证连通性就重启服务?那是事故预定了。 中间层聚焦高可用和变更,引用[1]的摄像头车牌识别系统就很典型——运维需要验证识别服务挂掉时能否自动切换。 最关键的容量层容易被忽略,但引用[2]提到"京东阿里级运维",显然需要模拟流量突增。用户若真在这种环境,得补充全链路压测方案。 突然想到个矛盾点:用户引用[3]的PS1优化属于纯运维需求,但测试团队未必关注。这里要提醒用户区分"运维自身需求"和"业务系统需求",避免测试范围蔓延。 最后决定用表格区分必测/选测项。运维最恨无效测试,所以把"监控告警闭环"放在首位——这点在引用[1]的BUG生命周期里也有呼应。另外特意加了"灾难恢复"的暴力测试,毕竟没经历过机房断电的运维生涯是不完整的(笑)。 </think> 基于运维工作的核心目标(系统稳定性与业务连续性),写给运维的测试验证点需聚焦**部署、配置、监控、故障处理**等环节。以下是关键测试验证框架: --- ### **一、部署与配置验证** 1. **部署完整性** - 验证部署包版本是否与发布清单一致 `$ \text{md5sum} $` - 检查配置文件参数(如数据库连接串、端口号)是否匹配环境要求 *示例:* ```bash grep "db_host" /etc/app/config.yml # 验证配置项 ``` > 引用[3]中的sed配置修改需重启服务生效。 2. **依赖服务连通性** - 测试与数据库、消息队列、存储服务的网络连通性(`telnet`或`nc`) - 验证权限(如服务账户访问密钥、防火墙规则) --- ### **二、系统功能与性能验证** | **测试类型** | **验证点** | **运维工具示例** | |--------------------|----------------------------------------|-----------------------| | **服务健康检查** | API响应状态码(200/503)、响应延时 | `curl -I http://service/health` | | **容量验证** | 磁盘剩余空间(>20%)、内存水位线 | `df -h`, `free -m` | | **负载测试** | 模拟流量峰值下的CPU/IO瓶颈 | `stress-ng`, `jmeter` | > 引用[1]中系统测试需覆盖高并发场景。 --- ### **三、高可用与灾备验证** 1. **故障转移** - 主动杀死节点进程,验证集群是否自动切换(如Kubernetes `Pod重启策略`) 2. **备份恢复** - 执行定时备份脚本,模拟数据损坏并还原(`mysqldump` + `scp`) - 验证恢复后业务数据一致性 --- ### **四、监控与告警验证** 1. **监控覆盖度** - 关键指标是否采集(CPU/内存/磁盘IO/网络丢包率) 2. **告警有效性** - 手动触发阈值(如`dd if=/dev/zero of=/tmp/fill bs=1M`填满磁盘) - 验证告警通道(短信/邮件/钉钉)是否及时接收 --- ### **五、安全与权限验证** 1. **渗透面缩减** - 扫描开放端口(`nmap`),确认非必要端口关闭 - 验证SSH配置符合安全基线(如禁用密码登录)[^3] 2. **权限控制** - 测试临时账号权限回收时效性 - 敏感操作审计日志是否记录(如`sudo`命令) --- ### **六、运维自动化脚本验证** ```python # 示例:自动化部署验证脚本 import requests def check_service(url): try: resp = requests.get(url, timeout=5) assert resp.status_code == 200 # 关键断言 except Exception as e: alert_ops_team(f"服务异常: {str(e)}") # 对接告警系统 ``` > 需验证脚本的异常处理能力(如网络波动、超时)。 --- ### **关键结论** **运维最需关注的测试优先级:** 1. **监控告警闭环**(故障快速发现) 2. **灾备恢复流程**(业务连续性保障) 3. **配置一致性**(减少人为失误) > 引用[2]指出大型系统运维需"技术+流程"双保险,测试即流程落地的核心手段。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值