以下內容大部分來自 ron-patton-software-testing
PART III Applying Your Testing Skills
Chapter 8 Configuration Testing
1. component vs a peripheral (外圍設備)?
- Generally, a component is a hardware device internal to a PC.
- A peripheral is external to the PC.
- The lines can become blurry(模糊）, though, depending on the type of hardware.
2. How can you tell if a bug you find is a general problem or a specific configuration problem?如何確定發現的錯誤是一般問題還是特定配置問題？
- Rerun the exact same steps that revealed the bug on several different configurations.
- If the problem doesn’t occur on those, it’s very likely a configuration bug. If it occurs on the different configurations, it’s likely a general problem.
- Be careful, though. It could be a configuration problem across an entire equivalence class. For example, it’s possible that the bug shows up only on laser printers, but not inkjet printers. 不過要小心。 這可能是整個等效類的配置問題。 例如，錯誤可能僅在激光打印機上顯示，而在噴墨打印機上不顯示。
3. How could you guarantee that your software would never have a configuration problem?
- This is sort of a trick question. You’d need to ship the hardware and software together as one package, the software would only work on that hardware, and the hardware would have to be completely sealed, not having a single interface to the outside world.
4. True or False: A cloned sound card doesn’t need to be considered as one of the configurations to test.
It depends.
- A cloned hardware device is internally identical to another but has a different
name and possibly a different case. Often they are 100 percent functionally equivalent, but sometimes the device drivers are different, allowing one to support more or different features than the other. 克隆的硬件設備在內部與另一個設備相同，但是名稱不同，大小寫也可能不同。 它們通常在功能上是100％等效的，但是有時設備驅動程序是不同的，從而使一個驅動程序可以支持更多或不同的功能。
5. In addition to age and popularity, what other criteria might you use to equivalence partition hardware for configuration testing?
- Region or country is a possibility as some hardware devices such as CD-ROM players only work with CDs in their region.
- Another might be consumer or business. Some hardware is specific to one, but not the other. Think of others that might apply to your software.
6. Is it acceptable to release a software product that has configuration bugs?
- Yes. You’ll never be able to fix them all. As in all testing, the process is risk based.
- You and your team will need to decide what you can fix and what you can’t. Leaving in an bscure bug that only appears with a rare piece of hardware is an easy decision. Others won’t be as easy.
Chapter 9 Compatibility Testing
1. True or False: All software must undergo（經歷） some level of compatibility testing.
False. There will be a few rare, standalone, proprietary first versions of software out there that don’t interact with anything. For the other 99 percent of the world, though, some level of compatibility testing will be necessary.
2. True or False: Compatibility is a product feature and can have different levels of compliance.
- True. The level of compatibility that your software has is based on your customers’needs.
- It may be perfectly fine for a word processor to not be compatible with a competitor’s file format or for a new operating system to not support a certain class of gaming software.
- As a tester, you should provide input to these decisions by determining how
much work would be involved in checking that compatibility.
3. If you’re assigned to test compatibility of your product’s data file formats, how would you approach the task? 怎麼測數據文件格式兼容性
- Research whether your program follows existing standards for its files. If so, test that it meets those standards.
- Equivalence partition the possible programs that would read and write your program’s files.
- Design test documents with representative samples of the types of data that your program can save and load.
- Test the transfer of these files between your program and the other programs.
4. How can you test forward compatibility?
- Testing forward compatibility is tough—after all, how can you test against something that doesn’t exist yet? The answer is to make sure that what you’re testing is thoroughly and carefully defined to the point that it could be deemed (被認爲) a standard.
- That standard then becomes the means for assuring that what you’re testing is forward compatible.
Chapter 10 Foreign-Language Testing
1. translation vs localization?
- Translation is concerned only with the language aspects—translating the words.
- Localization takes into account the customs, conventions, and culture of the region or locale.
2. Do you need to know the language to be able to test a localized product?
No, but someone on the test team needs to be fluent. You can test the non–language specific portions of the software, but knowing a bit of the language will help you be more efficient.
3. What is text expansion and what common bugs can occur because of it?
- Text expansion occurs when English text is translated into another language.
- The length of text strings can grow 100 percent or more. Text that used to fit onscreen, in dialog boxes, in buttons, and so on no longer does. It can be truncated or cause other text to roll off. It’s even possible to have the software crash because the extra long text no longer fits in the memory set aside for the string and other memory is overwritten.
4. Identify several areas where extended characters can cause problems.
The order of sorted or alphabetized words and phrases, conversion between upper- and lowercase, and just general display and printing issues.
5. Why is it important to keep text strings out of the code?
- Localizing becomes much easier if the person doing the work has to modify only a text file rather than the programming code.
- It also makes the testing work easier because you’ll know that the code didn’t change on the localized version of the software. 這也使測試工作變得更容易，因爲您將知道代碼在軟件的本地化版本中沒有更改。
6. Name a few types of data formats that could vary from one localized program to another.
Measurements such as pounds, inches, and gallons. Time in 24-hour or 12-hour format.
Currency has recently become important now that many European countries have converted to the Euro. There are many others.
Chapter 11 Usability Testing
1. True or False: All software has a user interface and therefore must be tested for usability.
True. Eventually, even the most deeply embedded software is exposed, in some way, to a user. Keep in mind that the UI may be as simple as a switch and a light bulb or as complex as a flight simulator. Even if the software is a single module of code, its interface, in the form of variables and parameters, is exposed to the programmer.
2. Is user interface design a science or an art?
It’s a little bit of both. Many user interface designs have been thoroughly tested in the labs, been through rigorous(嚴格) studies, only to be complete failures in the marketplace.
3. If there’s no definitive right or wrong user interface, how can it be tested?
Software testers should check that it meets seven important criteria:
That it follows standards and guidelines, that it’s intuitive(直觀的), consistent, flexible, comfortable, correct, and useful.
4. List some examples of poorly designed or inconsistent UIs in products you’re familiar with.
- Try setting the time on your car radio’s clock—can you do it without using the manual?
- A few Windows dialog boxes have the OK button on the left and the Cancel button on the right, whereas others have Cancel on the left and OK on the right. If you get used to one layout and click without looking, you could lose your work!
- Did you ever accidentally hang up on someone when you clicked the receiver hook on your phone to use call waiting or conference calling?
5. What four types of disabilities could affect software usability?
Visual, hearing, motion, and cognitive impairments.
視覺，聽覺，運動和認知障礙。
6. If you’re testing software that will be accessibility enabled, what areas do you need to pay close attention to?
（如果您正在測試將啓用輔助功能的軟件，那麼您需要密切注意哪些方面？）
Areas dealing with the keyboard, mouse, sound, and display. If the software was written to a popular platform that supports accessibility, the test effort will be a bit easier than if the accessibility features were programmed entirely from scratch.
Chapter 12 Testing the Documentation
1. Start up Windows Paint and look for several examples of documentation that should be tested. What did you find?
- There’s rollover help—the little pop-up descriptions you get when you hold the cursor over a painting tool. Selecting About from the Help menu displays a window with copyright and licensing information. Pressing F1 starts the online
help system where you can read the manual, select from an index, or type in words to search for. There’s also function help—for example, if you select Edit Colors from the Colors menu, click the ? in the title bar, and then click one of the colors, you’ll get help about choosing and creating colors.
2. The Windows Paint Help Index contains more than 200 terms from adding custom colors to zooming. Would you test that each of these takes you to the correct help topics? What if there were 10,000 indexed terms?
Every testing task is a risk-based problem. If you have time to test all the index entries,you might choose to do so. If you can’t test them all, you’ll have to create equivalence partitions of the ones you think are important to check. You could base your decision on information you get from the programmers on how the index system works. You might talk with the writer to find out how the entries were generated. You might try one of each starting letter, or the 1st, 2nd, 4th, 8th, 16th, … and last. You could even use test tools
3. True or False: Testing error messages falls under documentation testing.
True. But, it’s not just documentation testing. The content of the message needs to be tested as documentation, but forcing the message to appear and assuring that the correct message is displayed is testing the code.
4. In what three ways does good documentation contribute to the product’s overall quality?
Improved usability,
improved reliability,
and lower support costs.
Chapter 13
1. What basic elements of a Web page can easily be tested with a black-box approach?
The static elements —text, graphics, and hyperlinks.
2. What is gray-box testing?
- Gray-box testing is when you can take a peek at the underlying code and use that information to help you test. 灰盒測試是您可以窺視底層代碼並使用該信息來幫助您進行測試。
- It’s different from white-box testing in that you’re usually looking at simple scripting code, not a complex, compiled language such as C++. You’re also
not examining it to the same level of detail as you would with white-box esting.
3. Why is gray-box testing possible with Web site testing?
Because many Web sites are principally created with easily viewable HTML, a mark-up language, not an executable program.
4. Why can’t you rely on a spell checker to check the spelling on a Web page?
Because a spell checker can only check ordinary text. It can’t check graphical letters or dynamically generated text.
5. Name a few areas that you need to consider when performing configuration and compatibility testing of a Web site.
The hardware platform,
the operating system,
the Web browser,
browser plug-ins,
browser options and settings,
video resolution and color depth,
text size,
and modem 調制解調器
speeds.
6. Which of Jakob Neilsen’s 10 common Web site mistakes would cause configuration and compatibility bugs?
Gratuitous use of bleeding-edge technology. Existing hardware and software is always susceptible to new technology being run on it for the first time. This was a bit of a trick question—it wasn’t mentioned in the chapter, but hopefully you could arrive at the answer by applying what you’ve learned in Part III of the book.