Software Test first week study

First week of software testing:

The first chapter:

Software Testing: Software testing is an activity that evaluates the properties or capabilities of a program or system and determines that it conforms to its own desired results.

The purpose of the test:

1. Because we are not good enough programmers

2. Not concentrating enough energy to overcome the mistakes

3. Sometimes forget to use full-structured, top-down design to get our solution

4. We should have differentiated what other programmers or clients say, how they think, and what they really mean.

5. The test itself is a recognition of "failure (failure)"

Purpose of the Learning test:

1. Management software development process: Requirements Test-〉 functional Acceptance test Plan

2. Better design, preparation of software (requirements, completion of required functions, testability, safety and reliability, availability, execution speed, maintainability)

3. Master the principles and methods of software testing, improve the quality

Noun definitions:

Error : a mistake made by a designer or developer

Defect : The usual serious costly cost is due to gaps in demand (not recognized requirements), errors ignored by the program designer

Failure: Executing a defect code causes the system to produce incorrect results in some cases.

Understanding Software Testing:

Tips: Each link will have the understanding, design, expression, coding, operation and input of the correctness of the guarantee.

Otherwise, problems will arise.

Causes of defects:

Error Understanding Requirements

Requirements Design Error

Wrong understanding of design content

Encoding error

Program execution failed

Not meet the Needs

The Test life cycle has 3 opportunities to introduce errors during the development phase to propagate the defect to the next stage:

V-Type Development model:

Testing is not done after the coding is complete, it is an ongoing process that involves requirements analysis, software design and testing

Testing is demand-based, and testing is trying to find the difference between the expected behavior of a system or its constituent parts and observed behavior

Can only verify defects in the program and cannot verify that there are no defects in the program

Test Case:

In order to test, we need to set the input of the program to be tested, expect its output, etc., the set of information is called the test case

The difficulty is that the information for the design document is written for the developer, and the structure is trying to "what it is"

Testers need the behavior to try to get "what he does"

A closed curve is used to visually represent the set and its relational plot called Venn diagram (also called Venturi).

John Venn (John Wayne) was a 19th century British philosopher and mathematician who invented the Venn diagram in 1881.

Test divided into: black box test and white box test

Black box test: The software specification is the sole basis

White Box testing: Test based on program structure

	Black box	White box
Focus on	Behaviors in specifications	Program source code Structure
Specifications implementation	Can be tested	Hard to test
Implementation out of specifications	Hard to test	Can be tested
Test Case Creation	Does not depend on the realization method,cases is still available even though method has changed	Depend on the realization method,cases change when program changes
	Redundances and software flaws not have being tested may exist	There is strong theoretical basis. For a variety of test (coverage testing, branch testing)

Chapter II

Black box test

basic point of view : Any program can be regarded as a mapping from the input definition domain to the output range, this view will be measured by the program as a non-open black box, the contents of the black box (implementation) is completely unaware, only know what the software to do. Unable to see the contents of the box, so do not know how the software is implemented, do not care about the structure inside the black box, only concerned about the software input data and output results.

equivalence class: an equivalence class refers to a disjoint subset of input fields

Equivalence class Partitioning:

Valid equivalence class: Does the inspection program implement the pre-defined function and performance of the specification

Invalid equivalence class: Check whether the software functions and performance are implemented in a place that does not meet the specification requirements

Common principles of equivalence class partitioning

(1) divided by interval

(2) divided by numerical value

(3) divided by numerical value set

(4) by restrictive conditions or rules

(5) Subdivision equivalence class

Equivalence class test Case design

(1) After the equivalence class is established, all the divided equivalence class tables can be listed .

(2) A unique number is specified for each equivalence class.

(3) Design a new test case so that it overwrites as many valid equivalence classes as they have not yet covered . Repeat this step until the test case overrides all valid equivalence classes.

(4) Design a new test case to overwrite and overwrite only one invalid equivalence class that has not yet been overwritten . Repeat this step until the test case overrides all Invalid equivalence classes.

Software Test first week study