There are variuos names for the same thing. Some call it software inspection, which also could extend to the design and its documentation, some call it code inspection which relates more to the source code. A third name would be Fagan Inspection, called after the person who invented this quality assurance and testing method.
Code inspections are a highly efficient test method which can not be substituted by any other test methods. It is time consuming but according to statistics it will find up to 90% of the contained errors, if done properly. However it all depends on the methods and checks applied and on the diligence of the inspectors. It must not be confused with the so called "code review" or "walk through" which is usually done in a single meeting lasting for a couple of hours. A proper code inspection may take several days and needs the help of tools to browse the symbols in order to find the places where they are used. The code review can be used in addition to e.g. to generated acceptance of a software package by the integrators, but it must not be a substitute for a proper inspection. Proper inspections can be applied for almost all work products in the software life cycle. At the first glance they may look very time consuming. But statistical evaluations have shown that over the whole life cycle of the software development they even save resources and thus money and improve the quality of the product.
![20100929_c99e11055b4275bdf2cexSKRXH7dWCJs.gif](https://i-blog.csdnimg.cn/blog_migrate/bf45611ea99d8660ed9112b23ebd97d2.gif)
Source of the diagram.gif
Source of the diagram: Michael Fagan
Most people are not aware that the manual static testing methods i.e. inspections, reviews and walk throughs are defined in the "IEEE Standard for Software Reviews". This is the IEEE 1028-1997 standard. I want to give a short overview on the main definitions in this standard, however I will not discuss the "Management Review" which is in the widest sense a check of a project's performance and the related documents. I will also omit a discussion of the Audits described in the standard, which a more relalted to having external checks on work products and processes. I will focus on the review techniques for technical work products as they are typically used within a company. I also want to point out the problems involved with these methods and make an attempt to present some solutions for these problems.
Code inspections are a highly efficient test method which can not be substituted by any other test methods. It is time consuming but according to statistics it will find up to 90% of the contained errors, if done properly. However it all depends on the methods and checks applied and on the diligence of the inspectors. It must not be confused with the so called "code review" or "walk through" which is usually done in a single meeting lasting for a couple of hours. A proper code inspection may take several days and needs the help of tools to browse the symbols in order to find the places where they are used. The code review can be used in addition to e.g. to generated acceptance of a software package by the integrators, but it must not be a substitute for a proper inspection. Proper inspections can be applied for almost all work products in the software life cycle. At the first glance they may look very time consuming. But statistical evaluations have shown that over the whole life cycle of the software development they even save resources and thus money and improve the quality of the product.
![20100929_c99e11055b4275bdf2cexSKRXH7dWCJs.gif](https://i-blog.csdnimg.cn/blog_migrate/bf45611ea99d8660ed9112b23ebd97d2.gif)
Source of the diagram.gif
Source of the diagram: Michael Fagan
Most people are not aware that the manual static testing methods i.e. inspections, reviews and walk throughs are defined in the "IEEE Standard for Software Reviews". This is the IEEE 1028-1997 standard. I want to give a short overview on the main definitions in this standard, however I will not discuss the "Management Review" which is in the widest sense a check of a project's performance and the related documents. I will also omit a discussion of the Audits described in the standard, which a more relalted to having external checks on work products and processes. I will focus on the review techniques for technical work products as they are typically used within a company. I also want to point out the problems involved with these methods and make an attempt to present some solutions for these problems.
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/11379785/viewspace-675909/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/11379785/viewspace-675909/