ISEB Foundation Chapter2 - Tài liệu ISEB chương 2

[tvn]

Chapter2:
Testing throughout Lifecycle

"What is clear from the Inquiry Team's investigations is that neither the Computer Aided Dispatch (CAD) system itself, nor its users, were ready for full implementation on 26th October 1992. The CAD software was not complete, not properly tuned, and not fully tested. The resilience of the hardware under a full load had not been tested. The fall back option to the second file server had certainly not been tested."

Extract from the main conclusions of the official report into the failure of the London Ambulance Service's Computer Systems on October 26th and 27th 1992.

2.1 OVERVIEW
...

2.2 OBJECTIVES

- Understand the difference between verification and validation testing activities
- Understand what benefits the V model offers over other models.
...

2.3 Models for Testing

This section will discuss various models for testing. Definitions of these models will differ however the fundamental principles are agreed on by experts and practitioners alike. We cover verification and validation (V & V), the V-Model and briefly discuss a Rapid Application Development (RAD) approach to testing.

2.3.1 Verification and validation (V&V)

Verification is defined by B87925 as the process of evaluating a system or component to determine whether the products of the given development phase satisfy the conditions imposed at the start of that phase.
...

2.3.2 V-model

There are many models used to describe the sequence of activities that make a Systems Development Life Cycle (SDLC). SLDC is used to describe activities of both development and maintenance work. Three models are worth mentioning.

- Sequential (the traditional waterfall model).
- Incremental (the function by function incremental model).
...

2.3.3 Sequential Model

Initial Appraisal
Feasibility Study
Requirements, specification
...

2.3.4 Plan for wanted waterfall model development of system

The overall project plan for development of a system might be as shown below:
...

2.3.5 Sequential model plus testing gives 'V' diagram

The V diagram is another way of looking at the sequential development but this time from viewpoint of testing activities that need to be completed later in SDLC.
...

2.3.6 'V' with test recognized deliverable

The activity of Business Analysis has, as deliverables, the Specification of Requirements from which Acceptance Test Plan is constructed. To have created, for example, System Architecture without integration Test Specification is to do only half the job!
...

2.3.7 Revised plan for system development

The overall project plan for development of a system might be as shown below. Note the new early quality control points.
...

2.3.8 Rapid Application Development

The spiral, Rapid Application Development (RAD) model has the benefit of the evolutionary approach. This is an incremental process of build a little then test a little, which has the benefit of attempting to produce a usable but limited version early.
...

2.4 ECONOMICS OF TESTING

This section looks at some of the economic factors involved in test activities. Although some research has been done to put forward the ideas discussed, few organizations have yet to provide accurate figures to confirm these theories.
...

2.5 RELATIVE COSTS TO FIX ERROR

The cost of fixing errors escalates as we move the project towards field use. From an analysis of sixty-three projects cited in Boehm: Software Engineering Economics (Boehm, 1981).
...

2.6 High level test planning

You should be aware that many people use the term 'test plan' to describe a document detailing individual tests for a component of a system. We are introducing the concept of high level test plans to show that there are a lot more activities involved in effective testing than just writing test cases.
...

2.6.1 SPACE - the final frontier (of testing?)

This may be useful acronym to help you remember what you should include in any high level test plan document. The actual format is up to you and will depend upon your own company standards and other internal considerations. Space stands for Scope, People, Approach, Criteria and Environment and we have tried to map this onto the IEEE 829 headings as follows:
...

2.7 Component testing

Component testing is described fully in BS-7925 and should be aware that component testing is also known as unit testing, module testing or Program Testing. The definition from BS7925 is simply the testing of individual software components.
...

2.8 INTEGRATION TESTING

Integration is the process of combining components into larger assemblies. From the standard BS-7925 integration testing is defined as "testing performed to expose faults in the interfaces and in the interaction between integrated components", However, in this section we look at two interpretations of integration testing known as integration testing in the large and integration testing in the small.
...

2.9 SYSTEM TESTING

System testing is defined as the process of testing an integrated system to verify that it meets specified requirements.
...

2.10 ACCEPTANCE TESTING

The definition of acceptance testing in BS7925 states that "acceptance testing is formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component". Acceptance testing may be the only form of testing conducted by and visible to a customer when applied to a software package. The most common usage of the term relates to the user acceptance testing (VAT) but you should be aware that there are several other uses of acceptance testing, which we briefly describe here.
...

2.11 MAINTENANCE TESTING

Maintenance testing is not specifically defined in BS7925 but it is all about testing changes to the software after it has gone into productions.

There are several problems with maintenance testing. If you are testing old code the original specifications and design documentation may be poor or in some cases non-existent. When defining the scope of the maintenance testing it has to be judged in relation to the changed code; how much has changed, what areas does it really affect etc. This kind of impact analysis is difficult and so there is a higher risk when making changes - it is difficult to decide how much regression testing to do.

Các bạn vui lòng download bản đầy đủ ở file đính kèm