Card and Glass introduced three types of software design complexity that can also be used in testing. These are discussed below.

Structural Complexity

It is defined as $$ S(m)=f_{\text {out }}^{2}(m) $$

where S is the structural complexity and $f_{\text {out }}(m)$ is the fan-out of module $m .$

This metric gives us the number of stubs required for unit testing of the module $m.$ Thus, it can be used in unit testing.

Data Complexity

This metric measures the complexity in the internal interface for a module $m,$ and is defined as

$$ D(m)=v(m) /\left[f_{\text {out }}(m)+1\right] $$

where $v(m)$ is the number of input and output variables that are passed to and from module $m.$

This metric indicates the probability of errors in module $m.$ As the data complexity increases, the probability of errors in module $m,$ also increases. For example, module $X,$ has 20 input parameters, 30 internal data items, and 20 output parameters. Similarly, module $Y,$ has 10 input parameters, 20 internal data items, and 5 output parameters. Then, the data complexity of module $X,$ is more as compared to $Y,$ therefore $X,$ is more prone to errors. Therefore, testers should be careful while testing module $X.$

System Complexity

It is defined as the sum of structural and data complexity:

$$ S C(m)=S(m)+D(m) $$

Since the testing effort of a module is directly proportional to its system complexity, it will be difficult to unit test a module with higher system complexity. Similarly, the overall architectural complexity of the system increases with the increase in each module's complexity. Consequently, the efforts required for integration testing increase with the architectural complexity of the system.