test coverage for requirements-凯发k8网页登录

this example uses:

this example shows how to collect test coverage for a model that implements requirements. coverage refers to determining the testing completeness by analyzing how much of the model logic is exercised. for requirements-based testing, coverage results can be scoped to linked requirements. with this scoping you can assess if each model element is covered by the intended test case.

the example shows how scoping coverage results to linked requirements can reveal both inadequate requirement linking and testing gaps. it also shows how to increase the coverage.

the model in this example is cruisecontrolrbtcovexample, which represents a cruise control system. this model implements and is linked to requirements. a test file has already been created for this example.

open the cruise control model

cruisecontrolrbtcovexample

view the linked requirements

the requirements for this cruise control system have been captured in the requirements editor. to view the requirements, use slreq.open('cruisecontrolrbtcovreqs.slreqx').

open the test manager and test file

use sltestmgr to open the test manager.

click open and select cruisecontrolrbtcovtests.mldatx. the tests have been written to verify that the model behavior meets the specified requirements. they have also been set up to record decision and condition coverage. expand coverage settings to see the selected metrics.

each test case verifies and is linked to a requirement. for example, the throttle test verifies the throttle requirement. this requirement specifies that the throttle is applied smoothly if the speed differs from the target. the test verifies this behavior using a logical assessment, which checks that the throttle rate of change is between -1 and 1 radians per second, as defined in the requirement description.

run the test and view coverage results

run the test.

click on results in the results and artifacts pane when the test finishes running. note that the tests pass and that 100% aggregated coverage is reported.

turn on scoping the test results to linked requirements

click the top-level results in the results and artifacts pane. then, in the aggregated coverage results pane, click the scope coverage results to linked requirements check box. scoping the results means that each test only contributes coverage for the corresponding model elements that implement the requirement verified by that test. scoping checks that model elements are covered by the intended test cases. the coverage results, which update automatically, now show aggregated coverage for decision and execution at 92% and 76%, respectively.

view the coverage results in the model

click on the model name in the analyzed model column to highlight the coverage results in the model and display the coverage report details.

in the model, if the requirements table is not shown below the model, open it by clicking the perspectives views in the lower right corner of the model canvas and then, clicking requirements.

open the controller subsystem. blocks that do not have 100% coverage appear in red. two sets of constant and sum blocks are not linked to requirements and were never executed.

link blocks to requirements

in this case, the missing coverage indicates insufficient requirements linking. these constant and sum blocks are necessary for implementing the increment and decrement requirements and should be linked to the appropriate requirements.

in the table in the requirements pane, expand cruisecontrolrbtcovreqs. right-click on the upper constant block and select requirements > link to selection in requirements browser. then, click on the increment requirement in the requirements table. repeat this for the upper sum block.

for the lower constant and sum blocks, repeat the linking steps, but link to the decrement requirement.

increase coverage from a specific test

open the pi controller and click on the discrete-time integrator block. the coverage details show that the true decision for the upper limit was executed by the increment test (t4), rather than the throttle test (t6). since the block is part of the implementation of the throttle requirement, it should have been tested by the throttle test, which verifies the throttle requirement. the increment test does not verify this requirement and does not contribute coverage for this block when the scope model coverage to linked requirements setting is enabled.

to resolve the missing coverage for this block, the throttle test needs to be updated to exercise the discrete-time integrator block more.

in the test browser pane of the test manager, select throttle test. under inputs, select td_throttle_updated.mat as the external inputs file. this updated input throttle data file has some additional seconds of test data, which increase the target speed more aggressively while maintaining the actual speed.

select cruisecontrolrbtcovtests in the test browser pane and rerun the test. click the scope coverage results to linked requirements check box. the coverage results show 100% coverage, which indicates that the tests adequately execute the model.

revised test reveals an issue in the design

the revised throttle test now fails verification. the failure occurs because the throttle increases too aggressively and is outside the required boundaries specified in the test. this indicates an issue with the model design. the pi controller block implementation would need to be updated to apply the throttle within the required limits, including when the target and actual speeds differ significantly.

conclusion

in summary, scoping coverage results to linked requirements can help reveal gaps in testing. scoping accomplishes this by assessing that each model element is exercised by the test that verifies the corresponding requirement.