Regression testing of security products

Software testing
How to perform regression testing when security patches are integrated into the COTS components? I also want to know the procedure for minimizing the selection of test cases for these patches. Even if patch management tools are available, it does not focus much on regression testing, it seems.

Answer Wiki

Thanks. We'll let you know when a new response is added.

Well, the first thing that crosses my mind is to ask “How did you test the original installation?”

Regression testing is usually a repetition or subset of the original acceptance testing, depending on what changed.

Can you provide more detail to give us a better idea of what you’ve already done?


Discuss This Question: 1  Reply

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Bobkberg
    I got a private reply from gprakas74 which I'll quote here (nothing confidential), so that others may see what he or she is getting at. =================== Quote =================== Well. Suppose you upgrade an application with security patch. Now, a change in the application would occur at various parts (sub-components). It is noteworthy to identify that modified sub-components and apply the regression test for that part only by selecting that specific test cases. (COUGAR process). The problem is that we are not having the source code of the application and security products as they are third party components. Hence, having the binary codes of the components and performing dynamic analysis of the system, selection of subset of regression test suite should be prefered. But that too could be done with the identification of the failure in the execution process. Now, I want to know that any security patches added to the COTS components could be able to perform minimizing the selection of regression test in an efficient way without accessing the source code and know failure scenarios in advance. ================= End Quote =================== The first place I'd start is with the release notes for the patch - since those often provide details about specific fixes - at least to the level of the function of the fixed areas. If you have a support contract (and are therefore more of a known quantity to the vendor), you should contact the support organization to see if you can get a better description of what was fixed and what was impacted. A third method - which borders on violating the license agreement, but if carefully done can be skirted... is to do a file inventory before and after the patch application, and note which files have changed in size or modification date. My general rule of thumb is that most bug fixes involve added code, so I just look at what got larger. If you know what a given module does, this will give you a clue. Get a copy of the "strings" utility and dump out the text and unicode messages before and after patching, and compare the messages. This can also suggest the function of each module. I hope this helps you, Bob
    1,070 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: