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

 Thảo luận: Functional & Structural

 Lỗi & phân loại lỗi

Lý do, định nghĩa kiểm thử

 Có hai lý do chính :

 Để đánh giá về chất lượng phần mềm

 Để phát hiện ra các vấn đề

 Chúng ta thực hiện kiểm thử vì biết chắc rằng chúng ta

có thể làm sai, đặc biệt là trong lĩnh vực phần mềm

Các định nghĩa cơ bản

 Error (sai lầm):

 Là sai lầm do con người mắc phải trong quá trình làm phần

mềm, nó đồng nghĩa với từ “mistake” Ví dụ khi lập trình viên mắc sai lầm trong việc coding thì ta gọi đó là bug

 Fault (lỗi):

 Fault là kết quả của error hay nói chính xác là thể hiện của error

Ví dụ nó có thể là đoạn văn bản khi lấy yêu cầu khách hàng, hoặc có thể là sơ đồ luồng dữ liệu khi làm thiết kế…

Các định nghĩa cơ bản (2)

 Test (kiểm thử):

 Kiểm thử là quá trình tìm ra failure, hoặc chứng tỏ rằng sự thực

hiện chương trình là đúng

 Testcase (trường hợp kiểm thử):

 Một trường hợp kiểm thử tương ứng với thực hiện chương trình

với tập dữ liệu đầu vào, và các dữ liệu đầu ra mong muốn

Trường hợp kiểm thử (Test cases)

trường hợp kiểm thử cho nội dung mà ta cần kiểm thử.

 Dữ liệu đầu vào, gồm có 2 loại: dữ liệu tiền điều kiện

(pre-condition), dữ liệu đầu vào thực cho testcase

 Dữ liệu đầu ra, gồm 2 loại: dữ liệu hậu điều kiện (postcondition),

dữ liệu đầu ra thực tế

kiểm thử, ngoài ra cũng nên lưu lại lịch sử thực thi các

trường hợp kiểm thử, bao gồm: khi nào và ai thực hiện, có lỗi hay không có lỗi và phiên bản của phần mềm kiểm thử.

Các thông tin chính của trường hợp kiểm

Vòng đời kiểm thử

Kiểm thử Cài đặt

Sơ đồ Venn

 Kiểm thử phần mềm về cơ bản là liên quan đến hành vi

của chương trình.

 Một trong những khó khăn của người kiểm thử là các tài

liệu chủ yếu được viết bởi hoặc viết cho những người phát triển phần mềm, do đó nó chú trọng vào cấu trúc hơn là hành vi

 Chúng ta xem xét một sơ đồ venn để làm rõ thêm các

vấn đề trong kiểm thử.

Sơ đồ Venn (2)

Program behaviors

Specification (expected)

Program (observed)

 Phần giao nhau của S và P là phần đúng, những hành vi

này có cả trong đặc tả và trong cài đặt.

Sơ đồ Venn (4)

Test case (Verified)

Specification (expected)

Program (observed)

T

1 2

3 4

7 5

6

Sơ đồ venn (5)

 Chúng ta thấy có những hành vi có trong đặc tả nhưng

không có trường hợp kiểm thử tương ứng (test case) thì các trường hợp kiểm thử là chưa đầy đủ.

 Có những trường hợp kiểm thử không có hành vi tương

ứng trong đặc tả, lúc đó xảy ra 2 trường hợp hoặc là các trường hợp kiểm thử là không đảm bảo hoặc là đặc tả bị thiếu.

 Người kiểm thử cần làm những gì để cho vùng 1 là lớn

nhất có thể? Hay làm thế nào để xác định được các

trường hợp kiểm thử trong T Điều này phụ thuộc vào phương pháp kiểm thử.

Xác định các trường hợp kiểm thử

 Có hai cách tiếp cận chính để xác định các trường hợp

kiểm thử đó là:

 Kiểm thử theo chức năng (Function testing)

 Kiểm thử theo cấu trúc (Structural Testing)

Kiểm thử theo chức năng

 Kiểm thử theo chức năng là dựa trên việc nhìn nhận bất

kì chương trình nào cũng gồm các hàm ánh xạ các giá trị

từ miền vào sang miền dữ liệu ra.

 Với cách tiếp cận theo chức năng để xác định các

trường hợp kiểm thử ta chỉ quan tâm đến tài liệu đặc tả phần mềm.

 Không cần quan tâm đến nội dung cài đặt chỉ quan tâm

đến đầu vào và đầu ra Phương pháp này còn gọi là

phương pháp kiểm thử kiểu “hộp đen” (black box)

Kiểm thử theo chức năng (2)

 Ưu điểm:

 Chúng độc lập với cách thức cài đặt phần mềm, vì vậy nếu

chúng ta thay đổi cách thức cài đặt thì vẫn có thể sử dụng được các trường hợp kiểm thử

 Chúng ta có thể thực hiện kiểm thử song song với quá trình cài

đặt phần mềm, làm giảm thời gian phát triển dự án

 Nhược điểm:

 Có thể gây dư thừa các trường hợp kiểm thử

 Các trường hợp kiểm thử theo chức năng vẫn chưa phủ được

hết chương trình và vẫn có thể có những lỗ hổng mà của phần mềm không được kiểm thử

Kiểm thử theo cấu trúc (Structural Testing)

 Structural Testing la gi ?

 Tương phản với phương pháp Functional Testing, còn gọi là

White Box Testing

 “See inside”: cho phép Tester xác đinh TCs dựa vào thực tế

implement source code

Nội dung, Mục tiêu kiểm thử cấu trúc

 Mọi câu lệnh (phép gán, phép tính logic,…)

 Mọi điều kiện Logic có thể (rẽ nhánh)

 Mọi flow xử lý trong chương trình (Function A->

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ị một hay một số lệnh tuần tự , hoặc

thay cho điểm hội tụ các đường điều khiển

 Mỗi cạnh nối 2 nút biểu diễn dòng điều khiển

Ví dụ sử dụng lý thuyết đồ thị

buy(dress, bag) {

if dress already in bag

display “already bought it”

G

B

Lý do thực hiện Structural Testing

% Defects Introduced in this phase

Coding Unit

Test

Funct Test

System Test

Post Release

% Defects found in

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 thì ko được phản ánh

 Structural

 Dựa vào source code

 Code thường dựa vào SDD Nếu source code được implement

thiếu so với SRS (do SDD làm sơ sài,…) thì nhìn vào source code ko nhận ra thiếu sót

Lỗi & phân loại lỗi

 Xoay quanh sự khác biệt giữa Process & Product:

 Process: Chỉ dẫn cách thức, phương pháp làm

 Product: Kết quả cuối cùng của 1 process

 Testing and Software Quality Assurance (SQA)

 SQA cố gắng cải tiến product bằng cách cải tiến process

 SQA liên quan nhiều hơn tới cách giảm thiểu lỗi trong quá trình

phát triển, trong khi Testing thì liên quan tới tìm ra lỗi của sản

phẩm

=> Cả 2 đều hưởng lợi từ việc định nghĩa rõ ràng kiểu của lỗi

Phân loại lỗi

 Lỗi có thể được phân loại theo nhiều cách:

 Lỗi phát sinh trong giai đoạn phát triển (Development)

 Lỗi phát sinh khi triên khai,…

Phân loại lỗi (1)

 Input/Output Faults :

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 của param

Correct result at wrong time (too early, too late)

Chưa login thành công đã bật cờ online

Incomplete or missing result Spurious result Fix sẵn giá trị, ko xử lý thật Spelling/grammar

Phân loại lỗi (2)

 Logic Faults:

Missing case(s)

Duplicate case(s) Tính tổng 2 lần (+=)

Extreme condition neglected –

Thiếu ĐK cuối cùng ĐK: Nếu >=1000 thì lấy 1000, khi tinh dc kq ko kiểm tra ĐK này mà cứ 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 đúng

Test of wrong variable

Incorrect loop iteration Ko dung while{} mà dùng do {}while

Phân loại lỗi (3)

 Computation Faults:

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, hoặc group ko đúng

Insufficient precision (round-off,

truncation)

Làm tròn số sai Wrong built-in function Hàm float của javascript bị sai với số float có

> 16 số

Phân loại lỗi (4)

 Interface Faults:

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ả về không phù hợp

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 là 30, nhưng insert 50 kí tự Incorrect subscript

Incorrect type

Incorrect data scope

Level of Testing

 Mô hình chữ V:

Thanks for your attention