WGU C857 - Software Quality Assurance
Latest 2022 Graded A+
3 Types of Acceptance Tests ✔✔Benchmark, Pilot, Parallel
(details below)
Benchmark tests ✔✔tests ran by users using *predefined test cases*
Pilot tests ✔✔t
...
WGU C857 - Software Quality Assurance
Latest 2022 Graded A+
3 Types of Acceptance Tests ✔✔Benchmark, Pilot, Parallel
(details below)
Benchmark tests ✔✔tests ran by users using *predefined test cases*
Pilot tests ✔✔tests ran by users under *normal or everyday situation*
Beta testing ✔✔done at customer's site
Alpha testing ✔✔done at developer's site
Parallel test ✔✔New system operates in parallel with previous version to make transition easier
for user
LOC measurement of productivity ✔✔Error per line of code is better. LOC is not good for all
programs because it is hard to measure. Some programs only use one line.
Cyclomatic complexity ✔✔a measure of the complexity of a module's decision structure.
Module Design Complexity ✔✔iv(G);
is the cyclomatic number for the module
Design Complexity ✔✔SO;
sum of iv(G) for itself and all decedents
Integration complexity ✔✔S1;
SO - n + 1
Module Integration testing ✔✔evaluate just the module and its immediate children
Design Integration testing ✔✔evaluate the entire graph
White box testing ✔✔look into program graph at cyclomatic #, basis, IP, DU path coverage, and
program slice
Functional testing ✔✔do not look at program structure, only at the specifications or requirements
Unit level testing ✔✔White box and functional testing of each module
Integration testing ✔✔integrate modules, that have been tested at unit level
Unit and Functional testing ✔✔verification that the programmer implemented the design correctly
System testing ✔✔validation that the system does what the customer wants it to do
*System testing steps* ✔✔functional testing,
performance testing,
acceptance testing,
installation testing
*Function point* ✔✔used early in lifecycle at requirements analysis as a mechanism to estimate
the project with the use of a historical baseline for comparison
*Function point factors* ✔✔Inputs, Outputs, User inquiries, Data files to be accessed, Interfaces
to other applications
Weights for factors ✔✔reflects the approximate difficulty associate with implementing each of
the 5 factors
Complexity adjustment ✔✔reflects the complexity of the whole application
Metric ✔✔is an interpretation of a set of data points, and is used as a measurement process
Key to estimating size ✔✔having a historical baseline of performance to use for comparison
Halstead Metrics ✔✔Linguistic metrics; predicts the number of bugs in the software.
McCabe Metrics ✔✔Structural Metrics; used to measure complexity for testing; used for
integration testing
Complexity Profile Graph (CPG) ✔✔creates a profile and not just a single number to indicate the
software's complexity. The profile gives a graph to indicate complexity of each line of code. It also
gives the overall software complexity. It is based off of values from each measurable unit.
Segment (CPG) ✔✔is a bar in the graph; it is computed based off of content, breadth, reachability,
inherent, total of all
Maintainability Index (MI) ✔✔used after the system is developed; the smaller the number the
better.
Big Bang Integration ✔✔Test each module and then all of it together. Modules will need either
drivers, stubs (defined below), or both depending on what layer. 2 step approach.
Drivers ✔✔needed for integration testing when the module is not the very top module and relies
on higher modules to test it.
Stubs ✔✔needed for integration testing when the module is not the very bottom and must rely on
lower modules for testing it.
Big Bang Flaws ✔✔Not good for large systems. Does not scale well. Difficult or impossible to
isolate faults
Bottom up Integration ✔✔Need drivers to test from bottom module and move up. Good for O/O
system because you start with basic components.
Bottom up flaws ✔✔Not appropriate functionally decomposed system because they usually start
from the top. Discovering major faults can be delayed. Doesn't reveal timing errors. Not good
when there is a lot of interactions between components.
Top down Integration ✔✔Need stubs to test the top modules by making sure bottom modules will
work. Done when major functionality exists at the top level, functionally decomposed systems.
Top down flaws ✔✔Using stubs can be complex and their correctness will influence the validity
of the test. Lack of individual testing on the interior components.
Sandwich Integration ✔✔Uses both top down and bottom up approach. Key is to identify a target
level, somewhere in the middle. Everything on top is top down and everything below is bottom
up. Will need stubs and drivers.
Breadth (CPG) ✔✔number of statements within a construct
Content (CPG) ✔✔ln(reserved words + operators + operands)
Reachability (CPG) ✔✔number of operators in predicate path + 1
Inherent (CPG) ✔✔assigned value based on type of control structure
Total ✔✔summation of breadth, content, reachability, inherent, with scaling factors associated
with each one.
Different Functional Tests ✔✔Test to pass,
Test to fail,
Blackbox,
Dynamic
(details below)
Test to pass details ✔✔Done first to make sure it can work with simple test cases. Not trying to
find bugs or break it
Test to fail details ✔✔After test to pass. The purpose is to break the software and find bugs.
Dynamic ✔✔Tests done with the software running
[Show More]
.png)
.png)
