Trở thành Tester

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

Test case thì có nhiều step, step có quá nhiều làm ta khó lòng quản lý bảo trì được, vậy nên hãy dùng step trong Selenium IDE cho hiệu quả và cẩn trọng. Quy tắc số 1 : (cơ bản) là sử dụng từ 15 - 20 dòng trong một testcase. Tại sao như vậy, nếu trí nhớ của bạn thuộc vào vùng bình thường không gì đặc biệt thì con số 15 dòng lệnh sẽ giúp bạn kiểm soát và làm việc tốt hơn trên testcase của mình, 20 dòng là con số tối đa, vượt qua nó testcase bạn sẽ phức tạp và rối rắm đi ngược lại quy tắc tinh giản hóa của Test Automation. (Trừ khi trí tuệ bạn cao hơn mức bình thường). Chia nhỏ nó ra Quy tắc số 2 : chia nhỏ testcase ra nếu quá dài. Giúp dễ quản lý và bảo trì. Gom những chức năng chung lại thành một tescase nhỏ và ta sẽ thực hiện nó liên tiếp với nhau khi thực thi lại. Riêng tôi gọi là nhóm testcase phụ. chia lại nhóm khi cần Kết luận: Mục tiêu của bài này nhằm giúp bạn tư duy về step của một testcase trong Se IDE, có thể giúp bạn tư duy thêm cả về manual và automat...

Bốc khói test, là việc kiểm tra một vòng phần mềm xem nó đã sẵn sàng hoặc ổn định hay chưa để tiến hành kiểm tra tiếp. Nguồn gốc cái tên này là do trước đó lúc người ta thường kiểm tra phần cứng xem nó có tóe lửa hay bốc khói hay không khi bắt đầu bật nguồn lên. "Kiểm tra khói" là chọn (hoặc tạo) ra một danh sách testcase nhằm mục đích xác định rằng những chức năng chính là làm việc được hay không. Những testcase này cần có chiều sâu, nhưng nên đảm bảo về chiều rộng. Nếu tôi có phần mềm máy tính có khả năng phép cộng, trừ, nhân, chia thì khi ra phiên bản mới: tôi không kiểm tra Sin(x) + Sin(y), cos(x) /sin(y)... mà chỉ chọn những testcase cơ bản bao phủ như: x+y, x-y, x*y, x/y., và kiểm tra giao diện xem có đầy đủ phím số, phím chức năng hay chưa. Câu hay nhất cho Smoke test tôi nghĩ sẽ là: Simple is the best - Đơn giản là nhất. Nhiều người không phân biệt được giữa: Sanity test và Smoke test. Dưới đây là hình minh họa cụ thể sự khác nhau: (Tuy rằng k đủ hết tình hu...

Nội dung: diễn giải và có ví dụ cụ thể về Sanity test. 1) Khái niệm: Sanity Test - Kiểm thử bình thường là một loại kỹ thuật kiểm thử trong đó tester sẽ kiểm tra những chức năng mới thêm, bug đã hoàn chỉnh trên hệ thống và tập trung vào một hoặc vài vùng mới chứ không phải toàn bộ hệ thống. Khất bại. Ví dụ: hi một phiên bản vừa ra đời ta sẽ ưu tiên kiểm tra những chức năng mà gây ra lỗi ở bản trước hoặc chức năng mới thêm ở bản hiện tại, ta áp dụng chiến lượt Sanity test nếu phần mềm không được như mong đợi thì từ chối nhận và đánh dấu là phiên bản này đã tPhần mềm máy tính v.1 được tích hợp chức năng cộng: 1 + 2 = 5 => Qua phiên bản sau v.2  lỗi không được fix thì => Phiên bản v.2 đã thất bại. 2) Ví dụ và áp dụng: Hệ thống phần mềm bán dừa qua internet phiên bản 1.0 với 20 chức năng khác nhau. Nhưng khi tạo một hóa đơn cho người mua dừa có lỗi không hiển thị địa chỉ của người này. Người chủ muốn qua phiên bản: 2.0 sẽ sửa được lỗi trên và có thể hiển thị t...

Sau khi chọn thì tool Automation phải hỗ trợ việc thao tác trên phần tử chọn. Bước 2: Thao tác trên phần tử đã chọn. Việc thao tác trên phần tử chọn gồm hai phép cơ bản: Đọc và Gán. (Get & Set). Đọc - nhằm phục vụ cho việc lưu trữ, kiểm tra... Gán - nhằm nhiệm vụ thực thi các lệnh trên phần tử đã chọn. Ví dụ: thao tác click chuột trên phần tử, cuộn trang... Automation phải hỗ trợ đa dạng công việc thao tác trên phần tử, vì nhu cầu người dùng thao tác trên một phần tử là rất lớn. Trên website thì người dùng cuộn lên xuống, nhấn chuột, trên mobile thì họ lại vuốt, tap... Cho nên nói Automation tool như làm dâu trăm họ, không hỗ trợ được thao tác gì hoặc quá đơn giản thì coi như vứt đi và không xài được. Bước 3: Kiểm tra kết quả. Sau khi hoàn thành xong hai bước, ta phải kiểm tra kết quả trả về để xác định việc testing của mình có đúng như mong đợi hay không? Bước này đơn giản nhưng cũng không thể thiếu được trong tính năng của Automation tool. Kết luận: Ba bước thần thánh...

Gọi là ba bước thần thánh vì phần mềm nào cũng phải làm được ba bước cơ bản này. Bước 1: Chọn phần tử. Mỗi hệ điều hành dùng mỗi công nghệ để hiển thị nội dung khác nhau. Do đó chọn được phần tử rất khó, điều mà các phầm mềm Automation làm đầu tiên là nhận định được mình sẽ làm việc trên cái gì? - Ứng dụng gì, viết dưới công nghệ gì ... Nếu không xác định được nó là gì thì không thể làm việc được! Đa nền tảng - Bài toán cho Automation Tool. Xu hướng chung của các hệ thống CNTT hiện tại chính là website, vì nó có khả năng hoạt động trơn tru và các hệ điều hành đề có thể hỗ trợ nó thông qua trình duyệt. Tuy nhiên có mỗi môi trường web mà lại có rất nhiều công nghệ bên trong như: Java, Flash, HTML5, ... Thị phần Mobile lại chiếm lĩnh cực đại trong những năm gần đây khiến các bộ Tool trên thị trường tiếp cận theo một phân đoạn nữa: chọn phần tử trên Mobile. Sự đa nền tảng của hạ tầng CNTT hiện tại có nhiều cái lợi, nhưng cũng lắm cái hại. Lợi ích của nó là làm cho CNTT đa...