80
James D. Mooneycover most expected situations and lead to a reasonably high confidence level in the correct operation of the software.
Guidelines for the testing activity are.
Develop a reusable test plan. A written test plan is always important.
For portable software the test plan should be designed to be reused for new ported implementations. Based on design
choices and experience to date, the plan should cleanly separate tests of system-dependent modules from tests of the modules that are common to all (or many)
implementations. It should be anticipated that after porting, the same tests will be applicable to the common modules (and should produce the same results.
Document and learn from errors. A record should be kept, as usual,
of all errors found, and the debugging strategies used to correct them. Again these records should be divided between common and system-dependent parts. Errors that have been corrected in common modules should not usually recur after a port.
Don’t ignore compiler warnings. Warnings from a compiler are often taken lightly, since they generally indicate a construct that is questionable but not considered a fatal error.
If the program seems to work, the warning maybe ignored. It is highly likely, though, that the problem identified by warnings means an increased likelihood of failure when running in a different environment. An unitialized variable maybe
harmless in one implementation, but cause incorrect behavior in the next.
Test portability itself. If portability has been identified as an intended attribute in the specifications, it is necessary to test if this goalhas been achieved. This may require
the use of portability metrics, discussed briefly below.
4.
Share with your friends: 
