Prevention Techniques:
Adequate Developer Staffing in Test Phase- Most developers would rather develop new code than fix defects, therefore it all too often happens that there are not enough developers to fix bugs as fast as the test group can find them. This leads to the software code being delivered with defects not yet fixed. Solution is to plan for bugs to be found and adequate resources retained to fix at least the high priority ones prior to release.
Adequate Ratio of Testers to Developers- Adequate developer to tester ratios can vary with industry and project phase, but a general rule of thumb is to have no less than 1 tester for every 5 developers. A higher ratio of developers to testers may cause inadequate testing to be accomplished, causing the product to be released with a high percentage of latent defects.
Adequate Staffing in Development Phase- Lack of sufficient staff may preclude assuring this attribute is not in the software. Using an estimation tool based on past performance may help allocate sufficient staff at appropriate times to preclude this attribute. However simply adding staff, especially late in the project may not help. (Brook's Law)
Coding Standards- Coding standard could limit the techniques used to allocate and de-allocate memory to those that are less error prone. Choice of the language used can also help lessen the probability of memory leaks, example C++ versus Java (garbage collection to free unused memory).
Estimation Tool or Technique- Lack of sufficient time may preclude assuring this attribute is not in the software. Using an estimation tool based on past performance may help allocate sufficient time to preclude this attribute.
Detection Techniques:
Automated Nightly Build and Test- Nightly functional testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Code and Test Peer Inspections- Peer reviews may catch exits where allocated memory has not been released.
Continuous Integration- Continuous integration testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Dynamic Analysis- Dynamic analyzers included leak detectors which can detect memory not being returned to the heap.
Functional / Regression Testing- Functional testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Fuzzing or Automated Random Testing- Random testing, if allowed to run for long periods of time may be a good approach to find memory leaks or resources not available or heavily loaded at certain times.
Graphics User Interface (GUI) Testing- GUI tests that run many hours automatically may be able to find memory leaks with show up as memory low messages or sytem crashes.
Load, Stress, Failover, Performance Test- LSP testing may show how the system handles situations which meet or exceed specifications (number of users, amount of data stored, transfer rates, etc.) to determine if the system meets specification and degrades gracefully beyond specified levels of performance. Unhandled exceptions may be exposed under these types of tests which lock up the system (for instance running out of memory due to a memory leak).
Negative Testing- Negative testing includes deliberately inputting incorrect information into the system under test which should produce meaningful error messages that correlate to the negative inputs. System lock ups or crashes due to memory leaks may be detected and corrected so that an error message will be issued and/or the system will degrade gracefully.
Release Testing (alpha, beta)- Release testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Smoke (Check In) Testing- Smoke testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Static Analysis- Static analysis can detect situations where memory is allocated and not deallocated.
Adequate Developer Staffing in Test Phase- Most developers would rather develop new code than fix defects, therefore it all too often happens that there are not enough developers to fix bugs as fast as the test group can find them. This leads to the software code being delivered with defects not yet fixed. Solution is to plan for bugs to be found and adequate resources retained to fix at least the high priority ones prior to release.
Adequate Ratio of Testers to Developers- Adequate developer to tester ratios can vary with industry and project phase, but a general rule of thumb is to have no less than 1 tester for every 5 developers. A higher ratio of developers to testers may cause inadequate testing to be accomplished, causing the product to be released with a high percentage of latent defects.
Adequate Staffing in Development Phase- Lack of sufficient staff may preclude assuring this attribute is not in the software. Using an estimation tool based on past performance may help allocate sufficient staff at appropriate times to preclude this attribute. However simply adding staff, especially late in the project may not help. (Brook's Law)
Coding Standards- Coding standard could limit the techniques used to allocate and de-allocate memory to those that are less error prone. Choice of the language used can also help lessen the probability of memory leaks, example C++ versus Java (garbage collection to free unused memory).
Estimation Tool or Technique- Lack of sufficient time may preclude assuring this attribute is not in the software. Using an estimation tool based on past performance may help allocate sufficient time to preclude this attribute.
Detection Techniques:
Automated Nightly Build and Test- Nightly functional testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Code and Test Peer Inspections- Peer reviews may catch exits where allocated memory has not been released.
Continuous Integration- Continuous integration testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Dynamic Analysis- Dynamic analyzers included leak detectors which can detect memory not being returned to the heap.
Functional / Regression Testing- Functional testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Fuzzing or Automated Random Testing- Random testing, if allowed to run for long periods of time may be a good approach to find memory leaks or resources not available or heavily loaded at certain times.
Graphics User Interface (GUI) Testing- GUI tests that run many hours automatically may be able to find memory leaks with show up as memory low messages or sytem crashes.
Load, Stress, Failover, Performance Test- LSP testing may show how the system handles situations which meet or exceed specifications (number of users, amount of data stored, transfer rates, etc.) to determine if the system meets specification and degrades gracefully beyond specified levels of performance. Unhandled exceptions may be exposed under these types of tests which lock up the system (for instance running out of memory due to a memory leak).
Negative Testing- Negative testing includes deliberately inputting incorrect information into the system under test which should produce meaningful error messages that correlate to the negative inputs. System lock ups or crashes due to memory leaks may be detected and corrected so that an error message will be issued and/or the system will degrade gracefully.
Release Testing (alpha, beta)- Release testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Smoke (Check In) Testing- Smoke testing may detect memory leaks, especially if some of the tests are long running or repetitive.
Static Analysis- Static analysis can detect situations where memory is allocated and not deallocated.
No comments:
Post a Comment