Tìm hiểu về các loại kiểm thử phần mềm

Kiểm thử phần mềm được chia làm 2 loại: Kiểm thử tĩnh và kiểm thử động. Vậy kiểm thử tĩnh là gì? Kiểm thử động là gì? Bài viết này sẽ giúp bạn hiểu rõ hơn về các loại kiểm thử phần mềm và giới thiệu một vài kỹ thuật kiểm thử phần mềm.

1. Kiểm thử tĩnh là gì?

1.1: Định nghĩa:

Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà không    thực hiện phần mềm. Điều này ngược với thử nghiệm động. Thường   thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu.

• Chủ yếu là kiểm tra cú pháp của code và/hoặc review code (kiểm tra xem code có được viết theo đúng tiêu chuẩn code. Ví dụ cách đặt tên hàm tên biến, cách sử dụng hàm chung đã đưa ra hay chưa) hoặc tài liệu để tìm lỗi bằng cách thủ công. Đây là loại kiểm thử được thực hiện bởi DEV (những người lập trình), làm việc một cách độc lập.
• Lỗi được phát hiện ở giai đoạn phát triển này là ít tốn kém để sửa chữa hơn so với lỗi phát hiện được ở các giai đoạn sau này trong các quy trình phát triển phần mềm

1.2: Các kỹ thuật sử dụng trong kiểm thử tĩnh

1.2.1: Walkthough

Phương pháp review giữa những đồng nghiệp với nhau sẽ phát hiện ra vấn đề và năng lực của từng người để giao nhiệm vụ (task) phù hợp với từng người.

1.2.2: Inspacetion

• Là phương pháp tìm lỗi ở source code
• Đảm bảo thực hiện theo bản đặc tả yêu cầu, bản đặc tả hệ thống
• Đảm bảo tính đúng đắn và xử lý logic
• Bộ phận phát triển , người có trách nhiệm(Moderator) và bộ phận QA thực hiện review source code

**1.2.3 : Review code **

Kiểm tra xem code có được viết theo đúng tiêu chuẩn code hay không.

2. Kiểm thử động

Kiểm thử động bao gồm 2 kỹ thuật : Kiểm thử hộp trắng và kiểm thử hộp đen

2.1. Kiểm thử hộp trắng(White box testing)

2.1.1. Định nghĩa

Kiểm  thử hộp trắng dựa vào thuật toán, cấu trúc code bên trong của chương trình với mục đích đảm bảo rằng tất cả các câu lệnh vàđiều kiện sẽ được thực hiện ít nhất một lần.

• Người kiểm thử truy cập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử.

• —Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình đã tuân theo đặc tả.

• Một chương trình sai do thiếu đường dẫn. Việc kiểm thử hộp trắng không thể biết được sự thiếu sót này.

• —Việc kiểm thử bằng kỹ thuật hộp trắng không thể phát hiện được lỗi do dữ liệu. Như vậy, việc kiểm thử chỉ dùng kỹ thuật hộp trắng là không đủ để phát hiện lỗi.

♦ Kiểm thử hộp trắng bao gồm:

• — Kiểm thử đường dẫn (Path test) : Kiểm thử bao quát các dòng source code, nhánh và đường dẫn.

• — Kiểm thử luồng điều khiển(Control flow test) : Xác nhận truy cứu các lịch sử thực hiện source code bằng cách sử dụng trình gỡ lỗi.

• — Kiểm thử nội bộ: Xác nhận các tham số, counter, vòng lặp

• — Kiểm thử tính năng: Đo thời gian xử lý của module,đường dẫn, dữ liệu cụ thể.

2.2. Kỹ thuật kiểm thử hộp đen (Black-Box Testing)

2.2.1.Định nghĩa

Là phương pháp test dựa trên đầu vào và đầu ra của chương trình  để test mà không quan tâm tới code bên trong được viết ra sao.   Tester  xem phần mềm như là một hộp đen

• — Nó còn được gọi là kiểm thử hướng dữ liệu hay là kiểm thử hướng in/out

• — Người kiểm thử nên xây dựng các nhóm giá trị đầu vào mà sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chương trình

♦ Kiểm thử hộp đen bao gồm:

• Kiểm thử chức năng và kiểm thử hệ thống
• Kiểm thử quá tải và kiểm thử hỏng hóc
• Kiểm tra hiệu năng

2.2.2.Các kỹ thuật trong kiểm thử hộp đen

a. Phân vùng tương đương (Equivalence partitioning)

• — Chia (partition) đầu vào thành những nhóm tương đương nhau (equivalence). Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó cũng hoạt động đúng và ngược lại

• — Mục đích : Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện

• — Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước:

  (1). Xác định các lớp tương đương

  (2). Xác định các ca kiểm thử.

Ví dụ minh họa

Xác định phân vùng tương đương và test case thích hợp theo yêu cầu dưới đây:

Zip Code - 5 chữ số

Last Name: từ 1 đến 15 ký tự (bao gồm chữ cái, ký tự, gạch ngang, dấu nháy, khoảng trắng và số)

(1) Phân vùng tương đương ZIP Code

Nhập ký tự số

Nhập ký tự chữ

Nhập ký tự đặc biệt

 Ký tự số	      Ký tự chữ	                Ký tự đặc biệt

Không nhập ký tự nào (Nếu có yêu cầu not Null thì báo lỗi ngược lại thì không làm gì)

Nhập < 5 ký tự

Nhập 5 ký tự

Nhập> 5 ký tự

 Không nhập gì	        Nhập <5 ký tự	      Nhập 5 ký tự	        Nhập > 5 ký tự

(2) Phân vùng tương đương Last name

Nhập ký tự số

Nhập ký tự chữ

Dấu chấm

Dấu phẩy

Khoảng trắng

Dấu nháy đơn

Nhập ký tự đặc biệt: Khác các ký tự dấu chấm, phẩy, khoảng trắng, dấu nháy đơn

Ký tự số	Ký tự chữ	Dấu chấm .	Dấu phẩy ,	Khoảng trắng	Dấu nháy đơn    ‘	Ký tự đăc biệt khác

Không nhập ký tự nào

Nhập 1 đến 15 ký tự

Nhập >15 ký tự

Không nhập gì	Nhập 1 đến 15 ký tự	Nhập >15 ký tự

b. Phân tích giá trị biên (Boundary value analysis)

Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu

Cách sử dụng phương pháp Giá trị biên

“Test các giá trị biên” chúng ta chỉ test các phần sau:

• — Bất kỳ một cách chọn thực hiện trong phương pháp “Giá trị biên” ta có thể sử dụng được tốt. Thay vì ta phải test toàn bộ vùng cần test ta có thể test 6 hoặc 4 case và vẫn đảm bảo là hệ thống hoạt động tốt.

• — Một số điểm cần lưu ý khi dùng phương pháp này

Luôn test trường hợp “0” nếu nó nằm trong vùng kiểm tra và một vài trường hợp nếu nó nằm ngoài vùng bởi vì 0 là giá trị khá đặc biệt.

    Luôn test các chuỗi rỗng nếu nó nằm trong vùng test và ngay cả khi nó không nằm trong vùng test.

Ví dụ minh họa

Cho một mảng [-3,10] ta có thể thiết kế được các test case là:

Giá trị nhỏ nhất: -3

Giá trị lớn nhất: 10

Giá trị nhỏ hơn giá trị nhỏ nhất: -4

Giá trị lớn hơn giá trị lớn nhất: 11

Giá trị nằm trong -3 và 10: 0

**c. Đồ thị nguyên nhân - kết quả(Cause & Effect Graphing)**

Một điểm yếu của hai phương pháp trên là chúng không khảo sát sự kết hợp của các trường hợp đầu vào. Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào, thì số lượng sự kết hợp thường là rất lớn. Nếu bạn không có cách lựa chọn có hệ thống một tập con các trạng thái đầu vào, có lẽ bạn sẽ chọn ra một tập tùy hứng các điều kiện, điều này có thể dẫn tới việc kiểm thử không có hiệu quả.

Đồ thị nguyên nhân – kết quả hỗ trợ trong việc lựa chọn một cách có hệ thống tập các ca kiểm thử có hiệu quả cao.

Kỹ thuật gồm có 4 bước:

- —  Xác định điều kiện vào và hành động cho mỗi module cần kiểm định.

- —  Xác định đồ thị nguyên nhân – kết quả.

- —  Đồ thị được chuyển thành bảng quyết định.

- —  Những phần trong bảng quyết định được chuyển thành test case.

Ví dụ minh họa

Trên màn hình đăng nhập, có 2 thông tin cần đưa vào là Tên đăng nhập và mật khẩu, chỉ thực hiện đăng nhập thành công nếu nhập đúng cả Tên đăng nhập và mật khẩu, các trường hợp còn lại sẽ hiển thị thông báo “Nhập không chính xác, yêu cầu nhập lại”

Bước 1: Xác định các điều kiện đầu vào. Số cột giá trị tính = 2 mũ N (N: số đầu vào)

    Đầu vào	     Giá trị  1	 Giá trị 2 Giá trị  3	     Giá trị  4
    Tên đăng nhập
    Mật khẩu

Bước 2: Nhập các giá trị có thể xảy ra. Mỗi giá trị đầu vào sẽ có 1 nửa là T(true), 1 nửa F (false)

    Đầu vào	      Giá trị  1	   Giá trị 2	   Giá trị 3  Giá trị  4
    Tên đăng nhập	 T            	T	        F	           F
    Mật khẩu	   T	          F	          T	             F
Bước 3: Xác định các giá trị đầu ra căn cứ đầu bài.

    Đầu vào	     Giá trị 1	Giá trị  2	Giá trị  3	Giá trị  4
    Tên đăng nhập	 T	             T            	F     	F
    Mật khẩu	   T               F	          T	      F
    Đầu ra
    Thông báo	Thành công	Chưa nhập pass	Chưa nhập tên	Chưa nhập pass hoặc tên
**d. Đoán lỗi (Error Guessing)**

- —  Một kỹ thuật thiết kế test-case khác là error guessing – đoán lỗi. Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm, các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.

- —  Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính trực giác cao và không thể dự đoán trước. Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó.Nói cách khác, bạn liệt kê những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế.

**2.3: Sự giống và khác nhau giữa kiểm thử hộp trắng và kiểm thử hộp đen**

**2.3.1 : Giống nhau**

Hai loại hình kiểm thử đều nhằm mục đích là kiểm định lại phần mềm nhằm loại bỏ những lỗi và những gì thiếu trong quá trình làm phần mềm nhằm mục đích là đem lại một sản phẩm tốt đến khách hàng.

**2.3.2: Khác nhau**

**1. Kiểm thử hộp trắng**

Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào cấu trúc/mã lệnh chương trình. Phương pháp kiểm thử hộp trắng kiểm thử một chương trình (một phần chương trình, hay một hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm các giá trị không đúng hay không theo dự định của chương trình.
Phương pháp dựa trên:
- Các câu lệnh (statement)
- Đường dẫn (path)
- Các điều kiện (condition)
- Vòng lặp (loop)
- Ngã rẽ (branch)

**2. Kiểm thử hộp đen**

Kiểm thử hộp đen hay còn gọi là kiểm thử chức năng, việc kiểm nghiệm này được thực hiện mà không cần quan tâm đến các thiết kế và viết mã của chương trình. Kiểm thử  theo cách này chỉ quan tâm đến chức năng đã đề ra của chương trình. Vì vậy kiểm thử loại này chỉ dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng hay không mà thôi.

Phương pháp dựa trên:
- Chức năng thiếu hoặc không đúng đắn
- Sai về giao diện

- Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài

- Sai thực thi chức năng

Tóm tắt: Tùy vào từng giai đoạn trong quá trình phát triển phần mềm sẽ dùng các loại kiểm thử thích hợp.