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
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. |
Không có nhận xét nào:
Đăng nhận xét