Fill This Form To Receive Instant Help
Homework answers / question archive / You should turn in a report (
You should turn in a report (.pdf is preferred) that documents your testing activities. Perform the following steps and describe each step in your report: 1. Analyze the software and identify each of the predicates. Map each source code clauses to letter. 2. For each predicate, create a truth table that contains each clause in the predicate. Number each row by the number of the predicate, followed by a sequential letter (e.g., la, lb, lc, 2a, 2b, 2c, etc.). Determine the conditions under which each clause determines the predicate. Use the truth table below as an example of how to construct your truth tables. 3. Using the truth tables, select a pair of rows that satisfy RACC (note that only one pair of RACC rows is required, not all pairs). Remember that tests are expensive to write, to run, and to maintain, so choose the RACC rows carefully to eliminate redundancy and minimize the size of the test set. Explain the process you used to perform the minimization. 4. Create a set of test inputs that satisfy the conditions specified by the selected RACC rows. Ensure that your inputs result in the desired test conditions by the time execution reaches the decision you are testing; that is, ensure that you can satisfy controllability and Teachability conditions for each test case. Explain why any infeasible test cases cannot be satisfied. 5. Implement a set of JUnit tests for the selected RACC rows. Name the tests so that it is clear which RACC rows are satisfied by each test (la, lb, lc, etc.). 6. Execute the JUnit tests and include the results. 7. Describe any fault(s) found, explain the conditions under which the fault(s) occur, and describe a correction to the MCAS software that eliminates the fault(s).
This assignment is an exercise in testing safety-critical software. The subject of the exercise is the Boeing 737 MAX Maneuvering Characteristics Augmentation System (MCAS) — or more correctly, a simple simulation of MCAS. The Federal Aviation Administration (USA), the European Union Aviation Safety Agency, and Transport Canada all require the use of the DO-178C safety standard for commercial aviation software. DO-178C classifies software according to the following risk levels:
• Catastrophic - Failure may cause deaths, usually with loss of the aircraft. Typically requires testing to the modified condition/decision coverage (MCDC) criterion. • Hazardous - Failure has a large negative impact on safety or performance, reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers. Typically requires testing to the edge/branch coverage criterion. • Major - Failure significantly reduces the safety margin or significantly increases crew workload. May result in passenger discomfort (or even minor injuries). Typically requires testing to the node/statement coverage criterion. • Minor - Failure slightly reduces the safety margin or slightly increases crew workload. Examples might include causing passenger inconvenience or a routine flight plan change. Does not require any specific testing criteria. • No Effect - Failure has no impact on safety, aircraft operation, or crew workload. Does not require any specific testing criteria.
Assume that your safety engineering team has identified the MCAS system as having a catastrophic level of risk. Your assignment is to test the software in accordance with the MCDC criterion. As we discussed in the week 9 slides, Restricted Active Clause Coverage (RACC) is equivalent to unique MCDC, the most common type of MCDC testing. Therefore, you will test the MCAS software according to the RACC criterion. Keep in mind that "testing-only" code is undesirable in general and is typically prohibited when testing safety-critical systems. Thus, do not make changes to the "Mcas" class. Changes to or using a test double or mock in place of dependencies (the "McasTimer" class) is permitted.