Module Testing Quality Improvement Measures

Abstract

The project objective was to update and validate module tests impacted by the modified design or Low-Level Requirements (LLRs). During this activity quality issues were identified which were present in the original tests done before 2006. This case study highlights the measures taken to overcome the quality issues.

1. INTRODUCTION

ACCORD performed the unit testing of an aircraft LRU software for a European customer during 2002 to 2006. Recently we received the rework of CSU Tests for SW parts updated during development. The project objective was to update and validate module tests impacted by the modified design or Low-Level Requirements (LLRs). During this activity quality issues were identified which were present in the original tests done before 2006. This case study highlights the measures taken to overcome the quality issues.

However, this approach has the following limitations:

  • However, this approach has the following limitations:
  • The stub functions are used to check the control flow of UUT. However, the behavior of the functions called by UUT will not be tested with actual (practical) values. The called functions will be tested in isolation as UUT.
  • The overall architecture of the software will not be tested with LLR based tests.
  • The testing strategy becomes more of white box testing rather than a black box testing.
  • The Hardware dependent functionalities (Including timing Requirements, interrupt processing requirements) cannot be tested when the UUT is tested in isolation.

To overcome these drawbacks, an attempt is made to perform the structural coverage from the High Level Requirements based or Hardware-Software Integration testing itself. This will ensure that the all the modules are integrated and tested as a fully Integrated software.

Download Whitepaper