|
|
Overview
The Error Finding/Bug Detection is a process comparable to testing consisting of searching through source code for coding constructs suspect of being high priority bugs or violate important coding practices. This process can identify failures and additional problems that have escaped the code inspection or testing processes.
This service does an identification process for two categories of problems: software defects / errors and violations of important coding practices. The problems found are categorized by severity and importance. The service delivers the results in a report.
Examples of condition types searched for and analyzed to attempt to identify bugs include:
|
Error Condition Detected
|
|
Assignments in conditionals where no method invocation is performed (class instantiation)
|
|
Empty statement bodies on non-loops
|
|
Logical expressions whose value is constant
|
|
Downward Casting
|
|
Functions that return a pointer to the local stack
|
|
Conversions of types from a source that is larger than the target into the target type
|
|
Switch Statements with no Default case, Dangling Else-Ifs
|
|
Switch Statements Without a Break
|
|
Un-initialized Persistent Variable
|
|
Unsafe Pointer Conversions (Different depths, change in precision)
|
|
Deallocation of non-allocated memory
|
|
Memory Corruption Errors, Uninitialized memory read
|
Testing finds serious errors in the source code only by actually executing the paths. Insufficient testing will leave the errors undetected and usually found first by a customer. While testing is an extremely common approach to identification of errors in a software system it is often true that one error can obscure the errors that would occur behind it in the control flow of an application. This elongates the process of discovering all the errors.
Techniques like the Error Finding / Error Detection process are finding errors statically not requiring the application to run, eliminating the problems of traditional testing.Efficiency is increased when automated through rapid filtering of suspect problems into relevant errors to have achieved value without consuming the organization's staff and resources.
Objectives
- Perform Analysis
- Analysis technology is run producing a list of software error suspects.
- Identify Potential Defect Locations (Characterization / Assess)
- Code flagged as a suspected violation is assessed (characterized) and prioritized. The list of flagged code is refined into suspects that are bugs, false hits, and low priority issues. Bugs are further refined into categories of severity. The output of such a process is a summary of findings and a listing of errors. The list of errors is available in electronic formats to facilitate remedia/tion.
- Interpret Cause
- Evaluate defects and errors identified.
Deliver Analysis
- Produce and deliver a report of defects and errors identified, and conclusions drawn from interpretation of cause analysis.
Deliverables
- A report that includes:
- Identification of locations in the software indicated by analysis techniques as defects and errors.
- Interpretation of suspects to identify:
- Cause analysis-indicating problems that are actual defects and their impact.
- Severity evaluation indicating importance of repair.
- Software process implications of defects and errors identified.
Customer Profiles
- Customers releasing a product on a critical path, which affords minimal cycle time for a thorough testing or code inspection activity.
- Customers needing a scheduled interval based Error / Defect detection service, which purges their system on a frequent basis.
- Customers requiring Error / Defect detection and value process improvement to avoid software defects creeping into their systems.
Service Options Available For Error Detection
- e-Factory: Remote access to customer site to perform this service.
- Factory: Perform this service in proServices' Trenton, NJ Factory.
- On-Site: Perform this service at the customer's site.(not available)
Service Qualifications
- Service is offered for the following programming languages: C, C++ and Java written for any platform.
- Factory -The COTS products interfaces are required at build time (i.e. class library header/import files). This requires the ability for header files to be exported to the factory or they must be owned by proServices.
|
|
