Mục lục
3
4
CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1. Tổng quan
1.1.1. Khái niệm
Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi.
Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng
theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra. Kiểm thử phần mềm
cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh
giá và hiểu rõ các rủi ro khi thực thi phần mềm.Đây là một pha quan trọng trong quá
trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được
hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?
1.1.2. Tiến trình kiểm thử
Kiểm thử thường bao gồm các bước:
Bước 1: lập kế hoạch kiểm thử, xác định kịch bản kiểm thử
Bước 2: tạo dữ liệu thử (thiết kế các ca kiểm thử)
- Kiểm thử với tất cả dữ liệu vào là cần thiết
- Chọn tập các dữ liệu thử đại diện từ miền dữ liệu vào
Bước 3: thực thi chương trình trên dữ liệu thử
- Cung cấp dữ liệu thử
- Thực thi
- Ghi nhận kết quả
Bước 4: quan sát kết quả kiểm thử
- Thực hiện trong khi hoặc sau khi thực hiện
5
- So sánh kết quả nhận được và kết quả mong đợi
1.1.3. Các nguyên tắc trong kiểm thử phần mềm
Có 7 nguyên tắc trong kiểm thử phần mềm:
-
Kiểm thử chỉ chứng tỏ được việc có lỗi
-
Kiểm thử tồn bộ là không thể
-
Kiểm thử càng sớm càng tốt
-
Sự tập trung của lỗi
-
Nghịch lí thuốc trừ sâu
-
Kiểm thử phụ thuộc vào ngữ cảnh
-
Sự sai lầm về việc khơng có lỗi
1.2. Phương pháp kiểm thử
1.2.1. Kỹ thuật kiểm thử
Có 2 kỹ thuật kiểm thử:
Kiểm thử tĩnh – Static testing: 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. 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.
Kiểm thử động – Dynamic testing: Là phương pháp thử phần mềm thông qua việc
dùng máy chạy chương trình để điều tra trạng thái tác động của chương trình.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
6
1.2.2. Phương pháp kiểm thử
1.2.2.1.Kiểm thử hàm (kiểm thử hộp đen)
Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của bạn là
hồn tồn khơng quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay
vào đó, tập trung vào tìm các trường hợp mà chương trình khơng thực hiện theo các
đặc tả của nó.
Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.
Các phương pháp kiểm thử hộp đen tiêu biểu:
-
Phân lớp tương đương
Phân tích giá trị biên
Kiểm thử bảng quyết định
a. Phân lớp tương đương
Kiểm thử lớp tương đương là phương pháp chia miền dữ liệu kiểm thử thành các
miền con sao cho dữ liệu trong mỗi miền con có cùng tính chất đối với chương trình,
có nghĩa là các ca kiểm thử của một miền con sẽ cùng gây lỗi cho chương trình, hay
cùng cho kết quả đúng, hay cùng cho kết quả sai tương tự nhau. Sau khi chia miền dữ
liệu của chương trình thành và miền con tương đương, chúng ta chỉ cần chọn một phần
tử đại diện của mỗi miền con này làm bộ dữ liệu kiểm thử. Các miền con này chính là
các lớp tương đương.
b. Phân tích giá trị biên
Kiểm thử giá trị biên (boundary testing) là một trong những kỹ thuật được áp dụng
phổ biển nhất trong kiểm thử hàm. Chúng ta sẽ coi một chương trình là một hàm tốn
học với đầu vào của chương trình tương ứng với các tham số của hàm và đầu ra của
chương trình là giá trị trả về của hàm. Vì hàm tốn học là ánh xạ từ miền xác định của
hàm đến miền giá trị của hàm. Chúng ta sẽ tập trung vào các giá trị biên và cạnh biên
của hai miền đầu vào và đầu ra này của hàm để xây dựng các ca kiểm thử. Khi chúng
7
ta dùng biên đầu ra tức là chúng ta cho các kết quả mong đợi nằm ở trên biên và cạnh
biên đầu ra.
c. Kiểm thử bảng quyết định
Kỹ thuật kiểm thử lớp tương đương và kiểm thử giá trị biên thích hợp cho các hàm
có các biến đầu vào khơng có quan hệ ràng buộc với nhau. Kỹ thuật kiểm thử dựa trên
bảng quyết định chúng ta xem xét trong chương này sẽ phù hợp cho các hàm có các
hành vi khác nhau dựa trên tính chất của bộ giá trị của đầu vào.
Kiểm thử dựa trên bảng quyết định là phương pháp chính xác nhất trong các kỹ
thuật kiểm thử chức năng. Bảng quyết định là phương pháp hiệu quả để mô tả các sự
kiện, hành vi sẽ xảy ra khi một số điều kiện thỏa mãn.
1.2.2.2. Kiểm thử cấu trúc (kiểm thử hộp trắng)
Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm
thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của
chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính
logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật
bên trong chương trình (và cả mã lệnh thực hiện chúng).
Các phương pháp kiểm thử hộp trắng
Có 2 hoạt động kiểm thử hộp trắng:
- Kiểm thử luồng điều khiển
- Kiểm thử dòng dữ liệu
a. Kiểm thử dòng điều khiển
Các bước thực hiện:
Bước 1: Xây dựng đồ thị dòng điều khiển
Vẽ đồ thị từ mã nguồn chương trình
8
Xác định độ phức tạp cyclomatic (C)
Xác định các đường đi (testpaths – các đường thực hiện)
Bước 2: xác định các mức bao phủ dựa trên các độ đo kiểm thử từ đó sinh ra các
test case
Bước 3: thực thi test case.
b. Kiểm thử dòng dữ liệu
Các bước thực hiện:
Bước 1: Xây dựng đồ thị dòng dữ liệu của chương trình
Bước 2: chọn một hoặc một số tiêu chí kiểm thử dòng dữ liệu (độ đo kiểm thử)
Bước 3: xác định các đường dẫn chương trình phù hợp với tiêu chí kiểm thử đã
chọn
Bước 4: lấy ra các biểu thức điều kiện từ tập các đường đi, thực hiện các biểu thức
điều kiện để có được các giá trị đầu vào cho các ca kiểm thử tương ứng với các
đường đi này và tính tốn giá trị đầu ra mong đợi của mỗi ca kiểm thử
Bước 5: thực hiện các ca kiểm thử để xác định các lỗi (có thể có) của chương trình
Bước 6: sửa các lỗi (nếu có) và thực hiện lại tất cả các ca kiểm thử trong trường hợp
trước năm phát hiện lỗi.
1.2.2.3. So sánh kiểm thử hộp trắng và kiểm thử hộp đen
Ưu nhược điểm của black box test và white box test:
Nội
dung
Black box test
White box test
9
1.Ưu
điểm
-Thích hợp trong việc kiểm tra
từng phân đoạn lớn các mã lệnh,
chức năng lớn
- Người thử nghiệm không cần
hiểu biết về mã lệnh được viết
trong chương trình
- Tách biệt giữa quan điểm của
người sử dụng và người phát triển
phần mềm
- Độ bao phủ hạn chế vì chỉ có
một phần nhỏ trong số các kịch
bản thử nghiệm được thực hiện
- Kiểm tra khơng hiệu quả do
2.Nhược
người thử nghiệm khơng hiểu biết
điểm
gì về cấu trúc bên trong phần
mềm.
- Tester có hạn chế về hiểu biết về
ứng dụng
- Thích hợp trong việc tìm kiếm lỗi
và các vấn đề trong mã lệnh
- Biết được yêu cầu bên trong của
phần mềm, kiểm tra sẽ sát hơn
- Cho phép tìm kiếm các lỗi ẩn bên
trong
- Các lập trình viên có thể tự kiểm
tra
- Giúp tối ưu việc mã hoá
- Do yêu cầu kiến thức cấu trúc bên
trong của phần mềm, nên việc kiểm
soát lỗi tối đa nhất
- Khơng thể tìm thấy tính năng chưa
thực hiện hoặc bỏ sót
- Địi hỏi hiểu sâu về cấu trúc bên
trong của phần mềm được thử
nghiệm
- Yêu cầu truy xuất mã lệnh bên
trong chương trình
- Sự khác nhau giữa Back box test và White box test
Tiêu
chuẩn
Black box test
White box test
1. Định
nghĩa
- Kiểm tra hộp đen là phương pháp
thử nghiệm phần mềm được sử dụng
để kiểm tra các phần mềm mà không
quan tâm đến cấu trúc bên trong của
chương trình.
- Kiểm tra hộp trắng là phương
pháp kiểm thử phần mềm, sử
dụng để kiểm tra phần mềm mà
yêu cầu phải biết cấu trúc bên
trong của chương trình.
2.Trách
nhiệm
- Thử nghiệm được thực hiện bên
ngồi, không liên quan đến nhà phát
triển phần mềm.
- Thông thường, các thử
nghiệm được thực hiện bởi nhà
phát triển phần mềm.
3. Cấp độ
test sử
dụng
- Thử nghiệm được áp dụng ở
- Thử nghiệm áp dụng ở cấp độ cao
mức độ thấp hơn như thử
như: kiểm tra hệ thống (System test), nghiệm đơn vị (Unit Test), thử
kiểm tra chấp nhận (Acceptance test) nghiệm hội nhập (Integration
test)
10
4. Biết lập
trình
- Khơng u cầu hiểu biết về Lập
trình
- Yêu cầu hiểu biết nhất định
về lập trình.
5. Biết việc
thực hiện
chương
trình
- Khơng u cầu hiểu về cấu trúc
bên trong chức năng, và khơng cẩn
hiểu làm thế nào để có được chức
năng đó
- Yêu cầu hiểu cấu trúc bên
trong chức năng được thực
hiện như nào.
6. Cơ sở
tạo Test
Cases
- Kiểm tra hộp đen được bắt đầu dựa
trên tài liệu yêu cầu kỹ thuật
- Kiểm tra hộp trắng được bắt
đầu dựa trên các tài liệu thiết
kế chi tiết
1.3. Các mức kiểm thử
1.3.1. Kiểm thử đơn vị - unit test
Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất.Kiểm thử thực hiện trên các hàm
hay thành phần riêng lẻ.
Cần hiểu biết về thiết kế chương trình và code.
Thực hiện bởi Lập trình viên (không phải kiểm thử viên).
Đơn vị: Là thành phần nhỏ nhất của phần mềm có thể kiểm thử được. Ví dụ: Các
hàm, lớp, thủ tục, phương thức.
Mục đích của việc kiểm tra unit test là cô lập từng thành phần của chương trình và
chứng minh các bộ phận riêng lẻ chính xác về các yêu cầu chức năng.
1.3.2. Kiểm thử tích hợp - Integration test
Kiểm thử tích hợp nhằm phát hiện lỗi giao tiếp xảy ra giữa các thành phần cũng như
lỗi của bản thân từng thành phần (nếu có).
- Thành phần có thể là:
+ Các module
+ Các ứng dụng riêng lẻ
11
+ Các ứng dụng client/server trên một mạng
- Integration Test có 2 mục tiêu chính:
+ Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
+ Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là
nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống
(System Test).
1.3.3. Kiểm thử hệ thống
Kiểm thử hệ thống là một mức của tiến trình kiểm thử phần mềm khi các module và
tích hợp các module đã được test.
Mục tiêu của kiểm thử hệ thống là để đánh giá phần mềm có tuân thủ theo các yêu
cầu đã đưa ra không
Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú
trọng các hành vi và lỗi trên tồn hệ thống, cịn Integration Test chú trọng sự giao tiếp
giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải
thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa
chúng hoạt động chính xác trước khi thực hiện System Test.
System Test thường được thực hiện bởi một nhóm kiểm tra viên hồn tồn độc lập
với nhóm phát triển dự án.
1.3.4. Kiểm thử chấp nhận - acceptance test
Kiểm thử chấp nhận là một cấp độ trong tiến trình kiểm thử phần mềm nhằm kiểm
thử hệ thống về khả năng chấp nhận được.
•
Mục tiêu của kiểm thử này là để đánh giá sự tuân thủ của hệ thống với các yêu
cầu nghiệp vụ và thẩm định xem đã có thể chấp nhận để bàn giao chưa.
•
Kiểm thử chấp nhận được khách hàng thực hiện (hoặc ủy quyền cho một nhóm
thứ ba thực hiện).
12
Kiểm thử chấp nhận là hoạt động thẩm định (validation) và do người sử dụng,
khách hàng kiểm tra. Họ xem hệ thống phần mềm có đáp ứng đúng như mong muốn
của họ không, không cần tài liệu đặc tả. Chúng ta cần kiểm thử chấp nhận vì đặc tả có
thể đã có khiếm khuyết hoặc người khách hàng và người phát triển cùng đọc một tài
liệu nhưng hiểu khơng hồn tồn như nhau.
1.3.5. Kiểm thử hồi quy – regression test
Có bất cứ sự thay đổi trong một ứng dụng phần mềm sẽ hồn tồn có thể gây ảnh
hưởng tới những thành phần khác. Regression testing được thực hiện để xác minh rằng
các lỗi đã được sửa không làm thay đổi kết quả của chức năng khác hoặc ảnh hưởng
đến các thành phần khác. Mục đích của Regression testing là để đảm bảo rằng thay đổi
sẽ không dẫn đến lỗi khác được phát sinh trong ứng dụng phần mềm. Các kỹ thuật
trong kiểm thử hồi quy giúp chúng ta xác định các ca kiểm thử cần thực hiện lại để chỉ
kiểm tra hệ thống ở những phần có liên quan, thay vì phải thực hiện lại tồn bộ hai
cơng việc này.
13
CHƯƠNG 2: LẬP KẾ HOẠCH KIỂM THỬ
2.1 Mục đích và phạm vi
-
Xác định thông tin cơ bản về dự án và các chức năng được kiểm thử
Liệt kê các yêu cầu kiểm thử
Những chiến lược kiểm thử
Ước lượng về tài ngun, chi phí
Những tài liệu sau khi hồn thành
Tài liệu kiểm thử này được áp dụng cho việc kiểm thử các chức năng của trang web
Mức kiểm thử: kiểm thử hệ thống
Chức năng kiểm thử:đăng nhập nhập, đăng ký, tìm kiếm, thêm giỏ hàng, đặt hàng.
Kiểm thử hiệu năng sử dụng Apache Jmetter kiểm thử hệ thống khi có nhiều mức
độ truy cập khác nhau.
2.2 Lịch trình kiểm thử
Cơng việc
Kết quả
Bắt đầu
Kết thúc
Lập kế hoạch kiểm
thử
Bản kế hoạch kiểm thử
10/09/2021
17/09/2021
Tìm hiểu lý thuyết,
kỹ thuật kiểm thử
Tài liệu lý thuyết, kỹ thuật
kiểm thử
18/09/2021
25/09/2021
Tìm hiểu cơng cụ
kiểm thử tự động
Tài liệu cơng cụ kiểm thử
tự động
26/09/2021
03/10/2021
Thiết kế Test Case
Bản thiết kế Test Case
04/10/2021
11/10/2021
Thực thi Test Case
Bản kết quả thực thi Test
12/10/2021
19/10/2021
Đánh giá kết quả
quá trình
Bản đánh giá kết quả
20/10/2021
27/10/2021
14
2.3 Những yêu cầu hệ thống
2.3.1 Phần cứng
Thành phần
Yêu cầu
CPU
Bộ xử lí 1 Ghz hoặc nhanh hơn 32 bit (x86) hoặc 64 bit (x64)
Bộ nhớ
Tối thiểu 1 GB RAM (32 bit) hoặc 4 GB RAM (64 bit). Khuyến
nghị là 4 GB RAM (32 bit) và 8 GB RAM (64 bit)
Ổ cứng
Ít nhất 1 GB dung lượng ổ cứng khả dụng. Cần thêm dung lượng đĩa
phụ thuộc vào mã nguồn dự án và các báo cáo thực hiện được tạo.
2.3.2 Phần mềm
Thành phần
Loại
Google Chrome
Trình duyệt web
Microsoft Windows 7 or 10
Hệ điều hành
2.3.3 Mơi trường kiểm thử
Máy tính cá nhân có kết nối internet, có thể truy cập vào trang web
.
Các chức năng của trang web được kiểm tra bằng Katalon trên các
trình duyệt Chrome, Edeg, FireFox,…
Hệ điều hành được sử dụng : Windows 10.
2.3.4. Công cụ kiểm thử
Hoạt động
Công cụ
Nhà cung cấp
Quản lý Test Case
Microsoft Office Excel
Microsoft
Kiểm thử chức năng
Katalon Studio
Katalon LLC
Kiểm thử hệ thống
Apache Jmeter
The Apache Sofwaroundation
15
16
2.4. Nhân sự
Thành viên
Nhiệm vụ
Trần Minh Long
Test Manager: Lập kế hoạch kiểm thử, thiết kế và thực thi
TestCase Chăm sóc khác hàng
Dương Văn Định
Tester: Thiết kế và thực thi các TestCase thêm giỏ hàng
Nguyễn Văn Nghiệp
Tester: Thiết kế và thực thi các TestCase mua hàng
Nguyễn Văn Hiếu
Tester: Thiết kế và thực thi các TestCase đăng nhập
Trần Đức Long
Tester: Thiết kế và thực thi các TestCase tìm kiếm
2.5. Kiểm thử chức năng
Mục đích kiểm thử
Đảm bảo các chức năng hoạt động chính xác so với đặc
tả
Kỹ thuật
Thực thi tất cả các trường hợp có thể có cho các chức
năng, sử dụng dữ liệu hợp lệ và không hợp lệ để kiểm
thử.
- Kết quả mong đợi khi dữ liệu hợp lệ
- Thông báo phù hợp khi dữ liệu không hợp lệ
Điều kiện dừng
- Tất cả TestCase đã được thực thi
- Tất cả các lỗi đều có lý do rõ ràng
Chịu trách nhiệm kiểm
thử
Tester
Phương pháp kiểm thử
Kiểm thử tự động bằng phần mềm Katalon Studio, các
TestCase được kiểm thử tuần tự theo các bước được định
nghĩa
Xử lý ngoại lệ
Liệt kê các vấn đề liên quan phát sinh trong quá trình
kiểm thử
17
2.6. Điều kiện chấp nhận
- Pass tất cả TestCase được định nghĩa
- Hệ thống chạy ổn trên các trình duyệt khác nhau
2.7. Lỗi và rủi ro
2.7.1. Phân loại lỗi
Mức độ
Đặc tả
Cao
Các chức năng của trang web không hoạt động được
Trung bình
Một số chức năng đơi khi khơng hoạt động được
Thấp
Những lỗi hầu như ko ảnh hưởng đến người dùng và hệ thống
2.7.2. Rủi ro
Rủi ro về dự án
Rủi ro về tổ chức:
-
nguồn nhân lực
tổ chức tốt
thành viên nhóm có kỹ năng để thực hiện cơng việc
hồn thành dự án đúng thời hạn
Rủi ro về kỹ thuật:
-
Kỹ thuật chưa được kiểm thử
Quy trình kiểm thử sai
Rủi ro nghiệp vụ (rủi ro đến từ công ty, khách hàng)
Trong trường hợp đó, Test Manager phải tìm ra các giải pháp để đối phó với rủi ro
như:
18
- Đặt mức độ ưu tiên cho các giai đoạn kiểm thử, tập trung vào kiểm thử các tính
năng chính của trang web
- Sử dụng một công cụ kiểm thử để tăng hiệu suất kiểm thử
Rủi ro sản phẩm
Hệ thống hoặc phần mềm không đáp ứng được mong đợi của khách hàng, người
dùng hoặc các bên liên quan. Rủi ro này liên quan đến chức năng của sản phẩm như
hiệu suất, bảo mật, kịch bản chạy sai…
+ Bỏ qua chức năng chính mà khách hàng yêu cầu
+ Phần mềm chạy sai gây thiệt hại tài chính
19
CHƯƠNG 3: GIỚI THIỆU VỀ CÔNG CỤ KIỂM THỬ TỰ ĐỘNG
3.1. Giới thiệu về kiểm thử tự động
Kiểm thử đang được xem là giải pháp chủ yếu nhằm đảm bảo chất lượng cho các
sản phẩm phần mềm, tuy nhiên độ phức tạp của các phần mềm ngày càng tăng và
trong mơi trường cạnh tranh như hiện nay địi hỏi các công ty phần mềm phải áp dụng
các phương pháp và cơng cụ nhằm tự động hóa các hoạt động kiểm thử. Chương này
giới thiệu về kiểm thử tự động và các công cụ hỗ trợ nhằm giải quyết vấn đề này.
Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong một kịch
bản kiểm thử. Kiểm thử tự động bằng một công cụ nhằm rút ngắn thời gian kiểm thử.
Mục đích của kiểm thử tự động là giảm thiểu thời gian, công sức và kinh phí, tăng độ
tin cậy, tăng tính hiệu quả và giảm sự nhàm chán cho người kiểm thử trong quá trình
kiểm thử sản phẩm phần mềm. Kiểm thử tự động sẽ được sử dụng khi dự án không đủ
tài nguyên (thời gian, nhân lực và chi phí), phải thực hiện kiểm thử hồi quy khi sản
phẩm được sửa đổi hoặc nâng cấp và cần kiểm thử lại các tính năng đã thực hiện tốt
trước đó, kiểm tra khả năng vận hành của sản phẩm trong các môi trường đặc biệt (đo
tốc độ xử lý trung bình ứng với mỗi yêu cầu, xác định khả năng chịu tải tối đa, xác
định cấu hình tối thiểu để thực thi hệ thống, kiểm tra các cơ chế an ninh và an
toàn, ...).
Với những loại dưới đây thích hợp cho tự động hóa( hiệu quả mang lại lớn):
-
Những kiểm tra cần thực hiện nhiều lần
-
Thực hiện kiểm tra ở nhiều môi trường
-
Đặc điểm kĩ thuật được xác định, test màn hình・chức năng khơng thay đổi trong
tương lai.
-
Thường xuyên thực hiện test xác nhận hoạt động cơ bản( chẳng hạn như di
chuyển hệ thống)
-
Test sự kết hợp của nhiều giá trị đầu vào ở một bước nào đó
20
-
Kiểm tra nhiều màn hình của dữ liệu đầu vào
-
Mục đầu vào ở nhiều màn hình đăng kí
Kiểm thử khơng thích hợp cho tự động hóa( Khơng mang lại hiệu quả)
-
Kiểm tra khơng có tính hồi quy
Kiểm tra những hoạt động như test độ tin cây, giới hạn, cạnh tranh…
Việc thực hiện tự động không phải là ứng dụng cho tất cả các trường hợp test
Khơng thể tự động hóa cho tất cả các trường hợp thử nghiệm. Với nhiều trường
hợp test không yêu cầu hồi quy, đặc điểm kĩ thuật ln thay đổi thì tự động hóa
khơng mang lại chút hiệu quả nào.
Một số công cụ kiểm thử tự động: Jmeter, Selemium webdriver, Katalon, QTP,….
3.2. Katalon studio
3.2.1. Giới thiệu về Katalon studio
Katalon Studio là một giải pháp kiểm thử tự động được phát triển bởi Katalon LLC.
Phần mềm này được xây dựng dựa trên các khung tự động hóa nguồn
mở selenium, Appium với
giao
diện IDE chuyên
dụng
để
kiểm
thử
ứng
dụng web, API, di động và máy tính để bàn. Bản phát hành đầu tiên để sử dụng nội bộ
là vào tháng 1 năm 2015. Bản phát hành công khai đầu tiên là vào tháng 9 năm 2016.
Năm 2018, phần mềm đã giành được 9% thâm nhập thị trường trong lĩnh vực kiểm thử
tự động giao diện người dùng, theo Báo cáo về tình hình kiểm thử năm 2018
của SmartBear.
Katalon được công nhận là Sự lựa chọn của khách hàng trong lĩnh vực kiểm thử tự
động phần mềm của Gartner Peer Insights tháng 3 năm 2019 và tháng 3 năm 2020.
Là một bộ công cụ tồn diện cho kiểm thử tự động hóa ứng dụng trên web và điện
thoại di động. Công cụ này bao gồm một gói đầy đủ các tính năng mạnh mẽ giúp vượt
qua những thách thức phổ biến trong tự động hóa thử nghiệm giao diện web, ví dụ như
pop-up, iFrame và wait-time. Giải pháp thân thiện và linh hoạt này giúp tester thực hiện
21
công tác kiểm tra tốt hơn, làm việc nhanh hơn và khởi chạy phần mềm chất lượng cao
nhờ vào sự thơng minh mà nó cung cấp cho tồn bộ q trình tự động hóa kiểm thử.
22
3.2.2. Ưu, nhược điểm
a. Ưu điểm
- Triển khai đơn giản
- Cài đặt nhanh chóng và dễ dàng: khơng chỉ cung cấp cài đặt đơn giản, Katalon
Studio còn giúp tester dễ dàng thiết lập mơi trường. Người kiểm thử có thể chạy kịch
bản kiểm thử đầu tiền của họ khá nhanh chóng bằng cách sử dụng các mẫu và tập lệnh
kiểm thử dựng sẵn của nó, chẳng hạn như kho đối tượng và thư viện từ khóa.
- Kết quả nhanh hơn và tốt hơn: các mẫu dựng sẵn với hướng dẫn rõ ràng giúp người
kiểm tra nhanh chóng xây dựng và chạy các kịch bản kiểm thử tự động. Có thể thực
hiện từng bước một tốc độ và hiệu quả, từ thiết lập dự án, tạo kiểm thử, thực hiện, tạo
báo cáo và bảo trì.
- Chế độ linh hoạt: có thể sử dụng bản ghi và từ khóa để xây dựng bài kiểm thử tự
động, trong khi có IDE đầy đủ để xây dựng tập lệnh nâng cao.
- Dễ sử dụng: ngay cả thủ cơng với kinh nghiệm lập trình tối thiểu cũng có thể khai
thác lợi ích của nó một cách dễ dàng.
- Ứng dụng đa trình duyệt: Katalon Studio hỗ trợ nhiều nền tảng: Windows 32 và 64
(7, 8, và 10) và OS X 10.5+.
- Katalon Studio khá mạnh mẽ trong việc kết nối dữ liệu cho việc thực thi kiểm thử
hướng dữ liệu. Không chỉ kết nối đến các tập tin dữ liệu cơ bản như Excel hay CSV,
công cụ này cho phép chúng ta kết nối đến các cơ sở dữ liệu như MySQL, SQL Server,
Oracle. Chỉ có một điều hơi lạ ở đây, Katalon Studio khơng hỗ trợ kết nối đến tập tin
XML.
- Sau khi thực thi kịch bản kiểm thử, các kết quả kiểm thử được tập hợp trong thư
mục Reports khá rõ ràng. Thêm nữa, Katalon Studio có khả năng trích xuất các kết quả
này thành báo cáo dưới nhiều định dạng khác nhau như HTML, CSV và PDF.
23
- Katalon là một gói và khung hồn chỉnh
b. Nhược điểm:
- Giải pháp mới nổi với một cộng đồng phát triển nhanh chóng.
- Bộ tính năng vẫn đang phát triển.
- Thiếu các lựa chọn cho các ngôn ngữ kịch bản: chỉ hỗ trợ Java/ Groovy.
3.2.3. Cấu hình và cài đặt
a. Cấu hình
Các yêu cầu hệ thống:
Hệ thống
Yêu cầu
Hệ điều hành
Windows 7, Windows 8, Windows 10, macOS 10.11+, Linux
(Ubuntu based)
CPU
Bộ xử lí 1 Ghz hoặc nhanh hơn 32 bit (x86) hoặc 64 bit (x64)
Bộ nhớ
Tối thiểu 1 GB RAM (32 bit) hoặc 4 GB RAM (64 bit). Khuyến
nghị là 4 GB RAM (32 bit) và 8 GB RAM (64 bit)
Ổ cứng
Ít nhất 1 GB dung lượng ổ cứng khả dụng. Cần thêm dung lượng
đĩa phụ thuộc vào mã nguồn dự án và các báo cáo thực hiện được
tạo.
Môi trường được hỗ trợ:
Trình
duyệt
Desktop
Version
on
Windows
Version on
MacOS
Chú ý
Internet
Explorer
9, 10, 11
N/A
Cấu hình IE bắt buộc: cấu hình Internet
Explorer
Microsof
t Edge
Hiện
hành
N/A
Tham khảo trang này để biết trạng thái
hiện
tại
của
Edge
WebDriver: />24
Firefox
56+
Google
Chrome
58+
Để sử dụng
Firefox 57 với
Katalon Studio,
vui lòng sử
dụng Katalon
Studio v5.1 +
Opera
Không hỗ
trợ
Safari
5.1+
9,10,11
b. Hướng dẫn cài đặt
Để tải Katalon Studio, chúng ta cần đăng ký một tài khoản với trang chủ. Sau khi tải
về, chúng ta chỉ cần giải nén là có thể sử dụng được. Katalon Studio khơng có một quá
trình cài đặt phức tạp. Điều này khá tiện lợi cho người dùng.
3.2.5. So sánh katalon và selenium
Tính năng
Selenium
25
Katalon Studio