7.2.4 Test strategy 7.2.4 测试策略
In commercial software development the programmer is typically required to ensure their code is as error free as possible before it is handed over to the testing team whose job is to identify errors in the presented program. With large and complex programs, it is vital that all aspects of the code be tested systematically and comprehensively. In order for the testing team to ensure comprehensiveness, they make use of a document called a test strategy. We will be producing a test strategy (in part) for Assignment B.
在商业软件开发中,程序员通常需要确保他们的代码在交给测试团队之前尽可能没有错误,测试团队的工作是识别所呈现程序中的错误。对于大型和复杂的程序,系统、全面地测试代码的所有方面至关重要。为了让测试团队确保全面性,他们使用了一个称为测试策略的文档。我们将为作业 B 制定一个测试策略(部分)。
A test strategy is document that specifies how your class or program will be tested and, after testing, provides documentation of all the tests done, including the results of the tests. This document should be developed before the program code is written as it is important to think about testing before you have an emotional investment in the outcome. Many designers draft up the test strategy based on the class diagram they present to the programmer to implement. The comprehensiveness of the class diagram is therefore important as it provides an overall high-level view of the system.
测试策略是指定如何测试类或程序的文档,测试后,提供已完成的所有测试的文档,包括测试结果。本文档应在编写程序代码之前开发,因为在对结果进行情感投资之前考虑测试非常重要。许多设计人员根据他们提交给程序员实现的类图来起草测试策略。因此,类图的全面性很重要,因为它提供了系统的整体高级视图。
There are many approaches to developing a test strategy and different organisations will adopt their own specific strategy. In this unit we will learn how to develop a very basic strategy, which typically contains two components:
制定测试策略的方法有很多,不同的组织会采用自己的特定策略。在本单元中,我们将学习如何制定一个非常基本的策略,它通常包含两个组成部分:
A test plan. This is a summary of all the tests which will be eventually performed on the program.
测试计划。这是最终将在程序上执行的所有测试的摘要。The actual tests. These are the specifications/details of all the tests listed in the test plan. Each test will contain the following three components:
实际测试。这些是测试计划中列出的所有测试的规格/详细信息。每个测试将包含以下三个组件:Test data 测试数据
Expected results 预期结果
Actual results. 实际结果。
When drafting a test strategy before the program has been developed, the only parts of the document that are left incomplete are the actual results. These are added after the program has been implemented and the tests have been run. When this is done, the actual results will be compared to the expected results and if they match then the test was successful. If they don't match then this indicates a problem in the program, or sometimes it indicates there is a problem with the test data.
在程序开发之前起草测试策略时,文档中唯一不完整的部分是实际结果。这些是在实施程序并运行测试后添加的。完成此操作后,会将实际结果与预期结果进行比较,如果匹配,则测试成功。如果它们不匹配,则表示程序中存在问题,或者有时表示测试数据存在问题。
Testing strategy example 测试策略示例
Let's consider the following class shown in the diagram below:
让我们考虑下图所示的以下类:
We have been provided with the following specification details:
我们已获得以下规格详细信息:
StaffId is a string of three numeric characters.
StaffId 是一个包含三个数字字符的字符串。Pay Scale is a single character from the set {A, B, C, X}.
薪级是集合 {A, B, C, X} 中的单个字符。Employee Status is either true to indicate currently employed, or false to indicate not currently employed.
Employee Status (员工状态) 为 true 表示当前已就业,false 表示当前未就业。
Test plan 测试计划
The following steps outline an approach to a test plan:
以下步骤概述了测试计划的方法:
Create an Employee object with the default constructor.
使用默认构造函数创建 Employee 对象。Create an Employee object with the non-default constructor:
使用非默认构造函数创建一个 Employee 对象:with valid field values 具有有效的字段值
with invalid field values
字段值无效
Test all get methods: 测试所有 get 方法:
Test getIsEmployee() 测试 getIsEmployee()
Test getPayScale() 测试 getPayScale()
Test getStaffId() 测试 getStaffId()
Test all set methods: 测试所有设置的方法:
Test setIsEmployee() 测试 setIsEmployee()
with valid field values 具有有效的字段值
with invalid field values
字段值无效
Test setPayScale() 测试 setPayScale()
with valid field values 具有有效的字段值
with invalid field values
字段值无效
Test setStaffId() 测试 setStaffId()
with valid field values 具有有效的字段值
with invalid field values
字段值无效
It is important to note the following:
请务必注意以下几点:
In the test plan, every method which has a formal parameter must involve both positive and negative testing.
在测试计划中,每个具有正式参数的方法都必须同时涉及阳性和阴性测试。If a class has multiple parameterised constructors, then each constructor should be specified as an independent test case.
如果一个类有多个参数化构造函数,则应将每个构造函数指定为独立的测试用例。A negative test could involve multiple values. When this happens, each value being tested is shown as an independent subcase under the same test heading.
否定测试可能涉及多个值。发生这种情况时,正在测试的每个值都在同一测试标题下显示为独立的子情况。
The actual tests 实际测试
Test 1 测试 1
Create an Employee object with the default constructor.
使用默认构造函数创建 Employee 对象。
Test data: 测试数据:
staffId: "000" staffId: “000”
payScale: 'X' payScale: 'X'
isEmployee: false isEmployee:false
Expected results: 预期结果:
staffId: "000" staffId: “000”
payScale: 'X' payScale: 'X'
isEmployee: false isEmployee:false
Actual results: 实际结果:
<added after the program has been developed>
在程序开发完成后添加 <>
Test 2.1 测试 2.1
Create an Employee object with the non-default constructor with valid field values.
使用具有有效字段值的非默认构造函数创建 Employee 对象。
Test data: 测试数据:
staffId: "517" staffId: “517”
payScale: 'X' payScale: 'X'
isEmployee: false isEmployee:false
Expected results: 预期结果:
staffId: "517" staffId: “517”
payScale: 'X' payScale: 'X'
isEmployee: false isEmployee:false
Actual results: 实际结果:
<added after the program has been developed>
在程序开发完成后添加 <>
Test 2.1b.1 测试 2.1b.1
Create an Employee object with the non-default constructor with invalid field values.
使用具有无效字段值的非默认构造函数创建 Employee 对象。
Test data: 测试数据:
staffId: "99" staffId: “99”
payScale: 'a' payScale: 'a'
isEmployee: true isEmployee:真
Expected results: 预期结果:
staffId: "517" staffId: “517”
payScale: 'X' payScale: 'X'
isEmployee: false isEmployee:false
Actual results: 实际结果:
<added after the program has been developed>
在程序开发完成后添加 <>
Test 2.1b.2 测试 2.1b.2
Create an Employee object with the non-default constructor with invalid field values.
使用具有无效字段值的非默认构造函数创建 Employee 对象。
Test data: 测试数据:
staffId: "abc" staffId: “abc”
payScale: '6' payScale: '6'
isEmployee: true isEmployee:真
Expected results: 预期结果:
staffId: "000" staffId: “000”
payScale: 'X' payScale: 'X'
isEmployee: false isEmployee:false
Actual results: 实际结果:
<added after the program has been developed>
在程序开发完成后添加 <>
The rest of the methods can be elaborated similarly to document the rest of the test strategy.
其余方法可以类似地详细说明,以记录测试策略的其余部分。
After the test strategy document has been completed, the implementation of the program can begin (the testing of the implementation would use a Test class—we will not be using that here as our platform doesn't support embedding multiple classes, so we will show a similar output with a test method).
完成测试策略文档后,就可以开始程序的实现了(实现的测试将使用 Test 类 — 我们不会在这里使用它,因为我们的平台不支持嵌入多个类,因此我们将使用测试方法显示类似的输出)。
Once the program has been implemented, the last part of the test strategy document is completed by appending the result of the execution for the specific method and affixing any screenshot available of the execution along with any applicable comments as follows:
Test 1
Create an Employee object with the default constructor.
Test data:
staffId: "000"
payScale: 'X'
isEmployee: false
Expected results:
staffId: "000"
payScale: 'X'
isEmployee: false
Actual results:
Test Passed!
Test 2.1
Create an Employee object with the non-default constructor with valid field values.
Test data:
staffId: "517"
payScale: 'C'
isEmployee: false
Expected results:
staffId: "517"
payScale: 'C'
isEmployee: false
Actual results:
Test Passed!
Test 2.1b.1
Create an Employee object with the non-default constructor with invalid field values.
Test data:
staffId: "99"
payScale: 'a'
isEmployee: true
Expected results:
staffId: "517"
payScale: 'X'
isEmployee: false
Actual results:
Test FAILED!
Method not validating length of staffId and value of payScale correctly.
Test 2.1b.2
Create an Employee object with the non-default constructor with invalid field values.
Test data:
staffId: "abc"
payScale: '6'
isEmployee: true
Expected results:
staffId: "517"
payScale: 'X'
isEmployee: false
Actual results:
Test Failed!
Method not validating value of staffId and payScale correctly.
The remaining methods should be tested along the same lines.
As we can see from the above demonstration, the test strategy is a living and typically very long document. While it is relatively simple to perform tests, it is time consuming to invoke each and every method one at a time, capture and then document the final result. While the process is painstaking, it is critical in software development.
The code provided above shows the tests commented out because only one test is generally executed at one time so as not to influence the value based on another method. Depending on the object and the test, this can be modified.