提升UML设计：有效编写测试用例的实战指南

4星 · 超过85%的资源需积分: 9 176 浏览量更新于2024-07-24 收藏 1.01MB PDF 举报

在《UML设计测试用例》一书中，作者Alistair Cockburn探讨了如何利用UML（统一建模语言）原则撰写出高效、精确的测试用例。随着软件系统的需求日益复杂，编写测试用例以描述业务流程和软件行为变得越来越普遍。然而，实际操作中，面临写作挑战时，人们往往不清楚应该如何着手，尤其是在确定所需内容的详略程度和关键细节方面。书中强调，尽管描述一个好的测试用例是基础，但更重要的是学会如何撰写出高质量的用例，使之既清晰易懂又具有实用性。作者分享了他的写作指导原则和教练技巧，包括思考过程、观察要点，以帮助读者构建出更完善的测试用例集。书中还提供了实例对比，展示了优秀的测试用例与不佳的案例之间的差异，以及如何通过不同的写作风格改进。此外，令人鼓舞的是，Cockburn指出，编写测试用例并不一定要遵循刻板的规则，而是要灵活适应需求，确保其能真实反映系统的功能和用户交互。他强调了测试用例设计的核心在于明确性和功能性，而不是过度复杂或冗余。书中可能会详细阐述以下知识点： 1. **UML在测试用例中的应用**：介绍UML图示（如序列图、活动图等）在描述系统行为和测试场景中的作用，以及如何将这些图转换为可执行的测试用例。 2. **编写原则**：探讨清晰度、一致性、目的性（即每个用例应有明确的目标）、可读性以及可维护性等核心原则，以及如何遵循这些原则进行写作。 3. **结构化方法**：提供一种结构化的步骤，如背景、目标、步骤、预条件、后置条件等，用于组织测试用例内容。 4. **写作技巧**：讨论如何运用故事叙述法、场景描绘、角色扮演等技巧，使测试用例更具生动性和易于理解。 5. **评估与反馈**：讨论如何评估测试用例的有效性和可能的改进方向，以及如何在团队中获取反馈并持续优化用例集。 6. **避免常见陷阱**：列出常见的错误，如过度设计、遗漏关键细节或假设读者已知过多背景信息，以便读者了解如何避免这些问题。 7. **适应性原则**：强调测试用例需要随着系统变化而调整，并能适应不同阶段的需求，如需求分析、设计和实现阶段。通过阅读这本书，读者可以提升他们的测试用例写作技能，不仅能够编写出符合UML标准的测试用例，还能确保这些用例能有效地支持软件开发过程。

xiv

Exercise 26 on page 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Exercise 27 on page 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Exercise 29“Fix faulty ’Login’” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Use Case 38: Use the order processing system . . . . . . . . . . . . . . . . . . . . . . . 239

Exercise 30 on page 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Exercise 34 on page 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Use Case 39: Buy stocks over the web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Exercise 37 on page 128: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Use Case 40: Perform clean spark plugs service . . . . . . . . . . . . . . . . . . . . . . . 241

Chapter 25 Appendix C: Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . 242

Main terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Types of use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Chapter 26 Appendix D: Reading . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Books referenced in the text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Articles referenced in the text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Online resources useful to your quest.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

1. I

NTRODUCTION

ASES

What do use cases look like?

Why would different project teams need different writing styles?

Where do they fit into the requirements gathering work?

How do we warm up for writing use cases?

It will be useful to have some thoughts on these questions in place before getting into the details

of use cases themselves. Feel free to bounce between this introduction and Use Case Body Parts,

picking up background information as you need.

1.1 What is a Use Case (more or less)?

A use case captures a contract between the stakeholders of a system about its behavior. The use

case describes the system’s behavior under various conditions as it responds to a request from one

of the stakeholders, called the primary actor. The primary actor initiates an interaction with the

system to accomplish some goal. The system responds, protecting the interests of all the stake-

holders. Different sequences of behavior, or scenarios, can unfold, depending on the particular

requests made and conditions surrounding the requests. The use case collects together those

different scenarios.

Use cases are fundamentally a text form, although they can be written using flow charts,

sequence charts, Petri nets, or programming languages. Under normal circumstances, they serve to

communicate from one person to another, often to people with no special training. Simple text is,

therefore, usually the best choice.

The use case, as a form of writing, can be put into service to stimulate discussion within a team

about an upcoming system. They might later use that the use case form to document the actual

requirements. Another team might later document the final design with the same use case form.

They might do this for a system as large as an entire company, or as small as a piece of a software

application program. What is interesting is that the same basic rules of writing apply to all these

different situations, even though the people will write with different amounts of rigor, at different

levels of technical detail.

When the use cases document an organization’s business processes, the system under discussion

is the organization itself. The stakeholders are the company shareholders, customers, vendors, and

Chapter 1. Introduction to Use Cases

What is a Use Case (more or less)? - Page 16

government regulatory agencies. The primary actors will include the company’s customers and

perhaps their suppliers.

When the use cases record behavioral requirements for a piece of software, the system under

discussion is the computer program. The stakeholders are the people who use the program, the

company owning it, government regulatory agencies, and other computer programs. The primary

actor will be the user sitting at the computer screen or another computer system.

I show several examples of use cases below. The parts of a use case are described in the next

chapter ("Use Case Body Parts"). For now, just note that the primary actor is the one with the goal

that the use case addresses. Scope identifies the system that we are discussing, the preconditions

and guarantees say what must be true before and after the use case runs. The main success

scenario is a case in which nothing goes wrong. The extensions section describes what can happen

differently during that scenario. The numbers in the extensions refer to the step numbers in the

main success scenario at which each different situation gets detected (for instance, steps 4a and 4b

indicate two different conditions that could show up at step 4). When a use case references another

use case, the second use case is written in italics or underlined

The first use case describes a person about to buy some stocks. over the web To signify that we

are dealing with a goal to be achieved in a single sitting, I mark the use case as being at the "user

goal" level, and tag the use case with the "sea-level" symbol . The second use case describes a

person trying to get paid for a car accident, a goal that takes longer than a single sitting. To show

this, I mark the level as "summary", and tag the use case with the "above sea level" kite symbol

. These symbols are all explained in more detail later.

The first use case describes the person’s interactions with a program (the "PAF" program)

running on a workstation connected to the web. I indicate that the system being discussed is a

computer system with the symbol of a black box, . The second use case describes a person’s

interaction with a company. I indicate that with the symbol of a building, . The use of symbols

are completely optional. Labeling the scope and level are not.

Here are the first two use cases.

Chapter 1. Introduction to Use Cases

What is a Use Case (more or less)? - Page 18

ASE

2: G

PAID

FOR

CAR

ACCIDENT

Primary Actor: The Claimant

Scope

: The insurance company ("MyInsCo")

Level

: Summary

Stakeholders and Interests:

the claimant - to get paid the most possible

MyInsCo - to pay the smallest appropriate amount

the dept. of insurance - to see that all guidelines are followed.

Precondition

: none

Minimal guarantees

: MyInsCo logs the claim and all activities.

Success guarantees

: Claimant and MyInsCo agree on amount to be paid, claimant gets paid

that.

Trigger:

Claimant submits a claim

Main success scenario

1. Claimant submits claim with substantiating data.

2. Insurance company verifies claimant owns a valid policy

3. Insurance company assigns agent to examine case

4. Insurance company verifies all details are within policy guidelines

5. Insurance company pays claimant and closes file.

Main success scenario

1a. Submitted data is incomplete:

1a1. Insurance company requests missing information

1a2. Claimant supplies missing information

2a. Claimant does not own a valid policy:

2a1. Insurance company declines claim, notifies claimant, records all this, terminates pro-

ceedings.

3a. No agents are available at this time

3a1. (What does the insurance company do here?)

4a. Accident violates basic policy guidelines:

4a1. Insurance company declines claim, notifies claimant, records all this, terminates pro-

ceedings.

4b. Accident violates some minor policy guidelines:

4b1. Insurance company begins negotiation with claimant as to degree of payment to be

made.

________________________________________

Most of the use cases for this book come from live projects, and I have been careful not to touch

them up (except to add the scope and level tags if they weren’t there). I want you to see samples of

what works in practice, not just what is pretty in the classroom. People rarely have time to make

the use cases formal, complete, and pretty. They usually only have time to make them "sufficient".

Sufficient is fine. It is all that is necessary. I show these real samples because you will rarely be

able to generate perfect use cases yourself, despite whatever coaching I offer in the book. I can’t

even write perfect use cases most of the time.

剩余248页未读，继续阅读

锅锅果

粉丝: 0
资源: 1

提升UML设计：有效编写测试用例的实战指南

掌握UML基础：事物ThingP-uml与面向对象分析设计

UML系统分析与设计：面向对象的方法

UML模式：面向对象分析与设计实战指南

A Test Case Genneration Approach Based on Sequence Diagram and Automata Models

uml2.0-test-profile.rar_OMG

基于UML的图书馆购书管理系统设计 计算机软件综合设计

UML课件

基于UML的教学互动网站的设计与实现.docx

一个软件设计的全过程(基于UML) 推荐

面向对象分析与设计复习题UML和模式应用.docx

最新资源

基于UML的图书馆购书管理系统设计计算机软件综合设计