Ron Patton软件测试习题：配置测试、兼容性测试、外语测试、可用性测试文档测试、网站测试_all software has a user interface and therefore mu

以下内容大部分来自 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.