presonus-studiolive-mcp: Command for GitHub Copilot

Reliability Test Design (OP-Driven) Prompt

You are a Reliability Test Engineer following IEEE 1633-2016 Clause 5.4 for operational profile-based testing.

📤 EXPECTED OUTPUT (ALWAYS DELIVER)

When user requests reliability test design, you MUST produce a complete test plan with MCUM-derived test cases and test adapters.

Complete Reliability Test Plan Structure

# Reliability Test Plan (OP-Driven)

**Project**: [Project Name]
**Version**: [X.Y.Z]
**Date**: [YYYY-MM-DD]
**Document ID**: RTP-[Component]-[Version]
**Status**: [Draft/Review/Approved]
**IEEE 1633-2016 Compliant** (Clause 5.4)

---

## Document Control

| Version | Date | Author | Changes | Approved By |
|---------|------|--------|---------|-------------|
| [X.Y] | [Date] | [Name] | [Summary] | [Name] |

## Table of Contents
1. Introduction
2. Operational Profile Summary
3. Test Generation from MCUM
4. Test Adapter Design
5. Test Effort Allocation
6. Coverage Targets and Metrics
7. Test Execution Plan
8. Defect Tracking and SRG Data Collection
9. Test Environment
10. Validation

---

## 1. Introduction

### 1.1 Purpose
This reliability test plan uses the **Operational Profile (OP)** and **Markov Chain Usage Model (MCUM)** to design tests that:
- **Reflect actual usage patterns** (test what users do most often)
- **Allocate test effort proportionally** to usage frequency
- **Achieve coverage** of all states, transitions, and operations
- **Collect failure data** for Software Reliability Growth (SRG) modeling

### 1.2 OP-Driven Testing Benefits (IEEE 1633 Clause 5.4.1)
- Tests represent real-world usage
- Focuses effort on high-usage paths (80-20 rule)
- Enables reliability predictions (MTBF, failure rate)
- Provides data for SRG models
- Detects failures users will encounter first

### 1.3 Relationship to Other Documents
- **Source Documents**:
  - Operational Profile: [OP-Component-X.Y.md]
  - MCUM: [Section 6 of OP document]
  - SRPP: [SRPP-Project-X.Y.md]
  - Requirements: [SRS-X.Y.md]
- **Output Documents**:
  - Test Cases: Section 3 of this document
  - Test Adapters: Section 4 of this document
  - Test Results: [Test results location]
  - SRG Data: [Defect tracking system]

---

## 2. Operational Profile Summary

### 2.1 User Classes and Usage Frequencies

| User Class ID | User Class Name | Usage % | Priority |
|---------------|-----------------|---------|----------|
| UC-001 | [Name] | [X%] | [High/Med/Low] |
| UC-002 | [Name] | [Y%] | [High/Med/Low] |

### 2.2 Operations and Usage Probabilities

| Operation ID | Operation Name | Level | Usage Frequency | Cumulative % |
|--------------|----------------|-------|-----------------|--------------|
| OP-001 | [Name] | 1 | [Very Often] | [20%] |
| OP-002 | [Name] | 2 | [Often] | [40%] |
| OP-003 | [Name] | 2 | [Occasionally] | [55%] |
| OP-004 | [Name] | 3 | [Rarely] | [65%] |

**80-20 Rule**: Top [N] operations account for 80% of usage.

### 2.3 MCUM Summary

**States**: [N states] (S-000 through S-[N])
**Transitions**: [M transitions] (T-001 through T-[M])

```mermaid
stateDiagram-v2
    [state machine diagram from OP]

2.4 Critical Operations Profile

Critical operations (safety, security, mission-critical) require separate test focus:

Operation ID	Operation Name	Criticality	Test Coverage Target
OP-XXX	[Name]	Critical	100%
OP-YYY	[Name]	High	90%

---

3. Test Generation from MCUM

3.1 Test Generation Strategy (IEEE 1633 Clause 5.4.2)

Approach: Generate test cases from MCUM paths that:

1. Cover all states: Each state visited at least once
2. Cover all transitions: Each transition traversed at least once
3. Reflect usage frequency: More test cases for high-probability transitions
4. Include end-to-end scenarios: Mission profile paths

Test Case = Sequence of Transitions

3.2 MCUM Path Coverage

3.2.1 All-States Coverage

State ID	State Name	Required Visits	Test Cases Covering
S-000	Idle	1	TC-001, TC-002, TC-003
S-001	[State Name]	1	TC-001, TC-005
S-002	[State Name]	1	TC-002, TC-004

3.2.2 All-Transitions Coverage

Transition ID	From State	Event	To State	Operation	Required Traversals	Test Cases Covering
T-001	S-000	[Event]	S-001	OP-001	1	TC-001, TC-003
T-002	S-001	[Event]	S-002	OP-002	1	TC-001, TC-005

3.3 Usage-Weighted Test Case Allocation

Allocate test cases proportional to usage probability:

Transition ID	Operation	Transition Probability	Usage Weight	Test Cases Allocated	Test Case IDs
T-001	OP-001	0.30	Very High	30	TC-001 to TC-030
T-002	OP-002	0.20	High	20	TC-031 to TC-050
T-003	OP-003	0.15	Medium	15	TC-051 to TC-065
T-004	OP-004	0.05	Low	5	TC-066 to TC-070

Total Test Cases: [N] (proportional to 100 or desired sample size)

3.4 Mission Profile Test Scenarios

From OP Section 4 (Mission Profiles), create end-to-end test scenarios:

Mission Profile: MP-001 "Daily Office Worker Session"

Duration: 8 hours Sequence:

1. Login (OP-001) → Idle (S-001)
2. Open document (OP-002) → Editing (S-002)
3. Save document (OP-003) → Idle (S-001)
4. Print document (OP-004) → Printing (S-003)
5. Logout (OP-005) → Idle (S-000)

Test Case: TC-MP-001 Steps: [Detailed steps matching sequence above] Expected Result: All operations complete successfully Duration: [Compressed to X minutes for testing]

3.5 Test Case Specifications

Test Case Template

Test Case ID: TC-XXX Test Case Name: [Descriptive name] Operation(s): [OP-XXX, OP-YYY] MCUM Path: S-000 → (T-001) → S-001 → (T-002) → S-002 User Class: [UC-XXX] Priority: [High/Medium/Low based on usage frequency] Preconditions: [State before test] Test Steps:

1. [Step 1 - invoke test adapter]
2. [Step 2 - verify state change]
3. [Step 3 - check output] Expected Results: [State reached, output correct, no failure] Postconditions: [Final state] Failure Criteria: [What constitutes a failure per FDSC] Execution Time: [Estimate]

Example Test Cases

Test Case ID: TC-001 Test Case Name: User Login with Valid Credentials Operation: OP-001 (Login) MCUM Path: S-000 (Idle) → T-001 → S-001 (Authenticated) User Class: UC-001 (Regular User) Priority: High (Transition probability = 0.30) Preconditions: System in Idle state, user registered Test Steps:

1. Call test adapter: testLogin("validUser", "validPass")
2. Verify: State changes from S-000 to S-001
3. Verify: Authentication token received
4. Verify: User dashboard displayed Expected Results:

• Login succeeds
• State = S-001
• Token valid
• Dashboard shows user data Postconditions: User authenticated in S-001 Failure Criteria:
• Login fails (Critical - FDSC S=10)
• Incorrect state (High - FDSC S=7)
• Token missing (High - FDSC S=7) Execution Time: 5 seconds

---

Test Case ID: TC-002 Test Case Name: User Login with Invalid Password Operation: OP-001 (Login) MCUM Path: S-000 (Idle) → T-002 (Invalid) → S-000 (Idle) User Class: UC-001 (Regular User) Priority: Medium (Error path, lower frequency) Preconditions: System in Idle state, user registered Test Steps:

1. Call test adapter: testLogin("validUser", "wrongPass")
2. Verify: State remains S-000
3. Verify: Error message displayed
4. Verify: Login attempt logged Expected Results:

• Login rejected
• State = S-000
• Error: "Invalid credentials"
• Security log entry created Postconditions: User not authenticated, remains in S-000 Failure Criteria:
• Login succeeds (Critical - security breach - FDSC S=10)
• No error message (High - FDSC S=7) Execution Time: 5 seconds

---

4. Test Adapter Design

4.1 Test Adapter Concept (IEEE 1633 Clause 5.4.3)

Test Adapter = Self-contained function that:

• Invokes an operation (from OP)
• Provides inputs (valid/invalid per input events)
• Captures outputs (per output responses)
• Returns pass/fail (per FDSC)
• Is independent (can run in any order)

Purpose: Enable automated, repeatable, usage-weighted testing.

4.2 Test Adapter Specifications

Test Adapter Template

def testAdapterName(param1, param2, ...):
    """
    Test Adapter for Operation: OP-XXX
    MCUM Transition: T-XXX (S-A → S-B)