《SELectureNotesIntroup》由会员分享，可在线阅读，更多相关《SELectureNotesIntroup（14页珍藏版）》请在金锄头文库上搜索。
1、SE 433/333 Software Testing !square (3) = 6 A failure A defect SE433 - Spring 2013 LN1-25 3/18/13 A Simple Example ! For any integer n, square (n) = n*n. int square (int x) return x*2; !square (2) = 4 Correct result Not a failure SE433 - Spring 2013 LN1-26 3/18/13 The First Software Bug ! Moth found
2、 trapped between points at Relay # 70, Panel F ! Mark II Aiken Relay Calculator ! Harvard University ! September 9, 1945. SE433 - Spring 2013 On display in Smithsonian A Self Assessment Test LN1-28 3/18/13 Test the Following Program ! The program reads in 3 integer values that represent the lengths
3、of the sides of a triangle. ! The program prints a message that states whether the triangle is ! Equilateral (all 3 sides are equal) ! Isosceles (exactly 2 of the 3 sides are equal) ! Scalene (all 3 sides are of a different length) Write a set of test cases that you feel would adequately test this p
4、rogram. SE433 - Spring 2013 How Did You Do? Fundamentals of Testing LN1-31 3/18/13 Software Testing ! Software testing is ! the process of executing a program (or parts of a program) with the intention of finding defects ! The purpose of testing ! to find defects. ! to discover every conceivable wea
5、kness in a software product. SE433 - Spring 2013 1. Software testing is not debugging. 2. Software testing is not quality assurance LN1-32 3/18/13 Software Testing vs Quality Assurance (QA) ! Testing is necessary but not sufficient for QA ! Testing contributes to improve quality by identifying probl
6、ems. ! QA sets standards that project members (including testers) should follow in order to build a better software. SE433 - Spring 2013 LN1-33 3/18/13 Ad Hoc Testing ! Testing carried out informally ! No formal test preparation ! No recognized test design technique is used ! Expected results not de
7、fined ! Arbitrariness guides the test execution activity Ad hoc testing is not sufficient. SE433 - Spring 2013 LN1-34 3/18/13 Black Box Testing ! Treats a program or system as a black box ! Design test cases without the knowledge of internal structure and design of the system ! Design test cases bas
8、ed on the functional requirements of the system ! a.k.a: functional testing ! Send the system inputs, observe the outputs, decide if the system passed or failed the test ! Sometimes you dont have access to source code SE433 - Spring 2013 LN1-35 3/18/13 White Box Testing ! Open up the box! ! a.k.a: g
9、lass box, clear box, or structural testing ! Design test cases by examining the internal design and source code of the program ! Require detailed knowledge of its structure ! Introduce the idea of coverage: ! How adequate, or thorough, is the test suite? SE433 - Spring 2013 LN1-36 3/18/13 More Termi
10、nologies of Testing ! Test case ! A test case consists of inputs, steps/actions, and expected results, i.e., pass-fail criterion ! Test suite ! A group of test cases (usually organized around some principles) ! Test plan ! A document that specifies how a system will be tested, including criteria for
11、 success, i.e., the exit criteria. ! Testing process ! The testing process involves developing test plans, designing test cases, running the test cases, and evaluating the results SE433 - Spring 2013 LN1-37 3/18/13 Software Analysis ! Software analysis is ! the process of finding defects in a progra
12、m (or parts of a program) without executing the program. ! a.k.a. static analysis ! Compare to software testing ! Same purpose, different techniques ! Software analysis can be ! automated, i.e., using tools ! static analyzers ! manual, e.g., ! inspection, code review SE433 - Spring 2013 Principles o
13、f Software Testing LN1-39 3/18/13 Make No Assumptions ! Do not plan a testing effort under the tacit assumption that no defects will be found. SE433 - Spring 2013 LN1-40 3/18/13 Define Expected Results ! A necessary part of a test case is a definition of the expected output or results. ! Thoroughly
14、inspect the results of each test. ! Better: automated inspection, assertions Actual output!Expected output!? SE433 - Spring 2013 LN1-41 3/18/13 Independent Testing ! A programmer should avoid attempting test his or her own program. ! A programming organization should not test its own programs. SE433
15、 - Spring 2013 ! !independent tester!Must learn about the system,! !but, will attempt to break it! !and, is driven by quality!developer!Understands the system ! !but, will test “gently“! !and, is driven by “delivery“!LN1-42 3/18/13 Test the Invalid and Unexpected ! Test input conditions that are a)
16、invalid and unexpected b) valid and expected. ! Examining a program to see whether it a) does not do what it is supposed to do b) does what it is not supposed to do “Bugs lurk in corners ! and congregate at ! boundaries .“!Boris Beizer!SE433 - Spring 2013 LN1-43 3/18/13 Avoid Throwaway Test Cases ! Avoid throwaway (ad hoc) test cases unless the program is a truly a throwaway program. ! Prefer systematic, repeatable, and
