以下內容大部分來自 ron-patton-software-testing
PART II Testing Fundamentals
Chapter 4 Examining the Specification
1. Can a software tester perform white-box testing on a specification?
- Yes, if the tester is involved with the process used in defining the specification. He could attend the focus groups, usability studies, and marketing meetings to understand the underlying process being used to design the features and the overall product.
- There is a risk, though, that this information could bias the tester into assuming that the spec is correct.
2. Cite a few example of Mac or Windows standards or guidelines.
- On the Mac, deleted files go to the Trash Can. In Windows, they go to the Recycle Bin.
- Pressing F1 always displays Help for the software.
- The File menu is always the far-left menu choice in Windows.
- Selecting Help, About displays the software’s copyright, licensing, and version information.
- Ctrl+X performs a cut, Ctrl+C performs a copy, and Ctrl+V performs a paste.
3. Explain what’s wrong with this specification statement: When the user selects the Compact Memory option, the program will compress the mailing list data as small as possible using a Huffman-sparse-matrix approach.
- It uses the phrase as small as possible. This is impossible to test because it’s not quantifiable and not precise. The spec should state exactly what level of compression will take place.
- The statement also isn’t code-free. It explains how the feature will work on the algorithm level. This doesn’t belong in a requirements document. The user doesn’t care how the compaction occurs, just that it does.
4. Explain what a tester should worry about with this line from a spec: The software will allow up to 100 million simultaneous connections, although no more than 1 million will normally be used.
- Testability. It doesn’t matter that typical usage is only 1 million connections. If the specification states that 100 million are possible, the 100 million must be tested.
- The tester needs to find a way to test something this large or get the spec writer to reduce the maximum possible number to something closer to what’s typical.
Chapter 5 Testing the Software with Blinders On
1. True or False: You can perform dynamic black-box testing without a product specification or requirements document.
True. The technique is called exploratory testing, and you essentially use the software as though it’s the product spec. It’s not an ideal process, but can work okay in a pinch. The largest risk is that you won’t know if a feature is missing.
2. If you’re testing a program’s ability to print to a printer, what generic test-to-fail test cases might be appropriate?
- You could attempt to print with no paper and with jammed paper.
- You could take theprinter offline, unplug its power, and disconnect its printer cable.
- You could try printing with low ink or toner, maybe even with a missing cartridge.
- To identify all the possibilities, you could look in the printer’s operator’s manual and see what errors it supports and attempt to create all of them.
3. Start up Windows WordPad and select Print from the File menu. What boundary conditions exist for the Print Range feature?
- If you select the Pages option, the From and To fields are enabled. The obvious boundary conditions would be 0 and 99999, the smallest and largest values that the fields will hold.
- It would be wise to also test internal boundary conditions such as 254, 255, 256 and 1023, 1024, and 1025. There’s also another internal boundary condition.
- Try asking it to print pages 1 through 8 of a 6-page document. Notice that in this case, the software has to stop printing at page 6 because it’s out of data, not because it was told to stop at this page. It’s a different, internal boundary. See if you can think of more.嘗試要求它打印6頁文檔的1至8頁。 請注意，在這種情況下，該軟件必須在第6頁停止打印，因爲它沒有數據，而不是因爲被告知要在此頁面停止。 這是一個不同的內部邊界。 看看您是否還能想到更多。
4. Assume that you have a 10-character-wide ZIP code text box. What equivalence partitions would you create for this text box?:
• Valid 5-digit ZIP codes. Valid means that they’re numeric digits, not that they are existing, in-use ZIP codes—although that could be another partition.
• Valid 9-digit (9 digits with a dash) ZIP codes
• Short 5-digit. Have only 4 numbers, for example.
• Short 9-digit.
• Long 5-digit. Have 8 digits without a dash, for example. Hmm, is this the same as a short 9-digit partition?
• Long 9-digit. It may not be possible to type in more than 9 digits and a dash, but you should try.
• 10 digits, no dash. This is a little different than a long 9-digit partition.
• The dash in the wrong place.
• More than one dash.
• Non-digit and non-dash entries.
5. True or False: Visiting all the states that a program has assures that you’ve also traversed all the transitions among them.
False.
6. There are many different ways to draw state transition diagrams, but there are three things that they all show. What are they?怎麼畫狀態遷移圖
• Each unique state that the software can be in.
• The input or conditions that make it move from one state to the next.
• Conditions, variables, or output that’s produced when a state is entered or exited.
7. What are some of the initial state variables for the Windows Calculator?
- The initial displayed value and the internal partial result are set to 0.
- The memory register (MC, MR, MS, and M+ buttons) is set to 0.
- The memory system Clipboard contents (where data goes when you cut, copy, and paste) is left unchanged.
- Another initial state variable is where the Calculator appears onscreen when it’s started.
- Open up several copies of the Calculator and notice that the location isn’t always the same (at least on Windows 95/98).
- As an exercise in exploratory testing, see if you can figure out what the rules are for where the Calculator opens.
8. What actions do you perform on software when attempting to expose race condition bugs?
- You try doing multiple things at the same time. They could be related, like printing to two printers at the same time from the same application. Or, they could be unrelated, like pressing keys while a computation is taking place.
- What you want to do is force a situation where the software is competing (racing) with itself to perform some function.
9. True or False: It’s an unfair test to perform stress testing at the same time you perform load testing.
False. No test is ever unfair. Your job is to find bugs.
Chapter 6 Examining the Code
1. Name several advantages to performing static white-box testing. 靜態白盒測試優點
- Static white-box testing finds bugs early in the development cycle, making them less time-consuming and less costly to fix.
- The software testers can gain information about how the software works, what potential weaknesses and risky areas exist, and can build a better working relationship with the programmers.
- Project status can be communicated to all team members who participate in the testing.
2. True or False: Static white-box testing can find missing items as well as problems.
True. Missing items are arguably more important than normal problems and can be found through static white-box testing. When the code is checked against published standards and guidelines and carefully analyzed in formal reviews, missing items become obvious.
3. What key element makes formal reviews work?
Process. Having a process that’s followed is what makes the difference between a formal review and two pal programmers glancing over each other’s code.
4. Besides being more formal, what’s the big difference between inspections and other types of reviews?
The key difference is that with inspections, a person other than the original author of the code is the presenter. This obliges another person to fully understand the software being inspected. It’s much more effective than having others simply review the software for bugs.
5. If a programmer was told that he could name his variables with only eight characters and the first character had to be capitalized, would that be a standard or a guideline?
That would be a standard. If he was allowed to name them with no less than eight characters, but shorter was preferred, that would be a guideline.
6. Should you adopt（採用） the code review checklist from this chapter as your team’s standard to verify its code?
No! It’s provided as a generic example only. There are some good test cases in it that you should consider when you test your code, but you should research and read about other published standards before adopting your own.
Chapter 7 Testing the Software with X-Ray Glasses
1. Why does knowing how the software works influence how and what you should test?
- If you test only with a black-box view of the software, you won’t know if your test cases adequately cover all the parts of the software nor if some of the cases are redundant.
- An experienced black-box tester can design a fairly efficient suite of tests for a program but he can’t know how good that suite is without some white-box knowledge.
2. What’s the difference between dynamic white-box testing and debugging?
Both processes overlap, but the goal of dynamic white-box testing is to find bugs and the goal of debugging is to fix them. The overlap occurs in the area of isolating exactly where and why the bug occurs.
3. What are two reasons that testing in a big-bang software development model is nearly impossible? How can these be addressed?
- With the software delivered to you in one big piece, it’s difficult, if not impossible, to figure out why a bug occurs—the needle-in-a-haystack problem.
- there are so many bugs, some hide others. You’ll grab one and shout “gotcha” only to discover that the software is still failing.
- Methodically integrating and testing the modules as they are built allows you to find and fix bugs before they start to become hidden or pile on top of each other.
-將軟件交付給您的過程非常困難，即使不是不可能，也很難弄清楚爲什麼會出現錯誤-大海撈針的問題。
-有很多錯誤，有些隱藏了。 您會抓住其中一個並大喊“陷阱”，只是發現該軟件仍在發生故障。
-在構建模塊時，有條不紊地集成和測試模塊，使您能夠發現並修復錯誤，然後再將它們隱藏起來或彼此疊加。
4. True or False: If your product development is in a hurry, you can skip module testing and proceed directly to integration testing.
False! Unless, of course, your product is a module.
5. What’s the difference between a test stub and a test driver?
- A test stub is used in top-down testing. It stubs out, or substitutes itself, for a low-level module. It looks and acts to the higher-level code being tested just like the original low-level module.
- A test driver is the opposite of a stub and is used in bottom-up testing. It’s test code that replaces higher-level software to more efficiently exercise a low-level module.
6. True or False: Always design your black-box test cases first.
True. Design your test cases based on what you believe the software is supposed to do.
Then use white-box techniques to check them and make them most efficient.
7. Of the three code coverage measures described, which one is the best? Why?
- Condition coverage is the best because it also incorporates branch coverage and statement coverage.
- It assures you that all the conditions within decision logic, such as if-then statements, are verified, as well as all branches from those statements and the lines of code.
8. What’s the biggest problem of white-box testing, either static or dynamic? 白盒測試的最大問題
You can easily become biased. You might look at the code and say, “Oh, I see, I don’t need to test that case, the code handles it properly.” In reality, you were blinded by the light and eliminated necessary test cases. Be careful!