软考(软件设计师)软件工程-软件质量,软件测试,McCabe圈复杂度

软件质量

ISO/IEC 9126 是软件工程领域的经典质量模型,于1991年首次发布,2001年更新后成为软件产品质量评估的国际标准。其核心贡献是将抽象的"质量"概念分解为可度量、可管理的特性体系。以下是深度解析(2023年行业实践视角):


🧱 **一、模型分层结构

质量特性 功能性 可靠性 易用性 效率 维护性 可移植性 适合性 准确性 互操作性 安全性 功能依从性 易分析性 易改变性 稳定性 易测试性 需求覆盖率 用户任务完成率


🔍 二、六大特性详

1. 功能性(Functionality)
  • 定义:软件满足需求的能力
2. 可靠性(Reliability)
  • 定义:在规定条件下维持性能水平的能力
  • 案例
    • 航空控制系统要求 MTBF > 10,000小时
    • AWS EC2 SLA承诺可用性≥99.99%
3. 易用性(Usability)
  • 评估维度
    45% 30% 25% 易用性问题分布 学习成本高 操作效率低 错误恢复难
  • 度量举例
    • 新用户任务完成时间 < 5分钟(如滴滴出行首次叫车)
4. 效率(Efficiency)
  • 资源类型
    • 时间特性:响应延迟(如5G基站控制指令<10ms)
    • 资源利用:CPU/内存占用率(如MySQL查询内存<100MB)
5. 维护性(Maintainability)
  • 代码质量核心指标
指标 优质阈值 劣质信号
圈复杂度 < 15 > 50 (不可测试)
重复代码率 < 5% > 20% (修改风险↑300%)
6. 可移植性(Portability)
  • 关键活动
    • 环境抽象(如Spring Boot自动配置)
    • 依赖隔离(Docker容器化)

💎 总结

尽管已被ISO/IEC 25010取代,9126仍是质量模型的理论基石

正如Capers Jones所言:
"没有度量就没有改进" ------ 9126的价值在于将模糊的质量诉求转化为可行动的工程实践。在云原生时代,其精神正通过自动化质量流水线延续生命。


软件测试

一、测试目标与原则

核心目标
原则
  1. 缺陷集群性(二八定律):80%缺陷集中在20%模块
  2. 杀虫剂悖论:重复用例失效,需持续更新测试方案
  3. 尽早测试:需求阶段介入,降低修复成本(IBM统计:需求缺陷修复成本=代码级10倍)

二、测试层级金字塔(Mike Cohn模型)

1. 单元测试(Unit Testing)
  • 对象:函数/类方法

  • 工具 :JUnit(Java), Pytest(Python)

    java 复制代码
    // Junit示例:账户余额校验
    @Test
    void whenBalanceInsufficient_thenThrowException() {
        Account account = new Account(500);
        assertThrows(InsufficientBalanceException.class, () -> 
            account.withdraw(1000));
    }
  • 覆盖率要求:关键模块≥80%(航空软件要求100% MC/DC)

2. 集成测试(Integration Testing)
  • 焦点:模块间接口、数据流
3. 系统测试(System Testing)
  • 测试类型
    • 功能测试:需求覆盖度矩阵
    • 性能测试:JMeter模拟10万并发用户
    • 安全测试:OWASP ZAP扫描SQL注入
4. 验收测试(Acceptance Testing)
  • 形式
    • UAT(用户验收):真实业务流程验证
    • Alpha:开发环境内测
    • Beta:生产环境公测

三、测试方法矩阵

1. 黑盒 vs 白盒
维度 黑盒测试 白盒测试
测试依据 需求文档 代码结构
技术门槛 低(无需编码) 高(需读源码)
典型方法 等价类划分、边界值 路径覆盖、条件覆盖
2. 静态 vs 动态
  • 静态测试 :不运行代码
    • 代码审查(GitHub PR机制)
    • 需求评审(Checklist验证)
  • 动态测试 :运行中验证
    • 压力测试(Locust模拟秒杀场景)
    • 故障注入(Chaos Monkey随机终止节点)

四、效能度量体系

关键指标
指标 计算公式 健康阈值
缺陷逃逸率 上线后缺陷数 / 测试发现缺陷数 < 10%
自动化覆盖率 自动化用例数 / 总用例数 核心模块≥70%
平均修复时间(MTTR) 总修复时间 / 缺陷数量 < 4小时

McCabe圈复杂度

一、核心原理与公式

1. 控制流图(Control Flow Graph)基础

程序被抽象为有向图:

  • 节点:代码块(顺序执行语句)
  • :控制转移路径(分支/跳转)

True False 开始 语句1 条件判断 语句2 语句3 结束

2. 圈复杂度公式

圈复杂度 V(G) 的计算公式:

math 复制代码
V(G) = E - N + 2P
  • E:边的数量(Edges)
  • N:节点的数量(Nodes)
  • P:连通分量数(通常为1)

简化公式V(G) = 判定节点数 + 1

3. 复杂度风险等级

圈复杂度 风险等级 维护建议
1-5 低风险 优秀代码
6-10 中等风险 需审查
11-20 高风险 强烈建议重构
20+ 极高风险 不可接受

二、实例解析(含控制流图)

示例1:顺序结构

c 复制代码
void printSequence() {
    printf("A");
    printf("B");
    printf("C");
}

控制流图
Start printf'A' printf'B' printf'C' End

计算

  • 边数 E = 3
  • 节点 N = 4
  • V = 3 - 4 + 2 = 1

示例2:分支结构

c 复制代码
void checkValue(int x) {
    if (x > 0) {
        printf("Positive");
    }
    printf("Done");
}

控制流图
Yes No Start x>0? printf'Positive' printf'Done' End

计算

  • 判定节点:1个(if语句)
  • V = 1 + 1 = 2

示例3:多分支结构

c 复制代码
void evaluate(int score) {
    if (score >= 90) {
        printf("A");
    } else if (score >= 70) {
        printf("B");
    } else if (score >= 60) {
        printf("C");
    } else {
        printf("F");
    }
}

控制流图
Yes No Yes No Yes No Start score>=90? printf'A' score>=70? printf'B' score>=60? printf'C' printf'F' End

计算

  • 判定节点:3个(if/else if)
  • V = 3 + 1 = 4

三、实践

  1. 重构高复杂度函数
    • 策略模式替代分支嵌套
    • 表驱动法管理业务规则
  2. 预防措施
    复杂度>10 通过 提交代码 静态扫描 阻断合并 人工审核
相关推荐
workflower5 小时前
MDSE和敏捷开发相互矛盾之处:方法论本质的冲突
数据库·软件工程·敏捷流程·极限编程
~尼卡~9 小时前
软考(软件设计师)软件工程-成本评估模型,软件能力成熟度,软件配置管理
软件工程·软件设计师-软考
No Silver Bullet9 小时前
软件工程前端渠道类产品如何精准评估项目规模
前端·软件工程·规模估算
{⌐■_■}2 天前
【软件工程】tob和toc含义理解
前端·数据库·mysql·golang·软件工程·tidb
~尼卡~2 天前
软考(软件设计师)软件工程-软件过程模型,敏捷开发
软件工程·敏捷流程·软件设计师-软考
tuan_zhang2 天前
人机协同的关键枢纽:软件工程3.0中对象模型与模型驱动的融合路径
软件工程·对象模型
张较瘦_2 天前
[论文阅读] 软件工程 | 自适应CPS中的人机协作与伦理
论文阅读·软件工程
张较瘦_2 天前
[论文阅读] 软件工程 | 一篇关于开源许可证管理的深度综述
论文阅读·开源·软件工程
TOSUN同星2 天前
干货分享 | TSMaster DBC编辑器操作指南:功能详解+实战示例
数据库·oracle·编辑器·汽车·软件工程