Structural (Non-functional) Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 124

8.3 SECURITYTESTING
Consider leveraging equivalence classes for security behavior testing. Most se-
curity systems have different types or levels of security relating to end user
processing restrictions based on job roles. For example, a typical three-level
security system would define (1) clerks and other employees who just need to
view data at security level 1, (2) clerk managers who need to view and update
at security level 2, and (3) security administrators at security level 3 to grant
and deny permissions to clerks at security level 1 and clerk managers at security
level 2.
A brute force approach to testing these security behaviors would be to col-
lect all of the user ID/password pairs in the company (very sensitive corporate
information) and test each user ID/password pair to verify that the user ID under
test is authorized and has the appropriate security access. In smaller companies,
this could require testing hundreds of ID/password pairs. In larger companies,
this could require testing thousands of pairs. Applying equivalence class analy-
sis to the situation would allow you to choose may be 20-50 ID/password pairs
for each level of security. Remember that in each equivalence class of ID/pass-
words by security level, you want to choose some valid ID/password pairs for the
level (positive testing) and some invalid ID/password pairs for the level (negative
testing).
Security for the new application may include encryption of passwords, as well as
d at a t hat may b e sent or re ceive d by t he appl icat ion. Test i ng te ch n iques for encr y pt ion
are beyond the scope of this textbook; however, we have provided a starting point for
further reading. [37-41]
Once ID/password combinations, ID/password pair security levels, and data
encryption have been tested, there is one remaining area of security concern. As
with all software capabilities, security comes with a performance price tag. It takes
a fi nite amount of time (greater than zero) to complete a security activity every
time it is needed. Some software designers prefer to do security checking only at
the start of a user session. Other software designers prefer to do security checking
before each activity a user invokes. Still other software designers use a combina-
tion of initial checking and ongoing checking during end-user sessions. Regard-
less of the approach that the software designer takes to implementing security, the
tester needs to measure the application's performance degradation specifi cally due
to security. We have seen companies decide not to test security performance but
to “turn on” security just before the system goes “live” because security was not
expected to add noticeable processing overhead. These companies then faced the
following question midday the fi rst day the new application is live, “How can we
disable security until we fi nd out what is making the application run so slow in
production?”
Although performance testing is the subject of the next chapter, it is reasonable
to raise the security testing concern here and encourage the software development
team to turn on full security as early in the application as practical both from a
regression standpoint and a performance standpoint.