Tóm tắt kiến thức chung nhất ISTQB bằng hình ảnh- chương 2

Tóm tắt kiến thức chung nhất ISTQB bằng hình ảnh- chương 2

May 17, 2017 - admin

No Comments

Chúng tôi tiếp tục gửi bạn tóm tắt kiến thức của ISTQB foundation chương 2

Xem tóm tắt của chương 1

CHAPTER 2: TESTING IN THE LIFECYCLE

2.1 Software models

V-model (Sequential Development Model)

Early test design

– Test design finds faults

– Faults found early are cheaper to fix

– Most signification faults found first

– Faults prevented, not built in

– No additional effort, re-schedule test design

– Changing requirements caused by test design

Iterative-incremental Development Models ( Evolution Models)

– Iterative-incremental development is the process of establishing requirements, designing, building and testing a system in a series of short development cycles.

Examples are: prototyping, Rapid Application Development (RAD), Rational Unified Process (RUP) and agile development models.

– A system that is produced using these models may be tested at several test levels during each iteration

– Regression testing is increasingly important on all iterations after the first one.

– Verification and validation can be carried out on each increment.

Agile – Scrum development

Term: VV&T – Verification, Validation and Test

Verification ( Do it right)

Question: Are we building the product right?

Validation – ( Do right it)

Question: Are we build the right product?

Testing

The process of exercising software to verify that it satisfies specified requirements and to detect faults

Testing within a Life Cycle Model

There are several characteristics of good testing:

For every development activity there is a corresponding testing activity
Each test level has test objectives specific to that level
The analysis and design of tests for a given test level should begin during the corresponding development activity
Testers should be involved in reviewing documents as soon as drafts are available in the development life cycle

2.2.1 Component Testing (K2)

Test basis: Component requirements, detailed design, Code

Typical test objects: Components, Programs, Data conversion / migration programs, Database modules

Component testing (also known as unit, module or program testing)
Searches for defects in, and verifies the functioning of, software modules, programs, objects, classes, etc., that are separately testable
Done in isolation from the rest of the system
Stubs, drivers and simulators may be used.
Include testing of functionality and specific non-functional characteristics : Robustness testing, security
Test cases are derived from work products such as a specification of the component, the software design or the data model.
Component testing occurs with access to the code being tested and with the support of a development environment, such as a unit test framework or debugging tool.
Defects are typically fixed as soon as they are found, without formally managing these defects.
One approach to component testing is to prepare and automate test cases before coding. This is called a test-first approach or test-driven development.

2.2.2 Integration Testing (K2)

Test basis: Software and system design, Architecture, Workflows, Use cases

Typical test objects: Subsystems, Database implementation, Infrastructure, Interfaces, System configuration and configuration data

Integration testing tests interfaces between components, interactions with different parts of a system, such as the operating system, file system and hardware, and interfaces between systems.
There may be more than one level of integration testing and it may be carried out on test objects of varying size as follows

Component integration testing tests the interactions between software components and is done after component testing
System integration testing tests the interactions between different systems or between hardware and software and may be done after system testing.

Test approach:

Big-bang integration

Incremental integration

Top-Down integration
Bottom-up integration

2.2.3 System Testing (K2)

Test basis: System and software requirement specification, Use cases, Functional specification, Risk analysis reports.

Typical test objects: System, user and operation manuals, System configuration and configuration data

System testing is concerned with the behavior of a whole system/product.
The test environment should correspond to the final target or production environment as much as possible in order to minimize the risk of environment-specific failures not being found in testing.
Include tests based on risks and/or on requirements specifications, business processes, use cases, or other high level text descriptions or models of system behavior, interactions with the operating system, and system resources.
Investigate functional and non-functional requirements of the system, and data quality characteristics.
Testers also need to deal with incomplete or undocumented requirements.
System testing of functional requirements starts by using the most appropriate specification-based (black-box) techniques for the aspect of the system to be tested.
An independent test team often carries out system testing.

2.2.4 Acceptance Testing (K2)

Test basis: User requirements, System requirements, Use cases, Business processes, Risk analysis reports

Typical test objects: Business processes on fully integrated system, Operational and maintenance processes, User procedures, Forms, Reports, Configuration data

Acceptance testing is often the responsibility of the customers or users of a system; other stakeholders may be involved as well.
The goal is to establish confidence in the system, parts of the system or specific non-functional characteristics of the system.
Finding defects is not the main focus in acceptance testing.
Acceptance testing may assess the system’s readiness for deployment and use
Acceptance testing may occur at various times in the life cycle

Typical forms of acceptance testing include the following

User acceptance testing

Typically verifies the fitness for use of the system by business users

Operational (acceptance) testing

The acceptance of the system by the system administrators, including:

Testing of backup/restore or disaster recovery

User management
Maintenance tasks
Data load and migration tasks
Periodic checks of security vulnerabilities

3.Contract and regulation acceptance testing

Contract acceptance testing is performed against a contract’s acceptance criteria for producing custom-developed software.
Regulation acceptance testing is performed against any regulations that must be adhered to, such as government, legal or safety regulations.

4.Alpha and beta (or field) testing- Test Alpha và beta

Alpha testing is performed at the developing organization’s site but not by the developing team.
Beta testing, or field-testing, is performed by customers or potential customers at their own locations.

2.3 Test Types (K2)