软件测试 英文PPT 笔记

软件测试

来源:

 

主要内容:

本质

术语

分类

调试

IEEE标准

 

定义:

•         Glen Myers       Testing is the process of executing a program with the intent of finding errors

•         Paul Jorgensen

•         Testing is obviously concerned with errors, faults, failures and incidents. A test is the act of exercising software with test cases with an objective of

•         Finding failure

•         Demonstrate correct execution

 

测试的生命周期:

      

 

术语:

•         Error

–        Represents mistakes made by people

•         Fault

–        Is result of error. May be categorized as

•         Fault of Commission – we enter something into representation that is incorrect

•         Fault of Omission – Designer can make error of omission, the resulting fault is that something is missing that should have been present in the representation

•         Failure

–        Occurs when fault executes.

•         Incident

–        Behavior of fault. An incident is the symptom(s) associated with a failure that alerts user to the occurrence of a failure

•         Test case

–        Associated with program behavior. It carries set of input and list of expected output

•         Verification

–        Process of determining whether output of one phase of development conforms to its previous phase.

•         Validation

–        Process of determining whether a fully developed system conforms to its SRS document

Verification versus Validation

 

•         Verification is concerned with phase containment of errors

•         Validation is concerned about the final product to be error free

 

 

测试分类:

•         There are two levels of classification

–        One distinguishes at granularity level

•         Unit level

•         System level

•         Integration level

–        Other classification (mostly for unit level) is based on methodologies

•         Black box (Functional) Testing

•         White box (Structural) Testing

•         2, 5

–        Specified behavior that are not tested

•         1, 4

–        Specified behavior that are tested

•         3, 7

–        Test cases corresponding to unspecified behavior

 

•         2, 6

–        Programmed behavior that are not tested

•         1, 3

–        Programmed behavior that are tested

•         4, 7

–        Test cases corresponding to un-programmed behaviors

–         

•         there are no test cases, the testing is incomplete

•         If there are test cases that correspond to unspecified behaviors

–        Either such test cases are unwarranted

–        Specification is deficient (also implies that testers should participate in specification and design reviews)

测试方法:

•         Functional (Black box) inspects specified behavior

•         Structural (White box) inspects programmed behavior

 

•         Few set of guidelines available

•         A logical approach could be

–        Prepare functional test cases as part of specification. However they could be used only after unit and/or system is available.

–        Preparation of Structural test cases could be part of implementation/code phase.

–        Unit, Integration and System testing are performed in order.

单元测试的本质:

•         Applicable to modular design

–        Unit testing inspects individual modules

•         Locate error in smaller region

–        In an integrated system, it may not be easier to determine which module has caused fault

–        Reduces debugging efforts

测试用例

•         Test case is a triplet [I, S, O] where

–        I is input data

–        S is state of system at which data will be input

–        O is the expected output

•         Test suite is set of all test cases

•         Test cases are not randomly selected. Instead even they need to be designed.

测试用例需要设计

•         Almost every non-trivial system has an extremely large input data domain thereby making exhaustive testing impractical

•         If randomly selected then test case may loose significance since it may expose an already detected error by some other test case

•         Number of test cases do not determine the effectiveness

•         Each test case should detect different errors

 

黑盒测试

•         Equivalence class partitioning   等价类划分

•         Boundary value analysis          边界值分析

•         Comparison testing                 比较测试

•         Orthogonal array testing          矩阵测试(正交阵列?)

•         Decision Table based testing    基于决策表测试

–        Cause Effect Graph

•         等价类划分和边界值分析经常有共同的地方,测试时选值要选边界值

 

 

因果图:

•           Testing would be a lot easier:

–        if we could automatically generate test cases from requirements.

•         Work done at IBM:

–        Can requirements specifications be systematically used to design functional test cases?

•         Examine the requirements:

–        restate them as logical relation between inputs and outputs.

–        The result is a Boolean graph representing  the relationships

•         called a cause-effect graph.

•         Convert the graph to a decision table:

–        each column of the decision table corresponds to a test case for functional testing.

创建步骤:

•         Study the functional requirements.

•         Mark and number all causes and effects.

•         Numbered causes and effects:

–        become nodes of the graph.

•         Draw causes on the  LHS

•         Draw effects on the RHS

•         Draw logical relationship between causes and effects

–        as edges in the graph.

•         Extra nodes can be added

–        to simplify the graph

•         Refer “On the Experience of Using Cause-Effect Graphs for Software Specification and Test Generation” by Amit Paradkar. ACM Publications

白盒测试

•           Statement coverage

•         Branch coverage

•         Path coverage

•         Condition coverage

•         Mutation testing

•         Data flow-based testing

 

文件:	SoftwareTesting.rar
大小:	81KB
下载:	下载