Đề cương kiểm thử phần mềm tự động

Mục lục
Bài 1: Tổng quan về kiểm thử tự động ..............................................................................5
1.1Khái niệm kiểm thử tự động ..........................................................................................5
1.2 Mục tiêu của kiểm thử tự động ....................................................................................5
1.3 Quy trình kiểm thử tự động phần mềm .......................................................................7
1.4 Kiến trúc của một khung làm việc trong kiểm thử tự động......................................7
1.5 Lợi ích của kiểm thử tự động .................................................................................... 12
Bài 2: Tổng quan về kiểm thử tự động (tiếp) ................................................................ 13
2.1 So sánh kiểm thử tự động và kiểm thử thủ công .................................................... 13
2.2 Phân loại các công cụ kiểm thử tự động .................................................................. 15
2.3 Lựa chọn công cụ kiểm thử tự động cho bài toán và tổ chức của bạn ................. 21
Bài 3: Selenium WebDriver cơ bản................................................................................. 22
3.1 Giới thiệu Selenium WebDriver ............................................................................... 22
3.2 Giới thiệu WebElements ............................................................................................ 24
3.3 Xác định các phần tử của trang web (Elements)..................................................... 26
3.4 Các WedDriver hiện hành ......................................................................................... 28
Bài 4: Làm việc với WebDriver ....................................................................................... 29
4.1 Khám phá các đặc tính của WebDriver ................................................................... 29
4.2 Các tương tác năng cao của Webdriver ................................................................... 31
4.3 Hiểu các sự kiện của WebDriver .............................................................................. 31
4.4 Vào ra dữ liệu với WebDriver ................................................................................... 31
4.5 Mô hình đối tượng trang (Page Object Model) ....................................................... 31
Bài 5: Thảo luận 1 – Lựa chọn công cụ kiểm thử tự động ......................................... 37
Bài 6: Thực hành 1 – Làm việc với Selenium WebDriver ......................................... 37
Bài 7: Xây dựng công cụ kiểm thử hướng dữ liệu (Data Driven Test Framework
with Selenium Webdriver) ................................................................................................ 37
7.1 Yêu cầu của một Framework kiểm thử tự động...................................................... 37
7.2 Các đặc tính của một Framework ............................................................................. 37

Bộ môn CNPM – Khoa CNTT

1


7.3 Framework kiểm thử mức thành phần ..................................................................... 38
7.4 Giới thiệu về kiểm thử hướng dữ liệu ...................................................................... 40
7.5 Kiến trúc của Framework kiểm thử hướng dữ liệu ................................................ 40
7.6 Chuẩn bị và lưu trữ dữ liệu kiểm thử ....................................................................... 41
Bài 8: Thực hành 2 – Viết kịch bản kiểm thử tự động với Selenium WebDriver 42
Bài 9: Xây dựng công cụ kiểm thử hướng dữ liệu (Data Driven Test Framework
with Selenium Webdriver) (tiếp) ..................................................................................... 42
9.1 Xử lý dữ liệu kiểm thử ............................................................................................... 42
9.2 Sử dụng dữ liệu kiểm thử........................................................................................... 44
9.3 Thao tác với các ca kiểm thử, kịch bản kiểm thử ................................................... 45
9.4 Trình điều khiển kịch bản .......................................................................................... 46
9.5 Xây dựng thư viện kiểm thử ...................................................................................... 47
9.6 Nhật ký kiểm thử (Test Log) ..................................................................................... 48
Bài 10: Thảo luận 2 – Công cụ kiểm thử hướng dữ liệu............................................. 49
Bài 11: Thực hành 3 - Xây dựng công cụ kiểm thử hướng dữ liệu .......................... 51
Bài 12: Xây dựng công cụ kiểm thử hướng từ khoá (Keyword Driven Test
Framework with Selenium Webdriver) ......................................................................... 51
12.1 Giới thiệu về kiểm thử hướng từ khoá ................................................................... 51
12.2 Chuẩn bị và lưu trữ dữ liệu kiểm thử ..................................................................... 52
12.3 Xử lý dữ liệu kiểm thử ............................................................................................. 52
12.4 Từ khoá ở các mức độ khác nhau ........................................................................... 53
12.5 Thể hiện và xử lý dữ liệu kiểm thử dựa trên từ khoá ........................................... 53
Bài 13: Thực hành 4 – Xây dựng công cụ kiểm thử hướng dữ liệu (tiếp) .............. 54
Bài 14: Xây dựng công cụ kiểm thử hướng từ khoá (Keyword Driven Test
Framework with Selenium Webdriver) (tiếp) .............................................................. 54
14.1 Thao tác với các ca kiểm thử................................................................................... 54
14.2 Thao tác với từ khoá ................................................................................................. 55

14.3 Sử dụng dữ liệu kiểm thử ........................................................................................ 56

Bộ môn CNPM – Khoa CNTT

2


14.4 Trình điểu khiển kịch bản ........................................................................................ 56
14.5 Thư viện kiểm thử .................................................................................................... 58
14.6 Nhật ký kiểm thử ...................................................................................................... 59
Bài 15: Thực hành 5 – Xây dựng công cụ kiểm thử hướng từ khoá........................ 63
Bài 16: Xây dựng công cụ kiểm thử lai cho ứng dụng web (Hybrid Test
Framework with Selenium Webdriver) ......................................................................... 63
16.1 Giới thiệu về Hybrid Framework............................................................................ 63
16.2 Tích hợp kiểm thử hướng dữ liệu và kiểm thử hướng từ khoá ........................... 64
16.3 Dữ liệu kiểm thử ....................................................................................................... 69
16.4 Trình điều khiển ca kiểm thử .................................................................................. 69
16.5 Báo cáo kiểm thử ...................................................................................................... 73
Bài 17: Thảo luận 3 – Công cụ kiểm thử hướng từ khoá và lai ................................ 74
Bài 18: Thực hành 6 - Xây dựng công cụ kiểm thử hướng từ khoá và lai ............. 74
Bài 19: Xây dựng công cụ kiểm thử ứng dụng Mobile với Appium ........................ 74
19.1 Giới thiệu công cụ kiểm thử ứng dụng Mobile – Appium .................................. 74
19.2 Cài đặt và cấu hình Appium .................................................................................... 75
19.3 Viết kịch bản đơn giản với Appium ....................................................................... 78
19.4 Thực thi kịch bản với Appium ................................................................................ 79
19.5 Báo cáo kết quả kiểm thử ........................................................................................ 80
Bài 20: Xây dựng công cụ kiểm thử ứng dụng Mobile với Appium (tiếp) ............. 82
20.1 Chuẩn bị dữ liệu kiểm thử ....................................................................................... 82
20.2 Trình điều khiển các ca kiểm thử ........................................................................... 83
20.3 Xử lý lỗi ..................................................................................................................... 83

20.4 Thực thi các ca kiểm thử.......................................................................................... 84
20.5 Báo cáo kết quả kiểm thử ........................................................................................ 85
Bài 21: Thảo luận 4 – Kiểm thử tự động ứng dụng di động ...................................... 86
Bài 22: Thực hành 7 – Viết kịch bản kiểm thử tự động cho ứng dụng di động .... 86
Bài 23: Phát triển hướng hành vi và tự động kiểm thử chấp nhận ......................... 87

Bộ môn CNPM – Khoa CNTT

3


23.1 Phát triển hướng hành vi .......................................................................................... 87
23.2 Kiểm thử chấp nhận ................................................................................................. 87
23.3 Các công cụ kiểm thử chấp nhận ............................................................................ 90
23.4 Công cụ SpecFlow.................................................................................................... 90
23.5 Ngôn ngữ Gherkin .................................................................................................... 91
23.6 Tự động hoá kiểm thử chấp nhận với Specflow và Selenium ............................ 97
Bài 24: Thực hành 8 – Kiểm thử chấp nhận tự động với Specflow và Selenium 106
Bài 25: Thảo luận 5 – Phát triển hướng hành vi và kiểm thử chấp nhận ............ 106

Bộ môn CNPM – Khoa CNTT

4


Bài 1: Tổng quan về kiểm thử tự động
1.1Khá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 một TC.
Nó sử dụng một công cụ kiểm thử tự động nào đó để rút ngắn thời gian kiểm thử.
Kiểm thử tự động hỗ trợ các kiểm thử viên rất nhiều tùy vào công cụ và các nội dung

kiểm thử có thể thực hiện bằng tay hay không. Đối với những nhiệm vụ kiểm tra khó
mà thực hiện bằng tay hoặc yêu cầu chi phí về nhân công là quá lớn thì sử dụng tool
hỗ trợ là điều hết sức cần thiết.
1.2 Mục tiêu của kiểm thử tự động
Phần mềm có khiếm khuyết là thông thường và gây ra thiệt hại về kinh tế theo
thời gian. Chính vì vậy các tổ chức về phần mềm dành nhiều thời gian và nguồn lực để
phân tích và kiểm thử phần mềm.
Ngày nay ứng dụng tự động hóa vào các ngành đa dạng, trong đó có ngành
kiểm thử. Trước đây kiểm thử viên kiểm thử bằng tay thực hiện và ghi lại kết quả trên
giấy, nhưng với ứng dụng công nghệ thông tin thì các công cụ kiểm thử cũng phát
triển từ rất sớm hỗ trợ kiểm thử viên rất nhiều và đặc biệt là các trường hợp kiểm thử
đặc biệt mà kiểm thử bằng tay không thể thực hiện được hoặc rất khó khăn để thực
hiện. Các tổ chức càng quan tâm đến chất lượng phần mềm thì càng có nhiều chức
năng và nội dung được kiểm tra đòi hỏi kiểm thử viên phải thực hiện nhiều công việc
hơn vì vậy kiểm thử với sự hỗ trợ của công cụ là rất cần thiết.
Để giúp các kiểm thử viên có thể kiểm thử tự động đó là các Test Tool, tuy
nhiên không phải trong bất cứ trường hợp nào cũng có thể kiểm thử tự động. Vậy kiểm
thử thử tự động khi nào?
 Kiểm thử tự động trong các tình huống sau:
 Không đủ tài nguyên:
 Khi số lượng tình huống kiểm tra (TC) quá nhiều mà các kiểm thử 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 tra chức năng của một website.
Website này sẽ được kiểm tra với 6 môi trường gồm 4 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 tra tăng lên và lặp lại 6 lần so với việc kiểm tra
cho một môi trường cụ thể.
 Kiểm tra hồi quy:
Trong quá trình phát triển phần mềm (PTPM), 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 tra. 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

Bộ môn CNPM – Khoa CNTT

5


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 tra 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, kiểm thử viên không chỉ kiểm tra chức năng mới hoặc được sửa, mà
phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước đó. Điều này khó khả thi
về mặt thời gian nếu kiểm tra thủ công.
 Kiểm tra vận hành phần mềm trong môi trường đặc biệt:
Đây là kiểm tra 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 đó kiểm thử 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 tra 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 tra 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.

Việc kiểm tra thủ công cho những tình huống trên là cực khó, thậm chí "vô

phương". Vì vậy kiểm thử tự động tăng độ tin cậy, chính xác, giảm bớt chi phí thực
hiện kiểm thử cho các kiểm thử viên về thời gian, công sức; bên cạnh đó việc thiết kế
test case cho mỗi lần kiểm thử giúp kiểm thử viên rèn luyện kỹ năng lập trình (viết test
script), giảm sự nhàm chán khi cứ mãi thực hiện các kiểm thử thủ công. Hoạt động
kiểm thử tự động nhằm mục đích kiểm tra, 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. Nghĩa là nó thường được thực hiện sau khi đã thiết kế
xong các tình huống (TC). Tuy nhiên, như đã nói, không phải mọi trường hợp kiểm tra
đều có thể hoặc cần thiết phải tự động hóa, trong tất cả test case thì kiểm thử viên phải
đánh giá và chọn ra những TC 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.
 Mục tiêu của kiểm thử tự động :
 Giảm bớt công sức và thời gian thực hiện
 Tăng độ tin cậy
 Giảm sự nhàm chán
 Giảm chi phí cho tổng quá trình kiểm thử
 Ưu điểm của kiểm thử tự động:
 KTPM không cần can thiệp của kiểm thử viên.
 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
Bộ môn CNPM – Khoa CNTT

6


lần.
 Giả lập tình huống khó có thể thực hiện bằng tay
1.3 Quy trình kiểm thử tự động phần mềm
Quy trình kiểm thử tự động phần mềm cũng giống như quy trình thực hiện kiểm
thử thủ công chỉ khác ở chỗ kiểm thử tự động có hỗ trợ của công cụ ít hoặc nhiều như

tạo test script (có thể bằng tay hoặc công cụ), công cụ hỗ trợ về ghi lại kết quả và lưu
trữ kết quả trong máy tính. Quy trình này cũng gần tương tự với quy trình phát triển
phần mềm, được thực hiện qua nhiều bước, được tiến hành rất sớm trong quy trình
phát triển phần mềm và đội kiểm thử tiến hành gần như song song cùng đội phát triển
phần mềm.

Hình 1.1: Quy trình KTTĐ trong mối quan hệ với KTPM.
Để kiểm thử tự động thì công cụ là thành phần không thể thiếu trong tiến trình
này, việc kiểm thử viên thành thạo các công cụ kiểm thử đảm bảo cho quy trình kiểm
thử tự động được hiệu quả.
Một công cụ kiểm thử phần mềm tự động yêu cầu phải làm được những công
việc sau:
 Hiểu các mã assembly được kiểm tra một cách tự động.
 Tiến hành các nhiệm vụ đơn giản và lặp đi lặp lại một cách tự động.
 Tạo ra các kịch bản và chạy các kịch bản trong những lô lệnh theo một lịch
trình đã vạch ra.
 Kiểm tra giao diện của các đối tượng COM và các thành phần phần mềm
khác với tập dữ liệu được thiết lập sẵn.
 Truy cập vào dữ liệu để xác minh lại các kết quả.
 Truy cập vào Regestry để xác minh lại các kết quả.
1.4 Kiến trúc của một khung làm việc trong kiểm thử tự động
Bộ môn CNPM – Khoa CNTT

7


Kiến trúc của một khung kiểm thử tự động giống như một kiến trúc ứng dụng: nó
vạch ra cấu trúc tổng thể cho môi trường thử nghiệm tự động, xác định các chức năng
chung, các bài kiểm tra tiêu chuẩn, cung cấp các khuôn mẫu cho cấu trúc kiểm tra và
chỉ ra các quy tắc cơ bản về cách các bài kiểm tra được đặt tên, tài liệu và quản lý, để

một thư viện thử nghiệm duy trì và chuyển nhượng được.
Sự cần thiết cho một khuôn khổ thử nghiệm được xác định rõ ràng và thiết kế đặc
biệt tốt trong thử nghiệm. Đối với một ứng dụng, bạn có thể ít nhất cho rằng nhà phát
triển có một cơ bản sự hiểu biết về thiết kế phần mềm và các nguyên tắc phát triển,
nhưng đối với các bài kiểm tra tự động, tỷ lệ chênh lệch cao so với người kiểm tra
không có nền tảng kỹ thuật và không nhận thức được kỹ thuật phát triển có cấu trúc.
Khung kiểm tra được trình bày trong chương này có thể được áp dụng cho bất kỳ
hệ thống tự động hóa nào. Cách tiếp cận được miêu tả trong Cẩm nang này. Sự khác
biệt duy nhất giữa một phương pháp tiếp cận và một là trong cách các trường hợp thử
nghiệm cá nhân và kịch bản được cấu trúc. Bằng cách áp dụng một khuôn khổ, bạn có
thể tận hưởng hiệu quả đến từ việc chia sẻ các chức năng chung và hiệu quả mà các bài
kiểm tra tiêu chuẩn và các mẫu cung cấp.
Kiến trúc chung của một khung làm việc trong kiểm thử tự động được thể hiện
như hình dưới:
Các chắc năng chung:
Các chức năng phổ biến là các thủ tục tự động hoá các tác vụ được chia sẻ trong
toàn bộ thư viện thử nghiệm. Một số chức năng có thể được chia sẻ bởi tất cả các kiểm
tra, chẳng hạn như các thủ tục phục hồi từ các lỗi không mong muốn, kết quả nhật ký
và các tác vụ tương tự khác. Các chức năng này thường được cấu trúc như các thủ tục
con, có nghĩa là chúng có thể được gọi từ bất kỳ điểm nào và trở lại bước tiếp theo sau
khi gọi nó.
Các loại chức năng phổ biến khác là các tập lệnh hữu ích: ví dụ như làm mới cơ
sở dữ liệu hoặc nạp nó bằng một tập các bản ghi đã biết, xóa các tệp công việc tạm
thời hoặc quản lý môi trường thử nghiệm. Rõ ràng xác định và chia sẻ những thói quen
này sẽ làm giảm và đơn giản hóa sự phát triển và bảo trì testware. Các kịch bản này
nên được cấu trúc sao cho chúng có thể được thực hiện độc lập hoặc được liên kết với
Bộ môn CNPM – Khoa CNTT

8

nhau tuần tự như một phần của chu kỳ kiểm tra được tích hợp.

Các tiêu chuẩn kiểm thử:

Bộ môn CNPM – Khoa CNTT

9


Test templates
Mẫu kiểm tra cung cấp cấu trúc để phát triển các bài kiểm tra cá nhân. Nó có thể
được sử dụng để tăng tốc độ phát triển bằng cách cho phép một định dạng đơn được
nhanh chóng sao chép và điền vào, tiết kiệm thời gian cho các bài kiểm tra mới và thúc
đẩy sự nhất quán. Mặc dù các quy ước đặt tên cho các bài kiểm tra và các nội dung của
chúng rất quan trọng, và được mô tả đầy đủ hơn trong phần tiếp theo của Bản đồ ứng
dụng, điều quan trọng là mỗi bài kiểm tra riêng lẻ phải tuân theo một cấu trúc chung
để nó có thể dễ dàng liên kết với khung kiểm tra.
Ví dụ, các bài kiểm tra được dự kiến sẽ được gọi là chương trình con và chia sẻ
với các bài kiểm tra khác phải được phát triển để cho phép quay lại kiểm tra gọi;
Tương tự như vậy, các bài kiểm tra sẽ được thực hiện từ trình điều khiển hoặc cơ chế
kiểm soát khác phải có khả năng hoàn trả kiểm soát khi chúng được hoàn tất. Các
phương tiện chính xác để hoàn thành việc này sẽ thay đổi theo từng cách tiếp cận tự
động hóa và được thảo luận trong phần liên quan cho từng cách tiếp cận.

Bộ môn CNPM – Khoa CNTT

10

Application Map
Tương tự như từ điển dữ liệu cho một ứng dụng, Application Map mô tả và mô
tả các thành phần bao gồm ứng dụng và cung cấp thuật ngữ được sử dụng để kết hợp
các bài kiểm tra với ứng dụng.

Bộ môn CNPM – Khoa CNTT

11


1.5 Lợi ích của kiểm thử tự động
- Tiết kiệm tiền bạc vời thời gian: Nhận định này đặc biệt đúng nếu xét trong giai
đoạn bảo trì của các dự án lớn. Mỗi tuần chúng ta phải thực hiện regression test từ 1
đến 2 lần với số lượng test case rất lớn trong 1 đến 2 ngày. Gần như không thể thực
hiện cách thủ công, trong khi với kiểm thử tự động chúng ta hoàn toàn có thể với
nguồn nhân lực vô cùng khiêm tốn.
- Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các test
case với độ chính xác cao hơn.
- Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử tự động, chúng ta có
thể thực thi số lượng lớn test case trong một thời gian ngắn. Điều này giúp chúng ta
tăng độ bao phủ trong giai đoạn regression test (một ví dụ điển hình).
- Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta
muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất.
Ngoài ra còn một số lợi ích khác như:
+ Giảm bớt công sức và thời gian thực hiện quá trình kiểm thử
+ Tăng độ tin cậy.
+ Giảm sự nhàm chán cho con người
+ Rèn luyện kỹ năng lập trình cho kiểm thử viên
+ Giảm chi phí cho tổng quá trình kiểm thử.
Bộ môn CNPM – Khoa CNTT

12


Bài 2: Tổng quan về kiểm thử tự động (tiếp)
2.1 So sánh kiểm thử tự động và kiểm thử thủ công
2.1.1 Hạn chế của kiểm thử thủ công
Kiểm thử thủ công có một số hạn chế:
+ Không sử dụng lại được trong trường hợp kiểm thử hồi quy
+ Khi phải điền Form có quá nhiều thông tin thì kiểm thử thủ công tiêu tốn thời
gian và nguồn lực
+ Độ tin cây không cao
+ Trong một số trường hợp như kiểm thử hiệu năng, kiểm thử chịu tại thì kiểm
thư thủ công khó thực hiện được.
+ Tốn thời gian đối với mỗi lần release người kiểm thử vẫn phải thực hiện lại
một tâp hợp các test case đã chạy dẫn tới sự mệt mỏi lãng phí công sức.
2.1.2 Ưu điểm của kiểm thử tự động
Độ tin cậy cao(Reliability): Nhờ sự ổn định vượt trội của công cụ kiểm thử tự
động so với con người, đặc biệt trong trường hợp có quá nhiều test cases cần được
thực thi, nên độ tin cậy của kiểm thử tự động thường cao hơn so với kiểm thử thủ
công.
- Khả năng lặp (Repeatability): Hãy cùng xem xet một ví dụ: Trong một ngày
thời tiết xấu chúng ta phải thực thi một test case với 50 bộ dữ liệu đầu vào khác nhau.
Nếu thực thi cách thủ công, ngồi trước màn hình, nhập dữ liệu, click click .., check
check … trong 50 lần có lẽ bạn sẽ gục ngã sớm trên bàn làm việc của mình. NHƯNG,
nếu bạn thực thi bằng kiểm thử tự động, chỉ cần nhập dữ liệu vào file excel ( or csv,
…) cho script chạy và ngồi rung đùi cho tới khi nhận được báo cáo. Với độ ổn định
cao, bạn hoàn toàn có thể tin tưởng vào kết quả thực thi của công cụ kiểm thử tự động.
Quả là một viễn cảnh lý tưởng hơn nhiều.
- Khả năng tái sử dụng (Reusability): Với một bộ kiểm thử tự động, chúng ta có

thể sử dụng cho nhiều phiển bản ứng dụng khác nhau, đây được gọi là tính tái sử dụng.
- Nhanh (Fast): Đây là điều không cần phải bàn cãi, nếu cần 5 phút để thực thi
một test case cách thủ công, có thể bạn cần chưa đầy 30s để thực thi cách tự động.

Bộ môn CNPM – Khoa CNTT

13


- Chi phí thấp (Cost Reduction): Nếu áp dụng kiểm thử tự động đúng cách, chúng
ta có thể tiết kiệm được rất nhiều chi phí, thời gian và nhân lực. (Khi nào nên áp dụng
kiểm thử tự động sẽ được nói ở cuối bài)
2.1.3 Hạn chế của kiểm thử tự động
+ Các công cụ kiểm thử tự động mặc dù rất thuận tiện về nhiều phương diện
nhưng thực tế dù như thế nào đi chăng nữa thì nó cũng không phải là một công cụ có
thể thay thế hoàn toàn quá trình kiểm thử. Để thực hiện các thiếp lập tự động thì vẫn
cần có con người, phải bỏ công sức, tiền bạc và thời gian
- Khó mở rộng, khó bảo trì (Poor scalability and maintainability): Trong cùng
một dự án, để mở rộng phạm vi cho kiểm thử tự động là khó hơn nhiều so với kiểm
thử cách thủ công. Số lượng công việc phải làm để mở rộng phạm vi cho kiểm thử tự
động là nhiều hơn và khó hơn kiểm thử thủ công. Cũng vậy, để cập nhật một test case
thủ công, chúng ta chỉ cần mở ra và gõ, rất đơn giản. Nhưng kiểm thử tự động lại
không đơn giản như vậy, cập nhật hay chỉnh sửa yêu cầu rất nhiều công việc như
debug, thay đổi dữ liệu đầu vào, và cập nhật code mới.
- Khả năng bao phủ thấp(Low coverage): Chính vì việc khó ứng dụng, khó mở
rộng, cũng như đòi hỏi quá nhiều kỷ năng lập trình nên độ bao phủ của kiểm thử tự
động khá thấp (xét trên góc nhìn toàn dự án).
- Vấn đề công cụ và nhân lực (Technology vs. people issues): Cho đến nay công
cụ hỗ trợ kiểm thử tự động đã có những bước phát triển mạnh mẽ, chúng ta có các
công cụ rất tốt như QTP, Selenium, Test Complete, LoadTest, Jmeter, Visual Studio,

… Nhưng nhìn chung vẫn còn rất nhiều mặt hạn chế. Ngoài ra nguồn nhân lực đạt yêu
cầu cũng không nhiều.
+ Mất thời gian và công sức để tạo mới và chỉnh sửa script test
+ Mất chi phí cho các các công cụ tự động hóa như phí bản quyền, bảo trì, tìm
hiểu, giáo dục
+ Không thể thay thế kiểm thử thủ công
+ Kiểm thử thủ công có khả năng phát hiện lỗi tốt hơn kiểm thử tự động
+ Tự động hóa kiểm thử không cải thiện nhiều về tính hiệu quả

Bộ môn CNPM – Khoa CNTT

14


+ Tự động hóa kiểm thử có thể làm hạn chế sự phát triển phần mềm
+ Các công cụ không có trí tưởng tượng
2.2 Phân loại các công cụ kiểm thử tự động
Khi bắt đầu làm việc với kiểm thử tự động, chắc chắn chúng ta phải từng nghe
đến cụm từ Test Automation Framework – Mô hình (nền tảng) kiểm thử tự động. Cụm
từ này có thể gây khó chịu cho vài người, làm cho họ cảm thấy nó là một khái niệm
khó hiểu và khó thực hiện. Bài này được viết ra với mục đích giải thích vấn đề này
một cách đơn giản.
Mô hình kiểm thử tự động – một cách đơn giản – là một tập hợp các quy luật,
nguyên tắc dùng trong quá trình viết mã kiểm thử. Các quy luật giúp chúng ta viết mã
theo một cách mà kết quả cuối cùng là “giảm thiểu việc chỉnh sửa mã kiểm thử khi
ứng dụng thay đổi”.
NHỮNG MÔ HÌNH PHỔ BIẾN HIỆN NAY
• Tuyến tính (Linear)
• Hướng Modular
• Hướng dữ liệu (Data Driven)

• Hướng từ khóa (Keyword Driven)
• Hỗn hợp (Hybrid)
Chúng ta sẽ đi qua từng kiểu mô hình và các đặc điểm của nó
TUYẾN TÍNH – LINEAR FRAMEWORK
Đặc điểm cơ bản
• Mọi thứ liên quan đến mã đều được định nghĩa bên trong phương thức kiểm thử
• Không quan tâm đến việc lãng phí và trùng lặp các câu lệnh
• Việc record/playback thường xuyên sinh ra mã tuyến tính
• Dễ dàng để bắt đầu
• Khó khăn trong việc chỉnh sửa

Bộ môn CNPM – Khoa CNTT

15


Mô hình này có thể được dùng trong dự án nhỏ, nơi mà không có quá nhiều màn
hình giao diện cũng như chức năng. Mặc khác, chúng ta cũng hay dùng Mô hình này
khi sử dụng một công cụ kiểm thử tự động lần đâu tiên. Ngoài hai lý do trên, Mô hình
này không được khuyến khích sử dụng trong kiểm thử tự động.
HƯỚNG MODULE – MODULARITY FRAMEWORK
Đặc điểm cơ bản
• Các đối tượng được định nghĩa một lần và tái sử dụng trong các phương thức
kiểm thử.
• Các phương thức nhỏ và có mục đích được tạo ra cho những chức năng riêng
biệt
• Kịch bản kiểm thử tự động là một tập hợp các phương thức nhỏ và các đối
tượng được định nghĩa từ trước
• Cho phép chúng ta dễ dàng viết các mã dễ dàng được chỉnh sửa
Mục đích chính của mô hình này là việc chỉnh sửa dễ dàng. Nếu có bất kỳ thay

đổi nào trên giao diện, chúng ta chỉ cần chỉnh sửa trong các phương thức và đối tượng.
Mã kiểm thử chính của chúng ta vẫn hoạt động chính xác. Mô hình POM (Page Object

Bộ môn CNPM – Khoa CNTT

16


Model) – thường được dùng với Selenium – là một dạng của mô hình hướng modul.
Toàn bộ trang web sẽ được chia nhỏ thành các trang. Các đối tượng UI của từng trang
được định nghĩa bên trong từng lớp của trang đó. Nếu có bất kỳ thay đổi nào trên ứng
dụng web, chúng ta chỉ cần chỉnh sửa lớp của trang đó, những lớp của trang khác vẫn
giữ nguyên. Kết quả cuối cùng chúng ta sẽ có những đoạn mã được bảo trì tốt hơn và
dễ đọc hơn.
Điểm yếu của mô hình này là nó yêu cầu một mức độ kỹ năng lập trình và hiểu sâu về
hướng đối tượng. Nếu bạn có nó, khuôn mẫu này được khuyến khích sử dụng.

HƯỚNG DỮ LIỆU – DATA DRIVEN FRAMEWORK

Bộ môn CNPM – Khoa CNTT

17


Đặc điểm cơ bản
• Dữ liệu kiểm thử (giá trị đầu vào và đầu ra) được tách khỏi mã nguồn và lưu
trong một tập tin bên ngoài. Nó có thể là một tập tin CSV, một bảng Excel hay một cơ
sở dữ liệu.
• Khi mã kiểm thử thực thi, các giá trị này được lấy ra từ tập tin, chứa vào biến
và thay thế các giá trị cứng (nếu có) trong mã nguồn.

• Thực sự hữu ích khi mà cùng một kịch bản kiểm thử cần thực thi với nhiều dữ
liệu đầu vào khác nhau.
Có vài ưu điểm khi áp dụng mô hình này. Tất cả các giá trị kiểm thử được lưu
bên ngoài mã nguồn, do đó, bất kỳ thay đổi nào xảy ra trong quá trình phát triển ứng
dụng, chúng ta chỉ cần thay đổi dữ liệu trong tập tin bên ngoài, và mã kiểm thử tự
động của chúng ta vẫn được giữ nguyên.
Một ưu điểm khác là, khả năng sử dụng một kịch bản kiểm thử cho nhiều dữ liệu
khác nhau. Ví dụ như, bạn đang làm một kịch bản đăng nhập hệ thống với 100 user.
Bạn có thể viết 1 đoạn mã và một tập tin lưu trữ thông tin của 100 user. Sau đó, bạn
chỉ cần thực thi 1 lần, và đi qua cả 100 bộ dữ liệu. Bạn dễ dàng phát hiện, với kiểu dữ
liệu nào thì đoạn mã Fail. Đây cũng là một thế mạnh khi bạn đang làm kiểm thử phủ
định – Negative Test.
HƯỚNG TỪ KHÓA – KEYWORD FRAMEWORK

Bộ môn CNPM – Khoa CNTT

18


Đặc điểm cơ bản
• Cả dữ liệu và chức năng được định nghĩa bên ngoài mã nguồn
• Cần phát triển các từ khóa cho nhiều chức năng khác nhau
• Mã kiểm thử tự động đôi khi được lưu trữ ở một tập tin bên ngoài mã nguồn
giống như mô hình hướng dữ liệu. Các bước của kịch bản kiểm thử được viết từng
bước với định dạng bảng, nơi mà sử dụng các từ khóa và dữ liệu kiểm thử
• Mã nguồn chính sẽ đọc các bước trong định dạng bảng và thực thi các chức
năng tương ứng
• Cho phép các kỹ sư kiểm thử thủ công, nhưng người không biết về lập trình, có
thể là một phần, ở một mức độ, của nhóm kiểm thử tự động
Ưu điểm của mô hình hướng từ khóa

Mô hình này rất hữu dụng trong những trường hợp mà kịch bản kiểm thử có quá
nhiều thay đổi. Nếu bất kỳ bước nào trong kịch bản kiểm thử bị thay đổi, chúng ta
không cần phải chỉnh sửa mã nguồn. Chúng ta chỉ cần chỉnh sửa tập tin bên ngoài và
như vậy, kịch bản kiểm thử tự động sẽ được chỉnh sửa theo.
Chúng ta định nghĩa toàn bộ kịch bản ở tập tin và đưa cho kỷ sư kiểm thử thủ
công, họ sẽ thêm các đoạn văn bản (text) hoặc chỉnh sửa cái có sẵn. Bằng cách này, kỹ
sư kiểm thử tự động cũng có thể trở thành một phần của nhóm kiểm thử tự động bởi vì
họ không cần phải lập trình gì cả. Họ chỉ cần chỉnh sửa tập tin ở những vị trí cần thiết
và kịch bản kiềm thử tự động sẽ được chỉnh sửa một cách tự động.
Một lợi ích khác của mô hình này là, kịch bản kiểm thử của bạn trở thành một
công cụ độc lập. Bạn chỉ cần bảo trì kịch bản kiểm thử trong một tập tin và nếu bạn
cần thay đổi công cụ kiềm thử tự động ở điểm nào đó, bạn có thể dễ dàng chỉnh sửa
bằng cách viết lại cách đọc và thực thi tập tin với công cụ mới.
Mặc khác, khuyết điểm của mô hình này là, bạn cần phát triển các từ khóa cho
các chức năng khác nhau. Trong một dự án lớn, có thể có rất nhiều từ khóa mà bạn cấn
phải nhớ và tổ chức nó hợp lý. Bản thân việc này có thể sẽ làm một công việc nặng
nhọc cho quá trình phát triển kiềm thử tự động.
Ở vài trường hợp phức tạp, khi mà các đối tượng UI không thể được xác định dễ
Bộ môn CNPM – Khoa CNTT

19


dàng, chúng ta phải sử dụng nhiều kỹ thuật khác nhau để xử lý, mô hình này không
hữu dụng cho lắm.
Mô hình hướng từ khóa là một mô hình ưa thích của nhiều kỹ sư kiểm thử tự
động. Robot Framework – công cụ kiểm thử tự động được phát triển bởi Google – là
một công cụ phổ biến đi theo hướng từ khóa. Những công cụ đi theo hướng từ khóa
này còn có Test Architect hay Katalon Studio
HƯỚNG HỖN HỢP – HYBRID FRAMEWORK

Đặc điểm cơ bản
• Là sự kết hợp của hai hoặc nhiều kỹ thuật ở trên, kế thửa thế mạnh và loại bỏ
những điểm yếu của các mô hình khác.
• Mô hình này sử dụng cách tiếp cận theo hướng modul, kết hợp với hướng dữ
liệu hoặc hướng từ khóa
• Mô hình này có thể dùng mã nguồn để xủ lý những công việc đặc biệt mà quá
khó để tạo ra với cách làm từ khóa
Một cách đơn giản, mô hình này sử dụng kết hợp nhiều kỹ thuật với nhau. Chúng
ta có thể sử dụng hướng dữ liệu đồng thời với hướng modul. Trong vài trường hợp,
chúng ta có thể dùng từ khóa song song với modul. Cơ bản, khi nào chúng ta sử dụng
nhiều hơn một mô hình, đó là lúc chúng ta sử dụng hỗn hợp – Hybrid
Mô hình tồn tại là để cuộc sống của chúng ta dễ dàng hơn. Nó giúp chúng ta viết
ra những kịch bản kiểm thử tự động dễ chỉnh sửa và dễ đọc. Không có mô hình, kiểm
Bộ môn CNPM – Khoa CNTT

20


thử tự động có thể sẽ trở nên cực kỳ khó khăn. Với những thay đổi nhỏ của ứng dụng
mà chúng ta phải chỉnh sửa hàng trăm vị trí trong mã nguồn.
Do đó, hiểu và ứng dụng tốt những mô hình là một yêu cầu cần thiết cho bất kỳ
ai muốn tham gia và lĩnh vực kiểm thử tự động này.
2.3 Lựa chọn công cụ kiểm thử tự động cho bài toán và tổ chức của bạn
2.3.1 Tại sao phải kiểm thử tự động
Nhu cầu về tốc độ là thực tế là thần chú của thời đại thông tin. Bởi vì công nghệ
hiện đang được sử dụng như là một vũ khí cạnh tranh trên các mặt trước của sự tương
tác của khách hàng, lịch trình phân phối phải chịu áp lực thị trường. Các sản phẩm
muộn có thể làm mất doanh thu, khách hàng và thị phần. Tuy nhiên, áp lực kinh tế
cũng đòi hỏi nguồn lực và giảm chi phí, dẫn đến nhiều công ty áp dụng tự động hóa đ ể

giảm thời gian để thị trường cũng như cắt giảm ngân sách kiểm tra.
Mặc dù có thể tốn kém để bị trễ thị trường, nhưng nó có thể là thảm khốc để
cung cấp một sản phẩm bị lỗi. Sự thất bại của phần mềm có thể làm mất hàng triệu
hoặc thậm chí hàng tỉ đô la, và trong một số trường hợp toàn bộ các công ty đã bị mất.
Vì vậy, nếu bạn không có đủ người hoặc thời gian để thực hiện kiểm tra đầy đủ để bắt
đầu, việc thêm tự động hóa sẽ không làm giảm sự mất ổn định phần mềm và lỗi. Vì nó
được cung cấp đầy đủ thông tin rằng lỗi phần mềm - thậm chí chỉ một lỗi - có thể tốn
hơn hàng triệu lần so với ngân sách thử nghiệm của bạn, ưu tiên hàng đầu là phải cung
cấp phần mềm đáng tin cậy. Một khi đã đạt được, sau đó tập trung vào việc tối ưu hóa
thời gian và chi phí. Nói cách khác, nếu phần mềm của bạn không hoạt động, nó
không quan trọng như thế nào nhanh chóng hoặc giá rẻ bạn cung cấp nó.
2.3.2 Tiêu chí lựa chọn công cụ kiểm thử tự động
Sự thành công của kiểm thử tự động một phần lớn phụ thuộc vào việc lựa chọn
công cụ kiểm thử tự động (automation tools), trên thị trường hiện có rất nhiều tools
bao gồm cả tool miễn phí (open source) lẫn tool thương mại (commercial tools) và
việc chọn ra công cụ nào phù hợp nhất cho dự án là một thách thức thật sự.
Bạn cần đưa ra một tiêu chuẩn đúng đắn để chọn ra tool chính xác cho mình, sau
đây là một số tiêu chuẩn phổ biến, việc áp dụng các tiêu chuẩn nào, ưu tiên những tiêu
chuẩn nào là phụ thuộc vào bài toán cụ thể
1) Bạn có đủ nhân lực cần thiết cho dự án automation
2) Ngân sách của bạn cho automation là bao nhiêu?
3) Liệu tool có phù hợp với công nghệ và môi trường mà bạn đang dùng cho
Bộ môn CNPM – Khoa CNTT

21


ứng dụng của bạn?
4) Liệu tool có cung cấp bản dùng thử (trial version) để bạn có thể đánh giá
trước khi quyết định? Bản dùng thử có tất cả các tính năng của tool?

5) Mức độ hỗ trợ của nhà sản xuất, tài liệu hướng dẫn có đủ chỉ tiết, việc hỗ trợ
online có độ phản hồi tốt không?
6) Tool có dễ học không?
7) Bạn dùng tool chỉ cho project của bạn hay cho tất cả các project của công ty?
nếu bạn định dùng cho cả công ty thì cần phải đánh giá thêm các project khác, các tool
hiện dùng của công ty cũng như định hướng lâu dài của công ty.
8 ) Tool có thể hỗ trợ những loại test nào? trên những nền tảng nào?.
9) Tool có giao diện dễ dùng và tạo test script không? script có dễ bảo trì
không?
10) Tool có hỗ trợ xử lý gì trong những trường hợp phức tạp?
11) tool có hỗ trợ việc xử lý dữ liệu đầu vào không? chẳng hạn dữ liệu test từ
exel, xml, ...
12) Tool có cung cấp một report tốt, thông tin chi tiết và rõ rang không
13) Nó có thể tích hợp với các tool bạn đang dùng không?
14) Chính sách giá của nhà sản xuất.
Ngoài ra còn có thêm một số tiêu chuẩn (criteria) khác mà tùy bài toán, chúng
ta cần thêm vào trong danh sách.
Bài 3: Selenium WebDriver cơ bản
3.1 Giới thiệu Selenium WebDriver
a. Lịch sử của Selenium
Với các ứng dụng web trở thành phương pháp defacto để phát triển các ứng
dụng người dùng cuối, cần 1 giải pháp cho việc test. Điều này có nghĩa nhiều hơn và
chú trọng hơn vào framework tự động hóa trình duyệt để giúp kiểm tra trang web.
Nhiều năm qua, con người sử dụng Selenium IDE và Selenium RC để dẫn dắt nhiều
loại trình duyệt khác nhau. Selenium được tạo ra ban đầu bởi Jason Huggins, đã giải
quyết được vấn về của việc trình duyệt tương tác với người dùng.
Đây là 1 framework tự động hóa tốt, tuy nhiên nó bị giới hạn bởi JavaScript
sandbox trong các trình duyệt. JavaScript sandbox thực thi chính sách bảo mật khi
JavaScript được thực hiện để ngăn chặn mã độc trên máy khách hàng. Chính sách bảo
mật chính mà con người thông qua là Same Origin Policy. Nếu bạn cần chuyển từ

HTTP sang HTTPS, trình duyệt sẽ ngăn chặn hành động do lúc đó chúng ta không còn
ở cùng một gốc. Điều này khiến người phát triển trung bình như bạn khá phẫn nộ!
Bộ môn CNPM – Khoa CNTT

22


Selenium API cơ bản được thiết kế để làm việc từ bên trong máy chủ. Người phát triển
hay tester viết test đều phải làm như vậy trong HTML bằng cách sử dụng thiết kế 3 cột
dựa trên FIT.
Bạn có thể thấy điều này nếu mở Selenium IDE có 3 input box cần được hoàn
thành cho mỗi dòng thực thi tuy nhiên nó có khá nhiều vấn đề.
Patrick Lightbody và Paul Hammant đã nghĩ ra cách tốt hơn để điều khiển test của họ
và với cách này họ có thể sử dụng ngôn ngữ phát triển mà họ thích. Họ đã tạo ra
Selenium Remote Contral sử dụng Java như 1 máy chủ web.
Phần tiếp theo ta sẽ tìm hiểu về kĩ thuật cơ bản của WebDriver.
b. Kỹ thuật
Cấu trúc WebDriver không theo phương pháp như Selenium RC được viết hoàn
toàn trong JavaScript cho tất cả tự động hóa trình duyệt. JavaScript trong Selenium RC
sẽ mô phỏng hành dộng của người dùng. JavaScript này sẽ tự động hóa trình duyệt từ
trong trình duyệt đó.
WebDriver mặt khác cũng cố gắng để kiểm soát trình duyệt từ bên ngoài. Nó sử
dụng khả năng tiếp cận API để điều khiển trình duyệt. Khả năng tiếp cận của API
được sử dụng bởi số lượng lớn các ứng dụng truy cập và kiểm soát các ứng dụng khi
chúng được sử dụng bởi người dùng bị chặn.
WebDriver sử dụng phương pháp thích hợp nhất để truy cập khả năng tiếp cận
của API. Nếu bạn nhìn vào Firefox, nó sử dụng JavaScript để truy cập API. Nếu bạn
nhìn vào Internet Explorer, nó sử dụng C++. Phương pháp này có nghĩa là ta có thể
điều khiển trình duyệt bằng cách tốt nhất có thể nhưng có một nhược điểm là với các
trình duyệt mới ra trên thị trường sẽ không hỗ trợ phương pháp này như với Selenium

RC.
Những nơi phương pháp đó không làm việc, ta sẽ dùng JavaScript trong trang.
Ví dụ có thể tìm thấy ở HTML5 mới.

Hệ thống được tạo thành từ 4 phần khác nhau
Bộ môn CNPM – Khoa CNTT

23


WebDriver API
WebDriver API là một phần của hệ thống mà bạn tương tác trong suốt quá trình.
Nhiều thứ đã thay đổi từ API có độ dài 140 dòng mà Selenium RC API có. Cái này
hiện tại đã dễ quản lý và có thể thực sự phù hợp trên một màn hình thông thường. Bạn
có thể thấy điều này khi bạn bắt đầu sử dụng WebDriver ở chương tiếp theo. Điều này
được tạo thành từ WebDriver và các đối tượng WebElement.
driver.findElement(By.name("q")) và element.sendKeys("I love cheese");
Những lệnh này sau đó được dịch sang SPI. Điều này có thể thấy ở phần tiếp theo.
WebDriver SPI
Khi mã code đi vào Stateless Programming Interface hay SPI, sau đó được gọi
đến 1 cơ chế phá vỡ các nhân tố sử dụng ID duy nhất và sau đó gọi lệnh có liên quan.
Tất cả API gọi trên sau đó gọi dưới. Sử dụng ví dụ ở phần trước sẽ có code như sau:
findElement(using="name", value="q")
sendKeys(element="webdriverID", value="I love cheese")

Từ đó sẽ gọi đến giao thức JSON Wire. Ta vẫn sử dụng HTTP như một cơ chế vận
chuyển chính. Ta liên lạc tới các trình duyệt và 1 kĩ thuật vận chuyển client server đơn
giản mà người phát triển đã tạo là JSON Wire Protocol.
JSON Wire protocol
Những người phát triển WebDriver đã tạo ra 1 cơ chế vận chuyển gọi là JSON

Wire Protocol. Giao thức này có thể vận chuyển tất cả các yếu tố cần thiết tới code
điều khiển nó. Nó sử dụng REST giống như API như một cách để giao tiếp
Sát nhập 2 dự án
Cả Simon Stewart và Jason Huggins đều nghĩ rằng việc sát nhập 2 dự án với
nhau thực sự là 1 ý kiến tốt. Sau này nó gọi là Selenium 2.
Các nhà phát triển cứng về Selenium đang làm việc để đơn giản hóa cơ sở mã
code và xóa bỏ càng nhiều trùng lặp càng tốt. Ta đã tạo được Selenium Atoms mà sau
này được chia sẻ giữa 2 dự án.
3.2 Giới thiệu WebElements
Trang Web là thành phần cơ bản cấu tạo nên Website, do đó việc đặc tả một
trang Web là bước căn bản để có thể đặc tả chính xác một Website. Thông thường,
mỗi trang Web sẽ thực hiện các chức năng, nhiệm vụ khác nhau. Các trang Web có thể
được liên kết với nhau bằng việc chuyển trang với thao tác nhấp chuột vào đường dẫn
(link) hoặc các nút (button). Trong phần này, báo cáo trình bày một số khái niệm căn
bản giúp trang Web hoạt động.
Bộ môn CNPM – Khoa CNTT

24


Phần tử Web (Web Element). Phần tử Web là các thành phần cơ bản cấu tạo nên
một trang Web, mỗi phần tử Web có nhiều thành phần nhưng có 4 thành phần cơ bản,
bao gồm:
Thẻ mở (Opening Tag): Là phần mở đầu của một phần tử Web để thông báo việc
phần tử Web nào đó được sử dụng. Ví dụ: Để khai báo việc sử dụng một đoạn văn bản,
ta sử dụng thẻ mở

.
Các thuộc tính (Attributes): Mô tả thêm thông tin về phần tử Web, mỗi phần tử
Web có số lượng thuộc tính khác nhau, nhưng tất cả các phần tử Web đều có 4 thuộc
tính cơ bản sau:
– id: Đặc tả định danh duy nhất của phần tử Web.

– class: Đặc tả một hay nhiều lớp của phần tử Web.
– style: Đặc tả CSS style cho phần tử Web.
– title: Đặc tả thông tin mở rộng về phần tử Web
Nội dung (Element Content): Nằm giữa thẻ mở và thẻ đóng, được dùng để hiển
thị nội dung của phần tử Web.
Thẻ đóng (Closing Tag): Nằm ở vị trí cuối cùng trong cấu trúc một phần tử Web
dùng để thông báo việc kết thúc nội dung của một phần tử Web. Ví dụ: Để thông báo
kết thúc một đoạn văn bản, ta sử dụng thẻ đóng

.
Để thao tác với các phần tử trong C# ta sử dụng giao diện IWebElement
Các thuộc tính của IwebElement

Bộ môn CNPM – Khoa CNTT

25