Kiểm thử phần mềm

Lý do, định nghĩa kiểm thử Các định nghĩa cơ bản: Error, Fault, Failure, Incident Test, Testcase Trường hợp kiểm thử (Test cases) Sơ đồ Venn Các trường hợp kiểm thử Functional Testing Structural Testing Thảo luận: Functional Structural Lỗi phân loại lỗi Level of Testing

Software Testing A Perspective on Testing 1/31 Nội dung  Lý do, định nghĩa kiểm thử  Các định nghĩa bản:   Error, Fault, Failure, Incident Test, Testcase  Trường hợp kiểm thử (Test cases)  Sơ đồ Venn  Các trường hợp kiểm thử   Functional Testing Structural Testing  Thảo luận: Functional & Structural  Lỗi & phân loại lỗi  Level of Testing 2/31 Lý do, định nghĩa kiểm thử  Có hai lý chính:   Để đánh giá chất lượng phần mềm Để phát vấn đề  Chúng ta thực kiểm thử biết làm sai, đặc biệt lĩnh vực phần mềm  Định nghĩa kiểm thử: Kiểm thử trình thực chương trình với mục đích:  Tìm lỗi  Để phần mềm thực chức cách đắn 3/31 Các định nghĩa  Error (sai lầm):  Là sai lầm người mắc phải trình làm phần mềm, đồng nghĩa với từ “mistake” Ví dụ lập trình viên mắc sai lầm việc coding ta gọi bug  Fault (lỗi):  Fault kết error hay nói xác thể error Ví dụ đoạn văn lấy yêu cầu khách hàng, sơ đồ luồng liệu làm thiết kế…  Failure(thất bại):  Một thất bại xảy thực thi fault (thông thường xảy mã nguồn)  Incident (sự kiện):  Là biểu (hoặc số biểu hiện) xảy failure, để thông báo cho người dùng biết xuất failure 4/31 Các định nghĩa (2)  Test (kiểm thử):  Kiểm thử trình tìm failure, chứng tỏ thực chương trình  Testcase (trường hợp kiểm thử):  Một trường hợp kiểm thử tương ứng với thực chương trình với tập liệu đầu vào, liệu đầu mong muốn 5/31 Trường hợp kiểm thử (Test cases)  Vấn đề cốt lõi kiểm thử phần mềm xác định tập trường hợp kiểm thử cho nội dung mà ta cần kiểm thử  Các thông tin cần phải có trường hợp kiểm thử: :   Dữ liệu đầu vào, gồm có loại: liệu tiền điều kiện (pre-condition), liệu đầu vào thực cho testcase Dữ liệu đầu ra, gồm loại: liệu hậu điều kiện (postcondition), liệu đầu thực tế  Các trường hợp kiểm thử nên có định danh, lý kiểm thử, nên lưu lại lịch sử thực thi trường hợp kiểm thử, bao gồm: thực hiện, có lỗi hay lỗi phiên phần mềm kiểm thử  Kiểm thử có giá trị mã nguồn 6/31 Các thông tin trường hợp kiểm thử  Các thông tin trường hợp kiểm thử Định danh: Mục đích: Tiền điều kiện: Dữ liệu vào: Dữ liệu ra: Dữ liệu mong muốn: Lịch sử thực hiện: Ngày : kết quả: Phiên bản: Người thực 7/31 Vòng đời kiểm thử Fix error Đặc tả yêu cầu Sửa lỗi error Fault Thiết kế Cô lập lỗi error Fault Phân loại lỗi Cài đặt Fault Incident Kiểm thử 8/31 Sơ đồ Venn  Kiểm thử phần mềm liên quan đến hành vi chương trình  Một khó khăn người kiểm thử tài liệu chủ yếu viết viết cho người phát triển phần mềm, trọng vào cấu trúc hành vi  Chúng ta xem xét sơ đồ venn để làm rõ thêm vấn đề kiểm thử 9/31 Sơ đồ Venn (2) Program behaviors S P Specification Program (expected) (observed) 10/31 Nội dung, Mục tiêu kiểm thử cấu trúc  Nội dung:     Mọi câu lệnh (phép gán, phép tính logic,…) Mọi điều kiện Logic (rẽ nhánh) Mọi flow xử lý chương trình (Function A-> FunctionA1>FunctionA2) Mọi cấu trúc liệu dùng  Mục tiêu:     Mọi đường độc lập module cần thực lần Mọi ràng buộc logic thực phía (true) & phía sai (false) Tất vòng lặp biên & biên vận hành phải thực Mọi cấu trúc liệu nội dùng để đảm bảo hiệu lực thi hành no 18/31 Kĩ thuật sử dụng, mức độ bao phủ  Thường sử dụng lý thuyết đồ thị (Graph theory – Chapter 4) :   Mỗi nút (hình tròn) biểu thị hay số lệnh , thay cho điểm hội tụ đường điều khiển Mỗi cạnh nối nút biểu diễn dòng điều khiển  Mức độ bao phủ   Mong muốn kiểm tra tất lệnh (câu lệnh) có chương trình => khó khối lượng lớn Do thiết kế phải tính tới cân xứng “mức độ bao phủ” “năng suất” 19/31 Ví dụ sử dụng lý thuyết đồ thị buy(dress, bag) { A A if dress already in bag B display “already bought it” else C C B if bag is full D display “bag is full” D E else E F G F buy dress display “buy successful” end if end if G } 20/31 Mục đích cuối A What path coverage is achieved by ABG, ACDFG, ACEFG? C B D E F G in total covered So 3/3 = 100% path coverage 21/31 Lý thực Structural Testing $14,000 Percentage of Bugs 85% % Defects Introduced in this phase % Defects found in in this phase $1000 $25 $130 Coding Unit Test $ Cost to repair defect in this phase $250 Funct Test System Post Test Release Source: Applied Software Measurement, Capers Jones, 1996 22/31 Thảo luận: Functional & Structural  Functional :   Không dựa vào source code Thường dựa vào đặc tả (SRS,…) để xây dựng TCs Nếu SRS ko mô tả, mà source code implement ko phản ánh  Structural   Dựa vào source code Code thường dựa vào SDD Nếu source code implement thiếu so với SRS (do SDD làm sơ sài,…) nhìn vào source code ko nhận thiếu sót 23/31 Lỗi & phân loại lỗi  Xoay quanh khác biệt Process & Product:   Process: Chỉ dẫn cách thức, phương pháp làm Product: Kết cuối process  Testing and Software Quality Assurance (SQA) SQA cố gắng cải tiến product cách cải tiến process  SQA liên quan nhiều tới cách giảm thiểu lỗi trình phát triển, Testing liên quan tới tìm lỗi sản phẩm => Cả hưởng lợi từ việc định nghĩa rõ ràng kiểu lỗi  24/31 Phân loại lỗi  Lỗi phân loại theo nhiều cách:   Lỗi phát sinh giai đoạn phát triển (Development) Lỗi phát sinh triên khai,… 25/31 Phân loại lỗi (1)  Input/Output Faults : Type Instances Example Input Correct input not accepted Nhập số lượng học viên la: a Incorrect input accepted DL nhập sai => Lấy default value Description wrong or missing Mô tả nhầm: CompanyID, UserID Parameters wrong or missing Sai kiểu param Wrong format 200.000 or 20,000 Wrong result Kết sai Correct result at wrong time (too early, too late) Chưa login thành công bật cờ online Output Incomplete or missing result Spurious result Fix sẵn giá trị, ko xử lý thật Spelling/grammar Cosmetic 26/31 Phân loại lỗi (2)  Logic Faults: Instances Example Missing case(s) Duplicate case(s) Tính tổng lần (+=) Extreme condition neglected – Thiếu ĐK cuối ĐK: Nếu >=1000 lấy 1000, tinh dc kq ko kiểm tra ĐK mà insert vao BD Misinterpretation Hiểu sai, dịch sai or Spec ko rõ ràng Missing condition Confirm message: Yes/No deu xu ly Extraneous condition(s) ĐK ko Test of wrong variable Incorrect loop iteration Ko dung while{} mà dùng {}while Wrong operator (e.g., < instead ≤) 27/31 Phân loại lỗi (3)  Computation Faults: Instances Example Incorrect algorithm Missing computation Tràn số Incorrect operand Sai toán hạng Incorrect operation Sai toán tử, phép tính Parenthesis error Thiếu, thừa ngoặc đơn, group ko Insufficient precision (round-off, truncation) Làm tròn số sai Wrong built-in function Hàm float javascript bị sai với số float có > 16 số 28/31 Phân loại lỗi (4)  Interface Faults: Instances Example Incorrect interrupt handling Nhấn đồng thời chuột phải, chuột trái I/O timing Call to wrong procedure Call to non-existent procedure Parameter mismatch (type, number) Incompatible types Kiểu trả không phù hợp Superfluous inclusion 29/31 Phân loại lỗi (5)  Data Faults: Instances Example Incorrect initialization Khởi tạo biến sai, ví dụ: string strName = null; Incorrect storage/access Lỗi truy cập file, DB Wrong flag/index value Incorrect packing/unpacking BD ko tương ứng với Package (source code) Wrong variable used Wrong data reference Scaling or units error Incorrect data dimension Độ dài field: Name 30, insert 50 kí tự Incorrect subscript Incorrect type Incorrect data scope Sensor data out of limits 30/31 Level of Testing  Mô hình chữ V: 31/31 Thanks for your attention 32