Software Engineering Lecture Slides Ivan Marsic Rutgers University LECTURE 7 Software Testing

Software Engineering Lecture Slides Ivan Marsic Rutgers University LECTURE 7 Software Testing 2 Topics • Overview of Software Testing • Test Coverage and Code Coverage • Practical Aspects of Unit Test[.]

LECTURE 7: Software Testing Ivan Marsic Rutgers University Topics • • • • Overview of Software Testing Test Coverage and Code Coverage Practical Aspects of Unit Testing Integration and System Testing Overview of Software Testing • “Test chứng tỏ có mặt lỗi, khơng chứng tỏ khơng có lỗi.” —Edsger W Dijkstra • Một lỗi (fault, “defect”, “bug,”) phần tử phần cứng phần mềm có sai sót mà gây cố hệ thống • Test-Driven Development (TDD) • Mỗi bước trình phát triển phải bắt đầu kế hoạch cách kiểm tra xem kết đạt mục tiêu hay chưa • Developer khơng nên tạo xuất phẩm (a system requirement, a UML diagram, or source code) mà khơng biết cách test • Một test case (ca kiểm thử) lựa chọn cụ thể input dùng kiểm thử chương trình • Một test tập hữu hạn test case Why Testing is Hard • Vấn đề quan trọng cần cân nhắc: – Test nhiều trường hợp tốt, chi phí có hạn • Mục tiêu tìm lỗi nhanh tốt rẻ tốt – Lí tưởng: với lỗi, ta cần thiết kế test case để phát lỗi chạy • Thực tế, ta phải chạy nhiều test case “thất bại” chúng không phát lỗi Logical Organization of Testing Component code Component code ( Not necessarily how it’s actually done! ) Unit test Te st Unit test ed co m po ne nt Integration test Component code Unit test Ensure that each component works as specified Integrated modules System test System in use Ensures that all components work together Function test Verifies that functional requirements are satisfied Quality test Verifies nonfunctional requirements Acceptance test Customer verifies all requirements Installation test Testing in user environment Các loại test • Unit test: test riêng rẽ cô lập component (phương thức, lớp, vài lớp nhỏ) Không động đến sở liệu, đĩa cứng… • Integration test – kiểm thử tích hợp: test việc tích hợp component với xem chúng có làm việc với khơng • System test – kiểm thử hệ thống: test toàn hệ thống xem có thỏa mãn yêu cầu chức phi chức • Acceptance test – kiểm thử chấp nhận: Khách hàng test toàn hệ thống (thiết kế pha phân tích u cầu) • Regression test – kiểm thử hồi quy: Khi hệ thống phải sửa thêm hay thay đổi yêu cầu, toàn chức cũ phải test lại để đảm bảo phần sửa đổi không ảnh hưởng đến phần cũ Acceptance Tests - Examples [ Recall Section 2.2: Requirements Engineering ] Input data • Test with the valid key of a current tenant on his/her apartment (pass) Expected result • Test with the valid key of a current tenant on someone else’s apartment (fail) • Test with an invalid key on any apartment (fail) • Test with the key of a removed tenant on his/her previous apartment (fail) • Test with the valid key of a just-added tenant on his/ her apartment (pass) Example: Test Case for Use Case [ Recall Section 2.3.3: Detailed Use Case Specification ] Test-case Identifier: TC-1 Use Case Tested: UC-1, main success scenario, and UC-7 Pass/fail Criteria: The test passes if the user enters a key that is contained in the database, with less than a maximum allowed number of unsuccessful attempts Input Data: Numeric keycode, door identifier Test Procedure: Expected Result: Step Type in an incorrect System beeps to indicate failure; keycode and a valid door records unsuccessful attempt in the database; identifier prompts the user to try again flashes a green light to indicate success; Step Type in the correct System records successful access in the database; keycode and door identifier disarms the lock device Các kiểu thiết kế test • Black box testing – kiểm thử hộp đen: phân tích chương trình cách thử input khác nhau, không quan tâm cài đặt Thương dùng cho acceptance test • White box testing – kiểm thử hộp trắng: chọn liệu test với kiến thức cài đặt (kiến trúc, thuật tốn, mã chương trình) Thường dùng cho unit test Test Coverage • Test coverage đo xem phần đặc tả code kiểm tra test • Code coverage đo xem phần code kiểm tra test • Các tiêu chí đo code coverage: – – – – equivalence testing boundary testing control-flow testing state-based testing 10 Đảm bảo State Coverage  Test phủ trạng thái xác định 01 lần (mỗi trạng thái nằm 01 test case)  Phủ transition hợp lệ 01 lần  Kích hoạt transition khơng hợp lệ 01 lần 19 Quy trình test Arrange / setup: Tạo thứ cần test mơi trường test Act: Kích hoạt thao tác cần test fixture Assert / verify: Kiểm tra xem trạng thái thực (actual state) có trạng thái trơng đợi (expected state) hay khơng 20 Các khía cạnh thực tiễn Unit Testing • Unit cần test gọi fixture, hay SUT (system under test) • Mock objects: – Một test driver giả lập phần hệ thống kích hoạt hoạt động SUT – Một (vài) test stub giả lập component mà SUT gọi • Quy trình test: Tạo SUT, test driver, stub Cho test driver kích hoạt thao tác SUT Kiểm tra xem trạng thái thực (actual state) có trạng thái trơng đợi (expected state) hay không 21 Testing the KeyChecker (Unlock Use Case) Test driver : Controller enterKey() k : Key : Checker : KeyStorage start() k := create() val := checkKey(k) testDriver : loop [for all stored keys] sk := getNext() compare() Tested component : Checker Test stubs k : Key : KeyStorage k := create() result := checkKey(k) loop [for all stored keys] sk := getNext() compare() display result (a) (b) 22 xUnit / JUnit • Các phương thức dạng assert_*_() thường dùng để kiểm tra trạng thái Chúng định nghĩa trạng thái trông đợi báo lỗi trạng thái thực khơng giống • http://www.junit.org/ • Ví dụ: – assertTrue(4 == (2 * 2)); – assertEquals(expected, actual); – assertNull(Object object); – v.v 23 Example Test Case Listing 2-1: Example test case for the Key Checker class public class CheckerTest { // test case to check that invalid key is rejected @Test public void checkKey_anyState_invalidKeyRejected() {   // set up Checker checker = new Checker( /* constructor params */ );   // act Key invalidTestKey = new Key( /*setup with invalid code*/ ); boolean result = checker.checkKey(invalidTestKey);   // verify assertEqual(result, false); } } 24 Đặt tên phương thức cho test case Set up Act 〈methodName〉_〈startingState〉_〈expectedResult〉 Verify Ví dụ tên phương thức cho test case với nội dung: kiểm tra hàm checkKey() ln reject khóa khơng hợp lệ checkKey_anyState_invalidKeyRejected() 25