Bài giảng Kiểm thử và đảm bảo chất lượng phần mềm: Chương 3

Bài giảng Kiểm thử và đảm bảo chất lượng phần mềm: Chương 3 cung cấp cho người học những kiến thức như: Tổng quan về lỗi phần mềm; Thực hành kiểm thử; Kiểm thử tĩnh; Tổng quan về thiết kế trường hợp kiểm thử. Mời các bạn cùng tham khảo!

KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Chương KỸ THUẬT KIỂM THỬ Các nguyên lý Vòng đời Kỹ thuật kiểm thử Kiểm thử chức Kiểm thử cấu trúc Quản lý chất lượng Kỹ thuật kiểm thử Kiểm thử phần mềm Nội dung Tổng quan lỗi phần mềm Thực hành kiểm thử Kiểm thử tĩnh Tổng quan thiết kế trường hợp kiểm thử Lỗi phần mềm (Bug) Một lỗi phần mềm là sự không trùng khớp giữa chương trình và đặc tả của nó, nếu đặc tả phần mềm tồn tại và được cho là đúng Đặc tả sai  phần mềm sai Một lồi phần mềm hiện diện chương trình không làm cái mà người sử dụng đầu cuối mong muốn nó làm Cá c nhó m lỗ i phầ n mề m phô ̉ biêLỗ́ingiao diện người dùng - User interface errors 1) 2) Lỗi xử lý - Error handling 3) Lỗi liên quan tới ranh giới/biên - Boundary-related errors 4) Lỗi tính toán - Calculation errors 5) Lỗi các trạng thái đầu và sau - Initial and later states 6) Lỗi luồn kiểm soát - Control flow errors 7) Lỗi xử lý hoặc dịch dữ liệu - Errors in handling or interpreting data 8) Tranh đoạt điều khiển - Race conditions 9) Điều kiện tải - Load conditions 10) Phần cứng – Hardware 11) Kiểm soát phiên bản và mã nguồn – Source and version control 12) Tài liệu – Document 13) Các lỗi kiểm thử – Testing errors 1) User interface errors Có nhiều cách để làm cho chương trình làm việc một cách khó khăn, người ta quy chúng vào một nhóm lỗi có tên là “Lỗi giao diện người dùng” Lỗi giao diện người dùng chia thành nhiều nhóm nhỏ ­ Functionality: chương trình không làm những thứ như nó nên làm, hoăc la ̣ ̀m  môt ca ̣ ́ch khô s ̉ ở hay không hoàn chinh ̉ ­ Communication: Làm thế nào đê ti ̉ ̀m ra cách sử dung ch ̣ ương trình? Nó có  chính xác không? Có gì đó nhầm lẫn, sai lêch không? ̣ ­ Command structure: Có dễ bi lac trong ch ̣ ̣ ương trình không? Có lênh na ̣ ̀o dễ bi ̣ nhầm lẫn không? Có lỗi nào làm ban la ̣ ̃ng phí thời gian không? Vì sao? ­ Missing commands: chương trình thiếu lênh, c ̣ ứng nhắc và khó điều chinh đê ̉ ̀  phù hợp với từng đối tượng người sử dung. VD phi ̣ ́m tắt ­ Performance:chương trình chay bi châm h ̣ ̣ ̣ ơn mong đợi người dùng ­ Output: không có đu thông tin đâ ̉ ̀u ra mong muốn. VD người sử dung muô ̣ ́n xuất  đầu ra qua thiết bi đâ ̣ ̀u cuối, têp, ma ̣ ́y in 2) Error handling Không lường trước hết các sai sót của chương trình và bảo vệ chương trình trước các sai sót này Thiếu thông báo lỗi hoặc điều kiện sinh lỗi Giải quyết lỗi được phát hiện không hợp lý Vd việc bảo vệ chống lại liệu bị corrupt, kiểm tra liệu đầu vào người dùng, kiểm soát phiên bản, bỏ qua lỗi tràn nhớ, so sánh liệu, không phục lỗi, phục hồi có lỗi phần cứng 3) Boundary­related errors Bất kỳ thành phần nào của chương trình được mô tả có sự xuất hiện của miền giá trị: từ nhiều đến ít hơn, từ lớn nhất tới nhỏ nhất, từ sớm nhất tới muộn nhất, đầu tiên tới cuối cùng, ngắn nhất tới dài nhất đều cần kiểm tra ranh giới miền giá trị Chương trình thường chạy đúng và ổn định với các giá trị nằm miền xác định và hay bị gặp lỗi/ sự cố tại các giá trị nằm ngoài biên của miền xác định Tìm kiếm lỗi ranh giới: vịng lặp, khơng gian nhớ, thời gian, xử lý sai trường hợp nằm ranh giới VD ­ Số lượng sinh viên tối thiêu cua 1 l ̉ ̉ ớp tín chi la ̉ ̀ 15 tối đa là 40 sinh viên ­ Dung lượng bô nh ̣ ớ chiếm dung cua ch ̣ ̉ ương trình khi thực thi tối thiêu la ̉ ̀ 2MB  tối đa là 50MB ­ … 4) Calculation errors Hiểu sai cơng thức Sai số tính toán Tính toán sai sai thuật toán Sử dụng sai công thức Sử dụng sai kiểu dữ liệu cho công thức tính toán 5) Initial and later states Nhiều chương trình chỉ sai ở lần chạy đầu tiên, ở những lần chạy sau các thông tin khởi tạo đã được lưu trữ lại nên việc chạy chương trình không gặp lại lỗi này nữa Tìm kiếm lỗi: thiết lập mục liệu khơng, khởi tạo biến kiểm sốt vịng lặp, khởi tạo lại trỏ, … VD Lỗi lần đầu chạy file chưa được khởi tạo, 6) Control flow errors Luồng kiểm soát của một chương trình miêu tả cái mà chương trình sẽ làm tiếp theo những hoàn cảnh cụ thể Lỗi luồng kiểm soát xẩy chương trình thực hiện sai việc làm tiếp theo Lỗi thường xuất giả định trạng thái trả sai, xử lý ngoại lệ dựa cách thoát, tràn tràn đệm, thất bại việc chặn bỏ chặn ngắt, so sánh, lỗi kiểu liệu, thiếu sai mặc định - default Vd Lỗi luồng kiểm soát xẩy câu lệnh rẽ nhánh 10 Tổng quan về thiết kế trường hợp  kiểm thử Những tài liệu tester cần đọc hiểu Định hướng test tester Quy trình test Sự cần thiết test case Các thành phần test case Kỹ thuật thiết kế test case 50 Những tài liệu tester cần hiểu Requirement documents : Những yêu cầu, mong muốn, suy nghĩ khách hàng phần mềm mà họ muốn Specification documents : Những ý tưởng, dự định để thực hóa yêu cầu, mong muốn khách hàng Design documents : Cụ thể, chi tiết việc làm việc Ví dụ: Requirement documents : Khách hàng muốn có họ đươc sử dụng phần mềm Specification documents : Người dùng phải đăng nhập mật Design documents : phải có textfield username, password, password phai dài ký tự… 51 Định hướng kiểm thử Functional Requirement ( yêu cầu chức ) : test theo chức mà phần mềm cần phải có Non-functional Requirement ( yêu cầu phi chức ) : test chức mà phần mềm nên có nên giống Gồm loại non-functional: Look and feel , Boundary, Negative 52 Định hướng kiểm thử… Non-functional Requirement ­ Look and feel (cảm giác người dùng ) : theo cảm giác của người sử  dụng, thường đươc ưu tiên sau cùng vì khơng ảnh hưởng nhiều tới  phần mềm ­ Boundary (biên) : kiểm tra những giới hạn có thể có của  phần mềm.  ­ Negative (bất thường): kiểm tra chuyện gì xảy ra khi khơng đi theo  đúng quy luật phần mềm, đây là lọai test có thể tìm đươc những lỗi  quan trọng, tùy vào kinh nghiệm của tester.  53 Ví dụ Minh họa với Form login gồm có fields username, password nút submit login Functional: Chức login thành cơng với valid account Look and feel: Theo cảm giác user button nên highlight trỏ qua Boundary: giới hạn biên tối đa 20 ký tự đươc phép nhập Negative: khoảng trắng ký tự bất thường mà người nghĩ tới gây nên lỗi 54 Quy trình test Sơ đồ tổng quát 55 Quy trình test Understand Requirement: Tester phải hiểu đươc yêu cầu từ khách hàng mà developer thực từ định hướng cần phải test Test Approaches: Tester cân nhắc lựa chọn phương pháp test phù hợp với dự án test theo Black-box hay White-Box hay Gray-box Test Type: Tester cân nhắc lựa chọn loại test cần phải thực dự án requirement test, Smoke test, Monkey test, Regression test… ­ Bug type: Đinh hướng tester cần tập trung tìm những loại bug gì vd: bug liên  quan đến interface, hay bug liên quan giá trị biên ­ Interface : Xác định những interface nào cần đươc test, mối liên quan của từng  interface với nhau ­ Stability: Xác định độ ổn định của ứng dụng dựa trên tiêu chí nào, mức tối  thiểu nào có thể chấp nhận ứng dụng trươc khi giao cho khách hàng 56 Quy trình test… Test Phases: Xác đinh giai đọan bắt đầu trình test dự án, từ xác đinh thời gian, nhân sự, chuẩn bị cho việc test Design Method: Tạo Form thống , quy định testcase, report bug nhằm chuẩn bị cho việc test đươc tiến hành bước Test Tool: Lựa chọn Tool phục vụ cho việc test tự động vd nhự Quick test Pro Tool, Selenium, Canoo Webtest, Test Plan: Quản lý tiến độ, phân công nhiệm vụ việc test dự án Test Case: Tạo trường hợp cần phải test ứng dụng 57 Tại sao phải thiết kế test case?   ­ ­ ­ ­ ­ ­ ­ ­ Tìm Bugs Khơng bị trùng lắp khi test Khơng bị sót so với test theo cảm tính Có thể tái sử dụng tiết kiệm thời gian test cho  những project gần giống nhau Testcase sẽ giúp bao phủ lỗi của phần mềm Ước lượng được thời gian test Việc test thực thi chính xác hơn Dùng để training cho tester mới 58 Phân loại Dựa vào phương pháp test White-box testing: Tester thường programmer sử dụng kiến thức lập trình, hiểu sourcecode cấu trúc bên phần mềm Vd: kiểm tra chức hàm có lỗi khơng, hàm không được sử dụng Black-box testing: Tester không cần biết bên code gì, quan tâm input output để tạo testcase Ví du: Testcase cho form login với username and password 59 Phân loại Gray-box Tesing : Kết hợp Glass-box Black-box testing để tạo testcase Ví dụ: testcase cho form login vơi username and password sử dụng kiến thức HTML 60 Testcase mẫu 61 Thành phần chính của test case Testcase ID : Dùng để phân biệt testcase với Summary : Mơ tả ngắn gọn mục đích testcase, phần quan trọng testcase Preconditions: Điều kiện tiên để thực testcase Steps: Hướng dẫn để thực theo mục đích testcase Expected results: Kết mong muốn chạy testcase 62 Thành phần chính của test case Observed Results: Kết thực tế quan sát đươc chạy testcase Status: Passed, Failed, Blocked(không thể thực theo bước để chạy testcase) Environment : Môi trường test phần mềm, Firefox, Chrome, IE6,7,8,9… Note: Ghi tester test BugID: Ghi nhớ bug với testcase bị failed 63 Kỹ thuật thiết kế test case Hộp đen Hộp trắng Phân lớp tương đương Bao phủ câu lệnh Phân tích giá trị biên Bao phủ định Đồ thị nhân – Bao phủ điều kiện Đoán lỗi Bao phủ điều kiện – định Kiểm thử dựa mô hình Bao phủ đa điều kiện … … 64 ... thuật kiểm thử Kiểm thử phần mềm Nội dung Tổng quan lỗi phần mềm Thực hành kiểm thử Kiểm thử tĩnh Tổng quan thiết kế trường hợp kiểm thử 25 Vai trị con người trong việc? ?kiểm? ? thử Quy trình? ?kiểm? ?thử? ?tổng qt... Transition Kỹ thuật kiểm thử Kiểm thử phần mềm Nội dung Tổng quan lỗi phần mềm Thực hành kiểm thử Kiểm thử tĩnh Tổng quan thiết kế trường hợp kiểm thử 34 Phương pháp? ?kiểm? ?thử? ?tĩnh Xem xét đặc...Kỹ thuật kiểm thử Kiểm thử phần mềm Nội dung Tổng quan lỗi phần mềm Thực hành kiểm thử Kiểm thử tĩnh Tổng quan thiết kế trường hợp kiểm thử Lỗi? ?phần? ?mềm (Bug) Một lỗi phần