ISTQB认证基础：软件测试原理与实践

PDF文件

ISTQB

软件测试

软件测试资质认证

基础级教材

5星 · 超过95%的资源 | 下载需积分: 10 | 2.52MB | 更新于2024-08-02 | 127 浏览量 | 举报 2 收藏

立即下载

"Foundations of Software Testing: ISTQB Certification" 是一本专注于软件测试基础的书籍，由Dorothy Graham、Erik van Veenendaal、Isabel Evans和Rex Black四位专家编写，旨在帮助读者准备ISTQB（国际软件测试资格认证板）的基础级考试。该书由Cengage Lrng Business Press出版，于2006年12月19日发行，共258页，ISBN号为9781844803552，采用平装本形式。本书内容详实，涵盖了软件测试的核心概念，包括： 1. 测试的基本原理：书中首先探讨了为何需要进行软件测试，强调了测试在软件开发过程中的重要性。接着，它解释了什么是测试以及测试的目的，帮助读者理解测试的本质。 2. 测试原则：阐述了18个关键的测试原则，这些原则是测试工作中的指南，有助于确保测试的有效性和效率。 3. 基本测试过程：介绍了软件测试的通用过程，包括测试计划、设计、执行、监控和控制等阶段，以及测试在整个软件生命周期中的位置。 4. 测试心理学：深入讨论了测试人员的心理状态和行为如何影响测试效果，以及如何培养有效的测试思维。 5. 软件生命周期中的测试：分析了不同软件开发模型（如瀑布模型、敏捷模型等）下的测试策略，定义了测试级别（如单元测试、集成测试、系统测试等），并讨论了维护测试的方法。 6. 静态技术：讲解了审查和静态分析工具的应用，以帮助在编码阶段发现潜在问题，减少缺陷的引入。 7. 测试设计技术：详细介绍了如何识别测试条件并设计测试用例，涵盖黑盒测试、白盒测试和基于经验的测试技术，以及选择适当测试技术的策略。每章末尾都提供了章节复习、样题和练习，以便读者检验学习成果，并为ISTQB认证考试做好准备。通过本书，读者不仅可以掌握软件测试的基础知识，还能了解到实践经验与理论知识的结合，从而提升测试技能和专业素养。

As you read this section, you'll encounter the terms code, debugging,

development of software, requirement, review, test basis, test case, testing

and test objective.

1.2.1 The driving test - an analogy for software testing

We have spent some time describing why we need to test, but we have not dis-

cussed what testing is. What do we mean by the word testing? We use the words

test and testing in everyday life and earlier we said testing could be described as

'checking the software is OK'. That is not a detailed enough definition to help

us understand software testing. Let's use an analogy to help us: driving tests. In

a driving test, the examiner critically assesses the candidate's driving, noting

every mistake, large or small, made by the driver under test. The examiner takes

the driver through a route which tests many possible driving activities, such as

road junctions of different types, control and maneuvering of the car, ability to

stop safely in an emergency, and awareness of the road, other road users and

hazards. Some of the activities must be tested. For example, in the UK, an

emergency stop test is always carried out, with the examiner simulating the

moment of emergency by hitting the dashboard at which point the driver must

stop the car quickly, safely and without loss of control. At the end of the test,

the examiner makes a judgment about the driver's performance. Has the driver

passed the test or failed? The examiner bases the judgment on the number and

severity of the failures identified, and also whether the driver has been able to

meet the driving requirements. A single severe fault is enough to fail the whole

test, but a small number of minor faults might still mean the test is passed.

Many minor faults would reduce the confidence of the examiner in the quality

—of the driving to the point where the driver cannot pass. The format of the

driving test and the conduct of the examiner are worth considering:

• The test is planned and prepared for. In advance of the test, the examiner

has planned a series of routes which cover the key driving activities to allow

a thorough assessment of the driver's performance. The drivers under test do

not know what route they will be asked to take in advance, although they

know the requirements of the test.

• The test has known goals - assessing whether the driver is sufficiently safe to

be allowed to drive by themselves without an instructor, without endanger

ing themselves or others. There are clear pass/fail criteria, based on the

number and severity of faults, but the confidence of the examiner in the

driving is also taken into account.

• The test is therefore carried out to show that the driver satisfies the require

ments for driving and to demonstrate that they are fit to drive. The examiner

looks for faults in the driving. The time for the test is limited, so it is not a

complete test of the driver's abilities, but it is representative and allows the

examiner to make a risk-based decision about the driver. All the drivers are

tested in an equivalent way and the examiner is neutral and objective. The

examiner will log factual observations which enable a risk assessment to be

made about the driving. Based on this, a driver who passes will be given a

form enabling him to apply for a full driving license. A driver who fails will

get a report with a list of faults and areas to improve before retaking the test.

• As well as observing the driver actually driving, the examiner will ask

questions or the driver will take a written exam to check their under

standing of the rules of the road, road signs, and what to do in various

traffic situations.

1.2.2 Defining software testing

With that analogy in mind, let's look at the ISTQB definition of software

testing.

Let's break the definition down into parts; the definition has some key

phrases to remember. The definition starts with a description of testing as a

process and then lists some objectives of the test process. First, let's look at

testing as a process:

• Process - Testing is a process rather than a single activity - there are a series

of activities involved.

• All life cycle activities - Chapter 2 looks at testing as a process that takes

place throughout the software development life cycle. We saw earlier

that the later in the life cycle we find bugs, the more expensive they are

to fix. If we can find and fix requirements defects at the requirements

stage, that must make commercial sense. We'll build the right software,

correctly and at a lower cost overall. So, the thought process of design

ing tests early in the life cycle can help to prevent defects from being

introduced into code. We sometimes refer to this as 'verifying the test

basis via the test design'. The test basis includes documents such as the

requirements and design specifications. You'll see how to do this in

Chapter 4.

• Both static and dynamic - We'll see in Chapter 3 that as well as tests where

the software code is executed to demonstrate the results of running tests

(often called dynamic testing) we can also test and find defects without exe

cuting code. This is called static testing. This testing includes reviewing of

documents (including source code) and static analysis. This is a useful and

cost effective way of testing.

• Planning - Activities take place before and after test execution. We need to

manage the testing; for example, we plan what we want to do; we control the

test activities; we report on testing progress and the status of the software

under test; and we finalize or close testing when a phase completes. Chapter

5 covers these test management activities.

• Preparation - We need to choose what testing we'll do, by selecting test con

ditions and designing test cases. Chapter 4 covers the test design activities.

• Evaluation - As well as executing the tests, we must check the results and

evaluate the software under test and the completion criteria, which help us

decide whether we have finished testing and whether the software product

has passed the tests.

• Software products and related work products - We don't just test code. We test

the requirements and design specifications, and we test related documents

such as operation, user and training material. Static and dynamic testing are

both needed to cover the range of products we need to test.

The second part of the definition covers the some of the objectives for testing -

the reasons why we do it:

• Determine that (software products) satisfy specified requirements - Some of

the testing we do is focused on checking products against the specification

for the product; for example we review the design to see if it meets require

ments, and then we might execute the code to check that it meets the design.

If the product meets its specification, we can provide that information to

help stakeholders judge the quality of the product and decide whether it is

ready for use.

• Demonstrate that (software products) are fit for purpose - This is slightly

different to the point above; after all the specified requirements might be

wrong or incomplete. 'Fit for purpose' looks at whether the software does

enough to help the users to carry out their tasks; we look at whether the soft

ware does what the user might reasonably expect. For example, we might

look at who might purchase or use the software, and check that it does do

what they expect; this might lead us to add a review of the marketing mate

rial to our static tests, to check that expectations of the software are properly

set. One way of judging the quality of a product is by how fit it is for its

purpose.

• Detect defects - We most often think of software testing as a means of

detecting faults or defects that in operational use will cause failures. Finding

the defects helps us understand the risks associated with putting the software

into operational use, and fixing the defects improves the quality of the prod

ucts. However, identifying defects has another benefit. With root cause

analysis, they also help us improve the development processes and make

fewer mistakes in future work.

This is a suitable definition of testing for any level of testing, from compo-

nent testing through to acceptance testing, provided that we remember to take

the varying objectives of these different levels of testing into account. (In

Chapter 2 we'll cover the different test levels, their objectives, and how they fit

into the software development life cycle.)

We can clearly see now why the common perception of testing (that it only

consists of running tests, i.e. executing the software) is not complete. This is one

of the testing activities, but not all of the testing process.

1.2.3 Software test and driving test compared

We can see that the software test is very like a driving test in many ways,

although of course it is not a perfect analogy! The driving examiner becomes

the software tester. The driver being examined becomes the system or software

under test, and you'll see as we go through this book that the same approach

broadly holds.

• Planning and preparation - Both the examiner and the tester need a plan of

action and need to prepare for the test, which is not exhaustive, but is repre

sentative and allows risk-based decisions about the outcome.

• Static and dynamic - Both dynamic (driving the car or executing the soft

ware) and static (questions to the driver or a review of the software) tests are

useful.

•

Evaluation

- The examiner and the tester must make an objective

evaluation,

log the test outcome and report factual observations about the

test.

•

Determine that they satisfy specified requirements - The

examiner and tester

both check against requirements to carry out particular tasks

successfully.

•

Demonstrate that they are fit for purpose

- The examiner and the

tester are not

evaluating for perfection but for meeting sufficient of the

attributes required

to pass the test.

•

Detect defects

- The examiner and tester both look for and log

faults.

Let's think a little more about planning. Because time is

limited, in order to make a representative route that would

provide a sufficiently good test, both software testers and

driving examiners decide in advance on the route they will take.

It is not possible to carry out the driving test and make decisions

about where to ask the driver to go next on the spur of moment.

If the examiner did that, they might run out of time and have to

return to the test center without having observed all the

necessary maneuvers. The driver will still want a pass/fail report.

In the same way, if we embark on testing a software system

without a plan of action, we are very likely to run out of time

before we know whether we have done enough testing. We'll see

that good testers always have a plan of action. In some cases,

we use a lightweight outline providing the goals and general

direction of the test, allowing the testers to vary the test during

execution. In other cases, we use detailed scripts showing the

steps in the test route and documenting exactly what the tester

should expect to happen as each step. Whichever approach the

tester takes, there will be some plan of action. Similarly, just as

the driving examiner makes a log and report, a good tester will

objectively document defects found and the outcome of the test.

So, test activities exist before and after test execution, and we

explain those activities in this book. As a tester or test manager,

you will be involved in planning and control of the testing,

choosing test conditions, designing test cases based on those test

conditions, executing them and checking results, evaluating

whether enough testing has been done by Examining completion

(or exit) criteria, reporting on the testing process and system under

test, and presenting test completion (or summary) reports.

1.2.4 When can we meet our test objectives?

Testing Principle - Early testing

Testing activities should start as early as possible in the software or system development life

cycle and should be focused on defined objectives.

We can use both dynamic testing and static testing as a means for

achieving similar

test objectives.

Both provide information to

improve both the system to be tested, and the development and

testing processes. We mentioned above that testing can have

different goals and objectives, which often include:

•

finding defects;

•

gaining confidence in and providing information about the level

of quality;

•

preventing defects.

Many types of review and testing activities-take place at different stages in

the life cycle, as we'll see in Chapter 2. These have different objectives. Early

testing - such as early test design and review activities - finds defects early on

when they are cheap to find and fix. Once the code is written, programmers

and testers often run a set of tests so that they can identify and fix defects in

the software. In this 'development testing' (which includes component, inte-

gration and system testing), the main objective may be to cause as many fail-

ures as possible so that defects in the software are identified and can be fixed.

Following that testing, the users of the software may carry out acceptance

testing to confirm that the system works as expected and to gain confidence

that it has met the requirements.

Fixing the defects may not always be the test objective or the desired

outcome. Sometimes we simply want to gather information and measure the

software. This can take the form of attribute measures such as mean time

between failures to assess reliability, or an assessment of the defect density in

the software to assess and understand the risk of releasing it.

When maintaining software by enhancing it or fixing bugs, we are changing

software that is already being used. In that case an objective of testing may be

to ensure that we have not made errors and introduced defects when we

changed the software. This is called regression testing - testing to ensure

nothing has changed that should not have changed.

We may continue to test the system once it is in operational use. In this case,

the main objective may be to assess system characteristics such as reliability or

availability.

Testing Principle - Defect clustering

A small number of modules contain most of the defects discovered during pre-release

testing or show the most operational failures.

1.2.5 Focusing on defects can help us plan our tests

Reviewing defects and failures in order to improve processes allows us to

improve our testing and our requirements, design and development

processes. One phenomenon that many testers have observed is that defects

tend to cluster. This can happen because an area of the code is particularly

complex and tricky, or because changing software and other products tends

to cause knock-on defects. Testers will often use this information when

making their risk assessment for planning the tests, and will focus on known

'hot spots'.

A main focus of reviews and other static tests is to carry out testing as

early as possible, finding and fixing defects more cheaply and preventing

defects from appearing at later stages of this project. These activities help us

find out about defects earlier and identify potential clusters. Additionally, an

important outcome of all testing is information that assists in risk assess-

ment; these reviews will contribute to the planning for the tests executed

later in the software development life cycle. We might also carry out root

cause analysis to prevent defects and failures happening again and perhaps

to identify the cause of clusters and potential future clusters.

剩余207页未读，继续阅读

ospring

粉丝: 3

ISTQB认证基础：软件测试原理与实践

ISTQB认证教程--FOUNDATIONS OF SOFTWARE TESTING

ISTQB 认证资料分享

ISTQB 软件测试专业认证资源

FOUNDATIONS OF SOFTWARE TESTING

Foundations Of SoftwareTesting

计算机科学基础：C版Foundations of Computer Science: C Edition

guessing-game:Fullstack Foundations-猜谜游戏:pool_8_ball:

Foundations of Software Engineering 2010年论文集

Foundations of PEAR: Rapid PHP Development

The foundations of cryptography: A Primer

最新资源