Trở thành Tester

Bài này nói về cách làm việc cơ bản của selenium. Bước khởi tạo : Chọn trình duyệt. Bước thực thi : Chọn phần tử web và thao tác. Cơ bản gồm hai thao tác. 1 - Bộ chọn phần tử: Chọn ra phần tử để thao tác trên đó. Se hỗ trợ các cách chọn như sau: Thuộc tính: name, id, class name Xpath. Css DOM TAG Tag HTML Link ... 2-  Thao tác: thực thi thao tác trên phần tử chọn ở bước 1. Se hỗ trợ các thao tác của người dùng: click, gán nội dung, rê chuột ... Ngoài ra còn có các thao tác hỗ trợ khi website có async: chờ trình duyệt load, chờ cho phần tử nào đó load ra... Bước kiểm tra : Kiểm tra các phần tử web đã thao tác có trả đúng như kết quả mong muốn hay không.

Giới thiệu sơ bộ: Selenium là công cụ hỗ trợ test auto trên môi trường web. DoB: 2004 Author: Jason Huggin. (Ghi nhớ để tri ân người tạo ra) Phiên bản đầu tiên Selenium 1.0 được cấu trúc như sau: - Code file: Có nhiệm vụ biên dịch code từ file liên kết như: Java, Ruby, ... - Remote Control Center: Nhận dữ liệu biên dịch và biến nó thành API gọi Javascript trên các API của trình duyệt như: IE, FF, Safari... - Bộ xử lý trình duyệt (Browser core) nhận tập lệnh Javascript của RCS (Remote Control Server) và thực thi các lệnh. RC (remote control) có một bộ core để biên dịch mã lệnh thành những phần Javascript tương thích cho từng trình duyệt. (Code=> Javascript RC => Gọi core xử lý JS=> Tạo ra javascript tương thích cho trình duyệt => Chạy trình duyệt web và trình duyệt web thực thi lệnh Javascript). Phiên bản thứ 2 của Selenium ra đời: Thay thế bộ RCS thành Selenium Web-driver theo đó selenium đẩy lệnh trực tiếp xuống browser làm cho hiệu suất tăng lên gấp bội...

Định nghĩa của ISTQB về tester trong mô hình phát triển phần mềm Agile. Bài dịch từ đại cương của chuẩn ISTQB về mô hình phát triển phần mềm. 1. Thế nào là mô hình phát triển phần mềm Agile? a. Nền tảngcủa Agile Vào năm 2001, một nhóm cá nhân độc lập đã thuyết trình một phương thức phát triển phần mềm mới, nhanh gọn và họ đồng ý với tuyên bố chung lập ra bốn nguyên tắc (như khẩu huyết) của mô hình phát triển Agile: 1) Cá nhân và cộng tác còn hơn là quy trình và công cụ (tools - công cụ hỗ trợ đo lường, quản lý...). 2) Phần mềm chạy được còn hơn là tài liệu thông suốt. 3) Cộng tác với khách hàng còn hơn là đàm phán hợp đồng. 4) Nhận được các thay đổi còn hơn là vòng vòng theo kế hoạch. Với 4 nguyên tắc trên từ đó nó được gọi là Bản tuyên ngôn của Agile. Sau đây là phân tích và diễn giải ý nghĩa. 1) Cá nhân và cộng tác Agile là mô hình hướng con người làm trung tâm, đòi hỏi các cá nhân phải cộng tác liên tục: giao tiếp, trao đổi... hơn là nói chuyện qua email, phần mềm ...

Câu hỏi ý muốn hỏi về sự hỗ trợ khi tester có tư duy lập trình. 1. Đa phần tester từ dân dev mà ra nên họ có tư duy lập trình sẵn. Đối với người từ ngành khác vào, việc biết code và tư duy lập trình sẽ giúp họ hiểu hơn về những gì hệ thống đang làm, nếu không biết code đôi khi là thiếu sót khá lớn. 2. Ngôn ngữ lập trình trong dự án, mỗi ngôn ngữ lập trình đều có mỗi cách bắt lỗi riêng biệt, nên bạn biết được ngôn ngữ trong dự án đang làm để phát triển thì bạn như hổ thêm cánh. 3. Lạm dụng code: ảnh hưởng không nhỏ đến tinh thần làm việc của dev nếu hay luyên thuyên về việc code như thế nào, lỗi này do code kia... Kết luận: Testing giờ được biết đến như một chuyên ngành riêng giúp cho chất lượng hệ thống phần mềm được nâng cao hơn. Biết code, sẽ giúp tester làm việc hiệu quả hơn trong công việc của mình, nhưng đừng lạm dụng hiểu biết của mình một cách quá đáng sẽ gây hiệu ứng không tốt.

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ử ...

Hướng dẫn test negative Link tham khảo: Guru99.com Test tiêu cực - Dịch chuối quá - nên mình quyết định dùng từ gốc là: Negative testing. Bài hướng dẫn sẽ gồm các phần sau: Định nghĩa - Negative testing là gì. (What) Negative testing có quan trọng không? (Is) Làm như thế nào? (How) Ưu và nhược điểm! (Pros. & cons.) Định nghĩa negative testing! Để đảm bảo hệ thống chạy trơn tru và ổn định, chúng ta chỉ test những trường hợp bình thường và hợp lệ là chưa đủ. Vì vậy, để đảm bảo hệ thống chạy có thể xử lý được những trường hợp ngoại lệ ta cần test thêm những ngữ cảnh không hợp lệ! (negative testing). Làm được việc này thì hệ thống sẽ có kinh nghiệm xử lý khi các ngữ cảnh này xảy ra bất thường. ví dụ:  Thực tế đời sống: Xe buýt chở được 20 người. Ta cho 20 người cho xe chở bình thường. Nhưng chuyện gì sẽ xảy ra nếu nó chở 21 hoặc 30 người? Xe bị đổ, nghiêng, lún, lái khó ...=> Đây là negative case. Phần mềm: Email field có thể chứa đến 50 ký tự => Đ...

Những sai lầm trong việc kiểm thử bằng tay manual - testing (Hay gọi là test tay theo tiếng việt). Đầu tiên là khái niệm: Kiểm thử trực tiếp (Manual Testing) là việc nhân viên kiểm thử thực thi việc kiểm tra hệ thống phần mềm mà không dùng qua bất cứ công cụ kiểm thử tự động nào. Dưới đây là những suy nghĩ sai lầm thường thấy của những người trong và ngoài ngành test: 1)  Ai cũng có thể thực hiện kiểm thử bằng tay. Sự thật : Testing đòi hỏi một loạt các kỹ năng khác nhau, không như tưởng tượng của một số người là ai làm cũng được. Ví dụ: kỹ năng phân tích, đọc tài liệu, trí tò mò, báo cáo... 2) Test xong nghĩa là không còn bug (defect).. Sự thật : Việc kiểm tra phần mềm chỉ mong muốn là tìm được nhiều bug nhất có thể. Nếu nghĩ testing tất cả mọi thứ là chuyện nhỏ thì là một câu chuyện hoang đường. Ví dụ: kiểm tra một trường email 50 ký tự. Ta sẽ có các trường hợp lũy thừa 50 ký tự số và chữ, và việc bỏ công test 1 trường email như thế mất hàng năm trời... 3) Test tự ...