nn-doc

Appearance

se02 Software Development Process, Risk, and Planning ​

软件开发过程、风险与项目规划 ​

Introduction 引言 ​

Software engineering is not only about writing code. It involves structured processes, planning, risk management, and estimation to ensure that software systems are reliable, maintainable, and delivered on time.

软件工程不仅仅是编写代码，它涉及结构化开发流程、项目规划、风险管理以及工作量估算，以确保软件系统可靠、可维护并按时交付。

A software development process organizes development activities into defined phases to improve design quality, project management, and productivity.

软件开发过程通过将开发活动划分为明确阶段，提高设计质量、项目管理能力和生产效率。

Software Development Process 软件开发过程 ​

A software development process (also called the Software Development Life Cycle, SDLC) divides development into phases to improve management and product quality.

软件开发过程（软件开发生命周期）将开发划分为多个阶段，以提升管理效率和产品质量。

The process represents a set of activities and outcomes that produce a software product.

该过程是一系列活动及其结果的集合，用于生产软件产品。

Common Process Models 常见开发模型 ​

Common development models include:

常见的软件开发模型包括：

  • Waterfall Model（瀑布模型）
  • Spiral Model（螺旋模型）
  • Agile Development（敏捷开发）
  • Extreme Programming（极限编程）

Agile emphasizes responding to change and working in uncertain environments through iterative development practices such as sprints, stand-ups, and test-driven development.

敏捷开发强调在不确定环境中快速响应变化，通过迭代开发实践（如冲刺、站会和测试驱动开发）实现灵活性。

Waterfall Model 瀑布模型 ​

The waterfall model organizes development into sequential phases:

瀑布模型按照顺序执行以下阶段：

  1. Requirements（需求收集）
  2. Analysis（分析）
  3. Design（设计）
  4. Coding（编码）
  5. Testing（测试）
  6. Operations & Maintenance（部署与维护）

Testing is the phase where defects are systematically discovered.

测试阶段用于系统性发现缺陷。

Importance of Process and Planning ​

过程与规划的重要性 ​

A well-defined process improves efficiency and flexibility. Investing time early in planning and process design often reduces cost and rework later.

良好的开发流程可以提高效率与灵活性。前期投入时间进行规划通常能够减少后期成本与返工。

Poor planning can lead to:

规划不当可能导致：

  • expanding project scope
  • late defect discovery
  • integration failures
  • lost bug reports

项目范围膨胀、缺陷发现过晚、系统集成失败以及缺陷记录丢失。

Effort Estimation 工作量估算 ​

Effort estimation predicts the time and resources required to complete a project.

工作量估算用于预测完成项目所需的时间与资源。

A common method is to break a project into smaller tasks and estimate each component.

常见方法是将项目拆分为多个子任务分别估算。

Constructive Cost Model (COCOMO) ​

COCOMO is a predictive model that estimates development effort using historical project data and effort multipliers.

COCOMO 是一种基于历史项目数据和调整因子的开发成本预测模型。

This approach relies heavily on past experience and documentation.

该方法高度依赖历史经验和文档记录。

Defect Cost and Early Detection ​

缺陷修复成本与早期发现 ​

The cost of fixing defects increases dramatically the later they are discovered.

缺陷越晚被发现，修复成本越高。

An IBM report estimates:

IBM 报告估计：

  • $25 during coding
  • $100 during build
  • $450 during testing
  • $16,000 after release

编码阶段约 $25，构建阶段 $100，测试阶段 $450，而发布后修复成本可达 $16,000。

This demonstrates the importance of early testing and quality assurance.

这说明早期测试和质量保证至关重要。

Risk and Uncertainty 风险与不确定性 ​

Risk management involves identifying, assessing, prioritizing, and minimizing risks.

风险管理包括识别、评估、排序并降低风险。

Examples of risks include:

风险示例包括：

  • staff illness or turnover
  • slow system performance
  • competitor products

人员流失、系统性能不足以及竞争产品出现。

Effective Risk Management 有效风险管理 ​

Effective strategies include:

有效策略包括：

  • addressing risks early
  • estimating likelihood and impact
  • focusing on major risks
  • preparing contingency plans

尽早处理风险、评估概率与影响、关注主要风险，并制定应急方案。

Psychological Factors in Risk Perception ​

风险认知中的心理因素 ​

Weber’s Law 韦伯定律 ​

Problems that are noticeable in small projects are harder to detect in large-scale systems.

小型项目中容易发现的问题，在大型系统中更难察觉。

Zero-Risk Bias 零风险偏见 ​

Zero-risk bias is the tendency to eliminate one risk entirely even if alternative actions reduce overall risk more effectively.

零风险偏见指人们倾向于完全消除某一风险，即使其他方案能更有效降低整体风险。

This bias can lead managers to make suboptimal decisions.

这种偏见可能导致管理决策不够理性。

Project Planning 项目规划 ​

Project planning includes estimating time, cost, and resources and managing risks effectively.

项目规划包括时间、成本与资源估算，以及风险管理。

Planning also involves:

规划还包括：

  • defining scope
  • scheduling tasks
  • budgeting
  • quality assurance planning

定义范围、制定进度、预算规划以及质量保障计划。

Planning Challenges 规划难点 ​

Software planning is difficult because:

软件项目规划困难的原因包括：

  • projects are often unique
  • technologies may be innovative
  • progress is hard to measure

项目具有独特性、技术创新性强，且进度难以量化。

Milestones and Deliverables ​

里程碑与交付物 ​

Milestones represent internal progress checkpoints.

里程碑表示内部进度检查点。

Deliverables are outputs delivered to the customer.

交付物是交付给客户的成果。

Statements like “80% complete” are not valid milestones.

“完成 80%” 不是有效的里程碑。

Scheduling Reality 进度现实规律 ​

Software projects often experience the “almost done” problem: the last 10% of work can require 40% of the total time.

软件项目常出现“接近完成”问题：最后 10% 工作可能耗费 40% 的总时间。

Accurate scheduling requires continuous updates and realistic estimates.

准确的进度安排需要持续更新和现实估算。

Conclusion 总结 ​

Software engineering success depends on structured processes, realistic planning, early defect detection, and effective risk management. Development processes help improve efficiency, but uncertainty and risk make estimation and scheduling challenging.

软件工程的成功依赖于结构化流程、合理规划、早期缺陷检测以及有效风险管理。开发流程可以提高效率，但不确定性和风险使估算与进度安排变得复杂。

Understanding these principles enables teams to deliver reliable software systems while minimizing cost, risk, and project failure.

理解这些原则可以帮助团队在降低成本和风险的同时交付可靠的软件系统。

se03 ​

Software Measurement & Metrics ​

软件度量与软件指标 ​

1. Why Measurement Matters ​

为什么需要度量 ​

EN: Measurement reduces uncertainty and supports decision-making.
中: 度量可以减少不确定性并支持决策。

EN: Organizations use metrics to decide funding, testing needs, performance improvements, and priorities.
中: 组织使用指标来决定项目投资、测试需求、性能改进和功能优先级。

2. Definition of Measurement ​

度量的定义 ​

EN: Measurement is the empirical assignment of numbers to attributes to describe them.
中: 度量是根据规则将数值赋予对象属性以描述其特征。

EN: Measurement is a quantitative reduction of uncertainty.
中: 度量本质上是通过数据减少不确定性。

3. Software Quality Metrics ​

软件质量指标 ​

EN: A software quality metric outputs a numerical value indicating a quality attribute.
中: 软件质量指标输出数值，用于表示软件某种质量属性。

EN: Metrics can evaluate performance, reliability, usability, and maintainability.
中: 指标可以评估性能、可靠性、可用性和可维护性。

4. Maintainability Index (MI) ​

可维护性指数 ​

EN: Maintainability Index ranges from 0–100 and indicates how easy code is to maintain.
中: 可维护性指数范围为 0–100，用于表示代码维护难易程度。

EN: Higher values indicate better maintainability.
中: 数值越高表示越容易维护。

EN: MI is derived from LOC, Cyclomatic Complexity, and Halstead Volume.
中: MI 由代码行数、圈复杂度和 Halstead 体积计算得出。

5. Lines of Code (LOC) ​

代码行数 ​

EN: LOC is easy to measure but can be misleading.
中: 代码行数易于测量，但可能产生误导。

EN: Formatting and programming language differences affect LOC counts.
中: 代码格式和编程语言差异会影响行数统计。

EN: More code does not mean better productivity.
中: 代码越多并不代表生产力越高。

6. Cyclomatic Complexity ​

圈复杂度 ​

EN: Cyclomatic complexity measures the number of independent execution paths in a program.
中: 圈复杂度衡量程序中独立执行路径的数量。

EN: It approximates the number of decisions and required test cases.
中: 它近似表示决策数量以及覆盖所有分支所需的测试用例数。

7. Halstead Volume ​

Halstead 体积度量 ​

EN: Halstead Volume measures program size using operators and operands.
中: Halstead 体积通过操作符与操作数衡量程序规模。

EN: It estimates program vocabulary and complexity.
中: 它反映程序词汇量和复杂度。

8. Software Quality Attributes ​

软件质量属性 ​

EN: Software quality includes scalability, security, usability, maintainability, and privacy.
中: 软件质量包括可扩展性、安全性、可用性、可维护性和隐私保护。

EN: Quality is multi-dimensional, not limited to functionality.
中: 软件质量是多维度的，而不仅仅是功能正确。

9. Validity in Measurement ​

度量中的有效性 ​

EN: Construct validity asks whether we measure what we intended.
中: 构念有效性指是否测量了真正想测的内容。

EN: Predictive validity indicates whether a metric predicts outcomes.
中: 预测有效性表示指标是否能预测结果。

EN: External validity concerns whether results generalize to other contexts.
中: 外部有效性关注结果能否推广到其他环境。

10. Measurement Biases ​

度量偏差 ​

Streetlight Effect 路灯效应 ​

EN: People measure what is easiest to measure rather than what is important.
中: 人们倾向测量容易测量的东西，而非真正重要的内容。

McNamara Fallacy 麦克纳马拉谬误 ​

EN: Making decisions solely on quantitative metrics while ignoring qualitative factors.
中: 仅依赖量化指标做决策，忽视无法量化的重要因素。

Correlation vs Causation 相关不等于因果 ​

EN: Correlative relationships do not prove causation.
中: 相关关系并不能证明因果关系。

EN: Causation requires theory, correlation, and predictive validation.
中: 因果关系需要理论支持、相关性证据和预测验证。

Confounding Variables 混杂变量 ​

EN: A confounding variable is a hidden factor influencing both variables studied.
中: 混杂变量是同时影响两个变量的隐藏因素。

EN: Ignoring confounders leads to misleading conclusions.
中: 忽略混杂变量会导致错误结论。

11. Metrics Can Create Bad Incentives ​

指标可能产生错误激励 ​

EN: When performance is measured by a metric, people optimize for the metric.
中: 当绩效由某项指标衡量时，人们会针对该指标进行优化。

EN: “You get what you measure.”
中: “你得到的正是你所衡量的。”

12. Measurement Scales ​

度量尺度类型 ​

EN: Nominal scale categorizes data without order.
中: 名义尺度用于分类，没有顺序关系。

EN: Ordinal scale provides ranking but no magnitude.
中: 顺序尺度提供排名，但没有数量差距。

EN: Interval scale shows ordered differences without a true zero.
中: 间隔尺度具有差值意义，但没有绝对零点。

EN: Ratio scale includes order, magnitude, and a true zero.
中: 比例尺度具有顺序、差值和真实零点。

13. Psychological & Social Influences ​

心理与社会因素 ​

EN: Social pressure can influence perception and judgment.
中: 社会压力会影响人的感知与判断。

EN: Groupthink can distort measurement interpretation.
中: 群体思维可能扭曲对数据的理解。

14. Challenges of Measurement ​

度量的挑战 ​

EN: Metrics may lack validity or be misinterpreted.
中: 指标可能缺乏有效性或被误解。

EN: Human bias and incentives affect measurement outcomes.
中: 人类偏见与激励机制会影响度量结果。

EN: Metrics must be interpreted carefully and used responsibly.
中: 指标必须谨慎解读并负责任地使用。

Key Takeaway 核心结论 ​

EN: Metrics are powerful tools for decision-making but must be used critically and with awareness of bias and limitations.
中: 指标是支持决策的有力工具，但必须批判性地使用，并注意其偏差与局限性。

se 04 Quality Assurance & Testing ​

质量保证与软件测试 ​

1. What is Quality Assurance (QA) ​

什么是质量保证（QA） ​

EN: Quality assurance maintains desired product properties through process choices and development practices.
中: 质量保证通过开发流程与工程实践来维持软件应有的质量属性。

EN: QA focuses on preventing defects by improving the process.
中: QA 通过改进流程来预防缺陷的产生。

QA ≠ Testing
QA = process + standards + practices
QA ≠ 测试；QA 是流程、规范与工程实践。

2. What is Testing ​

什么是测试 ​

EN: Testing executes the program and examines its outputs and behavior.
中: 测试通过运行程序并检查输出与行为来评估软件质量。

EN: Testing is one of the primary methods used in quality assurance.
中: 测试是质量保证中最重要的方法之一。

3. Testing Cannot Prove Absence of Bugs ​

测试不能证明没有缺陷 ​

EN: Testing can reveal the presence of defects, but not prove their absence.
中: 测试可以发现缺陷，但不能证明缺陷不存在。

EN: Infinite inputs make complete testing impossible.
中: 输入空间无限，因此完全测试是不可能的。

4. External vs Internal Quality ​

外部质量 vs 内部质量 ​

External Quality（用户视角） ​

EN: External quality refers to whether software behaves correctly and safely.
中: 外部质量指软件是否正确、安全地运行。

Examples 示例:

  • correct results 正确结果
  • reliability 稳定性
  • security 安全性
  • no crashes 无崩溃

Internal Quality（开发者视角） ​

EN: Internal quality refers to code readability, structure, and maintainability.
中: 内部质量指代码可读性、结构设计与可维护性。

EN: If maintenance dominates lifecycle cost, maintainability is critical.
中: 如果维护占生命周期主要成本，可维护性至关重要。

5. Why Can't a Program Verify Correctness? ​

为什么程序无法验证程序正确性？ ​

EN: The Halting Problem proves no program can always determine correctness.
中: 停机问题证明不存在能始终判断程序正确性的程序。

EN: Therefore, we rely on testing, analysis, and verification techniques.
中: 因此我们依赖测试、分析与验证技术来提高正确性信心。

6. Purpose of Testing ​

测试的目的 ​

EN: Testing increases confidence that the implementation meets the specification.
中: 测试提高我们对实现符合规范的信心。

EN: Testing helps detect defects early and reduce cost.
中: 测试有助于及早发现缺陷并降低修复成本。

7. Unit Testing ​

单元测试 ​

EN: Unit testing verifies individual components in isolation.
中: 单元测试在隔离环境中验证单个功能模块。

Advantages 优点:

  • easy bug localization 易定位问题
  • fast execution 运行快速
  • repeatable 可重复执行

xUnit Frameworks xUnit 测试框架 ​

Examples 示例:

  • JUnit
  • unittest
  • GoogleTest

A test case includes 测试用例包含:

  • setup 初始化
  • execution 执行操作
  • assertion 断言结果

8. Regression Testing ​

回归测试 ​

EN: Regression testing ensures new changes do not break existing functionality.
中: 回归测试确保新修改不会破坏已有功能。

EN: When a bug is fixed, add a test to prevent its return.
中: 修复 bug 后应添加测试防止其再次出现。

9. Integration Testing ​

集成测试 ​

EN: Integration testing verifies that multiple modules work together correctly.
中: 集成测试验证多个模块协同工作是否正确。

EN: It tests system interactions and data flow.
中: 它测试系统交互与数据流。

10. Test-Driven Development (TDD) ​

测试驱动开发 ​

EN: TDD writes tests before implementing code.
中: TDD 在实现代码之前先编写测试。

Workflow 流程:

  1. Write failing test 编写失败测试
  2. Implement code 编写实现代码
  3. Pass test 通过测试
  4. Refactor 重构代码

11. Mocking ​

模拟对象（Mocking） ​

EN: Mock objects simulate real dependencies in testing.
中: Mock 对象用于在测试中模拟真实依赖组件。

Used when 用于:

  • external APIs unavailable 外部接口未完成
  • dependencies expensive or slow 依赖昂贵或缓慢
  • failures difficult to trigger 错误难以触发

Analogy 类比: crash test dummies（汽车碰撞假人）

12. Fuzz Testing ​

模糊测试 ​

EN: Fuzz testing generates random inputs to discover crashes and vulnerabilities.
中: 模糊测试通过随机输入发现崩溃与安全漏洞。

Detects 可发现:

  • crashes 崩溃
  • buffer overflows 缓冲区溢出
  • null pointer errors 空指针错误

13. Penetration Testing ​

渗透测试 ​

EN: Penetration testing evaluates system security by simulating attacks.
中: 渗透测试通过模拟攻击评估系统安全性。

14. Difficult-to-Test Failures ​

难以测试的故障场景 ​

Examples 示例:

  • disk failure 磁盘故障
  • network outages 网络中断
  • memory exhaustion 内存耗尽

Solution 解决方案: mocking & simulation 模拟与仿真

15. Confirmation Bias in Testing ​

测试中的确认偏差 ​

EN: Confirmation bias is the tendency to favor evidence that confirms existing beliefs.
中: 确认偏差指人们倾向于寻找支持既有观点的证据。

Effects 影响:

  • ignoring failures 忽视失败结果
  • groupthink 群体思维
  • policy persistence 固守错误策略

Key Principles 关键原则 ​

EN: Testing increases confidence but cannot guarantee correctness.
中: 测试可以提高信心，但不能保证绝对正确。

EN: Unit tests detect bugs early; regression tests prevent their return.
中: 单元测试有助于早期发现缺陷，回归测试防止缺陷回归。

EN: Mocking enables testing in complex or unavailable environments.
中: Mock 技术使复杂或不可用环境下的测试成为可能。

EN: Testing is essential but must be complemented by good design and process.
中: 测试至关重要，但必须结合良好的设计与流程。

Quick Review (Exam Focus) ​

考试重点速记 ​

QA vs Testing

  • QA = process & prevention
  • Testing = execution & detection
  • QA 是流程与预防；测试是执行与检测

Quality Types

  • External → user experience
  • Internal → maintainability
  • 外部质量关注用户体验；内部质量关注可维护性

Testing Types

  • Unit → small components
  • Integration → modules together
  • Regression → prevent bug return
  • TDD → tests first
  • Mocking → simulate dependencies
  • Fuzz → random inputs
  • Pen test → security testing

Core Truths

  • Testing increases confidence
  • Testing cannot prove absence of bugs
  • Halting problem prevents full verification

Bias

  • Confirmation bias affects testing and decisions

SE05 Test Suite Quality Metrics ​

测试套件质量指标 ​

1. Purpose ​

EN ​

Test suite metrics evaluate how effective a test suite is.

中 ​

测试套件指标用于评估测试是否有效。

2. Three Perspectives on Testing ​

Lens of Logic ​

Tests must execute code to reveal bugs.

逻辑视角：未执行的代码可能隐藏缺陷。

Lens of Statistics ​

Testing samples possible inputs.

统计视角：测试是对真实输入的抽样。

Lens of Adversity ​

Introduce faults to evaluate detection ability.

对抗视角：通过制造缺陷测试系统能力。

3. Coverage ​

Definition ​

Coverage measures how much of a program is exercised.

覆盖率衡量测试执行了多少程序内容。

4. Line Coverage ​

Executed lines / total lines

执行行数 / 总行数

Limitation: 100% coverage does not guarantee correctness.
局限：100% 覆盖率不保证无错误。

5. Branch Coverage ​

Measures execution of true and false branches.

衡量条件分支真假路径是否被执行。

Branch coverage is stronger than line coverage.
分支覆盖比行覆盖更严格。

6. Other Coverage Types ​

  • Function coverage 函数覆盖
  • Condition coverage 条件覆盖
  • MC/DC (mission critical systems)

7. Coverage Limitations ​

Coverage does not ensure:

  • correct logic
  • correct data handling
  • security safety

覆盖率不能保证逻辑正确或安全性。

8. Testing as Sampling ​

Testing is sampling possible inputs.

测试是对输入空间的抽样。

Sampling Error ​

Tests pass but real inputs fail.

Sampling Bias ​

Tests do not represent real users.

9. User-Focused Testing ​

Focus on:

  • common inputs 常见输入
  • high-risk inputs 高风险输入

Risk = probability × damage

10. Beta Testing ​

External users test real usage scenarios.

外部用户参与测试。

11. A/B Testing ​

Compare two variants using real users.

通过用户数据比较两个版本。

12. Mutation Testing ​

Mutation testing evaluates test effectiveness by inserting defects.

通过引入缺陷评估测试质量。

Mutation Score ​

mutants killed / total mutants × 100

13. Key Hypotheses ​

Competent Programmer Hypothesis ​

Faults are usually small.

错误通常很小。

Coupling Effect ​

Detecting simple faults helps detect complex faults.

发现简单错误有助于发现复杂错误。

14. Mutation Testing Challenges ​

  • equivalent mutants 等价变异体
  • high cost 成本高

15. Key Insights ​

  • More coverage → more confidence
  • Coverage ≠ correctness
  • Testing is sampling
  • User behavior matters
  • Mutation testing evaluates test strength

覆盖率越高信心越高，但不代表正确；测试是抽样；用户行为最重要；变异测试评估测试能力。

se06 Test Inputs, Oracles, and Generation ​

测试输入、判定机制与自动生成 ​

1. Test Case Components ​

A test case includes:

  • input
  • oracle
  • comparator

测试用例包含：

  • 输入
  • 预期输出（oracle）
  • 比较机制

2. Comparator ​

Most tests require exact matching.

多数测试要求输出完全匹配。

Comparators may allow tolerance for randomness or precision.

比较机制也可允许误差或随机性。

3. Test Inputs ​

Inputs include:

  • user input
  • command-line arguments
  • environment variables
  • filesystem data
  • network responses
  • scheduling behavior

输入包括用户输入、命令行参数、环境变量、文件系统数据、网络响应和调度行为。

4. Path Coverage ​

With N independent decisions: Paths = 2^N

若有 N 个独立条件分支： 路径数 = 2^N

Branch coverage requires fewer tests.

分支覆盖所需测试更少。

5. Path Predicate ​

A path predicate is a condition that forces execution along a specific path.

路径谓词是使程序执行某路径的条件。

A satisfying assignment provides values that satisfy the predicate.

满足条件的变量赋值用于生成测试输入。

6. Path Explosion ​

Loops can create infinite paths.

循环可能产生无限路径。

Approximations:

  • ignore loops
  • limit iterations
  • limit number of paths

常见近似方法包括忽略循环或限制迭代次数。

7. The Oracle Problem ​

The oracle problem is determining the correct output.

Oracle问题是确定正确输出的困难。

Implicit oracles include:

  • no crashes
  • no infinite loops

隐式oracle包括程序不崩溃或不死循环。

8. Invariants ​

An invariant is a property true for all executions.

不变量是在所有执行中都成立的条件。

Invariants can serve as test oracles.

不变量可作为测试判定依据。

9. Learning Invariants ​

Run the program many times and record what is always true.

通过多次运行程序学习始终成立的条件。

Common behavior is not always correct behavior.

常见行为不一定正确。

10. Automated Test Generation ​

Steps:

  1. enumerate paths
  2. collect predicates
  3. solve constraints
  4. generate inputs

自动生成测试步骤包括枚举路径、收集条件、求解约束并生成输入。

11. Test Suite Minimization ​

Goal: smallest test set with maximum coverage.

目标：最小测试集实现最大覆盖率。

This is a computationally hard problem.

这是计算复杂问题。

Key Insights ​

  • A test needs both input and expected output.
  • Path coverage grows exponentially.
  • Oracles are difficult to construct.
  • Invariants can approximate correctness.
  • Automated tools assist test generation.

测试需要输入与期望输出；路径覆盖呈指数增长；oracle难以构造；不变量可近似正确性；自动工具可辅助生成测试。

se07 Code Inspection and Code Review ​

代码检查与代码评审 ​

1. Static Quality Assurance ​

Static QA evaluates code without executing it.

静态质量保证在不运行程序的情况下评估代码质量。

2. Code Review ​

Code review involves another developer examining proposed changes.

代码评审是由其他开发者检查代码修改。

Common tools:

  • GitHub Pull Requests
  • Gerrit
  • Phabricator

3. Code Inspection ​

Code inspection is a formal team process to examine code.

代码检查是一种正式的团队评审流程。

It is structured and more rigorous but expensive.

它结构化且严格，但成本较高。

4. Why Not Just Testing? ​

Testing cannot:

  • detect masked faults
  • evaluate maintainability
  • analyze design documents
  • ensure security and compliance

测试无法发现被掩盖的缺陷，也难以评估可维护性、安全性或设计文档质量。

5. Second Pair of Eyes ​

Different perspectives help reveal issues.

不同背景和经验有助于发现问题。

6. Code Review Goals ​

  • find defects
  • improve readability and design
  • suggest alternatives
  • knowledge transfer
  • improve transparency

代码评审目标包括发现缺陷、提升可读性、提出替代方案、促进知识共享和提升透明度。

7. Inspection Roles ​

  • Author 作者
  • Inspectors 审查员
  • Reader 朗读者
  • Scribe 记录员
  • Moderator 主持人

8. Inspection Process ​

  1. Planning
  2. Overview
  3. Preparation
  4. Meeting
  5. Rework
  6. Follow-up

9. Social Considerations ​

Avoid blaming authors. Focus on defects, not people.

避免责备作者，应关注缺陷而非个人。

Reviews should not be used for performance evaluation.

代码评审不应用于绩效考核。

10. Group Decision Bias ​

Group discussions may reinforce incorrect assumptions.

群体讨论可能强化错误观点。

11. Best Practices ​

  • sessions < 60 minutes
  • review < 400 LOC/hour
  • preparation finds most issues

最佳实践包括会议不超过60分钟，每小时审查不超过400行代码，并在会前准备阶段发现大多数问题。

12. Root Cause Analysis ​

Reviews should improve the development process.

代码评审应帮助改进开发流程。

13. Cost Benefits ​

Early defect detection saves significant cost.

早期发现缺陷可以显著降低成本。

Key Insights ​

  • Static reviews complement testing.
  • Multiple reviewers improve quality.
  • Reviews improve code and team knowledge.
  • Social dynamics affect review effectiveness.

静态评审是测试的重要补充，多人审查提升质量，同时促进知识共享，但社会因素也会影响评审效果。

se08 Dynamic Analysis ​

动态分析 ​

1. Definition ​

Dynamic analysis runs an instrumented program to collect runtime information.

动态分析通过运行插桩程序收集运行时信息。

2. Purpose ​

Dynamic analysis helps answer runtime questions such as:

  • performance
  • memory usage
  • race conditions
  • coverage
  • security vulnerabilities

动态分析用于回答运行时性能、内存使用、竞态条件、覆盖率和安全漏洞等问题。

3. Instrumentation ​

Instrumentation modifies a program to record additional information.

插桩通过修改程序以记录额外运行信息。

It can be done at compile time or via virtual machines.

可在编译阶段或通过虚拟机实现。

4. Common Dynamic Analyses ​

  • coverage analysis
  • path profiling
  • information flow (taint tracking)
  • execution time profiling

常见动态分析包括覆盖率分析、路径分析、信息流追踪和执行时间分析。

5. Race Conditions ​

A race condition occurs when multiple threads access shared state without synchronization.

当多个线程在无同步机制下访问共享状态时会发生竞态条件。

6. Taint Tracking ​

Tracks whether untrusted input influences sensitive operations.

追踪不可信输入是否影响敏感操作。

7. Data Collection Challenges ​

Recording all execution data is infeasible due to storage and performance limits.

由于存储和性能限制，不可能记录全部执行数据。

8. Limitations ​

  • performance overhead
  • false positives and negatives
  • instrumentation may alter behavior (Heisenbugs)

动态分析存在性能开销、误报漏报以及可能改变程序行为的问题。

9. Sound vs Complete ​

Sound analyses avoid missing defects. Complete analyses avoid false alarms.

可靠分析避免漏报，完备分析避免误报。

10. Real-world Tools ​

Examples include:

  • Eraser (race detection)
  • Chaos Monkey (resilience testing)
  • CHESS (concurrency testing)
  • Driver Verifier (driver testing)

现实工具包括Eraser、Chaos Monkey、CHESS和Driver Verifier。

Key Insights ​

  • Dynamic analysis observes runtime behavior.
  • Instrumentation enables runtime monitoring.
  • Race conditions and security flaws often require dynamic analysis.
  • Recording all data is infeasible.
  • Trade-offs exist between accuracy and performance.

动态分析用于观察运行时行为，插桩实现监控，竞态条件和安全问题常需动态分析，记录全部数据不可行，准确性与性能存在权衡。

se09 Static & Dataflow Analysis ​

静态分析与数据流分析 ​

来源：Static and Dataflow Analysis PPT

1. Software Quality & Motivation ​

软件质量与动机 ​

EN

Quality assurance is essential in software engineering.
Testing is the most common dynamic QA approach.

However, some defects such as race conditions, information leaks, and rare execution bugs are difficult to detect through testing.

Manual static approaches include:

  • code review
  • code inspection

Therefore, automatic static analysis is necessary.

中文

软件质量保障在软件工程中至关重要。
测试是最常见的动态质量保障方法。

然而，一些缺陷（竞态条件、信息泄露、罕见执行路径错误）难以通过测试发现。

常见人工静态方法包括：

  • 代码审查
  • 代码检查

因此需要自动化静态分析。

2. What is Static Analysis? ​

什么是静态分析？ ​

EN

Static analysis examines an abstraction of a program’s state space without executing the program.

It reasons about all possible executions and is conservative.

中文

静态分析是在不运行程序的情况下分析程序状态空间的抽象。

它推理程序的所有可能执行路径，并采用保守策略。

Simplified Definition 简化定义 ​

Static analysis = analyzing code, not runtime behavior.
静态分析 = 分析代码本身，而不是运行结果。

3. What is Dataflow Analysis? ​

什么是数据流分析？ ​

EN

Dataflow analysis tracks abstract values as they flow through a program.

It focuses on categories (e.g., secret vs public) rather than exact values.

中文

数据流分析跟踪变量在程序中的抽象值传播。

它关注类别（如秘密信息 vs 公共信息），而不是具体数值。

4. Why Static Analysis Matters ​

静态分析的重要性 ​

Apple SSL “goto fail” bug ​

EN

A duplicated goto fail caused certificate verification to be skipped.

Static analysis tools could detect this vulnerability.

中文

重复的 goto fail 导致证书验证被跳过。

静态分析工具可以检测出该安全漏洞。

Linux Driver Bug ​

EN

Returning from a driver with interrupts disabled can crash the system.

Such issues are difficult to detect through testing.

中文

如果驱动返回时中断仍关闭，系统可能崩溃。

这种问题很难通过测试发现。

5. Why Testing Alone is Insufficient ​

为什么仅靠测试不够？ ​

EN

Many defects occur on rare execution paths.

Executing all paths is infeasible.

Static analysis reasons about:

all possible runs
without executing the program.

中文

许多缺陷存在于罕见执行路径中。

执行所有路径在现实中不可行。

静态分析在不运行程序的情况下推理：

所有可能执行路径。

6. Static Analysis Goals ​

静态分析目标 ​

Static analysis verifies properties:

Safety ​

Bad things never happen.

Liveness ​

Good things eventually happen.

静态分析验证：

安全性 ​

坏事不会发生。

活性 ​

好事最终会发生。

7. Abstraction ​

抽象 ​

EN

Abstraction keeps semantically relevant details and ignores irrelevant ones.

It must handle uncertainty.

中文

抽象保留语义相关信息，忽略无关细节。

它必须能够处理不确定性。

8. Programs as Data ​

程序即数据 ​

Programs can be analyzed as:

  • strings (grep)
  • trees (AST)
  • graphs (CFG)

程序可以表示为：

  • 字符串（grep）
  • 树（AST）
  • 图（CFG）

9. Abstract Syntax Tree (AST) ​

抽象语法树 ​

EN

AST represents the syntactic structure of code while removing unnecessary syntax details.

中文

AST 表示代码语法结构，并去除不必要的语法细节。

10. Control Flow Graph (CFG) ​

控制流图 ​

EN

CFG represents all possible execution paths of a program.

It is a directed graph modeling program flow.

中文

CFG 表示程序所有可能执行路径。

它是描述程序流程的有向图。

11. Dataflow Analysis Process ​

数据流分析过程 ​

Steps:

  1. Build CFG
  2. Abstract variable values
  3. Apply transfer rules

步骤：

  1. 构建控制流图
  2. 抽象变量值
  3. 应用传播规则

12. Example Analyses ​

典型分析问题 ​

Definite Null Dereference ​

Pointer is always null when dereferenced.
指针解引用时是否一定为 null。

Secure Information Leak ​

Secret data may reach public output.
敏感信息可能泄露。

13. Global Dataflow Analysis ​

全局数据流分析 ​

Analysis must consider all paths, including loops and branches.

分析必须考虑所有路径，包括循环与分支。

14. Correctness Condition ​

正确性条件 ​

A variable is always null at use if:

on every path to its use,
the last assignment sets it to null.

若变量在使用时总为 null，则必须满足：

在所有路径上，
最后一次赋值都是 null。

15. Undecidability (Rice’s Theorem) ​

不可判定性 ​

Most interesting program properties are undecidable.

Examples:

  • halting problem
  • function output correctness

大多数有意义的程序属性不可判定，例如：

  • 停机问题
  • 输出正确性

16. Loops and Imprecision ​

循环与不精确性 ​

Programs contain loops.

Analysis must terminate even if programs loop.

This introduces imprecision.

程序通常包含循环。

分析必须终止，即使程序无限循环。

这会带来不精确性。

17. Conservative Analysis ​

保守分析 ​

If we cannot prove a property, we report:

  • definitely true
  • unknown

宁可不确定，也不能给出错误结论。

Engineering Tradeoff 工程权衡 ​

Developers → fewer false positives
Safety systems → fewer false negatives

开发工具 → 减少误报
安全系统 → 减少漏报

18. Dataflow Values ​

数据流取值 ​

ValueMeaning
⊥unreachable 未到达
constantknown value 确定值
⊤unknown 不确定

19. Transfer Functions ​

传递函数 ​

Transfer functions describe how statements transform information.

Examples:

  • assignment to constant → constant
  • function call → unknown
  • unrelated variable → unchanged

传递函数描述语句如何改变信息。

20. Information Propagation ​

信息传播 ​

Cin = value before statement
Cout = value after statement

Cin = 语句前
Cout = 语句后

21. Lattice Structure ​

格结构 ​

Values form an ordering:

⊥ < constant < ⊤

This guarantees termination.

值形成偏序结构，保证分析终止。

22. Definitely Null Analysis ​

空指针分析 ​

Warn when a pointer is definitely null at dereference.

当指针在解引用处确定为 null 时发出警告。

This is conservative.

这是保守分析。

23. Secure Information Flow Analysis ​

信息流安全分析 ​

Goal:

Determine whether sensitive data may reach public output.

目标：

判断敏感数据是否可能流向公开输出。

If a path exists from secret source to public sink → potential leak.

若存在路径 → 可能泄露。

24. Forward vs Backward Analysis ​

前向 vs 后向分析 ​

Forward analysis

propagates information from inputs to outputs
example: null analysis

Backward analysis

propagates requirements from outputs to inputs
example: leak detection

25. Liveness Concept ​

活跃性概念 ​

A variable is live if its value may be used later.

若变量未来可能被使用，则为活跃变量。

26. Static Analysis Limitations ​

静态分析局限 ​

Static analysis may:

  • over-approximate
  • miss rare behaviors
  • produce false warnings

静态分析可能：

  • 过度近似
  • 漏掉罕见行为
  • 产生误报

27. File Handle Analysis Example ​

文件句柄分析示例 ​

Track file states:

  • open
  • closed
  • unknown

跟踪文件状态：

  • 打开
  • 关闭
  • 未知

Detectable errors 可检测错误 ​

  • read on closed file
  • open twice
  • close unopened file

28. Key Takeaways ​

核心总结 ​

Static analysis reasons about all executions without running the program.

Dataflow analysis tracks abstract values through control flow.

Because many properties are undecidable, analyses must be conservative.

静态分析在不运行程序的情况下推理所有执行路径。

数据流分析跟踪变量在控制流中的传播。

由于不可判定性，分析必须采用保守策略。