QUẢN Lý d6cntt epu dai

MỤC LỤC


DANH MỤC HÌNH ẢNH


DANH MỤC BẢNG


LỜI MỞ ĐẦU
Ngày nay, các sản phẩm phần mềm đã có mặt trong tất cả các lĩnh vực đời sống,
kinh tế, xã hội của con người. Sản xuất phần mềm trở thành một ngành công nghiệp
mang lại giá trị lớn, có tốc độ phát triển nhanh như vũ bão. Đặc biệt với sự bùng nổ
Internet đã thúc đẩy nhu cầu công tác làm việc qua mạng và sử dụng các dịch vụ trực
tuyến. Các ứng dụng web trở thành xu hướng tất yếu của ngành công nghiệp phần
mềm. Nó giúp người dùng cộng tác với nhau trên những hệ thống linh hoạt không phụ
thuộc vào một nên tảng cố định ở mọi lúc mọi nơi.
Với yêu cầu ngày càng cao của việc phát triển phần mềm, mức độ phức tạp ngày
càng lớn, giới hạn về thời gian và chi phí ngày càng khắt khe, khách hàng ngày càng
khó tính có nhiều yêu cầu cao nên các công ty phần mềm cần phải đưa ra được những
sản phẩm đạt yêu cầu, do đó việc kiểm thử phần mềm là một yếu tố quan trọng không
thể thiếu.
Trong quá trình phát triển phần mềm, việc đảm bảo chất lượng phần mềm đang là
bài toán khó tiêu tốn hơn 50% công sức và chi phí của các doanh nghiệp phần mềm.
Kiểm thử là khâu không thể thiếu trong việc đảm bảo chất lượng phần mềm. Tùy vào
từng giai đoạn phát triển phần mềm mà có kiểm thử đơn vị, kiểm thử tích hợp, kiểm
thử chấp nhận v.v. Kiểm thử bằng tay tốn kém về thời gian, công sức, không kinh tế và
dễ gây nhàm chán cho người thực hiện kiểm thử. Vì vậy, nhiều công cụ kiểm thử tự
động ra đời phần nào giải quyết được những vấn đề trên.
Tuy nhiên việc kiểm thử chấp nhận dùng để kiểm định phần mềm có đáp ứng
đúng nhu cầu khách hàng, khách hàng có chấp nhận phần mềm hay không, kiểm thử

này lại không dễ tự động hóa, nhất là với các phần mềm ứng dụng web. Kiểm thử
tương tác giao diện người dùng là một vấn đề khó trong kiểm thử chấp nhận các ứng
dụng web. Thực tế, chúng ta phải kiểm tra sự hài lòng của khách hàng khi có sự thay
đổi giao diện màn hình ứng với tương tác của người dùng. Các thay đổi trạng thái này
có thể xảy ra trong một trang web hoặc từ trang web này sang trang web khác. Trong
thực tế, kiểm thử chấp nhận các ứng dụng web vẫn thực hiện thủ công. Vì thế, ngoài
việc gây nhàm chán cho kiểm thử viên, tốn kém cho nhà sản xuất, các ứng dụng web
hiện nay vẫn tiềm ẩn nhiều lỗi khi triển khai cho khách hàng
Do vậy em đã chọn đề tài “Nghiên cứu và xây dựng ứng dụng kiểm thử tự
động trên web với Robot Framework” làm đề tài cho đồ án thực tập của mình.
Robot Framework là một khung mã nguồn mở để kiểm thử chấp nhận tự động phần
mềm, thực hiện kiểm thử dựa trên từ khóa, khách hàng dễ dàng tham gia vào quá trình


kiểm thử. Hiện nay Robot Framework đang được cộng đồng kiểm thử trong nước và
thế giới quan tâm và được đánh giá rất cao.
Mục tiêu của đề tài là nghiên cứu lý thuyết và xây dựng kịch bản kiểm thử đối
với một ứng dụng thực tế. Sau khi hoàn thành đồ án ta có thể nắm được Robot
Framework với các thư viện chuẩn, thứ hai là tạo ra bộ kiểm thử sử dụng các từ khóa
do các thư viện của Robot Framework cung cấp, sử dụng thêm thư viện mở rộng
SeleniumLibrary để kết hợp với Robot Framework kiểm thử ứng dụng website
bizweb.vn
Nội dung đề tài đề cập đến các cơ sở lý thuyết về kiểm thử phần mềm, các phương
pháp thiết kế ca kiểm thử cho website, hoạt động kiểm thử bằng công cụ tự động và
tìm hiểu về công cụ Robot Framework. Đồ án gồm những nội dung chính sau:
• Chương 1: Tổng quan về kiểm thử phần mềm
• Chương 2: Công cụ kiểm thử phần mềm tự động Robot Framework và thư viện
Selenium
• Chương 3: Xây dựng chương trình kiểm thử module Quản lý đơn hàng trong
website bizweb.vn

Đây là đề một đề tài lớn, có sự đóng góp không nhỏ của các bạn trong công ty
Vidagis và đặc biệt là sự hướng dẫn tận tình của cô Bùi Khánh Linh. Nhưng đây cũng
là một đề tài mới do có những hạn chế nhất định về mặt kiến thức cũng như kinh
nghiệm thực tế nên trong đồ án của em không thể tránh được những thiếu sót, khuyết
điểm. Em rất mong được thầy cô và các bạn giúp đỡ để kiến thức bản thân cũng như
đồ án được hoàn thiện hơn.


CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
Trong chương này, ta sẽ đi vào nghiên cứu tổng quan về kiểm thử phần mềm,
gồm các kiến thức về lỗi phần mềm, kiểm thử phần mềm và cuối cùng là về việc thiết
kế các ca kiểm thử.
1.1.

Lỗi phần mềm

1.1.1. Định nghĩa
Lỗi phần mềm là thể hiện khi chương trình không làm những gì mà người dùng
mong muốn nó làm.
Lỗi phần mềm thường xuất hiện ở 3 dạng:
• Sai: Sản phẩm được xây dựng khác với đặc tả
• Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm được
xây dựng.
• Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả. Cũng có
trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấp nhận
nhưng khác với đặc tả nên vẫn coi là có lỗi.
Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu, khó sử
dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm họat động không đúng.
1.1.2. Nguyên nhân
- Lỗi mã nguồn: Chương trình không làm những gì mà người lập trình mong

muốn chương trình làm.
- Vấn đề thiết kế: Chương trình thực hiện những gì mà lập trình viên yêu cầu,
nhưng khách hàng không thích và không vui với nó.
- Vấn đề yêu cầu: Chương trình đã được thiết kế và thực hành tốt nhưng nó
không phù hợp với yêu cầu của khách hàng.
- Không hòa hợp giữa tài liệu và mã nguồn.
- Không hòa hợp giữa đặc tả và mã nguồn: Đặc tả yêu cầu bị thay đổi.
1.1.3. Lỗi phần mềm phổ biến
- Lỗi giao diện.
- Xử lý sự kiện làm người dùng không hiểu.
- Ngoài giá trị biên.
- Lỗi tính toán.
- Giai đoạn khởi động và kết thúc.
6


- Luồng điều khiển.
- Lỗi nhập dữ liệu.
- Điều kiện tải
- Điều kiện cạnh tranh
- Điều kiện không tương thích với môi trường.
- Dùng phần mềm phiên bản, ID điều khiển.
- Kiểm thử.
- Tài liệu.
1.2.

Kiểm thử phần mềm

1.2.1. Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế

để đảm bảo quá trình xây dựng phần mềm thực hiện theo cái mà chúng đã được thiết
kế để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây là một phần quan
trọng trong quá trình phát triển phần mềm, giúp cho người xây dựng phần mềm và
khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?
Các phương thức kiểm thử phầm mềm phổ biến:

Hình 1.1 Các phương thức kiểm thử phần mềm
• Automated Testing là kiểm thử phần mềm tự động
• Manual Testing là kiểm thử thủ công theo phương thức truyền thống
• Software Quality Assurance là quy trình có tính hệ thống, đòi hỏi phải đảm bảo
cả về quy trình và chất lượng sản phẩm.

7


1.2.2. Mô hình phát triển kiểm thử phần mềm

Hình 1.2 Mô hình chữ V
Các tính chất quan trọng trên mô hình kiểm thử:
Các hoạt động xây dựng phần mềm và kiểm thử là tách biệt nhau.
Cần phân biệt giữa các mức độ kiểm thử ở đó mỗi mức kiểm thử là kiểm thử trên mức
phát triển phần mềm tương ứng.
- Quy trình thiết lập các yêu cầu phần mềm, thiết kế, xây dựng, kiểm thử hệ
thống phần mềm được thực hiện như một chuỗi các chu trình phát triển ngắn
hơn.
- Các yếu tố quan trọng của quy trình kiểm thử:
- Cần có một mức độ kiểm thử cho mỗi công đoạn phát triển phần mềm.
- Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêu
đặc thù riêng.
- Việc phân tích và thiết kế các ca kiểm thử cho một mức độ kiểm thử nên bắt

đầu sớm nhất có thể.
- Các kiểm thử viên nên xem xét các tài liệu sớm có thể, ngay sau khi các tài liệu
này được tạo ra trong chu kỳ phát triển phần mềm.

8


- Số lượng và cường độ của các mức kiểm thử được điều khiển theo các yêu cầu
đặc thù của dự án phần mềm đó.
1.2.3. Các chiến lược kiểm thử phần mềm
1.2.3.1. Phương pháp kiểm thử
1) Phương pháp kiểm thử hộp đen
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ
liệu, hay hướng vào/ra. 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à hoàn toàn không quan tâm về cách hoạt động 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 thử chỉ được lấy từ các đặc tả yêu cầu.
Các phương pháp kiểm thử hộp đen:
Phân lớp tương đương.
Phân tích giá trị biên.
Kiểm thử dựa trên đặc tả yêu cầu tập trung vào kiểm thử tính thiết thực của phần
mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ
thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm
thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ
liệu đầu vào đã cho, giá trị đầu ra( hay cách thức hoạt động) có giống với giá trị mong
muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là
cần thiết, nhưng không đủ để ngăn chặn những rủi ro chắc chắn.
Ưu và nhược điểm:
Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử đơn vị

nên rất đơn giản là luôn tâm niệm rằng: một mã lệnh phải có lỗi. Những kiểm thử viên
hộp đen tìm ra lỗi mà những nhà lập trình viên không tìm ra. Nhưng mặt khác người ta
cũng nói kiểm thử hộp đen”giống như là đi trong bóng tối mà không có đèn vậy”, bởi
vì kiểm thử viên không biết các phần mềm được kiểm thử thực sự được xây dựng như
nào. Đó là lý do, có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca
kiểm thử để kiểm thử một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm thử bằng một ca
kiểm thử duy nhất, và hoặc 1 số phần của chương trình không được kiểm thử chút nào.
Do vậy kiểm thử hộp đen có ưu điểm của” một sự đánh giá khách quan” mặt
khác cũng có nhược điểm của” thăm dò mù”.
2) Phương pháp kiểm thử hộp trắng
Phương pháp kiểm thử hộp trắng có thể được sử dụng để đánh giá sự hoàn thành
của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều
9


này cho phép các nhóm phần mềm khảo sát các phần của một hệ thống ít khi được
kiểm thử và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm thử.
Kiểm thử hộp trắng thường do các lập trình viên thực hiện.
1.2.3.2. Cấp độ kiểm thử cơ bản
Kiểm thử phần mềm gồm có các cấp độ: kiểm thử đơn vị, kiểm thử tích hợp,
kiểm thử hệ thống và kiểm thử chấp nhận sản phẩm.

Hình 1.3 Sơ đồ các cấp độ kiểm thử
1) Kiểm thử đơn vị
Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được.
Ví dụ: các hàm, thủ tục, lớp hay phương thức đều có thể được xem là đơn vị.
Vì đơn vị được chọn để kiểm thử thường có kích thước nhỏ và chức năng hoạt
động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và
phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục
cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn vị đang kiểm thử. Một

nguyên lý đúc kết từ thực tiễn: Thời gian tốn cho kiểm thử đơn vị sẽ được đền bù bằng
việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức
kiểm thử sau đó.
Kiểm thử đơn vị thường do lập trình viên thực hiện. Công đoạn này cần được
thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển
phần mềm. Thông thường kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết
10


kế và code của chương trình. Mục đích của kiểm thử đơn vị là bảo đảm thông tin được
xử lý và kết quả đưa ra là chính xác, trong mối tương quan với dữ liệu nhập và chức
năng của đơn vị. Điều này thường đòi hỏi tất cả các nhánh bên trong đơn vị đều phải
được kiểm thử để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các
lệnh được thực thi trong một đơn vị. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm
giữa Then ... Else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc
kiểm thử và quét hết đơn vị đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để
chọn lựa.
Cùng với các mục kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị
trước các ca kiểm thử hoặc kịch bản kiểm thử, trong đó chỉ định rõ dữ liệu đầu vào,
các bước thực hiện và dữ liệu đầu ra mong muốn. Các ca kiểm thử và kịch bản kiểm
thử này nên được giữ lại để tái sử dụng.
2) Kiểm thử tích hợp
Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử như
một ứng dụng đã hoàn thành. Trong khi kiểm thử đơn vị kiểm thử các thành phần và
đơn vị riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm thử sự giao
tiếp giữa chúng.
Hai mục tiêu chính của kiểm thử tích hợp:
- Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị
- Tích hợp các đơn vị đơn lẻ thành các hệ thống nhỏ và cuối cùng là hệ thống hoàn
chỉnh chuẩn bị cho kiểm thử ở mức hệ thống.

Trong kiểm thử đơn vị, lập trình viên cố gắng phát hiện lỗi liên quan đến chức
năng và cấu trúc nội tại của đơn vị. Có một số phép kiểm thử đơn giản trên giao tiếp
giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến
đơn vị chỉ thật sự được kiểm thử đầy đủ khi các đơn vị tích hợp với nhau trong khi
thực hiện kiểm thử tích hợp.
Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã
được kiểm thử cẩn thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức đơn vị đã
được sửa chữa. Một số người hiểu sai rằng đơn vị một khi đã qua giai đoạn kiểm thử
đơn vị với các giao tiếp giả lập thì không cần phải thực hiện kiểm thử tích hợp nữa.
Thực tế việc tích hợp giữa các đơn vị dẫn đến những tình huống hoàn toàn khác. Một
chiến lược cần quan tâm trong kiểm thử tích hợp là nên tích hợp dần từng đơn vị. Một
đơn vị tại một thời điểm được tích hợp vào một nhóm các đơn vị khác đã tích hợp
trước đó và đã hoàn tất các đợt kiểm thử đơn vị trước đó. Lúc này, ta chỉ cần kiểm thử
11


giao tiếp của đơn vị mới thêm vào với hệ thống các đơn vị đã tích hợp trước đó, điều
này sẽ làm cho số lượng ca kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể.
3) Kiểm thử hệ thống
Mục đích kiểm thử hệ thống là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích
hợp) có thỏa mãn yêu cầu đặt ra hay không.
Kiểm thử hệ thống bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp
thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian.
Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc
phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ
thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng
tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến
chất lượng của toàn hệ thống.
Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm
thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp

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 kiểm thử đơn vị và kiểm thử tích hợp để bảo đảm mọi
đơn vị và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm thử
hệ thống.
Sau khi hoàn thành kiểm thử tích hợp, một hệ thống phần mềm đã được hình thành
cùng với các thành phần đã được kiểm thử đầy đủ. Tại thời điểm này, lập trình viên
hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lập
kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân tích các
yêu cầu.
Kiểm thử hệ thống là kiểm thử cả các hành vi chức năng của phần mềm lẫn các
yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm
hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" hoặc chiếm dụng bộ nhớ.
Sau giai đoạn kiểm thử hệ thống phần mềm thường đã sẵn sàng cho khách hàng hoặc
người dùng cuối cùng kiểm thử chấp nhận sản phẩm hoặc dùng thử. Đòi hỏi nhiều
công sức, thời gian và tính chính xác, khách quan, kiểm thử hệ thống thường được
thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án.
Bản thân kiểm thử hệ thống lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất
gồm:
- Kiểm thử chức năng: Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu
thiết kế.
12


- Kiểm thử hiệu năng: Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ
nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn...
- Kiểm thử khả năng chịu tải: Bảo đảm hệ thống vận hành đúng dưới áp lực cao
(ví dụ nhiều người truy xuất cùng lúc). Các trạng thái tới hạn, các "điểm chết",
các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều
trong kiểm thử thiết bị như POS, ATM...)...

- Kiểm thử cấu hình: Hệ thống có thể chạy được trên các môi trường khác nhau.
- Kiểm thử bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
- Kiểm thử khả năng phục hồi: Bảo đảm hệ thống có khả năng khôi phục trạng
thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt
quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến...
Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng
bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực. Lưu ý là không nhất
thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của
từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người
quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.
4) Kiểm thử chấp nhận sản phẩm
Thông thường, sau giai đoạn kiểm thử hệ thống là kiểm thử chấp nhận sản phẩm
đượ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). Mục đích
của kiểm thử chấp nhận sản phẩm là để chứng minh phần mềm thỏa mãn tất cả yêu
cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp
đồng).
Kiểm thử chấp nhận sản phẩm có ý nghĩa hết sức quan trọng, mặc dù trong hầu
hết mọi trường hợp, các phép kiểm thử của kiểm thử hệ thống và kiểm thử chấp nhận
sản phẩm gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành để bán rộng rãi trên thị trường cho nhiều người sử
dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha và kiểm thử
Beta. Với kiểm thử Alpha, người dùng kiểm thử phần mềm ngay tại nơi phát triển
phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa.
Với kiểm thử Beta, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong
môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa
chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá
trình phát triển phần mềm thì kết quả kiểm thử chấp nhận sản phẩm sẽ sai lệch rất lớn,
13

mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan
đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một
phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực
hiện dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình
nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v...
Gắn liền với giai đoạn kiểm thử chấp nhận sản phẩm thường là một nhóm những
dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v... Tất cả tài liệu
đi kèm phải được cập nhật và kiểm thử chặt chẽ.
1.2.4. Nguyên tắc kiểm thử phần mềm
Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ
một số quy tắc sau:
Quy tắc 1: Một phần quan trọng của một ca kiểm thử là định nghĩa của đầu ra
hay kết quả mong muốn.
Quy tắc 2: Lập trình viên nên tránh tự kiểm thử chương trình của mình.
Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ.
Quy tắc 4: Kiểm thử thấu đáo mọi kết quả của mỗi kiểm thử.
Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp
lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn.
Quy tắc 6: Khảo sát một chương trình để xem liệu chương trình có thực hiện cái
mà nó cần thực hiện chỉ là một phần, phần còn lại là xem liệu chương trình có thực
hiện cái mà nó không cần phải thực hiện hay không.
Quy tắc 7: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm
thấy lỗi.
Quy tắc 8: Xác suất tồn tại lỗi trong một đoạn chương trình là tương ứng với số
lỗi đã tìm thấy trong đoạn đó.
Quy tắc 9: Kiểm thử là một nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ.
1.2.5. Khó khăn của kiểm thử phần mềm
- Liên quan đến tiến trình phát triển: Phần mềm phát triển qua nhiều giai đoạn,
sự mất mát thông tin.

- Về mặt con người: Thiếu đào tạo, ít chú trọng vào vai trò kiểm thử.
- Về mặt thuật toán: Không tồn tại thuật toán tổng quát có thể chứng minh sự
đúng đắn hoàn toàn của bất ký một chương trình nào.
14


1.3.

Thiết kế các ca kiểm thử

1.3.1. Khái niệm
Thiết kế ca kiểm thử trong kiểm thử phần mềm là quá trình xây dựng các phương
pháp kiểm thử có thể phát hiện lỗi, sai sót, khuyết điểm của phần mềm để xây dựng
phần mềm đạt tiêu chuẩn.
1.3.2. Yêu cầu của một ca kiểm thử
Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần
mềm một cách nhiều nhất.
Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và công sức
nhất.
Không được quá đơn giản hay quá phức tạp, không thừa, không làm sai lệch
chương trình.
Một ca kiểm thử tốt:
- Nhận biết được đối tượng đang kiểm thử.
- Có tiêu chí đánh giá đúng hoặc sai.
- Phải chi tiết để bất cứ kiểm thử viên nào với những hiểu biết về hệ thống có thể
thực hiện được ca kiểm thử này.
Một ca kiểm thử không tốt:
- Để người dùng tự tìm dữ liệu để kiểm thử.
- Đưa ra những ý tưởng quá cao.
- Không xem xét như một người kiểm thử có kinh nghiệm.

- Đưa ra những bước khó xác định đúng hay sai.
1.3.3. Nội dung của một ca kiểm thử
Yếu tố quan trọng của một ca kiểm thử:
- Test case ID: Xác định một ca kiểm thử .
- Test case Description: Mô tả nội dung của một ca kiểm thử.
- Test case Procedure: Tập hợp các bước, hành động cần thiết để hoàn thành một
đối tượng hay điều kiện nào đó.
- Expected output: Tập hợp các kết quả sau khi thực thi.
- Inter-test case Dependence: Ca kiểm thử phụ thuộc cần phải có đã thực hiện
trước đó.
- Result: Kết quả sau khi đã kiểm thử xong.
- Date test: Thời gian thực hiện kiểm thử .
- Note: Những ghi chú cần thiết của ca kiểm thử.
Cú pháp của một ca kiểm thử:
Hành động + Chức năng + Điều kiện
15


Chức năng có thể là : chức năng, tính năng, điểm xác định.
Điều kiện có thể là dữ liệu.
Hành động : xác định, kiểm thử, giá trị, thực thi, chạy, tính toán…
Điểm xác định là dự kiến kết quả.
1.3.4. Thiết kế ca kiểm thử
Một trong những yếu tố quan trọng nhất trong kiểm thử chương trình là thiết kế
và tạo ra các ca kiểm thử có hiệu quả. Với những ràng buộc về thời gian và chi phí đã
cho, thì vấn đề then chốt của kiểm thử trở thành: Tập con nào của tất cả ca kiểm thử có
thể có khả năng tìm ra nhiều lỗi nhất?
Ví dụ về một ca kiểm thử của màn hình “Đăng nhập”:

Hình 1.4 Màn hình “Đăng nhập”

Test case description: Kiểm thử đăng nhập với [Tên người dùng] và [Mật khẩu] hợp lệ.
Test case procedure:
a) Nhập “aaa” vào trường [Tên đăng nhập]
b) Nhập “bbb” vào trường [Mật khẩu]
c) Bấm vào nút [Đăng nhập]
Expected output: Hiển thị trang hộp thư đến của tài khoản gmail vừa nhập.
Thông thường, phương pháp kém hiệu quả nhất là kiểm thử tất cả các đầu vào,
kiểm thử ngẫu nhiên của quá trình kiểm thử một chương trình bằng việc chọn ngẫu
nhiên một tập con các giá trị đầu vào có thể. Về mặt khả năng tìm ra nhiều lỗi nhất, tập
hợp các ca kiểm thử được chọn ngẫu nhiên có rất ít cơ hội là tập hợp tối ưu hay gần tối
ưu. Sau đây là một số phương pháp để chọn ra một tập dữ liệu kiểm thử một cách
thông minh.
16


1.3.4.1. Phân lớp tương đương
Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào
của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử. Phương
pháp này cố gắng xác định ra một ca kiểm thử mà làm lộ ra một lớp lỗi, do đó làm
giảm tổng số các trường hợp kiểm thử phải được xây dựng.
Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp
tương đương với một điều kiện vào. Lớp tương đương biểu thị cho tập các trạng thái
hợp lệ hay không hợp lệ đối với điều kiện vào.
Một cách xác định tập con này là để nhận ra rằng một ca kiểm thử được lựa chọn
tốt cũng nên có 2 đặc tính khác:
1) Giảm thiểu số lượng các ca kiểm thử khác mà phải được phát triển để hoàn
thành mục tiêu đã định của kiểm thử “hợp lý”.
2) Bao phủ một tập rất lớn các ca kiểm thử có thể khác. Tức là, nó nói cho chúng
ta một thứ gì đó về sự có mặt hay vắng mặt của những lỗi qua tập giá trị đầu
vào cụ thể.

Thiết kế ca kiểm thử 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ử.
Cơ sở:
Lỗi thường xuất hiện gần các giá trị biên của miền dữ liệu.
Nguyên tắc:
- Giá trị nhỏ nhất.
- Giá trị gần kề lớn hơn giá trị nhỏ nhất.
- Giá trị bình thường.
- Giá trị gần kề nhỏ hơn giá trị lớn nhất.
- Giá trị lớn nhất.
• Xác định các lớp tương đương
Các lớp tương đương được xác định bằng cách lấy mỗi trạng thái đầu vào và
phân chia nó thành hai hay nhiều nhóm.
Chú ý là hai kiểu lớp tương đương được xác định: lớp tương đương hợp lệ mô tả
các đầu vào hợp lệ của chương trình, và lớp tương đương không hợp lệ mô tả tất cả
các trạng thái có thể khác của điều kiện. Với một đầu vào hay điều kiện bên ngoài đã

17


cho, việc xác định các lớp tương đương hầu như là một quy trình mang tính kinh
nghiệm. Để xác định các lớp tương đương có thể áp dụng tập các nguyên tắc dưới đây:
1) Nếu trạng thái đầu vào xác định rõ giới hạn của các giá trị, xác định được một
lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ.
2) Nếu trạng thái đầu vào xác định số giá trị, xác định được một lớp tương đương
hợp lệ và hai lớp tương đương không hợp lệ.
3) Nếu trạng thái đầu vào chỉ định tập các giá trị đầu vào và chương trình sử dụng
mỗi giá trị là khác nhau, xác định một lớp tương đương hợp lệ cho mỗi loại và
một lớp tương đương không hợp lệ.

4) Nếu trạng thái đầu vào chỉ định một tình huống “chắc chắn”, xác định một lớp
tương đương hợp lệ và một lớp tương đương không hợp lệ.
Nếu có bất kỳ lý do nào để tin rằng chương trình không xử lý các phần tử trong
cùng một lớp là như nhau, thì hãy chia lớp tương đương đó thành các lớp tương đương
nhỏ hơn.
• Xác định các ca kiểm thử
Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụng các
lớp tương đương đó để xác định các ca kiểm thử. Quá trình này như sau:
1) Gán một số duy nhất cho mỗi lớp tương đương.
2) Cho đến khi tất cả các lớp tương đương hợp lệ được bao phủ bởi các ca kiểm
thử, viết một ca kiểm thử mới bao phủ càng nhiều các lớp tương đương chưa
được bao phủ càng tốt.
3) Cho đến khi các ca kiểm thử của bạn đã bao phủ tất cả các lớp tương đương
không hợp lệ, viết một ca kiểm thử mà bao phủ một và chỉ một trong các lớp
tương đương không hợp lệ chưa được bao phủ.
4) Lý do mà mỗi ca kiểm thử riêng bao phủ các trường hợp không hợp lệ là vì các
kiểm thử đầu vào không đúng nào đó che giấu hoặc thay thế các kiểm thử đầu
vào không đúng khác.
Mặc dù việc phân lớp tương đương là rất tốt khi lựa chọn ngẫu nhiên các ca kiểm
thử, nhưng nó vẫn có những thiếu sót. Ví dụ, nó bỏ qua các kiểu kiểm tr thử a có lợi
nào đó. Phương pháp tiếp theo, phân tích giá trị biên sẽ hạn chế được nhiều những
thiếu sót này.
1.3.4.2. Phân tích giá trị biên
Kinh nghiệm cho thấy các ca kiểm thử mà khảo sát tỷ mỷ các điều kiện biên có
tỷ lệ phần trăm cao hơn các ca kiểm thử khác. Các điều kiện biên là những điều kiện
18


mà các tình huống ngay tại trên và dưới các cạnh của các lớp tương đương đầu vào và
các lớp tương đương đầu ra. Phân tích các giá trị biên là phương pháp thiết kế ca kiểm

thử bổ sung thêm cho phân lớp tương đương, nhưng khác với phân lớp tương đương ở
hai khía cạnh:
1) Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong một lớp tương
đương là điển hình, mà nó yêu cầu là một hay nhiều phần tử được lựa chọn như
vậy mà mỗi cạnh của lớp tương đương đó chính là đối tượng kiểm thử.
2) Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gian đầu vào),
các ca kiểm thử cũng nhận được bằng việc xem xét không gian kết quả (các lớp
tương đương đầu ra).
Phân tích giá trị biên yêu cầu óc sáng tạo và lượng chuyên môn hóa nhất định và
nó là một quá trình mang tính kinh nghiệm rất cao. Tuy nhiên, có một số quy tắc
chung như sau:
1) Nếu trạng thái đầu vào định rõ giới hạn của các giá trị, hãy viết các ca kiểm thử
cho các giá trị cuối của giới hạn, và các ca kiểm thử đầu vào không hợp lệ cho
các trường hợp vừa ra ngoài phạm vi.
2) Nếu trạng thái đầu vào định rõ số lượng giá trị, hãy viết các ca kiểm thử cho
con số lớn nhất và nhỏ nhất của các giá trị và một giá trị trên, một giá trị dưới
những giá trị này.
3) Sử dụng quy tắc 1 cho mỗi trạng thái đầu vào. Sử dụng nguyên tắc 2 cho mỗi
trạng thái đầu ra.
4) Nếu đầu vào hay đầu ra của một chương trình là tập được sắp thứ tự tập trung
chú ý vào các phần tử đầu tiên và cuối cùng của tập hợp.
5) Sử dụng sự khéo léo để tìm các điều kiện biên.
1.3.4.3. Đoán lỗi
Một kỹ thuật thiết kế ca kiểm thử khác là đoán lỗi. Kỹ thuật viên kiểm thử được
đưa cho một 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 đó. Một ý tưởng khác để xác định các ca kiểm thử có liên đới với các giả

định mà lập trình viên có thể đã thực hiện khi đọc đặc tả (tức là: những thứ bị bỏ sót
khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết có cảm giác những đặc tả đó là rõ
19


ràng). 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ế.
1.4.

Kết luận chương

Qua chương 1, ta đã hiểu tổng quan về kiểm thử phần mềm, các kiến thức liên
quan tới kiểm thử phần mềm như: khái niệm lỗi phần mềm, nguyên nhân dẫn đến lỗi
phần mềm, các kiến thức về kiểm thử phần thử phần mềm gồm mô hình phát triển
kiểm thử phần mềm, chiến lược kiểm thử, nguyên tắc kiểm thử và các khó khăn mà
kiểm thử phần mềm gặp phải. Cuối cùng là hiểu rõ về việc thiết kế các ca kiểm thử,
các khái niệm và nội dung của một ca kiểm thử.
Chương tiếp theo ta sẽ đi vào tìm hiểu về công cụ để hỗ trợ kiểm thử phần mềm.
Và đi sâu vào tìm hiểu công cụ kiểm thử tự động Robot Framework.

20


CHƯƠNG 2: CÔNG CỤ KIỂM THỬ PHẦN MỀM TỰ ĐỘNG ROBOT
FRAMEWORK VÀ THƯ VIỆN SELELIUM
Trong chương này chúng ta sẽ tìm hiểu về kiến thức về kiểm thử tự động, các
công cụ kiểm thử phần mềm tự động đặc biết là nghiên cứu về công cụ kiểm thử sẽ sử
dụng trong đồ án này là công cụ Robot Framework và thư viện được sẽ sử dụng là
Selenium.
2.1. Kiểm thử tự động

 Khái quát về kiểm thử phần mềm tự động
Như đã biết công việc kiểm thử là một quá trình đi tìm những khiếm khuyết còn
sót lại trong khi làm một phần mềm hay một website. Và trong khi thực hiện công
việc đó bằng cách theo dõi mã lệnh, chạy kết quả thì còn sử dụng những công cụ,
phần mềm hỗ trợ cho quá trình kiểm thử. Càng ngày đi theo sự tiến bộ của khoa học
kỹ thuật thì những kỹ thuật mới, những hỗ trợ mới cũng ra đời giúp cho kỹ thuật viên
kiểm thử dễ dàng thực hiện công việc của họ hơn. Và thành tựu đáng kể nhất trong
công việc kiểm thử phần mềm hiện nay có được đó là kỹ thuật kiểm thử tự động.
Kiểm thử phần mềm tốn nhiều chi phí nhân công, thời gian. Trong một số dự án,
chi phí kiểm thử phần mềm chiếm 50% tổng giá trị của dự án. Nếu cần ứng dụng an
toàn hơn, chi phí kiểm thử còn cao hơn nữa.
Do đó một trong các mục tiêu của kiểm thử là tự động hóa nhiều, nhờ đó mà
giảm thiểu chi phí, giảm lỗi, đặc biệt giúp việc kiểm thử hồi quy dễ dàng và nhanh
chóng hơn.
Tự động hóa việc kiểm thử là dùng phần mềm điều khiển việc thi hành kiểm thử,
so sánh kết quả có được với kết quả mong muốn, thiết lập các điều kiện đầu vào, các
kiểm soát kiểm thử và các chức năng báo cáo kết quả…
 Khái niệm kiểm thử tự động
Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong 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ử.

 Quy trình kiểm thử tự động

21


Hình 2.1 Quy trình kiểm thử tự động
Bước 1: Sau khi tìm hiểu nghiệp vụ từ các tài liệu phân tích, thiết kế, nhóm kiểm thử
Lập kế hoạch kiểm thử xác định các chức năng cần kiểm tra tự động.
Bước 2: Nhóm kiểm thử thiết kế kịch bản kiểm thử các chức năng, mô tả luồng

nghiệp vụ chính, phụ cần kiểm tra sau đó thiết kế các trường hợp kiểm thử đủ các
thông tin: Mục đích, điều kiện kiểm thử, các bước thực hiện và kết quả mong muốn.
Bước 3: Tiến hành viết kịch bản kiểm thử
Bước 4: Từ các trường hợp kiểm thử được thiết kế trong bước 3, nhóm kiểm thử phát
triển các Test Script bằng Robot Framework, cấu hình dữ liệu đầu vào cho từng
trường hợp và thực hiện kiểm thử tự động các Test Script đã tạo.
Bước 5: Sau khi chạy chương trình sẽ có bản Report tạo ra, ghi lại thông tin của
script đã thực hiện.
Bước 6: Dựa vào kết quả thực hiện các Test Script ở bước 5 sẽ đánh giá và tạo báo
cáo kiểm thử.

22


• Bước 6 sẽ quay trở lại bước 1 nếu KTMP( Kiểm thử phẩn mềm) chưa thỏa mức
độ bao phủ yêu cầu phần mềm.
• Bước 6 sẽ quay trở lại bước 2 khi gặp lỗi thiết kế sai yêu cầu
• Bước 6 sẽ quay trở lại bước 3 khi gặp lỗi phát triển test script
 Tại sao phải dùng công cụ kiểm thử tự động
Công cụ kiểm thử tự động trong lĩnh vực phát triển phần mềm là công cụ giúp
thực hiện việc kiểm thử phần mềm một cách tự động. Tuy nhiên không phải mọi việc
kiểm thử đều có thể tự động hóa, câu hỏi đặt ra là trong điều kiện hoặc tình huống
nào dùng công cụ kiểm thử tự động là thích hợp? Việc dùng công cụ kiểm thử tự
động 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 tình huống kiểm thử quá nhiều mà các kỹ
thuật viên không thể hoàn tất bằng tay trong thời gian cụ thể nào đó. Có thể lấy
một dẫn chứng là khi thực hiện kiểm thử chức năng của một website. Website
này sẽ được kiểm thử với các môi trường gồm 3 trình duyệt và 2 hệ điều hành
tình huống này đòi hỏi số lần kiểm thử tăng lên và lặp lại nhiều lần so với việc
kiểm thử cho một môi trường cụ thể.

• Kiểm thử hồi quy: Trong quá trình phát triển phần mềm, nhóm lập trình thường
đưa ra nhiều phiên bản phần mềm liên tiếp để kiểm thử. Thực tế cho thấy việc
đưa ra các phiên bản phần mềm có thể là hàng ngày, mỗi phiên bản bao gồm
những tính năng mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp. Việc bổ
sung hoặc sửa lỗi code cho những tính năng ở phiên bản mới có thể làm cho
những tính năng khác đã kiểm thử tốt chạy sai mặc dù phần code của nó không
hề chỉnh sửa. Để khắc phục điều này, đối với từng phiên bản, kỹ thuật viên
không chỉ kiểm thử chức năng mới hoặc được sửa, mà phải kiểm thử lại tất cả
những tính năng đã kiểm thử tốt trước đó. Điều này khó khả thi về mặt thời gian
nếu kiểm thử thủ công.
• Kiểm thử khả năng vận hành phần mềm trong môi trường đặt biệt: đây là kiểm
thử nhằm đánh giá xem vận hành của phần mềm có thỏa mãn yêu cầu đặt ra hay
không. Thông qua đó kỹ thuật viên có thể xác định được 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. Có thể liệt
kê một số tình huống kiểm thử tiêu biểu thuộc loại này như sau:
- Đo tốc độ trung bình xử lý một yêu cầu của web server.
- Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm thử tình huống
1000 người dùng truy xuất web cùng lúc.
- Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hình
máy thấp nhất mà tốc độ xử lý của phần mềm vẫn có thể hoạt động ở mức cho
phép.
23


Việc kiểm thử thủ công cho những tình huống trên là cực khó, thậm chí “vô
phương”.
Cần lưu ý là hoạt động kiểm thử tự động nhằm mục đích kiểm thử, phát hiện
những lỗi của phần mềm trong những trường hợp đoán trước. Điều này cũng có
nghĩa là nó thường được thực hiện sau khi đã thiết kế xong các tình huống. Tuy
nhiên, như đã nói, không phải mọi trường hợp kiểm thử đều có thể hoặc cần thiết

phải tự động hóa, trong tất cả ca kiểm thử thì kỹ thuật viên phải đánh giá và chọn ra
những ca kiểm thử nào phù hợp hoặc cần thiết để áp dụng kiểm thử tự động dựa trên
những tiêu chí đã đề cập bên trên.
2.2. Giới thiệu một số công cụ kiểm thử tự động và Robot Framework
 Một số công cụ kiểm thử tự động:
• Kiểm thử chức năng( Functionality testing): Quicktest professional (QTP),
Selenium driver, Web link Validator (WLV)
• Kiểm thử bằng hiệu năng: Có rât nhiều công cụ kiểm thử như: OpenSTA, Load
runner – HP’s, Apache JMeter, WAPT, FORECAST, IBM Rational Performance
Tester…
 Robot Framework.
Là một chương trình mã nguồn mở, cung cấp một nền tảng kiểm thử dựa trên ngôn
ngữ lập trình Python hoặc Java. Dùng cho Automation test với các lĩnh vực như:
web,Win app, Database. Cách tiếp cận của nền tảng kiểm thử này là hướng từ
khóa( keyword driven) và hướng dữ liệu( data driven) dành cho việc kiểm thử để
nghiệm thu sản phẩm ngay từ đầu( end - to – end acceptance testing). Người dùng
có thể tạo các từ khóa cấp cao mới từ những cái hiện có bằng cách sử dụng cú
pháp tương tự được sử dụng để tạo ra các trường hợp thử nghiệm.
• Các tính năng của Robot Framework
- Dễ dàng thực hiện kiểm thử tự động với kịch bản ở dạng bảng.
- Robot Framework đưa ra kết quả thực thi các kịch bản kiểm thử và các log ở
dạng html. Điều này giúp chúng ta đọc và phân tích kết quả dễ dàng và nhanh
chóng.
- Robot Framework hỗ trợ chức năng đánh dấu các kịch bản kiểm thử nên cho
phép chúng ta lựa chọn kịch bản để thực thi một cách dễ dàng và tiện lợi.
- Cuối cùng, thế mạnh nhất của Robot Framework so với các nền tảng kiểm thử
khác là khả năng chạy trên nhiều hệ điều hành khác nhau mà không cần chỉnh
sửa kịch bản kiểm thử hay các từ khóa ở tầng dưới.
 Cài đặt Robot Framework
1. Cài đặt Python( Bắt buộc).

24


• Vào trang />
• Chọn mục download để tải chương trình về cài đặt. Chọn bản 2.7.9 để tải.

• Sau khi tải xong thì double click và cài như bình thường. (Next, Next…)
2. Thiết lập biến môi trường (Bắt buộc).
• Nhấp chuột phải lên “my computer”

25