AgentSkillsCN

Qa Strategy And Metrics

QA 策略与指标

SKILL.md

QA Strategy and Metrics Skill

Metadata (Tier 1)

Keywords: strategy, testing pyramid, quality, metrics, technical debt, complexity, maintainability, coverage principles

File Patterns: N/A (conceptual skill)

Modes: code_review, testing_frontend, testing_backend

Activation: Conceptual queries about testing strategy, quality metrics, or technical debt.

Instructions (Tier 2)

Testing Pyramid

code
       E2E (5-10%)
    Integration (15-20%)
  Unit Tests (70-80%)

Rationale:

  • •Unit: Fast (ms), cheap, high confidence in individual components
  • •Integration: Moderate speed (seconds), tests component interactions
  • •E2E: Slow (seconds-minutes), expensive, fragile, but validates real workflows

Anti-Pattern: Inverted pyramid (too many E2E tests)

  • •Slow CI/CD pipeline
  • •Flaky tests due to external dependencies
  • •High maintenance burden

Cyclomatic Complexity (CC)

Formula: CC = E - N + 2P

  • •E = edges in control flow graph
  • •N = nodes
  • •P = connected components

Interpretation:

  • •1-5: Low risk, straightforward logic
  • •6-10: Moderate complexity, well-structured
  • •11-20: Complex, consider refactoring
  • •21+: Very complex, MUST refactor

When to refactor:

  • •Function has CC > 15
  • •Function has multiple responsibilities
  • •Difficult to write tests (need many mocks)

Code Coverage Metrics

Statement Coverage: % of code lines executed Branch Coverage: % of decision paths taken (if/else, switch) Function Coverage: % of functions called

Critical Insight: 100% coverage ≠ 100% tested

  • •May miss edge cases
  • •May not test error handling
  • •May not validate business logic

Focus Areas:

  • •Error handlers (try/except, catch)
  • •Boundary conditions (null, empty, max)
  • •Complex conditionals

Maintainability Index (MI)

Formula (simplified):

code
MI = 171 - 5.2 * ln(HV) - 0.23 * CC - 16.2 * ln(LOC)
  • •HV = Halstead Volume (code complexity)
  • •CC = Cyclomatic Complexity
  • •LOC = Lines of Code

Ranges:

  • •85-100: Highly maintainable
  • •65-84: Moderately maintainable
  • •0-64: Difficult to maintain

Technical Debt

Formula: Debt = (Cost to Fix) * (Impact if Not Fixed)

Types:

  1. •Code Debt: Poor structure, duplication
  2. •Test Debt: Low coverage, missing tests
  3. •Documentation Debt: Missing/outdated docs
  4. •Architectural Debt: Design constraints

When to Pay Down:

  • •High-traffic code paths
  • •Before major refactoring
  • •Security-sensitive areas