CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 0 Các khái niệm cơ bản về phần mềm kiểm thử 0 Kiểm thử phần mềm là gì? Kiểm thử phần mềm là một quá trình kiểm tra để phát hiện ra lỗi của những phần mềm, ứng d[.]
CHƯƠNG TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1 Các khái niệm phần mềm kiểm thử 1.1.1 Kiểm thử phần mềm gì? Kiểm thử phần mềm trình kiểm tra để phát lỗi phần mềm, ứng dụng nhằm cung cấp cho khách hàng, lập trình viên… thơng tin chất lượng phần mềm kiểm thử Mục đích cuối công việc để đảm bảo sản phẩm (phần mềm, ứng dụng) tạo theo mong muốn khách hàng hoạt động hiệu Với cơng ty phát triển phần mềmthì Tester (chun viên kiểm thử phần mềm) có vai trị cốt yếu để đảm bảo uy tín cơng ty, tránh trường hợp sản phẩm lỗi bị khách hàng trả nơi sản xuất 1.1.2 Các phương pháp kiểm thử Trong lĩnh vực kiểm thử phần mềm có nhiều phương pháp áp dụng Trong viết tìm hiểu phương pháp b ản áp dụng cách phổ biến rộng rãi với ưu điểm nhược điểm nó, là: kiểm thử hộp đen, kiểm thử hộp trắng kiểm thử hộp xám a Kiểm thử hộp đen: Kiểm thử hộp đen phương pháp kiểm thử mà tester không cần quan tâm đến hoạt động bên hệ thống chạy sao, khơng cần quan tâm đến dịng lệnh bên hệ thống hệ thống mà cần tập trung vào giá trị đầu vào giá trị đầu hệ thống có với kết mong đợi trường hợp kiểm thử khơng để từ đánh giá chất lượng hệ thống Chính chế nên phương pháp có ưu nhược điểm sau: Ưu điểm Nhựợc điểm - Rất phù hợp hiệu mà số - Bị giới hạn độ bao phủ trường hợp lượng dòng lệnh hệ thống kiểm thử lớn - Không cần truy cập vào dịng - Sẽ khơng hiệu thực tế tester bị giới lệnh hạn kiến thức hệ thống - Phân biệt rõ ràng quan điểm - Độ bao phủ bị thiếu tester không kiểm tra người dùng với quan điểm nhà phát đoạn lệnh hệ thống tập trung triển vào dòng lệnh dễ xảy lỗi Ưu điểm Nhựợc điểm - Khơng cần địi hỏi kiến thức - Sẽ khó để thiết kế đầy đủ trường hợp ngôn ngữ lập trình tester để kiểm thử kiểm thử hệ thống b Kiểm thử hộp trắng: Kiểm thử hộp trắng việc nghiên cứu cụ thể chi tiết luồng hoạt động dòng lệnh bên hệ thống Kiểm thử hộp trắng gọi tên khác như: Glass testing hay openbox testing Kiểm thử hộp trắng đòi hỏi tester phải có kiến thức ngơn ngữ lập trình Tester cần phải nghiên cứu vào bên thống cụ thể dịng lệnh để tìm hiểu chúng có chạy hay không Dưới ưu nhược điểm phương pháp này: Ưu điểm Nhựợc điểm - Đối với tester có kiến thức ngơn ngữ - Trên thực tế việc sử dụng tester có kiến lập trình dễ dàng để phát lỗi thức ngơn ngữ lập trình làm gia tăng dòng lệnh giá thành để phát triển phần mềm - Giúp tối ưu hóa dịng lệnh hệ thống - Đơi lúc không khả thi kiểm tra chi tiết dịng lệnh để từ phát lỗi tiềm ẩn hệ thống, có nhiều luồng khơng thể kiểm tra - Các dịng lệnh khơng cần thiết dịng - Rất khó để trì phương pháp liên lệnh có khả mang đến lỗi tiềm ẩn bị tục, cần phải có tool chuyên biệt loại bỏ tool phân tích code hay tool phát lỗi sửa lỗi - Các tester có kiến thức ngơn ngữ lập trình sau thực phương pháp dễ dàng đạt độ bao phủ lớn thực thiết kế trường hợp kiểm thử sau c Kiểm thử hộp xám: Kiểm thử hộp xám phương pháp kiểm thử mà địi hỏi tester phải có lượng kiến thức định luồng hoạt động bên hệ thống Khác với kiểm thử hộp đen, phương pháp mà tester quan tâm để việc kiểm thử thông qua giao diện người dùng, kiểm thử hộp xám đòi hỏi tester phải truy cập vào tài liệu thiết kế hệ thống hệ thống sở liệu hệ thống Do mà tester chuẩn bị tốt liệu cho việc kiểm thử trường hợp kiểm thử trình lên kế hoạch kiểm thử hệ thống Ưu điểm Nhựợc điểm - Vì kết hợp kiểm thử hộp trắng - Vì phương pháp không dựa việc truy kiểm thử hộp đen nên có ưu điểm cập code hệ thống nên không tránh hai phương pháp việc độ bao phủ trường hợp kiểm thử bị giới hạn - Các tester sử dụng phương pháp - Khi sử dụng phương pháp nhiều trường khơng dựa vào dịng lệnh hệ hợp kiểm thử bị dư thừa mà thống mà chủ yếu dựa tài liệu nhà thiết kế phần mềm chạy trường hợp định nghĩa giao diện tài liệu kiểm thử trước đặc tả chức - Trong phương pháp tester - Việc kiểm tra tất luồng đầu vào hệ thiết kế nên trường hợp kiểm thử thống khơng thể thực bị giới hạn đặc biệt xung quanh giao thức kết nối mặt thời gian kiểm thử dẫn đến có loại liệu khác nhiều luồng hoạt động hệ thống không kiểm tra - Việc kiểm thử hồn thành từ góc nhìn người dùng từ nhà thiết kế d Bảng so sánh phương pháp kiểm thử Kiểm thử hộp đen Kiểm thử hộp xám Kiểm thử hộp trắng Không cần quan tâm đến luồng Cần có kiến thức Cần nắm tồn hoạt động hệ thống định luồng hoạt luồng hoạt động bên động bên hệ hệ thống thống Được biết đến với tên gọi khác Được biết đến với Được biết đến với tên như: closed-box testing, data-driven tên testing functional testing gọi khác như: gọi khác như: clear-box translucent testing testing code-based testing Được thực người dùng Được thực Thường hồn thành cuối, kiểm thử viên lập trình người dùng cuối, kiểm kiểm thử viên lập viên thử viên lập trình trình viên viên Việc kiểm thử dựa kết Việc kiểm thử dựa Dựa toàn kiến thức mong muốn kết thực tế mà sơ đồ sở luồng hoạt động bên hệ thống trả liệu sơ đồ hệ thống luồng liệu liệu kiểm thử phù hợp mà kiểm thử viên tự thiết kế Vì quan tâm đến giá trị đầu Mức độ đầy đủ Đầy đủ tốn nhiều vào, kết đầu kết mong trường hợp kiểm thử thời gian đợi nên phương pháp tốn mức vừa phải mức thời gian đô bao phủ độ tốn thời gian vừa trường hợp không đầy đủ phải Không thích hợp để kiểm tra Khơng thích hợp để Thích hợp để kiểm tra thuật tốn hệ thống kiểm tra thuật toán thuật toán hệ thống hệ thống Kiểm thử hộp đen Kiểm thử hộp xám Kiểm thử hộp trắng Phương pháp hoàn Các miền liệu Các miền liệu giới thành chế phát lỗi giới hạn hạn test test tester có kiến thức 11.3 Các cấp độ kiểm thử phần mềm Có nhiều mức độ q trình kiểm thử phần mềm kiểm thử chức năng, kiểm thử phi chức năng, kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận Bài viết mơ tả mức độ Các mức độ kiểm thử bao gồm nhiều phương pháp khác sử dụng tiến hành kiểm thử phần mềm Các mức độ kiểm thử phần mềm là: Kiểm thử chức Kiểm thử phi chức Kiểm thử chức (Functional Testing) Kiểm thử đơn vị (Unit testing) Kiểm thử tích hợp (Integration Testing) Kiểm thử hệ thống (System Testing) Kiểm thử hồi quy (Regression testing) Kiểm thử chấp nhận (Acceptance Testing) Kiểm thử alpha (Alpha Testing) Kiểm thử beta (Beta Testing) Kiểm thử phi chức (Non-Functional Testing) o Kiểm thử hiệu (Performance testing) o Load testing o Stress testing 10 Kiểm thử tính hữu dụng (Usability testing) 11 Kiểm thử Giao diện người dùng kiểm thử tính hữu dụng (UI and Usability testing) 12 Kiểm thử bảo mật (Security testing) 13 Kiểm thử tính di động (Portability testing) 1.1.4 Các phương pháp kiểm thử người Hai phương pháp kiểm thử người chủ yếu Code Inspections Walkthroughs Hai phương pháp bao gồm nhóm người đọc kiểm tra theo mã lệnh chương trình Mục tiêu chúng để tìm lỗi mà không gỡ lỗi Một Inspection hay Walkthrough cải tiến phương pháp kiểm tra mà lập trình viên đọc chương trình họ trước kiểm thử Inspections Walkthroughs hiệu người khác kiểm thử chương trình tốt tác giả chương trình Inspections/Walkthroughs kiểm thử máy tính bổ sung cho Hiệu tìm lỗi thiếu phương pháp Và việc sửa đổi chương trình nên sử dụng phương pháp kiểm thử kỹ thuật kiểm thử hồi quy 1.2 Nguyên tắc kiểm thử phần mềm Để kiểm thử đạt hiệu tiến hành kiểm thử phần mềm cần phải tuân thủ số quy tắc sau: Quy tắc 1: Một phần quan trọng ca kiểm thử định nghĩa đầu hay kết mong muốn Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình Quy tắc 3: Nhóm lập trình khơng nên kiểm thử chương trình họ Quy tắc 4: Kiểm tra thấu đáo kết kiểm tra Quy tắc 5: Các ca kiểm thử phải viết cho trạng thái đầu vào không hợp lệ không mong muốn, cho đầu vào hợp lệ mong muốn Quy tắc 6: Khảo sát chương trình để xem liệu chương trình có thực mà cần thực phần, phần cịn lại xem liệu chương trình có thực mà khơng cần phải thực hay khơng Quy tắc 7: Tránh ca kiểm thử bâng quơ trừ chương trình thực chương trình bâng quơ Quy tắc 8: Không dự kiến kết kiểm thử theo giả thiết ngầm khơng tìm thấy lỗi Quy tắc 9: Xác suất tồn lỗi đoạn chương trình tương ứng với số lỗi tìm thấy đoạn Quy tắc 10: Kiểm thử nhiệm vụ sáng tạo có tính thử thách trí tuệ Chương 2: Thiết kế TESTCASE 2.1 Khái niệm Thiết kế test – case kiểm thử phần mềm trình xây dựng phương pháp kiểm thử phát lỗi, sai sót, khuyết điểm phần mềm để xây dựng phần mềm đạt tiêu chuẩn 2.2 Vai trò việc thiế kế TESTCASE Tạo ca kiểm thử tốt có khả phát lỗi, sai sót phần mềm cách nhiều Tạo ca kiểm thử có chi phí rẻ nhất, đồng thời tốn thời gian cơng sức 2.3 Quy trình thiết kế TESTCASE Một lý quan trọng kiểm thử chương trình thiết kế tạo ca kiểm thử - Test case có hiệu Với ràng buộc thời gian chi phí cho, vấn đề then chốt kiểm thử trở thành: Tập tất ca kiểm thử có khả tìm nhiều lỗi nhất? Hộp đen Phân lớp tương đương Hộp trắng Bao phủ câu lệnh Phân tích giá trị biên Bao phủ định Đồ thị nguyên nhân – kết Bao phủ điều kiện Đoán lỗi Bao phủ điều kiện – định Bao phủ đa điều kiện Thông thường, phương pháp hiệu kiểm tra tất đầu vào ngẫu nhiên – trình kiểm thử chương trình việc chọn ngẫu nhiên tập giá trị đầu vào Về mặt khả tìm nhiều lỗi nhất, tập hợp ca kiểm thử chọn ngẫu nhiên có hội tập hợp tối ưu hay gần tối ưu Sau số phương pháp để chọn tập liệu kiểm thử cách thông minh Để kiểm thử hộp đen kiểm thử hộp trắng cách thấu đáo khơng thể Do đó, chiến lược kiểm thử hợp lý chiến lược kết hợp sức mạnh hai phương pháp trên: Phát triển kiểm thử nghiêm ngặt vừa việc sử dụng phương pháp thiết kế ca kiểm thử hướng hộp đen sau bổ sung thêm ca kiểm thử việc khảo sát tính logic chương trình, sử dụng phương pháp hộp trắng Mỗi phương pháp có ưu điểm khuyết điểm riêng, để có tập ca kiểm thử tối ưu, cần kết hợp hầu hết phương pháp Quy trình thiết kế ca kiểm thử bắt đầu việc phát triển ca kiểm thử sử dụng phương pháp hộp đen sau phát triển bổ sung ca kiểm thử cần thiết với phương pháp hộp trắng 2.3.1 Kiểm thử hộp trắng – Kiểm thử bao phủ logic Kiểm thử hộp trắng có liên quan tới mức độ mà ca kiểm thử thực hay bao phủ tính logic (mã nguồn) chương trình Kiểm thử hộp trắng việc thực đường chương trình, việc kiểm thử đầy đủ đường mục đích khơng thực tế cho chương trình với vịng lặp Các tiêu chuẩn kiểm thử bao phủ logic gồm có: Bao phủ câu lệnh – Statement Coverage Tư tưởng: Thực câu lệnh chương trình lần Xét ví dụ với đoạn mã lệnh JAVA sau: public void foo (int a, int b, int x){ if (a>1 && b==0) { x=x/a;} if (a==2||x>1){ x=x+1; } } Hình 2.1 Một chương trình nhỏ để kiểm thử Bạn thực câu lệnh việc viết ca kiểm thử đơn qua đường ace Tức là, việc đặt A=2, B=0 X=3 điểm a, câu lệnh thực lần (thực tế, X gán giá trị nào) Thường tiêu chuẩn Ví dụ, có lẽ định phép or phép and lỗi khơng phát Hay định thứ hai mà bắt đầu với x>0, lỗi khơng tìm Cũng vậy, có đường qua chương trình mà x khơng thay đổi (đường abd) Nếu lỗi, lỗi khơng tìm Hay nói cách khác, tiêu chuẩn bao phủ câu lệnh q yếu mà thường vơ ích Bao phủ định – Decision coverage Tư tưởng: Viết đủ ca kiểm thử mà định có kết luận hay sai lần Nói cách khác, hướng phân nhánh phải xem xét kỹ lưỡng lần bao phủ định trước không làm điều này; chúng sử dụng kết false định H kết true định K Lí do, hình 2.2, kết điều kiện biểu thức and or cản trở hay ngăn chặn việc ước lượng định khác Ví dụ, điều kiện and sai, không cần kiểm tra điều kiện biểu thức Tương tự vậy, điều kiện or khơng cần kiểm tra điều kiện cịn lại Do đó, lỗi biểu thức logic khơng phải lúc phát tiêu chuẩn bao phủ điều kiện bao phủ định/điều kiện Bao phủ đa điều kiện – Multiple condition coverage Tư tưởng: Viết đủ ca kiểm thử mà tất kết hợp kết điều kiện định, tất điểm vào phải gọi lần Ví dụ, xét chuỗi mã lệnh sau: NOTFOUND = TRUE; DO I=1 TO TABSIZE WHILE (NOTFOUND); /*SEARCH TABLE*/ …searching logic…; END; Bốn tình để kiểm thử là: ITABSIZE NOTFOUND có giá trị sai (mục vào cuối bảng) Dễ nhận thấy tập hợp ca kiểm thử thỏa mãn tiêu chuẩn đa điều kiện thỏa mãn tiêu chuẩn bao phủ định, bao phủ điều kiện bao phủ định/điều kiện Quay lại hình 2.1, ca kiểm thử phải bao phủ kết hợp: A>1, B= A>1, B0 A