CPSC 3720 - DAY 22 MARCH 31, 2017 ================================================================================ TESTING ------- A failure is caused by an erroneous state, which is caused by a fault. Test Stub - Partial implementation of components on which the tested components depend. Test Driver - Partial implementation of component that depends on the test component. Simulates the part of the system that uses the test components. Blackbox vs Whitebox Testing ---------------------------- Blackbox Focus on the input and output behavior Ignore the internal details or structure of the component Whitebox Focuses on internal structure of the component. Every state of the object and interactions are also tested. May require input that could not be described in functional requirements. Component Testing ----------------- Reviewing the source code in a formal meeting Conducted by a team: Developers Author of the component Moderator Additional (subject expert) reviewers Time consuming process Has been shown to usually be more effective than regular testing. Greatly depends on the quality of the team members. A type of code review. Overview Author briefly presents purpose and scope of the component Preperation Reviewers become familiar with the implementation. Inspection Meeting Step through the code Team raises issues Don't try to fix the fault, just identify Rework Author revises based on the faults found Follow-up Moderator checks on quality of rework and decides in the component needs to be re-inspected Usability Testing ----------------- Compare system to user's expections, not the specification of the system. Not a formal methodology Come up with tasks you want users to be able to accomplish in the system. Have users try to use the system. Observe the participants Where do they get stuck? Does it take longer than expected? Survey what they think of the system Unit Tests ---------- Just focus on one small part of the system Reduces complexity of the tests Focuses the test Easier ot pinpoint faults Independence of testing components Unit Test techniques Equivalence Testing Boundry Testing Path Testing State Based Testing Equivalence Testing ------------------- Blackbox Technique Minimizes number of test cases Inputs partitioned into equivalence classes Only test one member of the equivalence class Criteria to determine equivalence classes Coverage - every possible input belongs to an equivalence class Disjointedness - No input belongs to multiple equivalence class Representation - If the execution leads to an erroneous state, then any other input from the same equivalence would lead to the same erroneous state. Consider a function that takes in a month and year and returns the number of days in a month. We have 3 equivalence classes for the month parameter Months with 30 days Months with 31 days February, which can have 28 or 29 days 2 Equivalence classes for the year Leap year Not leap year Pick one example from each equivalence class and find all possible combinations to get 6 test cases. Boundry Testing --------------- A type of Equivalence Testing Instead of choosing any member of an equivalence class, choose elements from the "edge" of an equivalence class Leap years are multiples of 4, but years that are divisible by 100, but not divisible by 400 are not leap years Include years 1900 and 2000 to test those boundries Include boundry invalid cases Months of 0 or 13 Developing Test Cases --------------------- What are the Equivalence Classes? What are the Boundry cases? double getCommision(Date hireDate, char job) { double commission = 0.05; Date d1 = new Date(1, 1, 2006); Date d2 = new Date(1, 1, 2011); if(hireDate < d1) { commision = .15; } else if (hireDate < d2) { commission = .10; } if (job == 'a') { commission +=.025; } return commission; } Equivalence Classes: HireDate <01/01/2006 01/01/2006 <= hireDate < 01/01/2011 >= 01/01/2011 Job =='a' !-'a' Boundry Cases HireDate 12/31/2005, 01/01/2006, 12/31/2010, 01/01/2011 job "a", "A", "b", ...