Chuyển đến nội dung chính

Selenium IDE căn bản: Bộ công cụ hỗ trợ.

Selenium IDE cho phép chọn phần tử trực tiêp trên Firefox. Tuy nhiên trong một số trường hợp không thực hiện được vì website dùng Js để thao tác làm chèn lên thao tác chọn của Selenium IDE.

Để khắc phục ta dùng một vài ứng dụng như: Firebug để thay thế tính năng này, hoặc dùng Inspect Element của chính Firefox (Hiệu suất không cao bằng FireBug).

1) Cài đặt: Lên Google.com gõ firebug addon. > Vào link của Mozilla Firefox và install.
2) Trên trang web thực thi nhấn phím tắt: F12 hoặc Tool> Firebug.
3) Firebug hiện ra giao diện nhấn icon  để chọn phần tử trên web.
 
4) Dưới màn hình dom HTML sẽ thấy Element mong muốn, chuột phải hiện menu context> Lấy cách chọn.

 5) Chỉnh sửa lại và dán vô mục Target của IDE. >done.

Bài tập:
1) Cài đặt firebug.
2) Cài đặt Webdeveloper tool.
3) Lấy xpath bằng Firebug.
4) Lấy css path bằng firebug.



Nhãn:

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

Bảy nguyên tắc cơ bản của Kiểm thử phần mềm

Nội dung: nói và diễn giải về bảy nguyên tắc cơ bản trong testing software. Bài này là bài lý thuyết bổ sung và tester phải nắm được nằm lòng các nguyên tắc này! Bảy nguyên tắc (như khẩu huyết trong võ công): Kiểm thử tất cả mọi trường hợp là không thể được. ( EXHAUSTIVE testing is not possible ). Giải thích như sau: Một form có textbox cho phép nhập từ 1 -> 1.000.000.000.000. Nếu để kiểm thử nhập liệu cho textbox này ta phải kiểm thử 1k tỷ lần. Mỗi thao tác nhập cho là 1 giây, và phép toán kiểm tra nhập liệu là 0.1 giây nữa thì ta phải mất xấp xỉ 1k tỷ giây là khoảng 31k năm để thực thi nó. Đời người chỉ khoảng một trăm năm, vậy phải mất cả mấy nghìn đời để thực thi kiểm tra một textbox mà chưa kể đến nhiều đối tượng khác cho nên mới nói điều này là không thể làm được! (Chi phí nuôi nghìn người và giá trị bỏ ra là không xứng). Để xử lý thì ta: dùng kỹ thuật phân vùng tương đương, Phân nhánh nghiệp vụ, chia lớp xử lý... (Sẽ nói chi tiết sau). Kiểm thử là chỉ ra sai sót đang có ...
Đăng nhận xét
Đọc thêm

Ba lợi ích không ngờ tới của việc kết hợp test API trong quá trình code.

Bằng việc kết hợp TTD (Phát triển phần mềm theo hướng test) trong đó có API testing đưa đến ba hiệu quả rất thiết thực sau đây: 1. Chất lượng test. Nếu bạn chờ sau khi hoàn thành xong việc phát triển mới bắt tay vào test API thì những testcase của bạn sẽ có xu hướng trở thành happy case (những case thuận) và rất ít khi cho ra lỗi. Hiệu quả của việc này là phần mềm của bạn sẽ chạy rất khó khăn khi đưa ra môi trường thực tế. Ngược lại nếu bạn thực hiện API testing sớm thì những passive case sẽ chạy được và làm cho API trở nên mạnh mẽ và sáng tạo có khả năng hoạt động linh hoạt về lâu dài. 2. Test coverage (Độ bao phủ test). Thông thường API sẽ bao phủ toàn bộ các chức năng chính của phần mềm bạn, với xu hướng mobile web và đa nền hoạt động như hiện nay, độ che phủ chức năng của API ngày lại càng trở nên linh động và bao trùm. Do đó nếu làm tốt việc test API, thì bạn có thể khẳng định rằng phần mềm của bạn đã được bao phủ bởi nhiều testcase. 3. Test reuse (Sử dụng lại) Khi sử ...
Đăng nhận xét
Đọc thêm

Những trải nghiệm tệ bạc từ Phone UX

Dưới đây liệt kê một số Function và UX tệ của vài app. 1. SmartPay - Flow đăng ký và liên kết ngân hàng: Bắt nạp tiền 10k để xác thực, nhưng không hứa khi nào trả lại 10k này. - Sau khi bạn đăng ký xong bắt người dùng muốn liên kết ngân hàng thì phải trùng bởi SDT. Số điện thoại tuy là không thể thiếu, nhưng không bắt buộc là unique! (Rule này phải luôn nhớ, bởi rất nhiều App đang KYC qua số phone và tưởng rằng phone này là primary key!) 2. Tiki - Người dùng nếu remove app trên điện thoại 1 thời gian, sau đó cài lại thì app thì rơi vô exception điện thoại chưa xác thực. Để xác thực thì cần pair SDT, nếu SDT hết tiền, bị khóa 2 chiều => vô vọng! ... 3. SenPay - Khi bạn muốn mua hàng và sử dụng trên SenPay thì phải chờ một ngày may mắn, nếu không SenPay sẽ cho bạn ăn quả chờ OTP phone!
Đăng nhận xét
Đọc thêm