Tìm hiểu về DYNAMIC TESTING

Khái niệm: Kiểm thử tự động phần mềm (Test Automation) là: Quá trình xử lý

một cách tự động các bước thực hiện các TC bằng việc sử dụng các công cụ kiểm

thử (máy tính, chương trình, phần mềm,…)

Kiểm thử phần mềm chiếm đến 40% công sức của một dự án phát triển.Tự

động hóa là nhu cầu thiết yếu. Việc KTTĐ thường được xem xét trong một số tình

huống sau:

-         Không đủ tài nguyên: Khi số lượng TC quá nhiều mà Tester không thể hoàn

tất trong thời gian cụ thể.

-         Kiểm tra hồi quy: Khi phần mềm có sự thay đổi hay nâng cấp tại các phiên

bản.

-         Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt: Xác

định các yếu tố về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của

phần mềm. Một số vấn đề như:

• Tốc độ xử lý trung bình

• Số lượng yêu cầu cùng một lúc tối đa mà phần mềm đáp ứng được

• Cấu hình phần cứng thấp nhất mà phần mềm vẫn có thể hoạt động

được

v Quy trình kiểm thử thường bao gồm các bước:

1. Lập kế hoạch kiểm thử

2. Thiết kế kịch bản (test script) hay trường hợp kiểm thử (test case)

3. Tạo dữ liệu thử

4. Thực hiện kiểm thử và ghi nhận kết quả

5. Kiểm tra, phân tích, đánh giá kết quả

6. Lập báo cáo quá trình kiểm thử

Quy Trình Kiểm thử phần mềm

1) Lập kế hoạch kiểm thử (planning test)

Mục đích: Nhằm chỉ định và mô tả mục tiêu, phạm vi, tài nguyên, ràng buộc,

môi trường, các mạo hiểm, các phương pháp kiểm tra sẽ được triển khai và thực

hiện. Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch KTPM, bao gồm nhiều

chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực

lượng kiểm tra viên.

Bản kế hoạch kiểm tra đầu tiên được phát triển rất sớm trong chu trình

PTPM, ngay từ khi các yêu cầu đã tương đối đầy đủ, các chức năng và luồng dữ liệu

chính đã được mô tả. Bản kế hoạch này có thể được coi là bản kế hoạch chính

(master test plan), trong đó tất cả các kế hoạch chi tiết cho các mức kiểm tra và loại

kiểm tra khác nhau đều được đề cập.

Bảng kế hoạch chình và các bản kế hoạch chi tiết.

Tùy theo đặc trưng và độ phức tạp của mỗi dự án, các kế hoạch kiểm tra chi

tiết có thể được gom chung vào bản kế hoạch chính hoặc được phát triển riêng.

Sau khi bản kế hoạch chính được phát triển, các bản kế hoạch chi tiết lần lượt

được thiết kế theo trình tự thời gian phát triển của dự án. Quá trình phát triển các kế

hoạch kiểm tra không dừng lại tại một thời điểm, mà liên tục được cập nhật chỉnh

sửa cho phù hợp đến tận cuối dự án.

Các bước lập kế hoạch:

• Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ

được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng

được dùng để xác định nhu cầu nhân lực.

• Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá

trình cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra

viên quá yếu, không hiểu rõ yêu cầu.

• Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện

việc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ (tool) hỗ trợ kiểm tra,

chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện

để xác định thời gian kiểm tra.

• Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần

cứng, phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra.

• Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định

chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá

trình kiểm tra.

• Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch

chi tiết.

• Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những

người có liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc xem xét nhằm

bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai

sót trong các bản kế hoạch.

2) Thiết kế kịch bản hay trường hợp kiểm thử

Một kịch bản (Test Script) là một nhóm mã lệnh dạng đặc tả kịch bản dùng

để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho

những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi. Các

Test Script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động.

• Một trường hợp kiểm thử (Test Case-TC) là một tình huống kiểm tra,

được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một

TC thường bao gồm 4 phần cơ bản:

• Điều kiện: đặc tả các điều kiện cần có để tiến hành kiểm tra.

• Đầu vào: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào

để thực hiện việc kiểm tra.

• Kết quả mong chờ: kết quả mong đợi trả về từ đối tượng kiểm tra.

• Kết quả thực tế: kết quả thực tế trả về từ đối tượng kiểm tra.

a. Thiết kế Test case

Mục đích: Nhằm chỉ định các TC và các bước kiểm tra chi tiết cho mỗi

phiên bản phần mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất

cả các tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra.

Việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật,

thêm hoặc bớt xuyên suốt chu kỳ PTPM, vào bất cứ lúc nào có sự thay đổi yêu cầu,

hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ sung.

Các bước thiết kế test bao gồm:

• Xác định và mô tả TC: xác định các điều kiện cần thiết lập trước và trong

lúc kiểm tra. Mô tả mục đích, yêu cầu kiểm tra, đối tượng hoặc dữ liệu đầu vào, mô

tả các kết quả mong chờ sau khi kiểm tra, môi trường kiểm tra.

• Mô tả các bước chi tiết để kiểm tra: Thao tác này nhằm chi tiết hóa các

bước của một TC, cũng như chỉ định các loại dữ liệu nào cần có để thực thi các TC,

chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống…

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và

cách thức xác định việc kiểm tra đã hoàn thành hay chưa? Bao nhiêu phần trăm

phần mềm đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên

yêu cầu của phần mềm hoặc căn cứ trên số lượng code đã viết.

• Xem xét TC và các bước kiểm tra: Việc xem xét cần có sự tham gia của

tất cả những người có liên quan, kể cả trưởng dự án nhằm bảo đảm các TC và dữ

liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu

cầu, cũng như để phát hiện (và sữa chữa) các sai sót.

Các kỹ thuật thiết kế Test Case:

• Kỹ thuật dựa trên đặc tả – hộp đen: Tìm kiếm lỗi theo cách của hệ thống

thực hiện.

• Kỹ thuật dựa trên cấu trúc – hộp trắng: Tìm kiếm lỗi theo cách hệ thống

được xây dựng.

Hai kỹ thuật trên sẽ được mô tả chi tiết hơn ở phần sau.

• Kỹ thuật dựa trên kinh nghiệm: Tạo kiểm thử chủ yếu nhờ vào sự hiểu biết

về hệ thống, kinh nghiệm quá khứ, phương pháp phỏng đoán về lỗi. Có thể được

hướng dẫn bởi: Danh sách các ý kiểm tra, việc phân loại lỗi, liệt kê các kiểu tấn

công, cách tiếp cận “săn” lỗi, tập các lý do kiểm thử.

b. Phát triển Test Script

Mục đích: Bước này thường không bắt buộc trong các loại và mức kiểm tra,

chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các Test Script có

khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã

định nghĩa ở bước thiết kế test.

Các bước phát triển Test Script bao gồm:

• Tạo Test Script: thủ công hoặc dùng công cụ hỗ trợ để phát sinh script một

cách tự động (tuy nhiên trong hầu hết mọi trường hợp, ta vẫn phải chỉnh sửa ít hoặc

nhiều trên các script được sinh tự động). Thông thường, mỗi bước kiểm tra được

thiết kế trong phần thiết kế test, đòi hỏi ít nhất một Test Script. Các Test Script có

khả năng tái sử dụng càng nhiều càng tốt để tối ưu hóa công việc.

• Kiểm tra Test script: xem có “chạy” tốt không nhằm bảo đảm các Test

Script hoạt động đúng yêu cầu, thể hiện đúng ý đồ của các bước kiểm tra.

• Thành lập các bộ dữ liệu ngoài dành cho các Test Script: bộ dữ liệu này sẽ

được các Test Script sử dụng khi thực hiện kiểm tra tự động. Gọi là “ngoài” vì

chúng được lưu độc lập với các Test Script

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: bảo đảm các Test

Script được tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu.

3) Tạo dữ liệu thử

Kiểm thử với tất cả các dữ liệu vào là cần thiết, nhưng chúng ta không thể

thực hiện kiểm thử “vét cạn” được. Do đó nên chọn tập các dữ liệu thử đại diện từ

miền dữ liệu vào dựa trên các tiêu chuẩn chọn dữ liệu thử. Yêu cầu đối với bộ dữ

liệu kiểm thử là phải phủ kín được mọi trường hợp cần đánh giá.

4) Thực hiện kiểm thử và ghi nhận kết quả

a) Chuẩn bị môi trường

Thực tế bước này thực hiện song song với quá trình thiết kế các TC và Test

Script và được thực hiện bởi cán bộ chuyên trách. Mục đích là khảo sát môi trường

phần cứng cũng như phần mềm phục vụ cho việc thực thi test: phần cứng, phần

mềm, máy chủ, mạng, dữ liệu, …

b) Thực thi test

Thực thi các bước kiểm tra đã thiết kế có thể test không có dữ liệu đầu vào

(test chay) hoặc sử dụng bộ dữ liệu đã chuẩn bị ở bước trước.

Giám sát quá trình này đến khi hoàn thành hay bị treo giữa chừng, đồng thời

ghi nhận các kết quả cần thiết. Nếu quá trình diễn ra trơn tru thì cần xem xét lại độ

tin cậy của kết quả kiểm thử, nhận biết các vấn đề do ảnh hưởng của những yếu tố

ngoài phần mềm như: bộ dữ liệu, môi trường, TC, Test Script,… Nếu quá trình bị

treo hoặc dừng giữa chừng cần phân tích để xác định nguyên nhân và đưa ra hướng

giải quyết.

Vấn đề là Test bao nhiêu là đủ?

Khi nào thì nên dừng việc kiểm thử? Rất khó để xác định điều này. Sau đây

là một vài trường hợp phổ biến:

- Một số lượng lỗi nhất định được tìm thấy

- Tỷ lệ mà lỗi được tìm thấy là quá nhỏ

- Những rủi ro của dự án ở mức chấp nhận được

- Đạt đến yêu cầu phạm vi test

- Ngân sách kiểm thử hết

- Hết thời gian

- …

Nhìn chung, quyết định dừng kiểm thử dựa trên mức độ rủi ro của dự án có

chấp nhận được hay không?

5) Kiểm tra, phân tích, đánh giá kết quả

Bước này mang tính thẩm tra toàn cục, nhằm vào giá trị của các kết quả kiểm

tra. Bao gồm:

-         Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và đánh

giá sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực tế, tổng hợp và gửi

thông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để

kiểm tra sau đó.

-         Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt được độ bao phủ

yêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra (tính trên các yêu cầu của phần

mềm và số lượng code đã viết).Tổng hợp và phân tích lỗi: Số lượng lỗi, phân loại lỗi. Đưa ra số liệu phục

vụ cho việc cải tiến các qui trình phát triển, giảm sai sót cho các chu kỳ phát triển

và kiểm tra sau đó. Ví dụ, tính toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi, những

lỗi “ngoan cố” hoặc thường xuyên tái xuất hiện.

-         Xác định quá trình kiểm tra có đạt yêu cầu hay không.

-         Tính toán các số liệu khác liên quan đến quá trình kiểm tra chẳng hạn số

giờ, thời gian kiểm tra, …

6) Lập báo cáo

Ở bước này, Tester tổng hợp các kết quả thực thi test, lập tài liệu báo cáo

(Test result report) và gửi cho tất cả những người có liên quan. Nội dung chủ yếu

của tài liệu này:

Giới thiệu tài liệu

Giới thiệu các test item mục tiêu

Các TC dự kiến thực hiện, đã thực hiện

Kết quả chi tiết của việc thực hiện từng TC

Thống kê tỉ lệ TC được thực hiện và tỉ lệ thành công của các TC.

Đưa ra các yêu cầu mới

Ghi chú về các hiện tượng cần theo dõi thêm

Nếu được kết luận đã đủ tốt, sản phẩm sẽ được ứng dụng trong thực tiễn.

Nhận xét

Bảng nhận xét về kiểm thử tự động

Thuận lợi	Khó khăn
KTPM không cần quá nhiều can thiệp của Tester .	Mất chi phí tạo các script để thực hiệnKTTĐ.
Giảm chi phí khi thực hiện kiểm tra sốlượng lớn TC hoặc TC lặp lại nhiều lần	Tốn chi phí dành cho bảo trì các script.
Giả lập tình huống khó có thể thực hiệnbằng tay.	Đòi hỏi Tester phải có kỹ năng tạoscript KTTĐ.
Tăng độ tin cậy bởi nâng cao mức độ baophủ trường hợp kiểm thử.	Không áp dụng được trong việc tìm lỗimới của phần mềm.