Embed Size (px)
Citation preview
©The McGraw-Hill Companies, 2006
Chapter 9
Software quality
©The McGraw-Hill Companies, 2006
Software Quality
There are many desirable features of a piece of software.
We will concentrate on the following:•maintainability;•reliability;•robustness;•usability.
©The McGraw-Hill Companies, 2006
The waterfall approach
• Until a few decades ago software developers went through a number of phases and complete each of these before moving on to the next.
• This approach to software development was often called the waterfall model.
©The McGraw-Hill Companies, 2006
The RAD approach
• Involves doing the activities described above a "little bit at a time";
©The McGraw-Hill Companies, 2006
Maintainability
• The requirements of an application are rarely fixed and often change over time.
• Maintaining a system refers to the need to update an existing system to reflect these changing requirements.
• Code should be designed in such a way as to make these changes easier rather than harder.
©The McGraw-Hill Companies, 2006
Documentation
• For a software system to be easy to maintain, the software design needs to be clearly documented.
• When developing object-oriented programs, this design documentation should include:
- complete class diagrams;
- clear method definitions (parameter and return types, plus pseudocode when appropriate).
©The McGraw-Hill Companies, 2006
Guidelines for in-code documentation
When writing in-code documentation you should always include the following:
•comments to make the meaning of your code clear;•meaningful data names;•constants in place of fixed literal numbers;•consistent and clear indentation.
©The McGraw-Hill Companies, 2006
Javadoc
• Sun's JDK contains a tool, Javadoc, that allows you to generate professional documentation for classes that you write.
• In order to use this tool you must comment your classes in the Javadoc style.
©The McGraw-Hill Companies, 2006
©The McGraw-Hill Companies, 2006
Reliability
• A reliable program is one that does what it is supposed to do, in other words what it is specified to do.
• When attempting to build a program, two kinds of errors could occur: – compile-time errors;– run-time errors.
©The McGraw-Hill Companies, 2006
Compile-time errors
• Compile-time errors occur during the process of compilation.
• Examples of these kinds of mistakes in Java include:– missing semi-colons;– forgetting to close a bracket;– being inconsistent with names and/or types;– attempting to access a variable/object without having
first initialized it.
©The McGraw-Hill Companies, 2006
Verification
• Involves running your application in order to trap errors you may have made in program logic.
• A Java application typically consists of many classes working together.
• Testing for such errors will start with a process of – unit testing (testing individual classes) followed by – integration testing (testing classes that together
make up an application).
©The McGraw-Hill Companies, 2006
Unit testing
• All applications require a class with a main method before they can be run.
• This new class then acts as the driver for the original class.
• A driver is a special program designed to do nothing except exercise a particular class.
• If you look back at all our previous examples, this is exactly how we tested individual classes.
• When testing classes in this way, every method of the class should be tested.
©The McGraw-Hill Companies, 2006
Dummy classesDummy classes
• If you need to unit test a given class that relies upon the development of another class to which you do not have access, you can develop your own dummy class in place of the missing class.
• A dummy class is one that mimics an actual class in order for testing to proceed.
©The McGraw-Hill Companies, 2006
During integration testing check for the following compilation errors:
• All methods that are called must have an implementation in the receiving class
• The names of method calls must match the names of methods in the receiving class
• Parameter list of a method call must match the parameter list of the method in the receiving class
• The expected types of values returned from the method call must match the return type of the method in the receiving class
©The McGraw-Hill Companies, 2006
Black box testing
©The McGraw-Hill Companies, 2006
Testing equivalent groups: an example
©The McGraw-Hill Companies, 2006
Test data generated by examining equivalent groups of
input
• Here, there are eight equivalent input groups.
• When testing this method you should test at least one mark from each equivalent group
©The McGraw-Hill Companies, 2006
Boundary testing
• In addition to taking sample test cases from each equivalent group, the boundary values in particular should be tested.
• In this case the following boundary values should all be tested as well as the sample from each equivalent group identified earlier:
–1, 0, 1, 29, 30, 31,39, 40, 41,49, 50, 51,59, 60, 61, 69, 70, 71, 99, 100, 101
©The McGraw-Hill Companies, 2006
White box testing
©The McGraw-Hill Companies, 2006
The test log
©The McGraw-Hill Companies, 2006
Robustness
• A program is said to crash when it terminates unexpectedly.
• A robust program is one that doesn't crash even if it receives unexpected input values.
©The McGraw-Hill Companies, 2006
How robust is the SalesStaff class?
©The McGraw-Hill Companies, 2006
A driver for the SalesStaff class: an example of stress testing
©The McGraw-Hill Companies, 2006
Fixing the problem
©The McGraw-Hill Companies, 2006
Usability
• The usability of a program refers to the ease with which users of your application can interact with your program.
• For example, adding a help option into your menus
©The McGraw-Hill Companies, 2006
Escape sequencesEscape sequences
©The McGraw-Hill Companies, 2006
Using the DecimalFormat objects to format decimal numbers
The instructions above would lead to the following values being displayed:
before 12345.6789
after 012,345.679
©The McGraw-Hill Companies, 2006
Optional digits (using the # symbol)
This would result in the following output:
before 12345.6789
after 12,345.679
©The McGraw-Hill Companies, 2006
Graphical user interfaces
