David的测试技术空间,收藏好文档和分享我的技术理解。5年的数通产品测试和安全产品测试经验,3年Web产品测试和多年测试管理和测试工具开发经验。目前关注性能分析调优、Jmeter和TestNG+WebDriver+Hamcrest的培训推广。Welcome沟通交流,请留言或者发邮件到daviwang_2004 at soguo.com。

Basing Test Cases on Product Requirement Documents

上一篇 / 下一篇  2007-11-13 10:08:40 / 个人分类:旧资料

Basing Test Cases on Product Requirement Documents


By G.E. Morris

With a solid requirements document created it's fairly easy to create a test case document. Just get a soft copy of the requirements doc and modify it. The modification a requirements doc being converted to a test case needs depends in part on the format of the test case document being used. Starting with the requirements document (seeWriting Requirements Documents), the examples shown below walk you through the process of converting a requirements document to a set of test cases.

Consider the following example:

Registration Form

Enter your first and last names and click the Submit button.

First Name:

Last Name:


Modifying General Page Appearance Requirements

Modifying General Page appearance requirements section 1.0.0 is mostly just a matter of changing the word "shall" to "is" or "are."

1.0.0 General Page Appearance Requirements

1.1.1 The title "Registration Page" shall be left aligned at the top of the page.

1.1.2 The words "Registration Page" shall be spelled correctly.

1.1.3 The words "Registration Page" shall be in 26 point type.

1.1.4 The words "Registration Page" shall be in sans serif type type.

Becomes

1.0.0 General Page Appearance Test Cases

1.1.1 The title "Registration Page"isleft aligned at the top of the page.

1.1.2 The words "Registration Page"arespelled correctly.

1.1.3 The words "Registration Page"arein 26 point type.

1.1.4 The words "Registration Page"arein sans serif type type.


Test Case Format Options

The test cases for the first and last name fields require more modification, in part because the test cases tend to be more complex. Page appearance issues have simple pass/fail criteria, for instance either the page title is spelled correctly or it's not. With field validation test cases, which test decisions the code must make, there is an action on the part of the tester, an expected result and an actual result.

A simple format lists a test case number, an action, and a column labeled Pass/Fail to record results.

Case Number

Action

Pass/Fail

 

 

 


Table 1


A more elaborate format would have a test case number, an action column, an expected results column, an actual results column, and a Pass/Fail column.

 

Case Number

Action

Expected Results

Actual Results

Pass/Fail


 

 

 

 

Table 2



Modifying Requirements for Simple Test Case Formats

Requirement 2.1.1 needs very little modification to become test case 2.1.1. The requirement reads:

2.1.1 Entry with a blank First Name shall result in an error message being displayed saying The First Name must be filled in.

It becomes

2.1.1 Entering a blank First Name results in an error message being displayed saying The First Name must be filled in.

In the simple test case format, it looks like this:

Case Number

Action

Pass/Fail

2.1.1

Entry with a blank First Name results in an error message being displayed saying The First Name must be filled in.

 

 

 

 

Table 3


Modifying Requirements for More Complex Test Case Formats

Requirement 2.1.1 needs a little more modification to become test case 2.1.1 for a complex test case format than a simple one. The requirement reads:

2.1.1 Entry with a blank First Name shall result in an error message being displayed saying The First Name must be filled in.

It becomes

2.1.1 Action: Enter a blank First Name.

2.1.1 Expected Results: An error message is displayed saying The First Name must be filled in.

In the more complex test case format, it looks like this:

Case Number

Action

Expected Results

Actual Results

Pass/Fail

2.1.1

Entry with a blank First Name.

An error message is displayed saying The First Name must be filled in.

 

 

 

 

 

 

 

Table 4


TAG: 与目前工作有关的杂项

 

评分:0

我来说两句

Open Toolbar