Kiểm thử Phần mềm – Software Testing Chương 2: Các khái niệm cơ bản trong kiểm thử Phần mềm

Click to edit Master text styles Second level Third level Fourth level Fifth level ‹#› Click to edit Master title style 1 Kiểm thử Phần mềm – Software TestingChương 2: Các khái niệm cơ bản trong kiểm thử Phần mềm Lương Trần Hy Hiến, Khoa CNTT, ĐH Sư phạm TpHCM Nội dung 2.1. Quy trình kiểm tra phần mềm 2.2. Kế hoạch kiểm tra (Test plan) 2.3. Tình huống kiểm tra (Test case) 2.4. Dữ liệu kiểm tra (Test Data) 2.5. Lỗi (Bug) 2.6. Báo cáo kiểm tra (Test Report) 2.7. Các vai trò 2.1 Qui trình kiểm thử PM Kiểm thử thành phần Kiểm thử của các từng thành phần chương trình; Thường là trách nhiệm của lập trình viên tạo ra thành phần đó; Các test được tạo ra từ kinh nghiệm của lập trình viên. Kiểm thử hệ thống Kiểm thử một nhóm các thành phần được kết hợp lại để tại ra hệ thống hay hệ thống con; Trách nhiệm của một đội test độc lập; Các test được tạo ra dựa trên bản đặc tả hệ thống. 2.1 Qui trình kiểm thử PM Bắt đầu Kết thúc Lập kế hoạch test Phân tích, Thiết kế test So sánh kết quảtest với test case Chuẩn bị dữliệu test Chạy ứng dụngvới bộ dữ liệu test Test Report Test Results Test Data/S Test Case Test plan 2.2. Kế hoạch kiểm tra (Test plan) Cấu trúc chung của một test plan Tên project Danh sách các Module cần test Ngày bắt đầu, ngày kết thúc Danh sách các Test case Nhân sự tham gia Tài nguyên sử dụng (Servers, Workstations, Printers,…) Kế hoạch thực hiện (sử dụng Ms Project lập kế hoạch) … 2.3. Tình huống kiểm tra (Test case) Cấu trúc chung của một test case: Tên project, module Màn hình, chức năng Mã số Tài liệu tham khảo (SRS) Mục đích Dữ liệu test Mô tả các bước (Test step) Trạng thái Ngày tạo … Test case Ví dụ: kiểm tra màn hình đăng nhập Test case Ví dụ: kiểm tra màn hình đăng nhập Project: Web testing application Module: Testing Màn hình: Đăng nhập hệ thống Chức năng: đăng nhập Mã số: TC001 Dữ liệu test Username = “hienlth”, pass = “123456” Username = “admin”, pass = “admin” Các bước thực hiện kiểm tra Test case – Test step Step no Steps Data Expected result Actual results 1 Nhập Username và ấn nút OK Username = “hienlth” Hiển thị thông báo “Vui lòng nhập username và password” 2 Nhập Password và ấn nút OK Password = “123456” Hiển thị thông báo “Vui lòng nhập username và password” 3 Nhập Username , password và ấn nút OK Username = “hienlth”Password = “abc” Hiển thị thông báo “Username và password không hợp lệ” 4 Nhập Username , password và ấn nút OK Username = “abc”Password = “hienlth” Hiển thị thông báo “Username và password không hợp lệ” 5 Nhập Username, password và ấn nút OK Username = “abc”Password = “abc” Hiển thị thông báo “Username và password không hợp lệ” 6 Nhập Username, password và ấn nút OK Username = “”Password = “” Hiển thị thông báo “Username và password không hợp lệ” 7 Nhập Username, password và ấn nút OK Username = “hienlth”Password = “123456” Hiển thị trang chính của user “hienlth” 8 Nhập Username, password và ấn nút OK Username = “admin”Password = “admin” Hiển thị trang chính của user “admin” … 2.4. Dữ liệu kiểm tra (Test Data) Test Data là gì? Test Data là bộ dữ liệu được xây dựng để chạy thử các test case. Dữ liệu trong Test Data gồm có hai loại là dữ liệu thường (normal data) và dữ liệu bắt buộc (Initial Data). Xây dựng Test Data là một khâu rất quan trọng trong tiến trình test, vì kết quả test phụ thuộc rất lớn vào dữ liệu trong Test Data. 2.4. Dữ liệu kiểm tra (Test Data) Initial Data là gì? Initial Data là các trường dữ liệu dùng để khởi tạo chương trình, bắt buộc cần phải có để hệ thống có thể làm việc được. Initial Data là một bộ phận của Test Data. 2.4. Dữ liệu kiểm tra (Test Data) Test Data do ai thực hiện? Test Data thường do Test Leader và Developer xây dựng, sau khi có tài liệu phân tích thiết kế mức chi tiết.  Dữ liệu khởi tạo (Initial Data) là phần bắt buộc cần phải có để hệ thống có thể hoạt động được, thường do lập trình viên tạo lập sau khi hoàn chỉnh từng bộ phận của hệ thống. Test Leader chịu trách nhiệm xây dựng bộ dữ liệu Test Data thông thường. Sau đó, Tester sẽ dùng các dữ liệu này để thực hiện Test Case. 2.5. Lỗi (Bug) Cấu trúc chung của Bug: Tên bug Mã số, mức độ Test case tương ứng (nếu có) Màn hình, chức năng Dữ liệu Mô tả các bước thực hiện Hình chụp màn hình/quay phim các thao tác. Trạng thái Ngày tạo … 2.5 Bug (tt) Bug và vòng đời của bug : Bug (bọ): là thuật ngữ của những người làm công việc kiểm tra phần mềm gọi các lỗi của phần mềm, là bug. Vòng đời của bug: Là thời gian của 1 bugs tồn tại từ lúc phát sinh cho tới lúc bug được sửa. 2.5 Bug (tt) Các trạng thái của bug NEW. Trạng thái này bug mới được post lên hệ thống. Ngay lập tức Bugzilla sẽ gửi mail tới thành viên liên quan (Developer, PJ Leader...) Từ New có thế chuyển qua trạng thái khác: ASSIGNED hoặc RESOLVED . Các trạng thái của bug b. ASSIGNED. Trạng thái này bug được phân công cho DEV fix, ở trạng thái này, bug chưa được fix. Từ trạng thái này, có thể chuyển qua: NEW (chuyển cho người khác fix), RESOLVED (đã fix xong bug). Các trạng thái của bug c. RESOLVED. Trạng thái này bug đã được fix xong. Kết quả có thể là FIXED, INVALID, WONTFIX, DUPLICATE, LATER hoặc REMIND. Từ trạng thái này, bug có thể chuyển qua: REOPEN, VERIFIED, CLOSED hoặc UNCONFIRMED Các trạng thái của bug c. RESOLVED (2). FIXED : Bug đã fix xong. INVALID : Vấn đề không phải bug. WONTFIX : Vì lý do nào đó, bug nào sẽ không fix. DUPLICATE : Post bị trùng với một bug nào đó đã post. WORKSFORME : LATER : bug tạm chưa fix được. REMIND : Giống LATER. Các trạng thái của bug d. REOPENED. Trạng thái này do TESTER/QC chuyển từ trạng thái RESOLVED sang. Do fix rồi mà vẫn bị lỗi hoặc gây ra lỗi khác nữa. Trạng thái này có thể chuyển sang trạng thái RESOLVED hoặc ASSIGNED. Các trạng thái của bug e. VERIFIED Trạng thái này do TESTER đã test lại xong và xác nhận đã fix bug này. Trạng thái này có thể chuyển sang trạng thái UNCONFORMED, REOPEN hoặc CLOSED. Các trạng thái của bug f. CLOSED Trạng thái này bug đã fix xong và được test lại xong. Kết thúc 1 vòng đời của một bug. Ngoại lệ bug đã đóng rồi mà khi fix bug khác, gây ra lỗi bug này nữa thì sẽ chuyển từ trạng thái CLOSED sang REOPEN. 2.6. Báo cáo kiểm tra (Test Report) Cấu trúc chung của Test report: Test plan ? Tên người thực hiện Ngày thực hiện Môi trường test Bảng mô tả module/chức năng/test case và kết quả tương ứng Kết luận, đề xuất (nếu có) …. 2.7. Các vai trò Tester Vai trò Kiểm lỗi phần mềm Kiểm lỗi bản đóng gói Kiểm lỗi tài liệu User guide Installation Guide Release Notes Troubleshooting Tester Công việc Chuẩn bị môi trường test Windows XP, 2000, 2003 Linux IE, FireFox, Netscape, Mozilla Test Database, Test data Viết test case Thực hiện test các test case trong từng môi trường khác nhau Mô tả Bug và chi tiết các bước để tạo ra bug Theo dõi quá trình Fix Bug Báo cáo kết quả test Tester Phần mềm sử dụng Web testing Test Manager Role Tester Role Manual Test (Rational Manual Test, Test Complete…) Automation Test (Rational Functional Test, Test Complete,…) Load testing Code Analysis Project Management Tool Tester Role Workflow Tester Role Cảm ơn Bài giảng này tham khảo và hiệu chỉnh từ: Slide Công nghệ Phần mềm, Trần Ngọc Bảo, ĐH Sư Phạm TpHCM. Slide Lý thuyết Kiểm tra Phần mềm, Nguyễn Ngọc Tú, ĐH Hoa Sen Slide Kiểm chứng Phần mềm, Lê Duy Hoàng, ĐH KHTN TpHCM. 28 Câu hỏi và thảo luận ? Thank you!!!