Mỗi trình duyệt có những web sriver riêng

tìm control, xài hàm find element=> trả về element id

note: tìm hiểu cơ chế web socket?

locator: khi một tool work với element, đầu tiên phải chỉ tool biết nó work với cái
nào, locator same as địa chỉ của element
=> chỉ cho tool biết nên interact lên thẻ/element nào

require:
locator must be unique, reliable, good performance
short, descriptive
tránh sdung absolute path
tránh dynamic attribute
tránh dùng white card (eg: thay vì dùng * thì vdu nếu chỉ muốn lấy input thì nên
chỉ nhập input)

Headless browser

các loại application

web application: chrome, safari
native appication:
hybrid application

appium: work same as selenium

các loại locator:
ì, ui automator, classchain,...

Waiting
Interact với element, cần chờ load các element
2 loại wait in selenium
implicit way: gọi hàm để interact, sẽ wait tối đa 1 tgian nhất định để chờ element
load lên
-> thread sleep: tránh và ko xài vì ko tối ưu, tốn tgian...
explicit wait: chờ điều kiện khác hơn vd element có clickable ko, visible hay ko =>
đặt tgian chờ bao nhiêu, chỉ dùng cho đúng cái element muốn đặt thôi
=> nên tối ưu dùng implicit và explicit wait

chạy parallel:

selenium grid:

cloud service:

visual validation:
có thể kiểm tra bằng pixel - pixel comparision: issue: nhìn mắt thg giống nhau
nhưng khác 1 điểm ảnh cũng bị đánh là fail
DOM domparision
Visual AI

AI-powered ReportPortal:

Automation Framework:
Linear

driven framework:

UI Testing challenges:
high intial investment
finding right automation tool
high maintenance
suitable test case
sability: lúc nào pass lúc kia fail
...

UI best practive
do not rely on UI test automation
always use test design pettern and priciples
never use thread.sleep
khi fail should take screenshot for evidence
run test in parallel