from Baseline Software Management Plans and DC3 Management
DM DC3 Subsystem Integration Test Plan
Draft
DC3 Subsystem Integration Test (IT) Plan
1. Test Plan Identification
- Baseline Identifier
- DM DC3
- Testing Level
- DM Subsystem Integration.
2. References
- Baseline Design Documents
- Baseline Plan
3. Items to be tested
- Night Processing Pipeline Subsystem a sequence of
- Night Processing SDQA Pipeline Subsystem
- Science User Interface
- Image Data Train Processing Pipeline a sequence of
- Image Data Train SDQA Pipeline Subsystem
- Catalog Data Train Processing Pipeline a sequence of
- Catalog Data Train SDQA Pipeline Subsystem
- Data Release Processing Pipeline Subsystem a sequence of
- Data Transfer & Ingest Services
- Data Access Services
4. Features to be tested
The overall goal is to, first, extend the DC2 pipelines to support Data Release pipeline processing, and secondly, refine the DC2 nightly real-time observation processing (also known as the Nightly Processing Pipeline). Additionally, the end-to-end data quality will be assessed, and both the reliability of the infrastructure and middleware and their scalability to 15% of LSST required rates will be validated.
5. Approach
- Testing Strategy
- Subsystem Accretion Testing (aka building block or layering approach to adding new susbsystems to baseline)
- For each software subsystem:
- validate subsystem
- For each hardware subsystem:
- validate subsystem
- For each hardware & software subsystem integration:
- validate subsystem
- For each software subsystem:
- Subsystem Accretion Testing (aka building block or layering approach to adding new susbsystems to baseline)
- Test Types
- Subsystem Integration tests verify that the major software components work correctly with the rest of the system, and as specified in the architectural design. The common tests performed include:
- White-box Tests
- Black-box Tests
- Performance Tests
- Subsystem Integration tests verify that the major software components work correctly with the rest of the system, and as specified in the architectural design. The common tests performed include:
- Overall Test Sequencing
- The testing sequence generally follows the item order in Section 3. Items to be tested. For composite items, member items will be added to the validated baseline and tested, one at a time and in the sequence shown, until the entire composite item is incorporated. Then the composite item will be validated.
- Coverage level
- A minimum test coverage metric is not defined for DC3. The Unit Testing Standard? supports the developer's use of coverage analysis tools to verify each unit test suite's adequacy.
6. Test Criteria
- Item Pass/Fail Criteria
- Entry & Exit Criteria
- Suspension & Resumption Criteria
7. Test Deliverables
- Deliverables required prior to testing
- test plan
- test cases
- test procedures
- test data
- test tools
- test plan
- Deliverables on Completion
- test reports (build log, test log,
- test output data
- test problem reports
8. Testing Tasks
- identify the set of tasks necessary to prepare for and perform testing;
- identify all inter-task depedencies.
9. Environmental Needs
- Describe requirements of Baseline testbed setup
- test tools
- mode of use (i.e. standalone, networked)
- communications software
- hardware
- system software
10. Schedule
- include test milestones identified in software project plan and all item delivery events
11. Planning Risks and Contingencies
- Identify high risk assumptions of the test plans and contingency plans for each.
12. Test Case Specification
Refer to DM Subsystem Integration Test Cases.
