Static and Dynamic Testing (静态测试和动态测试)

Static and Dynamic Testing

Two other terms used to describe how software is tested are static testing and dynamic testing. Static testing refers to testing something that's not running examining and reviewing it. Dynamic testing is what you would normally think of as testing running and using the software.

The best analogy for these terms is the process you go through when checking out a used car. Kicking the tires, checking the paint, and looking under the hood are static testing techniques. Starting it up, listening to the engine, and driving down the road are dynamic testing techniques.

Static Black-Box Testing: Testing the Specification

Testing the specification is static black-box testing. The specification is a document, not an executing program, so it's considered static. It's also something that was created using data from many sources usability studies, focus groups, amrketing input, and so on. You don't necessarily need to know how or why that information was obtained or the details of the process used to obtain it, just that it's been boiled down into a product specification. You can then take that document, perform static black-box testing, and carefully examine it for bugs.

Earlier you saw an example of a product specification for the Windows Calculator. This example used astandard written document with a picture to describe the software's operation. Although this is the most common method for writing a spec, there are lots of variations. Your development team may emphasize diagrams over words of it may use a self-documenting computer language such as Ada. Whatever their choice, you can still apply all the techniques presented in this chapter. You will have to tailor them to the spec format you have, but the ideas are still the same.

What do you do if your project doesn't have a spec? Maybe your team is using the bing-bang model or a loose code-and-fix model. As a tester, this is a difficult position. Your goal is to find bugs early, ideally finding before the software is coded. but is your product doesn't have a spec, this may seem impossible to do. Although the spec may not be written down, someone, os several people, know what they're trying to build. It may be the developer, a project manager, or a marketer. Use them as the walking, talking, product spec and apply the same techniques for evaluating this "mental" specification as though it was written on paper. You can even take this a step further by recording the information you gather and circulating it for review.

Tell your project team, "This is what I plan to test and submit bugs against." You'll be amazed at how many details they'll immediately fill in.

TIP

You can test a specification with static black-box techniques no matter what the format of the specification. It can be a written or graphical document or a combination of both. You can even test an unwritten specification by questioning the people who are designing and writing the software.