Xác minh phần tử Hiện tại và lệnh chờ trong Selenium

Một bản ghi âm Selenium IDE Tập lệnh thực hiện các thao tác nhấp chuột và gõ phím, nhưng tự nó không bao giờ quyết định xem ứng dụng hoạt động đúng hay sai. Có hai nhóm lệnh thực hiện công việc đó: xác minh các lệnh kiểm tra trạng thái của trang và chờ đợi các lệnh này sẽ tạm dừng thực thi cho đến khi trang sẵn sàng để được kiểm tra.

⚠️ Lưu ý về các phiên bản: Các ảnh chụp màn hình bên dưới được lấy từ bản gốc. Firefox-cắm vào Selenium IDE này hiện không còn được phân phối nữa, và họ sử dụng tên tiếng Selenese theo kiểu camelCase. IDE hiện tại là Chrome. Firefox và Edge mở rộng trình duyệtHành vi được mô tả ở đây vẫn áp dụng, nhưng một số tên lệnh đã thay đổi — một bản đồping Bảng sẽ xuất hiện ở phần sau của bài viết này, và mọi lệnh gốc cũng như ảnh chụp màn hình đều được giữ nguyên chính xác như đã công bố.

Xác minh sự hiện diện của một phần tử

Chúng ta có thể sử dụng hai lệnh sau để xác minh sự hiện diện của một phần tử:

• xác minhElementPresent – trả về TRUE nếu phần tử được chỉ định được TÌM THẤY trong trang; FALSE nếu không
• xác minhElementNotPresent – trả về TRUE nếu KHÔNG TÌM THẤY phần tử được chỉ định ở bất kỳ đâu trong trang; SAI nếu nó hiện diện.

Cả hai lệnh đều nhận một phần tử định vị trong Target trường — một id, một tên, một bộ chọn CSS, một văn bản liên kết hoặc một Xpath biểu thức — và cả hai đều không cần giá trị.

Tập lệnh kiểm tra bên dưới xác minh rằng hộp văn bản Tên người dùng có trong Mercury Trang chủ của Tours trong khi hộp văn bản Tên thì không. Hộp văn bản Tên thực sự là một phần tử có trong trang Đăng ký của Mercury Chuyến tham quan, không có trong trang chủ.

Bởi vì đây là xác minh lệnh thay vì khẳng định Khi thực hiện các lệnh, lỗi sẽ được ghi vào nhật ký và các bước còn lại vẫn tiếp tục chạy. Sự khác biệt này sẽ được trình bày chi tiết hơn ở phần sau.

Xác minh sự hiện diện của một văn bản nhất định trong lệnh trong Selenium

Việc kiểm tra xem một phần tử có tồn tại hay không không phải lúc nào cũng đủ — một bài kiểm tra thường cần xác nhận các từ được hiển thị cho người dùng. Hai lệnh văn bản giải quyết trường hợp đó.

• xác minhTextPresence – trả về TRUE nếu chuỗi văn bản được chỉ định được TÌM THẤY ở đâu đó trong trang; FALSE nếu không
• xác minhTextNotPresent – trả về TRUE nếu KHÔNG TÌM THẤY chuỗi văn bản đã chỉ định ở bất kỳ đâu trong trang; SAI nếu nó được tìm thấy

Hãy nhớ rằng các lệnh này phân biệt chữ hoa chữ thường.

Nhật ký bên dưới cho thấy cùng một trang đã được kiểm tra hai lần với hai cách viết khác nhau của cùng một cụm từ.

Trong trường hợp trên, "Atlanta to Las Vegas" được xử lý khác với "atlanta to Las Vegas" vì chữ "A" trong "Atlanta" được viết hoa ở trường hợp đầu tiên trong khi viết thường ở trường hợp thứ hai. Khi sử dụng lệnh verifyTextPresent trên từng trường hợp, một trường hợp thành công trong khi trường hợp kia thất bại.

Xác minh vị trí cụ thể của một phần tử

Các lỗi bố trí hiếm khi làm hỏng bộ định vị, vì vậy việc kiểm tra sự hiện diện sẽ bỏ sót chúng. Các lệnh định vị sẽ khắc phục được thiếu sót đó.

Selenium IDE chỉ ra vị trí của một phần tử bằng cách đo (tính bằng pixel) khoảng cách từ cạnh trái hoặc cạnh trên của cửa sổ trình duyệt.

• xác minhElementPositionLeft – xác minh xem số pixel được chỉ định có khớp với khoảng cách của phần tử từ cạnh trái của trang hay không. Điều này sẽ trả về FALSE nếu giá trị được chỉ định không khớp với khoảng cách từ cạnh trái.
• xác minhElementPositionTop – xác minh xem số pixel được chỉ định có khớp với khoảng cách của phần tử từ cạnh trên cùng của trang hay không. Điều này sẽ trả về FALSE nếu giá trị được chỉ định không khớp với khoảng cách từ cạnh trên.

Đoạn mã bên dưới ghi lại các giá trị bù pixel dự kiến ​​vào cột Giá trị.

Hãy cẩn trọng khi sử dụng hai lệnh này. Độ lệch pixel thay đổi tùy thuộc vào kích thước cửa sổ, mức độ thu phóng và phông chữ đã cài đặt, vì vậy một giá trị được mã hóa cứng có thể hoạt động trên máy này nhưng lại không hoạt động trên máy khác.

Chờ lệnh trong Selenium

Lệnh kiểm tra chỉ có thể kiểm tra những gì đã hiển thị trên màn hình, vì vậy một thao tác kiểm tra chạy quá sớm sẽ thất bại ngay cả khi ứng dụng vẫn đang hoạt động. Các lệnh chờ giải quyết vấn đề về thời gian đó.

Sau đây là các loại lệnh chờ trong Selenium

và các lệnh chờ

Đây là các lệnh sẽ đợi trang mới tải trước khi chuyển sang lệnh tiếp theo.

Ví dụ như

• nhấp vào và chờ
• gõAndWait
• chọnAndWait

Mỗi lệnh trong số đó đều là một lệnh hành động thông thường với hậu tố AndWait được gắn kèm, như bước được ghi lại bên dưới cho thấy.

chờ lệnh

Đây là các lệnh chờ một điều kiện đã chỉ định trở thành đúng trước khi tiếp tục lệnh tiếp theo (bất kể việc tải trang mới). Các lệnh này phù hợp hơn khi sử dụng trên các trang web động dựa trên AJAX thay đổi giá trị và thành phần mà không cần tải lại toàn bộ trang. Những ví dụ bao gồm:

• chờForTitle
• chờForTextPresent
• chờForAlert

Hãy xem xét kịch bản Facebook dưới đây.

Chúng tôi có thể sử dụng kết hợp “click” và “waitForTextPresent” để xác minh sự hiện diện của văn bản “Cung cấp ngày sinh nhật của bạn”.

Chúng tôi không thể sử dụng clickAndWait vì không có trang nào được tải khi nhấp vào "Tại sao tôi cần cung cấp ngày sinh của mình?" liên kết. Nếu chúng ta làm vậy, bài kiểm tra sẽ thất bại

Quy tắc tương tự cũng áp dụng cho bất kỳ nội dung nào được chèn bằng tập lệnh chứ không phải bằng điều hướng, đó là lý do tại sao Màn hình điều khiển bằng AJAX Hầu hết các trường hợp đều cần sử dụng waitFor thay vì andWait.

So sánh lệnh Assert, Verify và waitFor trong Selenium IDE

Người mới bắt đầu thường chọn sai nhóm phần mềm rồi tự hỏi tại sao bộ phần mềm lại dừng lại ở lỗi đầu tiên, hoặc tại sao nó báo cáo đến hai mươi lỗi mà tất cả đều không phải là lỗi đầu tiên. trace quay lại số một. Ba tiền tố trả lời ba câu hỏi khác nhau.

Tiếp đầu ngữ	Những gì nó	Khi thất bại	Sử dụng tốt nhất cho
khẳng định	Kiểm tra tình trạng ngay lập tức	Ghi lại lỗi và dừng quá trình kiểm thử.	Điều kiện tiên quyết — việc đăng nhập phải thành công trước khi mọi thứ khác có ý nghĩa.
xác minh	Kiểm tra tình trạng ngay lập tức	Ghi lại lỗi và tiếp tục với lệnh tiếp theo.	Các bước kiểm tra độc lập, chẳng hạn như nhiều nhãn trên cùng một trang xác nhận.
chờ đợi	Các cuộc thăm dò ý kiến ​​cho đến khi điều kiện trở thành sự thật.	Ghi lại lỗi sau khi hết thời gian chờ, rồi tiếp tục.	Bất cứ thứ gì xuất hiện chậm trễ — phản hồi AJAX, biểu tượng chờ, hộp thoại.

Một mô hình thực tế kết hợp cả ba: xác nhận trang bạn vừa truy cập, chờ phần tử đến một cách bất đồng bộ, sau đó xác minh từng trường riêng lẻ. Thực hiện theo thứ tự đó có nghĩa là một lỗi điều hướng sẽ làm dừng quá trình kiểm thử sớm, trong khi một số lỗi không khớp về hình thức sẽ được báo cáo trong một lần chạy duy nhất. Nguyên tắc tương tự cũng áp dụng cho Selenium Các bài kiểm tra được viết bằng mã, trong đó các phương pháp tương đương là khẳng định cứng, khẳng định mềm và chờ đợi rõ ràng.

Xác minh và chờ lệnh trong trạng thái hiện tại Selenium IDE

Firefox- Plugin IDE tạo ra các ảnh chụp màn hình ở trên đã bị ngừng hoạt động và bộ lệnh đã được xây dựng lại cho tiện ích mở rộng trình duyệt hiện tại. Một số tên tiếng Selenese vẫn được giữ lại, một số được đổi tên và một vài tên bị loại bỏ. Bảng dưới đây đối chiếu các lệnh được sử dụng trong bài viết này với các lệnh tương đương hiện nay, được lấy từ tài liệu chính thức. Selenium Tài liệu tham khảo lệnh IDE.

Lệnh Selenese cổ	Lệnh trong IDE hiện tại
xác minhElementPresent	xác minh sự hiện diện của phần tử
xác minhElementNotPresent	xác minh phần tử không có mặt
xác minhTextPresence	Xác minh văn bản (phạm vi áp dụng cho bộ định vị phần tử, không phải toàn bộ trang)
xác minhTextNotPresent	Xác minh không phải văn bản (phạm vi áp dụng cho bộ định vị phần tử)
xác minh tiêu đề	xác minh tiêu đề
verifyElementPositionLeft / verifyElementPositionTop	Không có sự tương đương — các tuyên bố về lập trường đã bị bác bỏ.
clickAndWait, typeAndWait, selectAndWait	Không có hậu tố AndWait — lệnh open đã chờ trang tải xong.
chờForElementPresent	Chờ cho đến khi phần tử xuất hiện, với thời gian chờ tính bằng mili giây.
chờForAlert	Hiển thị cảnh báo hoặc xác minh văn bản cảnh báo sau khi hộp thoại xuất hiện.

Hai điểm khác biệt quan trọng nhất trong công việc hàng ngày. Thứ nhất, các lệnh chờ hiện tại — chờ phần tử hiện diện, chờ phần tử hiển thị, chờ phần tử có thể chỉnh sửa và các lệnh phủ định của chúng — mỗi lệnh đều yêu cầu một khoảng thời gian chờ cụ thể tính bằng mili giây, do đó một bước chậm không còn phải chia sẻ một thời gian chờ toàn cục nữa. Thứ hai, chức năng tìm kiếm văn bản trên toàn trang đã bị loại bỏ: xác minh văn bản cần một bộ định vị, điều này thường cho kết quả kiểm tra chính xác hơn.

Các lỗi thường gặp với lệnh Verify và waitFor

Hầu hết các sự cố được báo cáo với các lệnh này không phải là lỗi của IDE. Danh sách dưới đây liệt kê các lỗi thường gặp nhất và cách khắc phục từng lỗi.

• Phần tử tồn tại nhưng quá trình kiểm tra vẫn thất bại. Sự hiện diện và khả năng hiển thị là hai trạng thái khác nhau. Một phần tử bị ẩn sau một quy tắc CSS vẫn hiện diện trong DOM, vì vậy hãy kết hợp kiểm tra sự hiện diện với việc chờ phần tử hiển thị khi phép thử phụ thuộc vào việc người dùng thực sự nhìn thấy nó.
• Quá trình kiểm tra văn bản thất bại khi phát hiện các từ ngữ trông giống hệt nhau. Các ký tự khoảng trắng không ngắt dòng, khoảng trắng thừa ở cuối dòng và dấu nháy đơn cong được sao chép từ tài liệu thiết kế đều làm hỏng sự khớp chính xác. Hãy gõ lại chuỗi mong muốn bằng tay thay vì dán.
• Lệnh chờ bị hết thời gian trên một trang rõ ràng đã tải xong. Phần tử này thường nằm bên trong một iframe. Hãy chạy lệnh select frame trước, nếu không bộ định vị sẽ được đánh giá trên tài liệu không chính xác.
• clickAndWait bị treo trên ứng dụng một trang. Không có thao tác điều hướng nào diễn ra, vì vậy không cần phải chờ đợi. Hãy thay thế nó bằng một cú nhấp chuột kèm theo lệnh waitFor thích hợp.
• Việc kiểm tra vị trí thành công trên máy cục bộ nhưng lại thất bại trên máy chủ biên dịch. Kích thước màn hình và cách hiển thị phông chữ có thể khác nhau. Nên chọn kiểm tra sự hiện diện hoặc văn bản, hoặc thiết lập kích thước cửa sổ cụ thể ngay từ đầu bài kiểm tra.
• Toàn bộ bộ bài dừng lại ngay khi có sự không khớp đầu tiên. Lệnh assert đã được ghi nhận trong khi đáng lẽ ra phải là lệnh verify. Hãy đổi tiền tố và chương trình sẽ báo cáo mọi lỗi thay vì chỉ lỗi đầu tiên.

Một khi kịch bản vượt qua được những cạm bẫy này, bước tiếp theo thường là... lưu trữ các giá trị thời gian chạy vào các biến. Vì vậy, các kiểm tra so sánh với dữ liệu thực chứ không phải các chuỗi được mã hóa cứng.

Câu Hỏi Thường Gặp