CHIA SẺ NHỮNG MẸO VÀ THỦ THUẬT TRONG QUÁ TRÌNH LÀM VIỆC VỚI KIỂM THỬ TỰ ĐỘNG HÓA PHẦN MỀM


Question 01:
Cho mình hỏi một đối tượng mà không thể lấy được location hoặc selenium ko support thì mình làm cách nào để tương tác với nó vd: lấy text của nó, click vào một button…?

Answer:
Khi làm việc với Selenium thì mình thường phân cấp ưu tiên tương tác với 1 đối tượng như thế này:

1. Capture = xpath rồi tương tác = selenium
2. Capture bình thường không được thì chú ý kiểm tra xem nó có thuộc 1 frame nào đó ko. nếu thuộc frame switch vào frame đó rồi làm tiếp như bình thường
3. Sử dụng javascript để tương tác với element (ex: executeJavaScript(driver, “document.getElementById(‘docRename’).click()”);)
4. Dùng robot của java hoặc sikuli


Question 02:
Check file exist on Saucelabs VM – Team mình sáng nay có gặp trường hợp như sau:

Dùng selenium test web, khách hàng yêu cầu chạy test case trên saucelabs. Mọi thứ vẫn ổn cho đến khi gặp một cái check point “download 1 doc file and check it is downloaded”
Sau khi download xuống thì mình thông qua video của saucelab có thể thấy cái file nằm trong thư mục download, nhưng không có cách nào check được nó tồn tại bằng selenium cả. (máy saucelabs ko cùng mạng với mình, nên ko ping, ko telnet dc)

Answer:
Sau một hồi mày mò thì team mình tìm ra solution như sau:

Dùng chính browser mà mình đang run test case, open thư mục download lên bằng lệnh: driver.get(“file:///C:/Users/vien.do/Downloads/”);
Sau đó, tất cả các item trong thư mục đó sẽ hiện ra trên web, mình dùng xpath capture interface và check như ý muốn. Hi vọng tất cả anh chị và các bạn có được một ý niệm gì đó về check file exist trên những máy tính mà chúng ta hiện không nằm chung mạng và nó không cho mình connect tới. Liên quan đến các popup upload và download, team mình đang hướng đến cách dùng thuần selenium, ko phụ thuộc các tools thứ 3 nữa.


Question 03:
Mình đang tìm cách tắt popup download của Firefox khi download một file trong quá trình chạy bằng selenium (click download là nó tự down xuống như Chrome luôn). Có anh chị hay bạn nào đã làm được cái này rồi, có thể cho mình lời khuyên được không. Mình đã thử tìm kiếm, trên mạng cũng đã bày một số cách, nhưng mình mình làm theo thì nó vẫn không được?

Answer:
FirefoxProfile profile = new FirefoxProfile();
profile.setAcceptUntrustedCertificates(true);
profile.setPreference(“browser.download.folderList”, 2);
profile.setPreference(“browser.download.manager.showWhenStarting”, false);
profile.setPreference(“browser.helperApps.neverAsk.saveToDisk”, “application/msword, application/pdf”);
profile.setPreference(“pdfjs.disabled”, true);
profile.setPreference(“plugin.scan.Acrobat”, “99.0”);
profile.setPreference(“plugin.scan.plid.all”, false);
WebDriver driver = new FirefoxDriver(profile);


Question 04:
Về cơ bản thì record & play bằng sele IDE khá ok với các chức năng như login/ register/ forgot/ detail,.. nhưng liên quan đến popup, js hay css thì nó ko play được.
Anh có thể giải thích giúp em chút về các vấn đề như tại sao dùng webdriver mà ko là remote control hoặc JUnit vs TestNG (khả năng ứng dụng của từng loại đến đâu), có dùng được automation cho toàn bộ các trường hợp của website, việc tái sử dụng test sript có tốn time ko?

Answer:

Rất vui khi có người cùng đam mê với mình. Sau đây tôi sẽ giải thích những câu hỏi của bạn :

1. IDE (Selenium Ide) là một product nên bạn có thể yên tâm nó có thể handle được hết tất cả các trường hợp mà bạn nhắc tới như popup,css,…! IDE thực sự phù hợp với những dự án yêu cầu automate basic và ngắn ngọn và nó cũng rất hữu ích cho việc làm quen dần với Selenium dành cho các tester mới. Việc maintain script của IDE sẽ rất mất công và gây buồn chán cho các tester, vì sao lại vậy tôi sẽ giải thích rõ hơn ở ví dụ ở mục 4.

2. Selenium webdriver là 1 feature mới của version 2.0 trở lên, nó thừa hưởng đầy đủ các function để xử lý sự kiện như Selenium RC. Ngoài ra Selenium webdriver còn hỗ trợ bạn class action để handle những sự kiện phức tạp như mouse over, multi select, drag and drop một cách dễ dàn và hiệu quả.Nó tuỳ thuộc vào sự lựa chọn của bạn thôi nhé.

3. Tôi dùng testNG vì nó dễ dàng hơn trong việc truyền parameter cũng như config chạy test trên multi browser.Ngoài ra điều quan trọng nữa là testNG dễ dàng integrate với CI (Continuos Intergration) và nó hỗ trợ report test dưới dạng html nên sẽ giúp khách hàng có cái nhìn tổng quát và đơn giản hơn.

4. Tôi đưa ra trường hợp đơn giản như sau đê bạn thấy đc lợi ích của xây dựng framework với IDE nhé : trong 1 testcase đòi hỏi chúng ta phải login với 3 user có 3 quyền khác nhau , mặc định nếu bạn xử ly testcase bằng IDE, bạn sẽ phải viết lặp lại 3 script login nhưng nếu như bạn sử dụng framework với user define action thì bạn sẽ chỉ phải viết 1 hàm login và có thể dùng đi dùng lại nhiều lần. Trường hợp 2 khi bạn đã viết xong script login bằng ide và chạy trong 1 time nhưng developer thay đổi location của textbox username chẳng hạn thì bạn phai vào trong script login thay đổi location 3 lần cho phù hợp , nhưng nếu làm với framework với Page Object Model bạn chỉ việc vào sửa 1 lần duy nhất trong class LoginPage.


Question 05:
Cho mình hỏi các bạn một chút về kinh nghiệm chạy các dự án có sử dụng automation nhé.
Hiện tại, mình mới xây dựng xong automation script cho bộ TC gồm 70 testcases (main flows) và demo xong vs quản lý. Sau khi demo xong, anh ấy rất băn khăn về việc dùng lại được của script vì: sắp tới hệ thống có một đợt thay đổi khá rộng. Anh ấy sợ rằng sau khi thay đổi xong thì script không chạy được. Và nếu chỉ bắt đầu sửa sau khi bên dev build lên cho test thì đã muộn. Script sẽ không thể sử dụng được trong round test đầu tiên sau khi dev build cho test.
Anh ấy có suggest một số giải pháp để có thể sửa script ngay trong thời gian dev đang develop thay vì đợi dev develop xong. Ví dụ như:
– Yêu cầu dev cung cấp id của element mới nếu có
– Request dev cung cấp những bản daily build của họ để mình có thể sửa script cùng lúc với dev
Mình cũng đã cố gắng giải thích vs anh ấy một số khó khăn về việc sửa script mà không được nhìn thấy giao diện thực (chỉ cung cấp cấp id của element), hay rủi ro khi phải sửa đi sửa lại nếu dựa vào các bản daily build của dev. Mình cũng nói anh ấy rằng: nếu hệ thống thay đổi trên diện rộng thì khả năng sử dụng đc script trong round test đầu tiên là không thể được, script sẽ có ý nghĩa trong những lần sửa nhỏ, không ảnh hưởng đến flow của hệ thống
Tuy nhiên ở bậc quản lý, họ expect rất nhiều (save thật nhiều time, cover càng rộng càng tốt). Đây là dự án đầu tiên mình áp dụng automation nên rất băn khoăn. Dự án của mình chạy ổn định, bình thường chỉ sửa nhỏ hoặc thêm module mới, rất ít khi thay đổi lớn ảnh hưởng diện rộng
Vậy cho mình hỏi: liệu những suggest của anh ấy có hợp lý? Các bạn có lại từng làm như thế chưa. Và xin hãy chia sẻ tình trạng dự án thật của các bạn nhé.

Answer:

Bên bạn có dung Jenkins CI không?
Có được thì tốt. Còn không bạn nên locate các element theo text của nó. Nếu bên bạn dung CI thì ngày nào bạn cũng cho chạy và check sự thay đổi và maintain kịch bản có 70 cases cũng không nhiều.
Nên sử dung mô hình page object để tiết kiệm thời gian maintain. Một phương án nữa là bạn có thể tạo một cái object repository, lưu hết các địa chỉ của element lên file properties. Nếu thay đổi gì thì chỉ vào đấy đổi là được. Việc maintain kịch bản là điều không thể tránh được khi phát triển sản phẩm. họ có nhiều thay đổi. Bởi thế phát hiện sớm sửa sớm thì cần có CI. Nó cũng phụ thuộc rất nhiều vào cách thức tổ chức FW của bạn.
Automation chỉ phù hợp cho các chức năng đã ổn định, ko phải đang develop. Nếu chạy theo những chức năng đang develop thì bạn maintain ko kịp đâu, giả sử trường hợp này bạn có 700 TCs thì sao. Trường hợp có nhiều version của app, sau khi tích hợp các chức năng với nhau, chạy automation để xem những chức năng cũ/ version cũ có work đúng hay ko.
Mình thấy những suggest của ảnh hợp lý đó bạn. Bạn apply nó vào một thời gian đi rồi mới thấy ưu và khuyết điểm của nó. Thực ra nếu có thể send id cho mình sớm thì tốt cho mìn. Chỉ sợ rằng dev không define sớm. Về số lượng testcases của bạn cũng ít nên maintain cũng đâu thay đổi gì nhiều. Hơn nữa thời gian dev product và thời gian dev auto thì dev auto nhanh hơn nhiều.


Question 06:
Firefox version tương thích với Selenium?

Answer:

To use older versions of firefox use the following selenium versions:
Firefox 47: only works with selenium version 2.53.1
Firefox 46: 2.51.0 2.52.0 2.53.0
Firefox 44 – 45: 2.48.2, 2.49.0, 2.51.0, 2.52.0, 2.53.0
Firefox 39 – 43: 2.47.1, 2.48.2, 2.49.0, 2.51.0, 2.52.0, 2.53.0
Firefox 38: 2.46.0
Firefox 32 – 37: 2.45.0


Question 07:
Mình có thể dùng Selenium để test trường hợp đặt hàng có captcha không?

Answer:

Trên thực tế họ dùng captcha để chống việc automation (đăng kí tài khoản, spam mail, đặt hàng,..) nên mình ko nên automation cho chức năng này nhé bạn. Nếu trong trường hợp dự án bắt buộc thì bạn có thể nhờ đội developer bỏ chức năng hoặc hỗ trợ thư viện, bộ dữ liệu để pass qua vụ captcha này.
Nói về captcha thì nó cũng có 1 số loại: cơ bản như text (có giá trị trong attribute của element), hình ảnh (phải dùng thư viện hoặc third party để quét từ ảnh -> text), captcha trừu tượng hơn (tìm ảnh gần nghĩa, đồng nghĩa),..


Question 08:
Các bước làm Automation test với Selenium?

Answer:

Các bước thông thường (Coding/ ko phải record và playback nhé):
– Manual test qua các chức năng cần làm (ít nhất 1 vài lần) để đảm bảo chức năng ổn định
– Viết testcase manual cho các chức năng để ko bị miss các điểm cần verify (Bước này là phần option, tùy dự án gấp hay ko nên có hoặc ko)
– Estimate thời gian cho từng chức năng/ page/ screen (bao nhiêu testcase/ ngày)
– Implement testcase (Code)
– Run/ Debug testcase trên các browser mong muốn (IE/ Firefox/ Chrome/…)
– Lấy report (xml/ html/…)
– Tích hợp các module đã code với nhau và run regression test để tìm bug theo yêu cầu của dự án (theo tuần/ theo sprint/ theo mỗi lần release/ deploy/…)
– Bảo trì testscript khi có sự thay đổi (chức năng và/ hoặc UI)


Vui lòng xem thêm trong comment…