Đa I Tờ 's Blog

- Adhoc Testing là loại kiểm thử ngoài kế hoạch, phụ thuộc vào sự sáng tạo mà không tuân theo bất kỳ quy trình chính thức nào trong Test Process như: Software Requirements Specification - SRS, Test plan, Test case,... - Là phương pháp kiểm thử hộp đen - chỉ quan tâm input và output mà không cần quan tâm tới cách thức nó xử lí, hiện thực bên dưới như thế nào Ai thực hiện? - Người thực hiện phải là người có chuyên môn tốt và kiến thức chuyên sâu về sản phẩm vì Adhoc testing phụ thuộc vào sự ngẫu nhiên và trực giác phán đoán lỗi - Không chỉ giới hạn ở Tester mà bất kì thành viên nào trong team đều có thể thực hiện (dev, business analyst, scrum master,...) Thực hiện khi nào? - Bất kì giai đoạn kiểm thử nào trong SDLC (Software Development Life Cycle) từ UT tới UAT  - Thực hiện sau khi việc kiểm thử chính thức hoàn thành - Bất cứ khi nào thành viên trong team rảnh (không có task trong tay) thì đi thực hiện Adhoc Testing Cách thức thực hiện - Tự nghĩ ra các tình huống lắc léo, những tha...

- API: Application Programming Interface -> Cầu nối giữa client và server      + API Testing thuộc business logic layer (presentation -> business logic -> data management)      + API testing là kiểm thử trên server, không liên quan tới client     +   Tool sủ dụng: Postman, rest client,... - Cơ chế hoạt động của API     + Client gửi request tới server, server xử lí thông tin và gửi response lại cho client     + Sử dụng giao thức HTTP để truyền tải dữ liệu - Cách test API: 1. Gửi yêu cầu lên server với các tham số yêu cầu (run request): các phương thức sử dụng     + GET: yêu cầu server đưa lại resource -> Read     + POST: yêu cầu server tạo 1 resource mới -> Create     + PUT/PATCH: yêu cầu server cho sửa resource -> Update     + DELETE: yêu cầu server xóa resource -> Delete 2. Kiểm tra kết quả trả về (check response) -> so sánh kết quả thực tế với tài liệ...

 Local Storage vs Session Storage + Giống: Lưu theo từng cặp <key - value> Dung lượng lưu khoảng 5MB <value> chỉ lưu ở local browser nên server không truy cập được <value>  luôn luôn được lưu dưới dạng String, các kiểu dữ liệu khác cần parse về String trước khi lưu vào storage + Khác: localStorage:  Close tab hoặc close browser thì data vẫn còn chỉ khi clear cache hoặc clear data của browser thì data mới mất Chi sẻ dữ liệu giữa các tab (trường hợp mở nhiều tab) sessionStorage:  Mất data ngay khi close tab hoặc close browser Cookie Có thời hạn expire Dung lượng tối đa 4KB Truy cập được ở cả client và server (khi client gửi request tới server, cookie của trang sẽ được thêm vào request trước khi gửi) Ứng dụng để lưu token, authentication information,... để lưu trữ thông tin người dùng --- Link tham khảo:  https://www.geeksforgeeks.org/difference-between-local-storage-session-storage-and-cookies/

 Một số khái niệm cần phân biệt trong kiểm thử phần mềm  - Verification (Xác minh) vs Validation (Xác nhận) Verification: Confirm that sản phẩm có đáp ứng được đặc tả yêu cầu hay không product right: chúng tôi xây dựng sản phẩm có đúng không? Các hoạt động: nhận xét, hướng dẫn, xác minh Validation: Sản phẩm có đúng mong đợi của khách hàng hay không right product: chúng tôi xây dựng đúng sản phẩm không Thực hiện sau bước Verification Các hoạt động: functional testing, regression testing, smoke testing, system testing, UAT,... - Static vs Dynamic testing Static testing: Thực hiện trong Verification Đưa đánh giá về code Các phương pháp: walkthroughs, code review,... Dynamic testing: Thực hiện trong Validation Cho biết phần giới hạn của hệ thống Các phương pháp: Functional & Non-functional testing  - Functional vs Non-functional testing Functional testing: Sản phẩm làm gì: what the product does? Quan tâm "action & behavior" Dựa theo đặc tả yêu cầu Non-functional testi...

Hình 1. Sơ đồ tổng quan kiến thức về kiểm thử phần mềm 1. Các tài liệu trong test process - Test plan : là tài liệu mô tả về: scope, approach, schedule, resources - Test case : trình bày những thông tin cho kiểm thử một hạng mục. Tùy theo tổ chức sẽ có những custom phù hợp với tổ chức của mình nhưng vẫn đảm bảo gồm các thành phần: ID Test case description Pre-conditions Test case procedure Actual output Expected output Result (pass/fail) Note 1 test case luôn có 3 loại: Normal, Abnormal, Boundary - Bug report: Mô tả bug khi execute test cases -> Giúp dev tái hiện lại con bug một cách dễ dàng. Gồm các thành phần: ID Bug Description Environment: Browser, devices,... Các bước tái hiện: Pre-conditions Step to reproduce Actual output Expected output Mức độ nghiêm trọng (s everity - con bug ảnh hưởng như thế nào tới hệ thống) Critical: dừng ứng dụng (crash app) Serious: thiếu chức năng/chức năng không work Normal: chức năng không work nhưng vẫn có giải pháp khắc phục tạm thời để nó hoạ...