Trong chuyên mục này, các bạn chỉ được post các thông tin liên quan đến ISEB
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
"On November 4th the system did fail. This was caused by a minor programming error that caused the system to "crash", the automatic change over to the back up system had not been adequately tested, and thus the whole system was brought down".
Extract from the main conclusions of the official report into the failure of the London Ambulance Service 's Computer Systems on October 26th and 27th and November 4th 1992.
Static testing techniques is used to find errors before software is actually executed and contrasts therefore with dynamic testing techniques that are applied to a working system. The earlier we catch an error, the cheaper it is, usually, to correct. This module looks at a variety of different static testing techniques. Some are applied to documentation (e.g. walkthroughs, reviews and Inspections) and some are used to analyze the physical code (e.g. compilers, data flow analyzers). This is a huge subject and we can only hope to give an introduction in this module. You will be expected to appreciate the difference between the various review techniques and you will need to be aware of how and when static analysis tools are used.
After completing this module you will:
- Understand the various review techniques that you can apply to documentation and code.
- Appreciate the difference between walkthroughs, formal reviews and inspections.
4.3 REVIEWS AND THE TEST PROCESS
4.3.1 What is a review?
A review is a fundamental technique that must be used throughout the development lifecycle. Basically a review is any of a variety of activities involving evaluation of technical matter by a group of people working together. The objective of any review is to obtain reliable information, usually as to status and/or work quality.
4.3.2 Some history of reviews
During any project, management requires a means of assessing a measuring progress. The so-called progress review evolved as means of achieving this. However, results of those early reviews proved to be bitter experiences for many project managers. Just how long can a project remain at 90% complete? They found that they could not measure 'true' progress until they had a means of gauging the quality of the work performed. Thus the concept of the technical review emerged to examine the quality of the work and provide input to the progress reviews.
4.3.3 What can be reviewed?
There are many different types of reviews throughout the development life cycle. Virtually any work produced during development can be (and is) reviewed. This includes, requirements documents, designs, database specifications, designs, data models, code, test plans, test scripts, test documentation and so on.
4.3.4 What has this got to do with testing?
The old fashioned view that reviews and testing are totally different things stems from the fact that testing used to be tacked onto the end of the development lifecycle. However as we all now view testing as a continuous activity that must be started as early as possible you can begin to appreciate the benefits of reviews. Reviews are the only testing technique that is available to us in the early stages of testing. At early stages in the development lifecycle we obviously cannot use dynamic testing techniques since the software is simply not ready for testing.
4.4 TYPES OF REVIEW
Walk-through, informal reviews, technical reviews and Inspections are fundamental techniques that must be used throughout the development process. All have their strengths and weaknesses and their place in the project development cycle. All four techniques have some ground rules in common as follows:
4.5 REVIEW TEAM SIZE AND COMPOSITION
Problems with small teams must be avoided; bring in extra people, (perhaps use the Testing Team) to bring extra minds to bear on the issues.
Opinion is often divided as to whether or not the author should participate in a review. There are advantages to both scenarios. Since specifications and designs must be capable of being understood without the author present, an Inspection without them tests the document. Another reason for excluding the author from the review is that there should be team ownership of the product and team responsibility for the quality of all the deliverables, maintaining ownership via the author runs against this.
4.6 TYPE 1, 2 AND 3 REVIEW PROCESSES
Review process is both most effective and universal test method and management needs to make sure that review process is working as effectively as possible. Useful model for manager is 1,2,3 model.
4.6.1 Make reviews incremental
Whilst use of 1, 2, 3 model will improve review technique, reviewing task can be made easier by having incremental reviews throughout product construction.
This will enable reviewers to have more in-depth understanding of product that they are reviewing and to start construction type 3 material.
4.6.2 General review procedure for documents
Test team will need general procedure for reviewing documents, as this will probably form large part of team's work.
1. Establishing standards and format for document.
2. Check contents list.
4.6.3 Report on review
Be sensitive to voice of concerned but not necessarily assertive tester in team; this person may well have observed a fault that all others have missed. It should not be that person with load voice or strong personality is allowed to dominate.
This section on Inspections is based on an edited version of selected extracts from Tom Gib and Dorothy Graham's book [Gib, Graham 93].
Michael E. Fagan at IBM Kingston NY Laboratories developed the Inspection technique. Fagan, a certified quality control engineer, was a student of the methods of the quality gurus W. Edwards Deming and J. M. Juran.
4.7.2 Reviews and walk-through
Reviews and walkthroughs are typically peer group discussion activities - without much focus on fault identification and correction, as we have seen. They are usually without the statistical quality improvement, which is an essential part of Inspection. Walkthroughs are generally a training process, and focus on learning about a single document. Reviews focus more on consensus and buy-in to a particular document.
4.7.3 Statistical quality improvement
The fundamental differences between Inspection and other review methods is that Inspection provides a tool to help improve the entire development process, through a well-known quality engineering method, statistical process control, [Godfrey, 1986].
4.7.4 Comparison of Inspection and testing
Inspection and testing both aim at evaluating and improving the quality of the software engineering product before it reaches the customers. The purpose of both is to find and then fix errors, faults and other potential problems.
4.7.5 Differences between Inspection and testing
Inspection can be used long before executable code is available to run tests. Inspection can be applied mud earlier than dynamic testing, but can also be applied earlier than test design activities. Test can only be defined when a requirements or design specification has been written, since that specification is the source for knowing the expected result of a test execution.
4.7.6 Benefits of Inspection
Opinion is divided over whether Inspection is a worthwhile element of any product 'development' process. Critics argue that it is costly; it demands too much 'upfront' time and is unnecessarily bureaucratic. Supporters claim that the eventual savings and benefits outweigh the costs and the short-term investment is crucial for long-term savings.
4.7.7 Costs of Inspection
The cost of running an Inspection is approximately 10% - 15% of the development budget. This percentage is about the same as other walkthrough and review methods. However, Inspection finds far more faults for the time spent and the upstream costs can be justified by the benefits of early detection and the lower maintenance costs that result.
4.7.8 Product Inspection steps
- The Inspection process is initiated with a request for Inspection by the author or owner of a task product document.
- The Inspection leader checks the document against entry criteria, reducing the probability of wasting resources on a product destined to fail.
4.9.2 McCabe’s complexity metric
McCabe's complexity metric is a measure of the complexity of a module's decision structure. It is the number of linearly independent paths and therefore, the minimum number of paths that should be tested. The metric can be calculated in three different ways. The number of decisions plus one, the number of 'holes' or connected regions (bearing in mind that there is a fictitious link between the entry and exit of the program), or thirdly the equation:
Các bạn vui lòng tải nội dung đầy đủ ở file đính kèm