Tổng hợp các kiến thức cơ bản cho Tester

trainmax 21/11/2024

Nội dung 

Kiến thức nền tảng cho tester

1. Định nghĩa kiểm thử phần mềm

Kiểm thử phần mềm là quá trình xác minh (verification) và xác nhận (validation) rằng phần mềm được phát triển phù hợp với yêu cầu đã đề ra, hoạt động đúng như mong đợi và không có lỗi ảnh hưởng nghiêm trọng đến người dùng.

  • Xác minh (Verification): Kiểm tra xem sản phẩm có được xây dựng đúng cách hay không, tập trung vào giai đoạn phát triển.
    Ví dụ: Đọc tài liệu yêu cầu (SRS) để đảm bảo rằng các chức năng được mô tả rõ ràng và đúng với mục tiêu ban đầu.
  • Xác nhận (Validation): Đảm bảo rằng sản phẩm được xây dựng đúng nhu cầu của khách hàng và hoạt động như mong đợi.
    Ví dụ: Thử nghiệm giao diện người dùng để đảm bảo sản phẩm dễ sử dụng và phù hợp với kỳ vọng của khách hàng.

2. Mục tiêu kiểm thử

  1. Phát hiện lỗi (bugs):
    • Kiểm tra để tìm ra các lỗi chức năng hoặc logic trong phần mềm.
    • Ví dụ: Một ứng dụng đặt hàng trực tuyến cho phép người dùng nhập số lượng âm. Đây là lỗi cần phát hiện trong giai đoạn kiểm thử.
  2. Đảm bảo chất lượng sản phẩm:
    • Đảm bảo rằng sản phẩm hoạt động mượt mà, không gặp lỗi lớn khi triển khai cho khách hàng.
    • Ví dụ: Một trang web thương mại điện tử phải hoạt động tốt trên các trình duyệt khác nhau như Chrome, Safari, Firefox.
  3. Cải thiện trải nghiệm người dùng:
    • Đảm bảo sản phẩm dễ sử dụng, giao diện thân thiện và cung cấp giá trị cho người dùng.
    • Ví dụ: Kiểm tra ứng dụng ngân hàng có giao diện dễ sử dụng, rõ ràng, và không gây nhầm lẫn khi thực hiện giao dịch.

3. Các mức độ kiểm thử (Testing Levels)

  1. Unit Testing (Kiểm thử đơn vị):
    • Kiểm tra từng module hoặc đoạn mã riêng lẻ.
    • Ví dụ: Kiểm tra một hàm trong mã nguồn tính toán tổng hai số. Đầu vào là 35, đầu ra kỳ vọng là 8.
  2. Integration Testing (Kiểm thử tích hợp):
    • Kiểm tra sự giao tiếp giữa các module hoặc thành phần.
    • Ví dụ: Một ứng dụng có hai module: Đăng ký tài khoản và Gửi email xác nhận. Kiểm tra xem sau khi người dùng đăng ký, email xác nhận có được gửi thành công không.
  3. System Testing (Kiểm thử hệ thống):
    • Kiểm tra toàn bộ hệ thống như một đơn vị hoàn chỉnh.
    • Ví dụ: Kiểm tra toàn bộ hệ thống đặt vé máy bay: chọn vé, điền thông tin hành khách, thanh toán, và nhận email xác nhận.
  4. Acceptance Testing (Kiểm thử chấp nhận):
    • Kiểm tra xem phần mềm có đáp ứng các yêu cầu nghiệp vụ của khách hàng hay không.
    • Ví dụ: Một khách hàng yêu cầu ứng dụng quản lý nhân sự có thể xuất báo cáo lương. Tester kiểm tra xem tính năng xuất báo cáo có hoạt động chính xác không trước khi bàn giao sản phẩm.

4. Các loại kiểm thử chính (Testing Types)

  1. Functional Testing (Kiểm thử chức năng):
    • Đảm bảo phần mềm hoạt động đúng với các yêu cầu đã đề ra.
    • Ví dụ: Trong một ứng dụng ngân hàng, kiểm tra chức năng “Chuyển tiền” với các điều kiện:
      • Tài khoản nguồn còn đủ tiền.
      • Tài khoản đích hợp lệ.
  2. Non-Functional Testing (Kiểm thử phi chức năng):
    • Kiểm tra các yếu tố như hiệu suất, bảo mật, khả năng tương thích.
    • Ví dụ:
      • Hiệu suất: Đo tốc độ xử lý khi 1000 người dùng truy cập đồng thời.
      • Bảo mật: Kiểm tra ứng dụng không bị xâm nhập khi thử nhập mã độc vào form đăng nhập.
  3.  Regression Testing (Kiểm thử hồi quy):
    • Kiểm tra lại các phần đã hoạt động sau khi thay đổi mã nguồn hoặc sửa lỗi.
    • Ví dụ: Sau khi sửa lỗi tính sai số tiền trong giỏ hàng, kiểm tra toàn bộ tính năng thanh toán để đảm bảo không ảnh hưởng đến các phần khác.
  4. Smoke Testing (Kiểm thử khói):
    • Kiểm tra nhanh các chức năng chính của phần mềm để đảm bảo hệ thống hoạt động cơ bản.
    • Ví dụ: Sau khi triển khai bản build mới, kiểm tra xem ứng dụng có thể mở, đăng nhập, và thực hiện thao tác cơ bản mà không bị lỗi.
  5. Sanity Testing (Kiểm thử hợp lệ):
    • Kiểm tra tập trung vào một tính năng cụ thể sau khi thay đổi hoặc sửa lỗi.
    • Ví dụ: Sau khi cải thiện tính năng tìm kiếm trên trang web, chỉ kiểm tra tính năng này để xác nhận hoạt động tốt.

Quy trình kiểm thử (Testing Process)

Quy trình kiểm thử phần mềm bao gồm nhiều bước nhằm đảm bảo sản phẩm hoạt động đúng như mong đợi. Tester cần nắm chắc các bước trong quy trình để xử lý công việc kiểm thử hiệu quả hơn. Dưới đây là chi tiết từng bước, kèm theo ví dụ cụ thể:

1. Phân tích yêu cầu (Requirement Analysis)

Hiểu rõ yêu cầu sản phẩm từ tài liệu SRS (Software Requirement Specification) hoặc trực tiếp từ khách hàng. Đây là bước đầu tiên để xác định rõ những gì cần kiểm thử.

  • Hoạt động:
    • Đọc và hiểu tài liệu SRS hoặc tài liệu yêu cầu.
    • Xác định các chức năng chính, chức năng phụ, và các ràng buộc.
    • Phát hiện các yêu cầu không rõ ràng hoặc thiếu sót.
    • Trao đổi với khách hàng hoặc team phát triển nếu cần làm rõ yêu cầu.
  • Ví dụ:
    Một ứng dụng đặt vé máy bay yêu cầu:

    • Người dùng có thể tìm kiếm chuyến bay theo ngày, địa điểm đi và địa điểm đến.
    • Phải hiển thị giá vé, thời gian bay, và tên hãng hàng không.

Khi phân tích yêu cầu, tester cần đảm bảo hiểu rõ cách hoạt động của chức năng “Tìm kiếm chuyến bay” và các trường hợp cần kiểm thử như:

  • Người dùng nhập sai ngày.
  • Không có chuyến bay nào khả dụng.

2. Lập kế hoạch kiểm thử (Test Planning)

  • Hoạt động:
    • Xác định phạm vi kiểm thử (những gì sẽ và không được kiểm thử).
    • Xác định mục tiêu: Ví dụ, đảm bảo các chức năng chính hoạt động đúng.
    • Lựa chọn chiến lược kiểm thử: Thủ công, tự động, hoặc kết hợp cả hai.
    • Chuẩn bị tài nguyên: nhân sự, công cụ (Jira, Selenium…), và môi trường kiểm thử (server, database).
    • Lên kế hoạch lịch trình kiểm thử (timeline).
  • Ví dụ:
    • Phạm vi: Chỉ kiểm thử giao diện web, không kiểm thử phiên bản di động.
    • Công cụ: Sử dụng Selenium để kiểm thử tự động.
    • Môi trường: Dùng trình duyệt Chrome và Firefox trên hệ điều hành Windows 10.

3/4. Thiết kế kịch bản kiểm thử (Test Case Development & Enviroment)

  • Hoạt động:
    • Tạo các Test Case cụ thể, rõ ràng, dễ hiểu và có thể tái sử dụng.
    • Xác định Test Data: Dữ liệu đầu vào cần thiết để thực hiện kiểm thử.
    • Đảm bảo mỗi Test Case có mô tả chi tiết, bao gồm:
      • ID của Test Case.
      • Mục tiêu kiểm thử.
      • Các bước thực hiện.
      • Kết quả mong đợi.
  • Ví dụ:
    Test Case: Tìm kiếm chuyến bay khả dụng

    • ID: TC001.
    • Mục tiêu: Xác minh rằng chức năng tìm kiếm chuyến bay hoạt động đúng.
    • Bước thực hiện:
      1. Truy cập trang web đặt vé.
      2. Nhập thông tin:
        • Địa điểm đi: Hà Nội.
        • Địa điểm đến: TP. HCM.
        • Ngày: 25/12/2024.
      3. Nhấn nút “Tìm kiếm”.
    • Kết quả mong đợi: Hiển thị danh sách chuyến bay phù hợp với thông tin nhập vào.

5. Thực hiện kiểm thử (Test Execution)

  • Hoạt động:
    • Chạy các Test Case đã thiết kế.
    • Ghi nhận kết quả thực tế (Actual Result) và so sánh với kết quả mong đợi (Expected Result).
    • Gửi báo cáo lỗi (Bug Report) nếu phát hiện vấn đề.
  • Ví dụ:
    • Test Case: TC001 (Tìm kiếm chuyến bay).
    • Kết quả thực tế: Trang web hiển thị lỗi “Không tìm thấy chuyến bay” dù thông tin nhập hợp lệ.
    • Báo cáo lỗi (Bug Report):
      • ID: BUG001.
      • Mô tả: Chức năng tìm kiếm không hiển thị kết quả chính xác khi nhập thông tin hợp lệ.
      • Môi trường: Chrome, Windows 10.
      • Độ ưu tiên: Cao.

6. Theo dõi và báo cáo (Tracking & Reporting/ Test closure)

  • Hoạt động:
    • Theo dõi trạng thái lỗi: Mới (New), Đã sửa (Fixed), hoặc Đã đóng (Closed).
    • Kiểm tra lại lỗi (Retest) để xác minh lỗi đã được sửa.
    • Tổng hợp kết quả kiểm thử và gửi báo cáo kiểm thử (Test Report) cho team liên quan.
  • Ví dụ:
    • Trạng thái lỗi:
      • BUG001: Đã sửa.
      • BUG002: Chưa sửa.
    • Báo cáo kiểm thử:
      • Tổng số Test Case: 50.
      • Số Test Case thành công: 45.
      • Số Test Case thất bại: 5.
      • Tỷ lệ thành công: 90%.

Kỹ năng phân tích lỗi (Bug Analysis)

Phân tích lỗi là một trong những kỹ năng cốt lõi của tester, giúp phát hiện, ghi nhận, và truyền đạt thông tin về lỗi (bug) một cách rõ ràng, chi tiết để đảm bảo developer có đủ thông tin để khắc phục. Việc này bao gồm hiểu vòng đời lỗi, chuẩn bị báo cáo lỗi hiệu quả và sử dụng các công cụ hỗ trợ.

1. Hiểu rõ Defect Lifecycle (Vòng đời lỗi)

Vòng đời lỗi mô tả các trạng thái mà một lỗi trải qua từ khi được phát hiện đến khi được khắc phục hoàn toàn.

Các trạng thái chính trong vòng đời lỗi:

  1. New (Mới): Lỗi vừa được phát hiện và ghi nhận bởi tester.
    • Ví dụ: Tester phát hiện khi nhập số âm vào ô “Số lượng sản phẩm”, hệ thống không hiển thị thông báo lỗi.
  2. Assigned (Gán): Lỗi được gán cho một developer cụ thể để xử lý.
    • Ví dụ: Lỗi trên được gán cho Developer A, người chịu trách nhiệm xử lý module nhập liệu.
  3. Fixed (Đã sửa): Developer sửa lỗi và đánh dấu trạng thái là “Fixed”.
    • Ví dụ: Developer A sửa lỗi và gửi lại cho tester để kiểm tra.
  4. Retested (Kiểm tra lại): Tester kiểm tra lại lỗi đã được sửa để xác nhận lỗi không còn xảy ra.
    • Ví dụ: Tester thử nhập số âm vào ô “Số lượng sản phẩm” và thấy thông báo lỗi hiển thị đúng như mong đợi.
  5. Closed (Đóng): Lỗi được xác nhận là đã sửa xong và không còn tồn tại.
    • Ví dụ: Tester đánh dấu lỗi “Closed” trong hệ thống quản lý lỗi (như Jira).
  6. Reopened (Mở lại): Nếu tester phát hiện lỗi vẫn còn xảy ra hoặc tái phát sau khi sửa, trạng thái sẽ chuyển thành “Reopened”.
    • Ví dụ: Tester phát hiện thông báo lỗi hiển thị không đúng trên trình duyệt Safari, và lỗi được mở lại.

2. Các yếu tố cần có trong Bug Report

Bug Report là tài liệu quan trọng để mô tả chi tiết về lỗi, giúp developer hiểu và sửa lỗi nhanh chóng. Một Bug Report tốt cần các yếu tố sau:

  1. Mô tả chi tiết lỗi (Bug Description):
    • Mô tả ngắn gọn nhưng đầy đủ về lỗi, bao gồm:
      • Lỗi là gì?
      • Xảy ra khi nào?
      • Ở đâu trong phần mềm?
    • Ví dụ: “Hệ thống không hiển thị thông báo lỗi khi nhập số âm vào ô ‘Số lượng sản phẩm’ trên trang Giỏ hàng.”
  2. Các bước thực hiện để tái tạo lỗi (Steps to Reproduce):
    • Cung cấp từng bước cụ thể để developer có thể tái tạo lỗi.
    • Ví dụ:
      1. Truy cập trang web [example.com/cart].
      2. Thêm một sản phẩm vào giỏ hàng.
      3. Nhập giá trị “-1” vào ô “Số lượng sản phẩm”.
      4. Nhấn “Cập nhật giỏ hàng”.
  3. Kết quả mong đợi và kết quả thực tế (Expected vs. Actual Result):
    • Kết quả mong đợi: Hệ thống hiển thị thông báo lỗi: “Số lượng sản phẩm không thể là số âm.”
    • Kết quả thực tế: Không có thông báo lỗi, và giỏ hàng vẫn được cập nhật với số lượng âm.
  4. Môi trường kiểm thử (Environment):
    • Thông tin về môi trường nơi lỗi xảy ra: hệ điều hành, trình duyệt, thiết bị, phiên bản ứng dụng…
    • Ví dụ:
      • OS: Windows 11.
      • Trình duyệt: Google Chrome, Version 118.0.
      • Môi trường: Staging Server.
  5. Tài liệu bổ sung (Attachments):
    • Đính kèm ảnh chụp màn hình hoặc video để minh họa lỗi.
    • Ví dụ: Ảnh chụp màn hình giỏ hàng hiển thị số lượng “-1”.

3. Ví dụ chi tiết về Bug Report4. Lưu ý khi phân tích lỗi

  • Tính rõ ràng: Viết Bug Report với ngôn ngữ dễ hiểu, tránh từ ngữ chuyên môn khó hiểu.
  • Tính đầy đủ: Cung cấp đầy đủ thông tin cần thiết để developer tái tạo lỗi.
  • Tính khách quan: Tập trung vào mô tả vấn đề, không phán xét cách làm việc của nhóm phát triển.

Phân tích lỗi chính xác và viết Bug Report chi tiết không chỉ giúp tăng hiệu quả sửa lỗi mà còn cải thiện sự phối hợp giữa các nhóm trong dự án.

Công cụ hỗ trợ kiểm thử (Testing Tools)

  • Quản lý Test Case: TestRail, Zephyr, qTest.
  • Quản lý lỗi: Jira, Bugzilla, Redmine.
  • Kiểm thử tự động: Selenium, Katalon Studio, Appium.
  • Kiểm thử API: Postman, SoapUI.
  • Kiểm thử hiệu năng: JMeter, LoadRunner.

Kiến thức về kỹ thuật kiểm thử (Testing Techniques)

Kỹ thuật kiểm thử giúp tester thiết kế các kịch bản kiểm thử hiệu quả để phát hiện lỗi trong phần mềm. Các kỹ thuật kiểm thử phổ biến bao gồm:

1. Black-box Testing (Kiểm thử hộp đen)

  • Mô tả:
    Kiểm thử dựa trên yêu cầu và chức năng của phần mềm mà không cần biết về mã nguồn hoặc cấu trúc bên trong. Tester tập trung vào đầu vào và đầu ra của hệ thống.
  • Ví dụ:
    Một trang đăng nhập có các yêu cầu sau:

    • Nhập đúng tên người dùng và mật khẩu thì đăng nhập thành công.
    • Nhập sai thông tin thì hiển thị thông báo lỗi.

    Các trường hợp kiểm thử (Test Cases):

    • Nhập tên người dùng: “user123” và mật khẩu: “password123” → Hệ thống đăng nhập thành công.
    • Nhập tên người dùng: “user123” và mật khẩu: “wrongpass” → Hiển thị lỗi “Sai mật khẩu”.
    • Để trống tên người dùng hoặc mật khẩu → Hiển thị lỗi “Vui lòng nhập đầy đủ thông tin”.

2. White-box Testing (Kiểm thử hộp trắng)

  • Mô tả:
    Kiểm thử dựa trên việc hiểu rõ cấu trúc mã nguồn và logic bên trong. Tester thường là developer hoặc người có kiến thức lập trình.
  • Ví dụ:
    Một hàm kiểm tra số nguyên tố:

    python:
    def is_prime(n):
    if n <= 1:
    return False
    for i in range(2, int(n**0.5) + 1):
    if n % i == 0:
    return False
    return True
    Các trường hợp kiểm thử:
    • Input = 1 → Output = False (đoạn code if n <= 1)
    • Input = 2 → Output = True (đoạn code không vào vòng lặp for)
    • Input = 4 → Output = False (chia hết cho 2)

3. Exploratory Testing (Kiểm thử khám phá)

  • Mô tả:
    Kiểm thử không dựa trên kịch bản kiểm thử được chuẩn bị trước. Tester tự khám phá phần mềm, dựa trên kinh nghiệm và hiểu biết về hệ thống để phát hiện lỗi.
  • Ví dụ:
    Kiểm thử một ứng dụng thương mại điện tử:

    • Tester thử thêm sản phẩm vào giỏ hàng, sau đó thay đổi số lượng sản phẩm thành giá trị lớn bất thường (e.g., 99999).
    • Kiểm tra xem hệ thống xử lý thế nào khi thanh toán với số lượng sản phẩm không khả dụng.

4. Boundary Value Analysis (BVA – Phân tích giá trị biên)

  • Mô tả:
    Kiểm thử các giá trị ở ranh giới (giá trị biên) của phạm vi đầu vào để tìm lỗi. Lỗi thường xảy ra tại các điểm ranh giới hơn là ở giữa phạm vi.
  • Ví dụ:
    Một form yêu cầu nhập số lượng sản phẩm từ 1 đến 100.Các trường hợp kiểm thử:

    • Giá trị thấp nhất: 1 → Hợp lệ.
    • Giá trị cao nhất: 100 → Hợp lệ.
    • Giá trị thấp hơn biên dưới: 0 → Không hợp lệ, hiển thị lỗi “Số lượng không hợp lệ”.
    • Giá trị cao hơn biên trên: 101 → Không hợp lệ, hiển thị lỗi “Số lượng không hợp lệ”.

5. Equivalence Partitioning (EP – Phân vùng tương đương)

  • Mô tả:
    Chia tập dữ liệu đầu vào thành các nhóm (partition) tương đương sao cho nếu một giá trị trong nhóm bị lỗi, toàn bộ nhóm đó cũng có khả năng bị lỗi. Mỗi nhóm chỉ cần một test case đại diện.
  • Ví dụ:
    Một trường nhập tuổi yêu cầu giá trị từ 18 đến 60:Các vùng tương đương:

    • Vùng 1 (Không hợp lệ): Tuổi < 18 (ví dụ: 10).
    • Vùng 2 (Hợp lệ): Tuổi từ 18 đến 60 (ví dụ: 30).
    • Vùng 3 (Không hợp lệ): Tuổi > 60 (ví dụ: 70).

    Các trường hợp kiểm thử:

    • Nhập 10 → Không hợp lệ, hiển thị lỗi “Tuổi phải từ 18 đến 60”.
    • Nhập 30 → Hợp lệ.
    • Nhập 70 → Không hợp lệ, hiển thị lỗi “Tuổi phải từ 18 đến 60”.

Tóm tắt

  • Black-box Testing: Tập trung vào đầu vào/đầu ra, không quan tâm mã nguồn.
  • White-box Testing: Dựa trên hiểu biết về mã nguồn để kiểm thử.
  • Exploratory Testing: Kiểm thử sáng tạo, không có kịch bản cố định.
  • Boundary Value Analysis (BVA): Kiểm thử các giá trị biên để tìm lỗi.
  • Equivalence Partitioning (EP): Phân vùng dữ liệu đầu vào để giảm số lượng test case.

Các kỹ thuật kiểm thử này giúp tester bao quát được nhiều khía cạnh của phần mềm, đảm bảo tính chính xác, hiệu suất và trải nghiệm người dùng.

Kỹ năng bổ trợ (Soft Skills)

  • Kỹ năng giao tiếp: Trao đổi hiệu quả với team phát triển và khách hàng.
  • Kỹ năng phân tích và tư duy logic: Phát hiện vấn đề tiềm ẩn.
  • Tỉ mỉ và cẩn thận: Đảm bảo không bỏ sót lỗi.
  • Làm việc nhóm: Phối hợp tốt với các thành viên trong nhóm QA và Dev.

Nền tảng lập trình cơ bản (Optional)

Kiến thức lập trình cơ bản là một lợi thế lớn đối với tester, đặc biệt khi thực hiện kiểm thử nâng cao hoặc kiểm thử tự động. Tester hiểu về ngôn ngữ lập trình, cơ sở dữ liệu, và API sẽ dễ dàng phát hiện lỗi logic, tương tác hệ thống, và tối ưu hóa hiệu quả kiểm thử.

1. Hiểu các ngôn ngữ lập trình cơ bản (Python, Java, etc.)

  • Lợi ích:
    • Hiểu cách hoạt động của mã nguồn để kiểm thử logic tốt hơn.
    • Tự động hóa kiểm thử bằng cách viết script kiểm thử tự động.
    • Giao tiếp hiệu quả với developer khi cần sửa lỗi hoặc cải thiện hệ thống.
  • Ví dụ sử dụng Python:
    Tạo một script kiểm thử tự động kiểm tra hàm tính tổng trong phần mềm.

    python:
    def test_sum_function():
    result = sum([2, 3, 5])
    expected = 10
    assert result == expected, f”Lỗi: Kết quả là {result}, nhưng mong đợi {expected}”
    test_sum_function()
    Nếu hàm sum() trong phần mềm không trả về đúng giá trị, script này sẽ phát hiện lỗi ngay lập tức.

2. Kiến thức về cơ sở dữ liệu và truy vấn SQL khi test

  • Vai trò:
    • Kiểm tra dữ liệu trong cơ sở dữ liệu có được lưu trữ đúng và nhất quán không.
    • Truy xuất dữ liệu trực tiếp để so sánh với giao diện người dùng.
    • Phát hiện lỗi liên quan đến cơ sở dữ liệu như thiếu dữ liệu, sai dữ liệu, hoặc lỗi khóa ngoại.
  • Ví dụ sử dụng SQL:
    Một ứng dụng quản lý nhân sự yêu cầu hiển thị danh sách nhân viên theo phòng ban. Tester có thể dùng SQL để kiểm tra dữ liệu trực tiếp:

    sql
    SELECT employee_name, department
    FROM employees
    WHERE department = 'Sales';
    • Kết quả truy vấn được so sánh với danh sách hiển thị trên giao diện.
    • Nếu danh sách không khớp, tester có thể báo lỗi về hệ thống hoặc giao diện.

3. Kiến thức cơ bản về API khi test

  • Vai trò:
    • Kiểm thử các giao tiếp giữa các thành phần trong hệ thống qua API.
    • Phát hiện lỗi liên quan đến request/response, thời gian phản hồi, và bảo mật.
    • Đảm bảo rằng API trả về kết quả đúng và dữ liệu nhất quán với yêu cầu.
  • Ví dụ sử dụng API:
    Kiểm thử API đăng nhập bằng công cụ như Postman:

    • Request:
      • URL: https://example.com/api/login
      • Method: POST
      • Body:
        json
        {
        "username": "user123",
        "password": "password123"
        }
    • Response kỳ vọng:
      json
      {
      "status": "success",
      "token": "abc123xyz"
      }
    • Kiểm tra:
      • Nếu status không phải "success", báo lỗi.
      • Nếu thiếu token hoặc token không hợp lệ, kiểm tra mã nguồn API.

Kết hợp các kiến thức để kiểm thử hiệu quả hơn

  • Sử dụng Python hoặc Java để viết các script kiểm thử tự động.
  • Kết hợp SQL để kiểm tra dữ liệu đầu vào/đầu ra trong cơ sở dữ liệu khi thực hiện kiểm thử tích hợp.
  • Sử dụng công cụ như Postman, Swagger, hoặc viết mã kiểm thử API để đảm bảo API hoạt động ổn định.

Ví dụ thực tế:
Một ứng dụng thương mại điện tử cần:

  1. API để thêm sản phẩm vào giỏ hàng: Tester kiểm tra API qua Postman.
  2. Cơ sở dữ liệu để lưu thông tin sản phẩm: Tester dùng SQL để truy xuất dữ liệu kiểm tra.
  3. Script tự động hóa: Dùng Python viết script kiểm tra toàn bộ quy trình thêm sản phẩm, đặt hàng, và thanh toán.

Nếu bạn đang tìm kiếm khóa học tổng quan về các kiến thức căn bản dành cho tester, hãy truy cập link này để đăng ký ngay nhé!

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

All in one