2. Agenda
● Bugs in Software
● Why do bugs occur?
● Product Quality
● Kind of Tests
● Bug Finding Techniques
● Static Analysis
● Static Analysis Challenges
● Static Analysis Philosophy
● Our Accuracy Goal
● Bugs vs Style
● Tools used for efficient development and achieve quality
3. Bugs in software
• Programmers are smart
• We have good techniques (e.g., unit testing, pair
programming, code inspections) for finding bugs early
So, most bugs remaining in production code must be
subtle, and require sophisticated techniques to find.
• Right?
4. Why do bugs occur?
● Everybody makes dumb mistakes.
● Java (and similar languages) have very large standard
libraries.
● Many possibilities for confusion and misuse.
● Many possibilities for latent bugs (e.g., hashcode/equals).
● Programmers play fast and loose with threads.
5. Product Quality
Lots of obvious bugs find their way into production software
● Testing and code inspections will not find every bug.
● Very hard to get high test coverage for a large system
● Limits to frequency, completeness of code inspections
● Techniques to find more bugs automatically are valuable
Quality is the responsibility of everyone on the team.
6. What kind of tests do we follow to achieve
Quality?
7. Bug Finding Techniques
● Code Inspections
- Effective but have to be applied manually.
● Dynamic Techniques (Testing, Assertions)
- Examine runtime behaviour and examine paths that are
actually executed(advantages and disadvantages).
● Static Techniques
- Explore abstractions of all possible behaviours.
- Strongest formal proof of correctness (prohibitively
difficult).
- Partial verification demonstrates that some property holds
for all executions.
- Unsound techniques can identify “probable” bugs will miss
some real bugs and may give inaccurate warnings.
8. Static Analysis
Let the computer figure out where (some of) the bugs
are.
• Tools on static analysis to find bugs- Checkstyle,
PMD, FindBugs, ESC/Java, Cqual, apart from other
tools, papers, techniques etc,.
We think it should be!
9. Static Analysis Challenges
● Fundamental limits to static analysis
● Nontrivial properties of programs are undecidable
● Be consistently conservative: could choose to
● Never miss a real bug (but report some false positives)
● Never report a false positive (but miss some real bugs)
● Both false positives and false negatives are possible
10. Static Analysis philosophy
Two approaches to devising a static analysis to find bugs:
1. Given an analysis technique, figure out what bugs it
could find
2. Given a bug, figure out an analysis that could be used to find
occurrences of similar bugs
11. Accuracy Goal
Our goal is that at least 70% of high and medium priority
warnings should be real bugs.
• We manually classified warnings produced by tool for
several real applications and libraries.
• In general, we came close to achieving our goal.
12. Bugs vs Style
It is important to distinguish bug checkers from style
checkers-
● Style checkers warn about dubious or dangerous coding
idioms: however, instances of those idioms may not be
particularly likely to be a bug
● Bug checkers warn about code idioms that are likely to be
actual bugs.
● Style checkers are useful for enforcing consistent coding
standards and help prevent certain kinds of bugs.
13. Style checker
By following a coding standard, we ensure that the source code
is predictable in its semantics and understood in the same
manner across the development team.
We make a clear distinction between standards related to style
and standards related to best practices.
Examples of style standards are where to place braces and how
to use whitespace.
Examples of best practices are when to use interfaces and how
to implement an equals method.
14. Tools used for fixing Bugs and
following Style
● Eclipse
● PMD
● FindBugs
● EclEmma
15. PMD
● Syntactic checks on program source code
● No dataflow component
● Mainly detects violations of stylistic conventions
– May be symptomatic of deeper problems
● Contains a number of rule sets that define detectors for
different style violations
– Also tool for detecting suspected cut-and-paste code
● Extensible – either using Java or XPath
● Documentation contains details for using and extending
rulesets
16. FindBugs
● Static Analysis tool that is based on the notion of bug patterns
– Code idioms that are likely to be errors
– i.e. does not follow the usual correct practice of language or
API usage
● Similar to automated code inspection
● One of its aims is to raise awareness of the large number of
easily detectable bugs that are not caught by traditional QA
approaches.
● Open Source, contains detectors for bug patterns
– implemented using BCEL (bytecodeanalysis and instrumentation
library) and the Visitor design pattern
– Each detector visits each class of the application to be analysed
17. FindBugs
● Rough categories of detectors
– Class Structure and Inheritance Hierarchy
– Ignore code
● Linear Code Scan
– Scan bytecodeof methods of analysed class and use
heuristics to approximate control flow
● Control Sensitive
– Use accurate control flow graph
● Dataflow
– Most
19. Example
if ( out == null ){
try {
out.close() ;
} catch (IOException e) {
}
}
As I said we are human beings and could make mistakes
like the example above.
20. What can FindBugs do?
● Correctness bugs
Null Pointer Dereference
Return value ignored
● Multithreaded correctness bugs
Inconsistent synchronization
Unconditional wait
● Malicious code vulnerabilities
Mutable static
Returning a reference to an internal array
21. EclEmma
● EclEmma is a free java tool that calculates the percentage of
code accessed by tests. It can be used to identify which parts
of the java program are lacking test coverage.
● Our goal is to acheive > 80% of coverage
22. Conclusion
● PMD and FindBugs helps find out bugs and follow coding
standard during the development stage.
● EclEmma is used for measuring the code coverage.
● The number of bugs found in the test environment or
production becomes lesser by using these tools.