Cách Tạo Api Với Rails (Phần 2) Viết Test Case

--- Bài mới hơn ---

  • Học Kiểm Thử Api Trong 10 Phút
  • Giới Thiệu Tool Swagger Ui
  • Cách Viết Rails Api Document
  • Tôi Đã Viết Api Document Cho Dự Án Như Thế Nào?
  • Viết Api Document Cho Dự Án Sử Dụng Laravel
  • Tiếp theo Cách tạo API với Rails (phần 1)

    Mình sẽ hướng dẫn cách test căn bản cho API mình tạo. Thật ra mà nói thì mình phải viết test trước khi làm nhưng mà để tránh việc gây khó hiểu nên mình xin mạn phép đảo ngược qui trình.

    Để thuận lợi hơn cho việc viết test case mình sử dụng gem rspec-rails

    Test case thuộc tính của model mình đã tạo

    Để dễ dàng hơn trong việc viết test case mình sử dụng thêm 2 gem:

    • Gem factory_girl_rails để tạo fixture data
    • Gem shoulda
    • Nhớ bundle install lại sau khi add gem

    Chúng ta tạo lại model traveler

    rails g model traveler first_name:string last_name:string birthday:datetime gender:string

    Bây giờ cấu trúc app của chúng ta sẽ xuất hiện thêm phần này ( màu xanh lá cây)

    Tạo fixture data

    Vào file sau spec/factories/travelers.rb để kiểm tra lại fixture data mà FactoryGirls đã tạo. Mình sẽ edit lại một tí ( dựa vào gem ffake )

    FactoryGirl.define do factory :traveler do first_name { FFaker::Name.first_name } last_name { FFaker::Name.last_name } birthday { FFaker::IdentificationESCO.expedition_date } gender { FFaker::Gender.maybe } end end

    Test các thuộc tính của model

    Bạn tạo model cho traveler và test cho traveler nên bạn sẽ viết test case tại file traveler_spec.rb

    Vào file sau spec/models/traver_spec.rb để viết test case

    require 'rails_helper' describe Traveler do before { @traveler = FactoryGirl.build(:traveler) } subject { @traveler } it { should respond_to(:first_name) } it { should respond_to(:last_name) } it { should respond_to(:gender) } it { should respond_to(:birthday) } end

    Kiểm tra kết quả của test case

    Tại terminal bạn gõ theo cấu trúc rspec **đường đẫn file muốn test**

    rspec spec/models/traveler_spec.rb

    Test respond trả về khi request api

    • Test response code trả về thành công là 200
    • Test data trả về gồm những thành phần gì

    require 'spec_helper' describe V1::TravelersController do before do @traveler = FactoryGirl.create :traveler get "/v1/travelers", format: :json end it 'return traveler information' do traveler = JSON.parse(response.body, symbolize_names: true).first expect(traveler).to eql @traveler.last_name expect(traveler.to_s.to_i).to eql @traveler.birthday.to_s.to_i end it 'response code' do expect(response).to have_http_status(200) end end

    Run lệnh này để kiểm tra kết quả

    rspec spec/requests/v1/travelers_controller_spec.rb

    Yah! đã xong

    --- Bài cũ hơn ---

  • How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)
  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • Cách Test Api Như Thế Nào?
  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Sử Dụng WordPress Rest Api Toàn Tập
  • Cách Viết Test Case Cho Phần Mềm

    --- Bài mới hơn ---

  • Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử
  • 13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào
  • Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile
  • Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop
  • Bài 4. Kiểm Thử Ứng Dụng Di Động
  • 1. Test Case là gì?

    Các test case giúp hướng dẫn tester thông qua một chuỗi các bước để xác thực xem application có lỗi hay không và hoạt động theo yêu cầu của người dùng hay không. Học cách viết các test case đòi hỏi các kỹ năng viết cơ bản, chú ý đến chi tiết và tester phải hiểu rõ về application được test.

    Thông thường, các test case được viết cho một mô-đun nhất định hoặc một phần của application, được nhóm thành một test suite. Không phải thông thường, một phiên test sẽ bao gồm nhiều test case vì thường sẽ có nhiều hơn một kịch bản cụ thể được test.

    2. Một test case được viết tốt sẽ cho phép bất kỳ tester nào cũng hiểu được và thực hiện được test.

    Khi viết test case, điều quan trọng là bạn phải đặt mình vào vị trí của người dùng và nghĩ về tất cả những điều bạn cho là cần thiết để application hoạt động đúng. Trước tiên là bạn phải nổ lực để viết các test case tốt trước sẽ giúp bạn tiết kiệm thời gian và công sức sau này. Các test case được viết tốt sẽ tạo ra sự khác biệt giữa một application được test tốt và một application được test không tốt.

    Viết các test case – đặc biệt là viết một số lượng lớn trong cùng một lúc – có thể là một công việc tốn thời gian. Ở đây, chúng ta sẽ nghiên cứu một số mẹo về cách viết các test case, cùng với một mẫu của một test case ở cuối bài viết này.

    3. Cách viết test case cho phần mềm:

    3.1. Sử dụng một tiêu đề rõ ràng

    Một test case tốt bắt đầu với một tiêu đề rõ ràng. Như một best practice, tốt nhất là đặt tên cho test case cùng với tên mô-đun mà bạn đang test. Ví dụ: nếu bạn đang test trang login, hãy thêm “ Login successfully.

    Summary: Verify if a user will be able to login with a valid username and valid password.

    Pre-condition: User created an account before.

    Step by Step

    1. Navigate to button 5. Observe

    Expected result: Login successfully when entering username and password are correct

    5. Công cụ để viết test case

    Không có một phương pháp chính xác để viết lại nội dung các test case của bạn, nhưng có nhiều công cụ giúp quá trình viết các test case hiệu quả. Ví dụ, các test case thường được viết trong file excel. Nhiều testing team vẫn lựa chọn phương pháp này. Nó khá linh hoạt, bạn có thể tạo quy trình và phương pháp theo dõi các test case của riêng mình, nhưng nó cũng có thể cực kỳ tốn thời gian và cồng kềnh.

    Một số team sử dụng các công cụ quản lý dự án để ghi lại các test case của họ. Đây là một thay thế tuyệt vời cho excel vì có khả năng share giữa các member trong team

    Với một công cụ dành riêng cho các test case, bạn có thể viết các test case của mình, thực hiện các test của mình, báo cáo kết quả và cộng tác với nhóm của bạn trong mỗi bước của quy trình.

    6. Lợi ích thêm của viết test case

    Việc luyện tập viết test case giúp cho testing team có thể coverage được nhiều case nhất có thể xuyên suốt application, nhưng việc viết các test case thậm chí có tác động hơn đến việc đảm bảo chất lượng và trải nghiệm người dùng.

    • Bạn sẽ tìm thấy những lỗi trong thiết kế sớm hơn
    • Bạn sẽ tìm thấy các vấn đề về khả năng sử dụng
    • Những thành viên mới có thể nhận và test application mà không cần phải đào tạo nhiều
    • Nó có thể tạo sự đồng cảm với người dùng của bạn
    • Nó giúp bạn và những người khác hiểu về product

    Khi viết test case bạn đã đặt bạn vào vị trí của người dùng, điều này tạo nên sự đồng cảm cho những người dùngthực sự sẽ sử dụng product của bạn. Điều này có thể giúp dễ dàng feedback trở lại về thiết kế và quá trình phát triển. Khi bạn viết các test case, bạn sẽ xác định các vấn đề và các điểm cần cải thiện, những vấn đề này có thể được giải quyết trước khi application được đưa lên production.

    Viết test case có nghĩa là bất kỳ thành viên nào mới đều có thể dễ dàng tăng tốc độ làm việc trên dự án mà không cần đào tạo nhiều. Cuối cùng, các test case phác thảo chính xác cách sử dụng product và những gì được mong đợi.

    Một bộ các test case tốt sẽ giúp các thành viên khác trong team có thể share cho người khác để dễ dàng tìm hiểu về dự án. Hãy nghĩ về việc hỗ trợ khách hàng. Team hỗ trợ có thể duyệt các test case để hiểu các tính năng sắp tới sẽ hoạt động như thế nào. Họ có thể sử dụng những test case đó để viết tài liệu kỹ thuật và nội dung trợ giúp.

    7. Phần kết luận

    Viết các test case cần phải thực hành và có hiểu biết về phần mềm đang được test. Các test case được viết tốt có thể làm cho quá trình test của bạn trơn tru hơn và giúp bạn tiết kiệm thời gian trong quá trình sau này. Hãy dùng một công cụ để bạn có thể quản lý và sắp xếp các test case của mình một cách hiệu quả.

    Tham khảo

    All Rights Reserved

    --- Bài cũ hơn ---

  • Lập Trình Ứng Dụng Facebook
  • Cách Tạo Một Facebook Apps Và Lấy App Id, Secret Key
  • Cách Tải Ứng Dụng Trên App Store Cho Iphone
  • Điểm Danh Sự Thành Công Của Các App Bán Hàng Tại Việt Nam 2022
  • Viết App Ngành Bán Hàng Theo Yêu Cầu Tại Hà Nội
  • How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)

    --- Bài mới hơn ---

  • Cách Tạo Api Với Rails (Phần 2) Viết Test Case
  • Học Kiểm Thử Api Trong 10 Phút
  • Giới Thiệu Tool Swagger Ui
  • Cách Viết Rails Api Document
  • Tôi Đã Viết Api Document Cho Dự Án Như Thế Nào?
  • Đầu tiên, chúng ta cùng tìm hiểu:

    A. Testcase là gì?

      Testcase là các trường hợp kiểm thử bao gồm các hành động được thực hiện nhằm kiểm tra từng chức năng của ứng dụng phần mềm có hoạt động đúng theo như mong muốn hay không.

    B. Làm thế nào để có thể viết được Testcase tốt?

    I. Trước khi bắt tay vào việc viết Testcase thì chúng ta cần nhớ những điểm sau đây:

    • Là 1 newbie, mới gia nhập công ty, chúng ta nên hỏi QA leader về template viết Testcase và xin file đó để làm. ( Vì mỗi công ty sẽ có cách viết khác nhau)
    • Viết Testcase nhớ phải bám sát tài liệu yêu cầu ( spec)
    • 1 Testcase ID không quá 15 bước ( step)
    • Trước khi viết Testcase thì ta nên đọc và phân tích tài liệu thật kĩ càng, có chỗ nào chưa hiểu thì đặt Q&A ( Question & Answer) với các member trong team hoặc QA leader hoặc khách hàng để việc viết testcase và test được chính xác và chắc chắn hơn.

    II. Những nguyên tắc để viết TestCase tốt:1. Các trường hợp kiểm thử cần phải đơn giản và minh bạch: (Test Cases need to be simple and transparent)

    • Tạo các testcase đơn giản nhất có thể nhưng vẫn phải rõ ràng và dễ hiểu.

    2. Tạo Testcase với vai trò mình là End -user (người dùng ứng dụng đó)

      Mục tiêu cuối cùng của bất kì dự án phần mềm nào cũng là đáp ứng được tất cả các yêu cầu của khách hàng. Vậy nên đặt vị trí của mình là người dùng thì sẽ thực hiện test được hiệu quả hơn. Chứ không nên có suy nghĩ mình chỉ là QA, chỉ là tester nên mình cứ test theo những gì spec nói thôi. Khi thấy UI nó khó dùng thì ta nên ta feedback lại với PM hay với mọi người để tất cả cùng cân nhắc có nên thay đổi hay không.

    3. Mỗi testcase đều phải được xác định

      Đặt tên ID cho từng testcase để dễ dàng theo dõi

    b, Phân vùng tương đương (Equivalence Partition): Kỹ thuật này phân vùng phạm vi thành các phần / nhóm bằng nhau có xu hướng có cùng hành vi.

    c,Kỹ thuật Bảng quyết định (Decision tables) : Phương pháp này tìm được những tác động khi kết hợp các yếu tốt đầu vào khác nhau và các trạng thái phần mềm mà phải thực hiện đúng các quy tắc nghiệp vụ khác.

    d, Kỹ thuật đoán lỗi (Error Guessing Technique): Đây là đoán / dự đoán lỗi có thể phát sinh trong khi thực hiện test manual.

    5. Review chéo (Peer Review): Sau khi tạo xong Testcase, hãy nhờ đồng nghiệp của bạn review giúp, có thể là QA leader hay QA cùng team để phát hiện ra các case mà bạn còn thiếu hoặc bạn chưa nghĩ tới.

    C. Thực hành viết Testcase:

      Khi join vào dự án, chúng ta được QA Leader giao cho nhiệm vụ là viết Testcase cho màn Login của 1 website với UI như thế này:

    Ta sẽ viết theo format chuẩn như sau:

    Testcase ID Test Scenario Test Steps Test Data Expected Results Actual Results Status

    LG01

    Check UI

    As expected

    Pass

    LG02

    Check button Sign in when user input valid data

    4. User can login successfully and system go to the Homepage

    As expected

    Pass

    LG03

    Check button Sign in when user input invalid data

    4. User cannot login and system shows error message: Email is invalid.

    As expected

    Pass

    Qua 3 ví dụ trên các bạn có thể dễ dàng hơn với việc với Testcase rồi đúng không nào? Tương tự các case trên, các bạn áp dụng Kĩ thuật Bảng quyết định, ta sẽ có thêm các case sau:

    --- Bài cũ hơn ---

  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • Cách Test Api Như Thế Nào?
  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Sử Dụng WordPress Rest Api Toàn Tập
  • Cách Sử Dụng Api WordPress Rest
  • Cách Test Api Như Thế Nào?

    --- Bài mới hơn ---

  • Làm Thế Nào Để Viết Testcase Cho Người Mới Bắt Đầu
  • How To Write Test Cases ( Hướng Dẫn Cách Viết Testcases)
  • Cách Tạo Api Với Rails (Phần 2) Viết Test Case
  • Học Kiểm Thử Api Trong 10 Phút
  • Giới Thiệu Tool Swagger Ui
  • Sau khi đọc xong series “test API với Postman” của mình, các bạn có thể nắm được cái kiến thức cơ bản của API và các chức năng của Postman đem lại. Nhưng cách sắp xếp test và viết Testcase cho API như thế nào thì vẫn có vẻ chưa thông lắm, nên hôm nay mình sẽ viết 1 bài về cách test API như thế nào cho hợp lý.

    Ví dụ: Tôi muốn check API update_profile gồm 2 trường Name và Birthday. Trong đó trường Name là bắt buộc và phải lớn hơn 4 ký tự. Trường Birthday thì không bắt buộc nhập.

    Cách xử lý của Server và Client (có thể không giống với cty bạn):

    1. User vào màn hình Profile, sửa lại 2 trường Name và Birthday.
    2. User ấn vào nút Update Profile (Code ở client sẽ check điều kiện của trường Name, nếu đúng thì submit gửi API, gọi là request, nếu sai sẽ hiện thông báo tương ứng).
    3. Thông tin mới gồm Name và Birthday theo phong bì thư của API cập bến Server.
    4. Server đọc thư và check điều kiện lại 1 lần nữa.
    5. Nếu các thông tin Name và Birthday đều Valid thì 2 thông tin đó được cập nhật vào Database.
    6. Server trả lại thông tin, gọi là response, về lại cho client thông báo rằng nó đã cập nhật thành công.
    7. User nhìn thấy Name và Birthday của mình đã được thay đổi ở màn hình Profile.

    Khi thực hiện test API, chính là việc chúng ta test các bước 4, 5 và 6. Dó đó, với 1 API đơn lẻ, chúng ta sẽ check 2 phần chính:

    – tạm gọi là Syntax Testing (Validate dữ liệu – bước 4 + bước 6)

    – và Funtional Testing (Test business logic – bước 5 và 6).

    Syntax Testing

    Loại này sẽ tập trung vào cái Method check điều kiện: Accept với data đúng và Reject với data sai hay không. Một vài ví dụ:

    • Bỏ trống trường bắt buộc → Trong Response sẽ phải có thông báo lỗi, các thông tin khác không được cập nhật. Server không thực hiện 1 business logic nào cả.
    • Bỏ trống trường không bắt buộc → Không có lỗi gì cả, Server vẫn thực hiện business logic.
    • Điền các thông tin sai kiểu định dạng, ví dụ trường thời gian lại điền chữ → Trong Response sẽ phải có thông báo lỗi…

    Chốt lại: Cái này giống hệt như những trường hợp Validate dữ liệu, chúng ta vẫn hay làm hàng ngày.

    Functional Testing

    Loại này check các Method xử lý dữ liệu và thực hiện 1 chức năng có đúng hay không. Ví dụ:

    • Giá là X và số phần trăm discount là Y thì số tiền phải trả là X*(1-Y) hay không → Nó chính là việc test Method tính toán với các tham số X và Y mà thôi. Việc thực hiện business logic có thể không lưu kết quả vào DB.
    • Việc Update trường Name ở ví dụ ban đầu có được lưu vào DB hay không? → mở DB ra và check kết quả.
    • Yêu cầu trả về thông tin của những user có tên là “Nam” → Vào DB thực hiện câu Query và so sánh với Response xem 2 kết quả có khớp nhau hay ko…

    Test scenarios

    Cuối cùng là ta ghép các API lại với nhau sẽ nó có bị lỗi ở đâu không? Chỗ này chính là những cái Test Suite, gộp nhiều Test Case lại.

    Ví dụ như hình:

    1. Khi sử dụng Postman, hãy để mỗi trường hợp là 1 API riêng biệt, không test đè lên nhau, sau khó kiểm soát và không tạo được test case cho automation.
    2. Để không phải căng mắt check từng response của các trường hợp đơn lẻ, hãy đọc lại bài 9.

    Bài viết dựa trên bài ” API testing best practices ” của Bas Dijkstra

    API Testing với Postman (Phần 12) – Run Test Suites từ Runner

    --- Bài cũ hơn ---

  • Hướng Dẫn Tạo Secure Rest Api Trong
  • Sử Dụng WordPress Rest Api Toàn Tập
  • Cách Sử Dụng Api WordPress Rest
  • Kết Nối Rest Api Bằng Retrofit Trong Android
  • 10 Cách Tốt Nhất Để Viết Các Rest Api Node.js
  • Use Case Và Use Case Testing

    --- Bài mới hơn ---

  • Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
  • Guide Là Gì? Tất Cả Những Khái Niệm Về Guide Bạn Cần Biết
  • Tải Manualslib User Guides Owners Manuals Library Cho Máy Tính Pc Windows Phiên Bản
  • Viết Unit Test Cho Javascript Với Jasmine
  • Tìm Hiểu Về Jestjs, Viết Unit Test Cho Javascript
  • Use case là một tài liệu mô tả từ đầu đến cuối hành vi của hệ thống từ góc nhìn của người sử dụng. Use case mô tả sự tương tác đặc trưng giữa người dùng bên ngoài (Actor) và hệ thống. Mỗi Use case sẽ mô tả cách thức người dùng tương tác với hệ thống để đạt được mục tiêu nào đó. Ngoài ra, Use case cũng xác định trình tự các bước mô tả mọi tương tác giữa người dùng và hệ thống. Tuy nhiên, Use case được định nghĩa theo thuật ngữ của người dùng, không phải của hệ thống, mô tả những gì mà người dùng làm và người dùng nhìn thấy hơn là những gì đầu vào hệ thống mong đợi và đầu ra của hệ thống là gì.

    Những thành phần của Use case

    1. Brief description: Mô tả ngắn gọn giải thích các trường hợp
    2. Actor: Người dùng hệ thống
    3. Precondition: Là các điều kiện được thỏa mãn trước khi bắt đầu thực hiện
    4. Basic flow: hay “Main Scenario” là những luồng cơ bản trong hệ thống. Đó là luồng giao dịch được thực hiện bởi người dùng để hoàn thành mục đích của họ. Khi người dùng tương tác với hệ thống, vì đó là workflow bình thường nên sẽ không có bất kì lỗi nào xảy ra và người dùng sẽ nhận được đầu ra như mong đợi.
    5. Alternate flow: Ngoài workflow thông thường, hệ thống cũng có thể có workflow thay thế. Đây là tương tác ít phổ biến hơn được thực hiện bởi người dùng với hệ thống
    6. Exception flow: Là các luồng ngăn cản người dùng đạt được mục đích của họ
    7. Post conditions: Các điều kiện cần được kiểm tra sau khi hoàn thành.

    Use case diagram

    Use case diagram là một sơ đồ biểu diễn bằng hình ảnh về các hành vi của người dùng trong một hệ thống, cách người dùng tương tác với hệ thống. Nó chỉ ra luồng đi từ hoạt động này sang hoạt động khác trong một hệ thống. Nó đặc biệt quan trọng trong việc xây dựng mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi quyền kiểm soát giữa các đối tượng người dùng (Actors)

    • System: Nó có thể là một trang web, một ứng dụng hoặc bất kỳ component nào khác. Nó thường được biểu diễn bằng một hình chữ nhật. Nó chứa đựng các trường hợp sử dụng (Use case). Người dùng được đặt bên ngoài ‘hình chữ nhật’.
    • Use case: thường được biểu diễn bằng các hình bầu dục, chỉ định các hành động bên trong nó.
    • Actors: là những người sử dụng hệ thống. Nhưng đôi khi nó có thể là các hệ thống khác, người hoặc bất kỳ tổ chức nào khác.

    Use case testing là một kỹ thuật kiểm thử chức năng của kiểm thử hộp đen, vì thế chúng ta sẽ không cần quan tâm đến code. Nó giúp Tester xác định được các kịch bản kiểm thử được thực hiện trên toàn bộ hệ thống từ đầu đến cuối của mỗi giao dịch.

    Một vài đặc điểm của Use case testing

    • Use case testing không phải được thực hiện để quyết định chất lượng của phần mềm
    • Use case testing không đảm bảo bao phủ được toàn bộ ứng dụng của người dùng
    • Dựa trên kết quả kiểm thử từ Use case, chúng ta không thể quyết định việc triển khai môi trường của sản phẩm
    • Nó sẽ giúp tìm ra được những lỗi từ kiểm thử tích hợp

    Ví dụ về Use case testing

    Ví dụ với trường hợp kiểm tra điểm của sinh viên của hệ thống quản lý giáo dục

    Actors: Students, Teacher, Parents

    Pre-condition:

    1. Hệ thống phải có kết nối mạng Internet
    2. Người dùng phải có ‘Student ID’

    Qua bài viết này tôi hi vọng các bạn có thể hiểu rõ hơn về Use case và Use case testing. Viết Use case là một quá trình lặp lại. Bạn chỉ cần dành một chút thời gian để thực hành và cần có kiến thức tốt về hệ thống để thiết kế Use case. Tóm lại, chúng ta có thể sử dụng ‘Use Case testing’ trong một ứng dụng để tìm các liên kết còn thiếu, các yêu cầu không hoàn chỉnh… Tìm chúng và sửa đổi hệ thống sẽ đạt được hiệu quả và chính xác cho hệ thống.

    Nguồn: https://www.softwaretestinghelp.com/use-case-testing/

    All Rights Reserved

    --- Bài cũ hơn ---

  • Use Case Diagram Và 5 Sai Lầm Thường Gặp
  • Bản Vẽ Use Case (Use Case Diagram)
  • Hướng Dẫn Đặc Tả Use Case Quản Lý Khách Sạn 2022
  • Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
  • Hướng Dẫn Viết Unit Test Cho Laravel (P3)
  • Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử

    --- Bài mới hơn ---

  • 13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào
  • Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile
  • Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop
  • Bài 4. Kiểm Thử Ứng Dụng Di Động
  • Checklist Cho Kiểm Thử Ứng Dụng Di Động
  • Câu hỏi thường gặp mà tôi cũng đã thắc mắc là “Cách kiểm thử App dành cho thiết bị di động?” Trong hướng dẫn này, tôi cung cấp Mẫu kiểm thử, Kịch bản / Các trường hợp kiểm tra để thử nghiệm một ứng dụng di động.

    Bạn có thể thực hiện một số hoặc tất cả các Test Cases dựa trên các yêu cầu thử nghiệm trên thiết bị di động của bạn. Các test cases được tổ chức dựa trên các loại thử nghiệm trên thiết bị di động.

    Functional Testing Test Cases

    1. Loại ứng dụng dựa trên việc sử dụng chức năng kinh doanh (ngân hàng, chơi game, xã hội hoặc kinh doanh)
    2. Loại đối tượng mục tiêu (người tiêu dùng, doanh nghiệp, giáo dục)
    3. Kênh phân phối được sử dụng để truyền bá ứng dụng (ví dụ: Apple App Store, Google play, phân phối trực tiếp)

    Các kịch bản thử nghiệm cơ bản nhất trong thử nghiệm chức năng có thể được coi là:

    1. Để xác nhận xem tất cả các trường bắt buộc bắt buộc có đang hoạt động theo yêu cầu hay không.
    2. Để xác nhận rằng các trường bắt buộc được hiển thị trên màn hình theo cách đặc biệt hơn các trường không bắt buộc.
    3. Để xác nhận xem ứng dụng có hoạt động theo yêu cầu bất cứ khi nào ứng dụng bắt đầu / dừng lại hay không.
    4. Để xác nhận xem ứng dụng có chuyển sang chế độ thu nhỏ bất cứ khi nào có cuộc gọi đến không. Để xác nhận điều tương tự, chúng ta cần sử dụng điện thoại thứ hai để gọi điện thoại.
    5. Để xác nhận xem điện thoại có thể lưu trữ, xử lý và nhận SMS bất cứ khi nào ứng dụng đang chạy hay không. Để xác nhận tương tự, chúng ta cần phải sử dụng một điện thoại thứ hai để gửi sms đến thiết bị đang được thử nghiệm và nơi ứng dụng đang thử nghiệm hiện đang chạy.
    6. Để xác thực rằng thiết bị có thể thực hiện các yêu cầu đa nhiệm bất cứ khi nào cần thiết.
    7. Để xác nhận rằng ứng dụng cho phép các tùy chọn mạng xã hội cần thiết như chia sẻ, đăng và điều hướng, v.v.
    8. Để xác nhận rằng ứng dụng hỗ trợ bất kỳ giao dịch cổng thanh toán nào như Visa, Mastercard, Paypal, vv theo yêu cầu của ứng dụng.
    9. Để xác thực rằng các tình huống cuộn trang đang được kích hoạt trong ứng dụng khi cần thiết.
    10. Để xác nhận rằng các lỗi cắt ngắn là hoàn toàn nằm trong khẳ năng giải quyết.
    11. Để xác thực rằng người dùng nhận được thông báo lỗi thích hợp như “Lỗi mạng. Hãy thử sau một thời gian “bất cứ khi nào có bất kỳ lỗi mạng nào.
    12. Để xác thực rằng ứng dụng đã cài đặt cho phép các ứng dụng khác thực hiện thỏa đáng, và nó không ăn vào bộ nhớ của các ứng dụng khác.
    13. Để xác thực rằng ứng dụng sẽ tiếp tục hoạt động sau cùng trong trường hợp khởi động lại hoặc hỏng hệ thống.
    14. Để xác nhận xem việc cài đặt ứng dụng có thể được thực hiện trơn tru miễn là người dùng có các tài nguyên cần thiết và nó không dẫn đến bất kỳ lỗi đáng kể nào.
    15. Để xác nhận rằng ứng dụng thực hiện cơ sở khởi động tự động theo các yêu cầu.
    16. Để xác thực xem ứng dụng có thực hiện theo yêu cầu trong tất cả các phiên bản của thiết bị di động là 2g, 3g và 4g hay không.
    17. Để thực hiện Kiểm tra hồi quy để phát hiện các lỗi phần mềm mới trong các khu vực hiện có của một hệ thống sau khi đã thực hiện các thay đổi đối với chúng. Cũng chạy lại các kiểm tra đã thực hiện trước đó để xác định rằng hành vi của chương trình đã không thay đổi do các thay đổi.
    18. Để xác nhận xem ứng dụng có cung cấp hướng dẫn sử dụng có sẵn cho những người không quen thuộc với ứng dụng hay không.

    Performance Testing Test Cases

    Loại mục tiêu cơ bản của thử nghiệm này là đảm bảo rằng ứng dụng thực hiện chấp nhận được theo các yêu cầu hiệu suất nhất định như quyền truy cập của một số lượng lớn người dùng hoặc loại bỏ phần cơ sở hạ tầng quan trọng như máy chủ cơ sở dữ liệu.

    Các kịch bản thử nghiệm chung cho Kiểm tra hiệu suất trong ứng dụng dành cho thiết bị di động là:

    1. Để xác định xem ứng dụng có thực hiện theo yêu cầu trong các điều kiện tải khác nhau hay không.
    2. Để xác định xem mức độ phủ sóng của mạng hiện tại có thể hỗ trợ ứng dụng ở mức cao nhất, trung bình và tối thiểu hay không.
    3. Để xác định xem thiết lập cấu hình máy khách-máy chủ hiện có có cung cấp mức hiệu suất tối ưu được yêu cầu không.
    4. Để xác định các tắc nghẽn ứng dụng và cơ sở hạ tầng khác nhau ngăn cản ứng dụng thực hiện ở các mức chấp nhận được yêu cầu.
    5. Để xác nhận xem thời gian phản hồi của ứng dụng có đúng với các yêu cầu không.
    6. Để đánh giá sản phẩm và / hoặc phần cứng để xác định xem nó có thể xử lý khối lượng tải dự kiến hay không.
    7. Để đánh giá liệu tuổi thọ pin có thể hỗ trợ ứng dụng thực hiện theo khối lượng tải dự kiến hay không.
    8. Để xác nhận hiệu suất ứng dụng khi mạng được chuyển thành WIFI từ 2G / 3G hoặc ngược lại.
    9. Để xác nhận mỗi chu kỳ CPU được yêu cầu là tối ưu hóa
    10. Để xác nhận rằng mức tiêu thụ pin, rò rỉ bộ nhớ, tài nguyên như GPS, hiệu suất Máy ảnh cũng nằm trong các hướng dẫn bắt buộc.
    11. Để xác nhận tuổi thọ của ứng dụng bất cứ khi nào người dùng tải nghiêm ngặt.
    12. Để xác thực hiệu suất mạng trong khi di chuyển xung quanh với thiết bị.
    13. Để xác nhận hiệu suất của ứng dụng khi chỉ cần có các giai đoạn kết nối liên tục.

    Security Testing Test Cases

    Mục tiêu cơ bản của kiểm tra bảo mật là đảm bảo rằng các yêu cầu về bảo mật mạng và dữ liệu của ứng dụng được đáp ứng theo các nguyên tắc.

    1. Để xác thực rằng ứng dụng có thể chịu được bất kỳ tấn công bạo lực nào, đó là quá trình thử nghiệm và lỗi tự động được sử dụng để đoán tên người dùng, mật khẩu hoặc số thẻ tín dụng của một người.
    2. Để xác nhận xem một ứng dụng có cho phép kẻ tấn công truy cập vào nội dung nhạy cảm hoặc chức năng mà không cần xác thực thích hợp hay không.
    3. Để xác thực rằng ứng dụng có hệ thống bảo vệ mật khẩu mạnh và không cho phép kẻ tấn công lấy, thay đổi hoặc khôi phục mật khẩu của người dùng khác.
    4. Để xác nhận rằng ứng dụng không bị hết hạn phiên.
    5. Để xác định các phụ thuộc động và thực hiện các biện pháp để ngăn chặn bất kỳ kẻ tấn công nào truy cập các lỗ hổng này.
    6. Để xác định và phục hồi từ bất kỳ kịch bản mã không được quản lý nào.
    7. Để đảm bảo các chứng chỉ có được xác nhận hay không, ứng dụng có triển khai Chứng chỉ ghim hay không.
    8. Để bảo vệ ứng dụng và mạng khỏi các cuộc tấn công từ chối dịch vụ.
    9. Để phân tích lưu trữ dữ liệu và yêu cầu xác thực dữ liệu.
    10. Để cho phép quản lý phiên để ngăn chặn người dùng trái phép truy cập thông tin không được yêu cầu.
    11. Để kiểm tra xem mã mật mã có bị hỏng hay không và đảm bảo rằng mã đã được sửa chữa.
    12. Để xác thực xem việc thực hiện logic nghiệp vụ có được bảo mật hay không và không dễ bị tấn công từ bên ngoài.
    13. Để phân tích các tương tác hệ thống tệp, hãy xác định bất kỳ lỗ hổng nào và sửa các vấn đề này.
    14. Để xác thực các trình xử lý giao thức, ví dụ như cố gắng cấu hình lại trang đích mặc định cho ứng dụng bằng một iframe độc ​​hại.
    15. Để bảo vệ chống lại tiêm bên khách hàng độc hại.
    16. Để bảo vệ chống lại tiêm thời gian độc hại.
    17. Để điều tra bộ nhớ đệm của tệp và ngăn chặn mọi khả năng độc hại từ cùng một tệp.
    18. Để ngăn không cho lưu trữ dữ liệu không an toàn trong bộ đệm ẩn của bàn phím của ứng dụng.
    19. Để điều tra cookie và ngăn chặn bất kỳ hành động độc hại nào từ cookie.
    20. Để cung cấp kiểm toán thường xuyên cho phân tích bảo vệ dữ liệu.
    21. Điều tra các tệp được tạo tùy chỉnh và ngăn chặn bất kỳ hành động độc hại nào từ các tệp được tạo tùy chỉnh.
    22. Để ngăn chặn tràn bộ đệm và các trường hợp tham nhũng bộ nhớ. 24.Để phân tích các luồng dữ liệu khác nhau và ngăn ngừa bất kỳ lỗ hổng nào từ các luồng này.

    Usability Testing Test Cases

    Quy trình kiểm tra khả năng sử dụng của ứng dụng Di động được thực hiện để có một ứng dụng bước nhanh chóng và dễ dàng với ít chức năng hơn so với ứng dụng chậm và khó khăn với nhiều tính năng. Mục tiêu chính là để đảm bảo rằng chúng ta sẽ có một giao diện dễ sử dụng, trực quan và tương tự như các ngành được chấp nhận trong ngành được sử dụng rộng rãi.

    1. Để đảm bảo rằng các nút phải có kích thước cần thiết và phù hợp với các ngón tay lớn.
    2. Để đảm bảo rằng các nút được đặt trong cùng một phần của màn hình để tránh nhầm lẫn với người dùng cuối.
    3. Để đảm bảo rằng các biểu tượng là tự nhiên và nhất quán với ứng dụng.
    4. Để đảm bảo rằng các nút có cùng chức năng cũng phải có cùng màu.
    5. Để đảm bảo rằng việc xác thực cho các tiện ích phóng to thu nhỏ và thu nhỏ phải được bật.
    6. Để đảm bảo rằng đầu vào bàn phím có thể được giảm thiểu một cách thích hợp.
    7. Để đảm bảo rằng ứng dụng cung cấp một phương thức để quay lại hoặc hoàn tác một hành động, khi chạm vào mục sai, trong một khoảng thời gian chấp nhận được.
    8. Để đảm bảo rằng các menu ngữ cảnh không bị quá tải vì nó phải được sử dụng nhanh chóng.
    9. Để đảm bảo rằng văn bản được giữ đơn giản và rõ ràng để hiển thị cho người dùng.
    10. Để đảm bảo rằng các câu ngắn và đoạn văn có thể đọc được cho người dùng cuối.
    11. Để đảm bảo rằng kích thước phông chữ đủ lớn để có thể đọc được và không quá lớn hoặc quá nhỏ.
    12. Để xác thực ứng dụng sẽ nhắc người dùng bất cứ khi nào người dùng bắt đầu tải xuống một lượng lớn dữ liệu có thể không có lợi cho hiệu suất ứng dụng.
    13. Để xác thực rằng việc đóng ứng dụng được thực hiện từ các trạng thái khác nhau và xác minh xem nó có mở lại trong cùng một trạng thái hay không.
    14. Để đảm bảo rằng tất cả các chuỗi được chuyển đổi thành các ngôn ngữ thích hợp bất cứ khi nào có sẵn một cơ sở dịch thuật ngôn ngữ.
    15. Để đảm bảo rằng các mục ứng dụng luôn được đồng bộ hóa theo các hành động của người dùng.
    16. Để đảm bảo rằng người dùng cuối được cung cấp hướng dẫn sử dụng giúp người dùng cuối hiểu và vận hành ứng dụng có thể không quen thuộc với các thủ tục của ứng dụng.

    Kiểm tra khả năng sử dụng thường được thực hiện bởi người dùng thủ công vì chỉ có con người mới có thể hiểu được khả năng nhạy cảm và thoải mái của những người dùng khác.

    Compatibility Testing Test Cases

    Thử nghiệm tương thích trên thiết bị di động được thực hiện để đảm bảo rằng thiết bị di động có kích thước, độ phân giải, màn hình, phiên bản và phần cứng khác nhau nên ứng dụng sẽ được kiểm tra trên tất cả các thiết bị để đảm bảo ứng dụng hoạt động như mong muốn.

    1. Để xác nhận giao diện người dùng của ứng dụng là theo kích thước màn hình của thiết bị, không có văn bản / điều khiển nào là vô hình hoặc không thể truy cập được.
    2. Để đảm bảo rằng văn bản có thể đọc được cho tất cả người dùng cho ứng dụng.
    3. Để đảm bảo chức năng gọi / báo thức được kích hoạt bất cứ khi nào ứng dụng đang chạy. Ứng dụng này được thu nhỏ hoặc tạm ngưng trong trường hợp có cuộc gọi và sau đó bất cứ khi nào cuộc gọi dừng lại, ứng dụng sẽ được tiếp tục.

    Recoverability Testing Test Cases

    1. Phục hồi sự cố và gián đoạn giao dịch
    2. Xác nhận tình hình phục hồi ứng dụng hiệu quả sau các tình huống gián đoạn / sự cố bất ngờ.
    3. Xác minh cách ứng dụng xử lý giao dịch trong khi mất điện (tức là pin chết hoặc đột ngột tắt thiết bị thủ công)
    4. Việc xác nhận quá trình mà kết nối bị treo, hệ thống cần phải thiết lập lại để khôi phục dữ liệu bị ảnh hưởng trực tiếp bởi kết nối bị treo.

    Important Checklist

    1. Cài đặt thử nghiệm (cho dù các ứng dụng có thể được cài đặt trong một khoảng thời gian hợp lý và với tiêu chuẩn bắt buộc)
    2. Gỡ cài đặt thử nghiệm (cho dù ứng dụng có thể được gỡ cài đặt trong một khoảng thời gian hợp lý và với tiêu chí bắt buộc)
    3. Các trường hợp kiểm tra mạng (xác nhận xem mạng có hoạt động theo tải yêu cầu hay không, cho dù mạng có thể hỗ trợ tất cả các ứng dụng cần thiết trong quá trình thử nghiệm)
    4. Kiểm tra các phím chưa được ánh xạ
    5. Kiểm tra màn hình splash của ứng dụng
    6. Tiếp tục nhập bàn phím trong quá trình ngắt và các thời điểm khác như sự cố mạng
    7. Các phương thức xử lý việc thoát khỏi ứng dụng
    8. hiệu ứng sạc trong khi một ứng dụng đang chạy trong nền
    9. Pin yếu và nhu cầu hiệu suất cao
    10. Loại bỏ pin trong khi một ứng dụng đang được thực hiện
    11. Tiêu thụ pin theo ứng dụng
    12. Kiểm tra tác dụng phụ của ứng dụng

    Nguồn dịch: https://www.guru99.com/testing-mobile-apps.html

    All Rights Reserved

    --- Bài cũ hơn ---

  • Cách Viết Test Case Cho Phần Mềm
  • Lập Trình Ứng Dụng Facebook
  • Cách Tạo Một Facebook Apps Và Lấy App Id, Secret Key
  • Cách Tải Ứng Dụng Trên App Store Cho Iphone
  • Điểm Danh Sự Thành Công Của Các App Bán Hàng Tại Việt Nam 2022
  • Bắt Đầu Với Api Testing Như Thế Nào ?

    --- Bài mới hơn ---

  • Chia Sẻ: Hướng Dẫn Viết Luận Án
  • Viết Luận Văn: Cấu Trúc Bài Nghiên Cứu (Kỳ 3)
  • Cách Viết Một Bài Báo Khoa Học (Phần 3
  • Hướng Dẫn Đánh Giá Nhân Viên Cuối Năm Theo 3 Bước Cực Kỳ Hiệu Quả
  • 5 Cách Tạo Ứng Dụng Tuyệt Vời Để Tạo App Điện Thoại Không Cần Biết Lập Trình
  • 1 ngày đẹp trời ,chúng ta nhận được thông điệp yêu cầu Test các API của dự án . 1 sự hoang mang không hề nhẹ khi ta chưa bao giờ động vào API , không biết mặt mũi nó như nào, thậm chí còn không biết API là gì, được dùng như thế nào …Vậy làm sao để test được nó ? test như thế nào? Có giống test app / web/…bình thường không nhỉ?….

    Thực ra, khi làm công việc testing , cái chúng ta cần là mindset để đưa ra các testcase hiệu quả , còn việc tiếp cận với 1 loại ứng dụng mới hay 1 lĩnh vực công nghệ mới , có lẽ chỉ là việc học cách thức hoạt động và cách sử dụng nó thôi nhỉ 🙂

    Với API Testing cũng thế , đầu tiên chúng ta cần trả lời các câu hỏi cơ bản : API là gì ? Làm cách nào để Test được nó khi không có giao diện người dùng ?

    Google sẽ trả lời đầy đủ cho chúng ta những câu hỏi này ,chỉ cần chúng ta gõ từ khóa vào để hỏi thôi 😀

    Đầu tiên cần có tài liệu mô tả API (API Document)

    Tiếp nữa là cần cài tool Postman

    2. Tạo bộ Testcase API

    Để test API, chúng mình cũng cần tạo TC theo business flow của app . Mặc dù không có giao diện người dùng , nhưng test API chúng ta cũng cần phải test được tất cả các trường hợp được mô tả trong requirement , chạy được hết 1 flow của app . Như vậy , các viewpoint cho API testcase cũng sẽ bao gồm :

    • business flow
    • token (truyền sai token , token expried , không truyền token , token must be unique,….)
    • Permission
    • truyền ID vào URL (truyền sai ID , không truyền ID , ID must be unique,…)
    • header
    • request / respone
    • …..

    (Các thuật ngữ trong API như : token, authorization, header, method, body , request, respone , status code, message code,…sẽ coi như đã biết, nếu chưa biết có thể google thêm 😀 )

    3.1. Khởi đông postman và tạo collection

    Collection : Không bắt buộc phải tạo, tuy nhiên cũng giống như việc lưu trữ file trên máy tính, nếu chúng ta cứ tạo ra các file mới và vứt bừa bãi trên desktop thì sẽ rất khó để quản lý và theo dõi, cách giải quyết là tạo các folder chứa các file chung mục đích vào với nhau ,rất thuận tiện cho việc quản lý theo thư mục. Collection trên postman cũng tương tự như 1 folder , nó giúp chúng ta lưu trữ các request vào chung 1 chỗ .

    Màn hình Create new collection như trên sẽ được hiển thị

    Sau khi tạo, collection sẽ hiển thị ở bên trái cửa sổ làm việc . Các bạn có thể nhấn vào button để thao tác 1 số setting cho collection

    Share collections: get link để share collection với người khác

    Rename: Đổi tên của collection.

    Add Folder: tạo thêm collection mới bên trong Collection đó.

    Duplicate: nhân đôi collection đang có.

    Export: Xuất collection ra dạng file .json

    Monitor Collection: Dùng để test hiệu năng

    Mock Collection: giúp giả lập các API sử dụng chức năng Example mà postman hỗ trợ. Publish Docs: Tạo ra API Docs định dạng HTML.

    Các bạn có thể import link collection được share bởi người khác để tiếp tục làm việc bằng cách :

    3.2. Khai báo biến trong Collection variable

    Trong quá trình test với các request , có rất nhiều giá trị mà request nào chúng ta cũng phải khai báo (VD như thông tin server , token,…) . Khi thay đổi các thông số này , chúng ta sẽ phải sửa lại ở từng request , việc này rất mất time và to tay 😀 . Thay vì việc liên tục copy và paste mỗi khi tạo request , chúng ta chỉ cần khai báo 1 lần bằng cách Edit collection và chọn Variables để bắt đầu khai báo biến .

    Để khai báo biến token hay bất kỳ 1 giá trị nào khác chúng ta cũng làm tương tự. Giá trị Current values sẽ tự sinh sau khi nhập initial values

    Sau khi biến đã được khai báo, để sử dụng các biến này trong các request , chúng ta gọi biến theo cú pháp {{tên biến}}

    Ví dụ :

    3.3. Gửi request với Postman

    Sau này nếu có thay đổi giá trị của các biến này, chúng ta chỉ việc vào update lại initial values cho nó thôi 🙂

    Để gửi request lên server , chúng ta cần có các thông tin sau :

      Method

    Các method thường được sử dụng :

    • GET :được sử dụng để lấy thông tin từ sever theo URI đã cung cấp (VD : view thông tin user ,…)
    • POST : gửi thông tin tới sever thông qua các biểu mẫu http (VD : Create user ,..)
    • PUT: ghi đè tất cả thông tin của đối tượng với những gì được gửi lên (VD : Update user,..)
    • PATH : ghi đè các thông tin được thay đổi của đối tượng (VD : Update user,…)
    • DELETE : xóa tài nguyên trên server.(VD: Xóa user,…)

    2. URL

    3. Header

    4. Body

    3.4. Truyền Token

    Server sẽ trả về respone , VD như sau :

    Khi gửi request login (get token) , server sẽ trả về 1 token để từ các request sau user phải truyền đúng token vào mới request được. Nó giống như chiếc chìa khóa để vào nhà vậy 🙂

    Token là 1 chuỗi random và unique . Ví dụ request login lần đầu tiên sinh ra 1 token, bạn tiếp tục send request lần nữa, server sẽ trả về 1 token mới không trùng với token trước.

    Vậy chúng ta truyền token vào đâu để gửi request ?

    Có thể truyền token bằng 2 cách như sau :

    Để tự động check response trả về ,chúng ta có thể sử dụng 1 vài dòng code đơn giản . Ví dụ muốn kiểm tra login thành công, chúng ta mở tab Tests trên Postman và viết script sau :

    pm.test(“Status code is 200”, function () { pm.response.to.have.status(200); pm.test(“Status code name has string OK”, function () { pm.response.to.have.status(“OK”);

    Sau khi send request , kết quả sẽ được hiển thị ở phần Test Results như sau :

    Hoặc để kiểm tra login thành công trả về status code :200 , status code name : OK ,chúng ta viết 2 dòng code sau vào phần Tests :

    3.6. Trích xuất data trong response để sử dụng trong các request tiếp theo

    Để kiểm tra trường hợp trả về Fail ,chúng ta sửa expect khác với kết quả thực tế , VD như sau:

    Trong quá trình test , có rất nhiều thông tin từ respone mà chúng ta cần trích xuất để làm input cho request tiếp theo. Việc copy paste gây mất time ,đôi khi copy sai dẫn đến gửi request sai . Không sao, chúng ta có thể làm “smart” hơn bằng cách viết script để trích xuất data mong muốn từ response trả về . Ví dụ muốn lấy token và userID trong respone trả về, ta viết code như sau :

    Đoạn code này có nghĩa là lấy thông tin token , userId và đặt thành biến có tên là “token” , “userID”

    3.7 . Pre-request script

    Để sử dụng các biến này trong request khác, chúng ta gọi biến theo cú pháp {{tên biến}}

    Ví dụ : Lấy thông tin userID và token trong respone trả về để truyền vào URL và header cho request tiếp theo :

    Các bước khi gửi 1 request :

    pm.globals.set(“name”, “User” + parseInt(Math.random().toString(9).substring(2,7)));

    Như vậy chúng ta có thể sử dụng Pre-request script để tạo data(biến) để truyền vào param cho request

    VD: Viết dòng code sau để tạo 1 biến “name” có giá trị là “UserXXXXX” .

    Sau đó truyền biến này vào body để gửi request

    Khi chạy request này ,server sẽ tự động sinh ra user name là giá trị ngẫu nhiên theo đúng cú pháp UserXXXXX

    --- Bài cũ hơn ---

  • Tạo 1 Rest Api Phục Vụ Cho Mục Đích Học Tập Trong 30 Giây
  • Tất Tần Tật Về Restful Apis Và Công Cụ Postman
  • Restful Api Là Gì? Cùng Tìm Hiểu Về Restful Api
  • Restful Api Web Service Là Gì Tạo Restful Api Web Service Trong Java Spring Boot
  • Vấn Đề Nhận Check (Séc) Từ Nước Ngoài Gửi Về Việt Nam?
  • Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile

    --- Bài mới hơn ---

  • Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop
  • Bài 4. Kiểm Thử Ứng Dụng Di Động
  • Checklist Cho Kiểm Thử Ứng Dụng Di Động
  • 5 Cách Viết Ứng Dụng Di Động
  • Hướng Dẫn Viết Ứng Dụng Cho Điện Thoại
  • + App chỉ cho phép đăng nhập bằng số điện thoại di động.

    + Logo không có link, chỉ là cái hình đại diện

    + Số điện thoại là một label

    + Nút đăng nhập là một button

    + Ô nhập số điện thoại là 1 textbox theo quy định của số điện thoại

    Hãy viết test case cho tất cả các trường hợp kiểm thử.

    + Về giao diện, thì cần nhìn tổng quan xem kết quả app thực tế có giống với hình vẽ của mẫu thiết kế hay không.

    + Font chữ, kích thước các nút và logo, cũng như chiều cao, chiều dài textbox và label

    + Điều kiện để đăng nhập thành công là gì?

    + Phương thức đăng nhập được thực hiện như thế nào?

    + Chỉ có cái điện thoại không thì không thể đăng nhập được.

    Vì nếu vậy thì người khác biết số điện thoại của mình là có thể đăng nhập được. Vì vậy mình đoán là sau khi nhập số điện thoại, nó sẽ hiển thị màn hình tiếp theo để nhập mật khẩu. Hoặc hệ thống sẽ gửi một mật khẩu dùng một lần (OTP) đến số điện thoại (vừa được nhập) để đăng nhập. Nếu làm theo cách OTP thì sẽ có rủi ro, người cầm điện thoại của mình sẽ nhập số điện thoại của mình và nhận được sms của mình, và đăng nhập luôn

    + Điều kiện để đăng nhập thất bại là gì?

    Khi đã biết điều kiện để đăng nhập thành công, thì mình sẽ biết làm sao để nó thất bại.

    + Nhập khoảng trắng đầu, giữa và cuối dòng.

    + Số điện thoại bắt đầu 1 chữ số (khác 0)

    + Nhập sđt hợp lệ (10 số)

    + Nhập sđt hợp lệ (11 số)

    1. Sdt nhập cả chữ và số thì sao, ktra security. Khoảng trắng 2 đầu sdt

    2. Test xoay ngang , dọc màn hình.

    3. 2 điện thoại cùng dn 1 số ntn.

    4. Sau dn thành công thì vào màn hình nào.

    5. Môi trg test nữa ví dụ điện thoại nào, hệ điều hành.

    6. Có kết nối, k kết nối mạng thì sao

    7. Đăng nhập vào nhận mã otp xong thì điện thoại sụt nguồn, tắt máy, mất mạng sao …

    8. Đăng nhập có cuộc gọi đến thì sao

    9. Đăng nhập vào ok, chưa thoát ra, lại đăng nhập vào bằng 1 điện thoại khác thì hệ thống xlys ntn

    10. Copy ký tự đặc biệt, ký tự chữ rồi paste vào có được không

    11. Trường hợp dùng bảng mã khác unicode thì nhập số có oki ko

    12. Nếu app này được cài đặt nhiều ngôn ngữ thì khi chuyển đổi giữa các ngôn ngữ có bị lỗi hay không

    --- Bài cũ hơn ---

  • 13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào
  • Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử
  • Cách Viết Test Case Cho Phần Mềm
  • Lập Trình Ứng Dụng Facebook
  • Cách Tạo Một Facebook Apps Và Lấy App Id, Secret Key
  • Mẫu Test Cases Để Kiểm Tra Web Và Ứng Dụng Desktop

    --- Bài mới hơn ---

  • Bài 4. Kiểm Thử Ứng Dụng Di Động
  • Checklist Cho Kiểm Thử Ứng Dụng Di Động
  • 5 Cách Viết Ứng Dụng Di Động
  • Hướng Dẫn Viết Ứng Dụng Cho Điện Thoại
  • Viết Ứng Dụng Di Động Phong Cách Hướng Đến 2022
  • Đây là một danh sách kiểm thử cho các ứng dụng web và máy tính để bàn.Mục tiêu của bài viết là để chia sẻ một trong những danh sách kiểm thử toàn diện nhất.

    Tầm quan trọng của việc sử dụng checklist cho việc kiểm thử

    • Duy trì một kho lưu trữ tiêu chuẩn của các trường hợp thử nghiệm tái sử dụng cho các ứng dụng của bạn sẽ đảm bảo các lỗi phổ biến nhất sẽ bị bắt một cách nhanh chóng hơn.
    • Checklist giúp nhanh chóng hoàn tất viết test case các phiên bản mới của ứng dụng.
    • Sử dụng lại test case giúp tiết kiệm tiền về nguồn lực để viết kiểm tra lặp đi lặp lại.
    • Các trường hợp kiểm tra quan trọng sẽ được đảm bảo luôn luôn làm cho nó gần như không thể quên.
    • Kiểm tra checklist có thể bởi dev để đảm bảo các vấn đề phổ biến nhất được cố định trong giai đoạn phát triển bản thân.
    1. Thực thi các kịch bản với vai trò người dùng khác nhau ví dụ như người dùng admin, người dùng khách, …
    2. Đối với các ứng dụng web những tình huống này có thể được thử nghiệm trên nhiều trình duyệt như IE, FF, Chrome, và Safari với các phiên bản của khách hàng đã được phê duyệt.
    3. Thử nghiệm với độ phân giải màn hình khác nhau như 1024 x 768, 1280 x 1024, …
    4. Ứng dụng nên được thử nghiệm trên nhiều màn hình như màn hình LCD, CRT, điện thoại xách tay, máy tính bảng, và di động.
    5. Ứng dụng thử nghiệm trên các nền tảng khác nhau như các hệ điều hành Windows, Mac, Linux.

    Giả định: Giả sử rằng ứng dụng của bạn hỗ trợ chức năng sau:

    • Các forms với các trường khác nhau.
    • Cửa sổ con.
    • Ứng dụng tương tác với cơ sở dữ liệu.
    • Tiêu chí tìm kiếm bộ lọc khác nhau và hiển thị kết quả.
    • Upload hình ảnh.
    • Chức năng gửi email.
    • Chức năng xuất dữ liệu.

    Kịch bản thử nghiệm chung

    GUI và khả năng sử dụng các kịch bản thử nghiệm

    1. Tất cả các mục trên trang (ví dụ như hộp văn bản, tùy chọn radio, danh sách thả xuống) nên được sắp xếp đúng.
    2. Các giá trị số nên được quyền biện minh trừ khi có quy định khác.
    3. Đủ không gian cần được cung cấp giữa các trường nhãn, cột, dòng, thông báo lỗi, …
    4. Thanh Scroll nên được kích hoạt khi cần thiết .
    5. Kích thước font chữ, phong cách và màu sắc cho dòng tiêu đề, mô tả văn bản, nhãn, dữ liệu infiled, và thông tin điện lưới nên được tiêu chuẩn theo quy định tại SRS.
    6. Mô tả hộp văn bản nên đa đường.
    7. Trường Disabled nên được chuyển sang màu xám và người sử dụng không nên thiết lập tập trung vào các trường này.
    8. Sau khi bấm vào bất kỳ trường văn bản đầu vào, con chuột mũi tên con trỏ nên được thay đổi để trỏ.
    9. Người dùng không nên gõ vào thả xuống chọn danh sách.

      10 Thông tin lấp đầy bởi người sử dụng sẽ được giữ nguyên khi có thông báo lỗi trên trang submit. Người sử dụng sẽ nộp submit lại bằng cách sửa chữa các lỗi.

    10. Kiểm tra nếu trường nhãn thích hợp được sử dụng trong các thông báo lỗi.
    11. Giá trị trường Dropdown sẽ được hiển thị trong định nghĩa thứ tự sắp xếp.
    12. Tab và Shift + Tab nên hoạt động đúng.
    13. Tùy chọn mặc định radio nên được lựa chọn trước khi load trang.
    14. Dòng mức cụ thể và trang trợ giúp thông điệp nên có sẵn.
    15. Kiểm tra nếu các trường chính xác đã được nhấn mạnh trong trường hợp lỗi.
    16. Kiểm tra xem tùy chọn danh sách thả xuống là có thể đọc được và không phải cắt ngắn nhờ vào trường kích thước giới hạn.
    17. Tất cả các nút trên trang nên có thể truy cập bằng phím tắt và người dùng sẽ có thể thực hiện tất cả các hoạt động sử dụng bàn phím.
    18. Kiểm tra tất cả các hình ảnh bị broken.
    19. Kiểm tra tất cả các trang liên kết hỏng.
    20. Tất cả các trang nên có tiêu đề.
    21. Thông báo xác nhận sẽ được hiển thị trước khi thực hiện bất kỳ bản cập nhật hoặc xóa các hoạt động.
    22. Giờ glass sẽ được hiển thị khi ứng dụng đang bận.
    23. Trang văn bản nên để biện minh.
    24. Người sử dụng nên có thể chỉ chọn một tùy chọn radio và bất kỳ sự kết hợp với hộp kiểm tra.

    Kịch bản thử nghiệm cho bộ lọc tiêu chuẩn

    1. Người sử dụng sẽ có thể lọc kết quả sử dụng tất cả các thông số trên trang chức năng tìm kiếm.
    2. Tinh chỉnh nên tải trang tìm kiếm với tất cả người sử dụng lựa chọn các thông số tìm kiếm.
    3. Khi có ít nhất một trong các tiêu chí lọc là cần thiết để thực hiện các hoạt động tìm kiếm, đảm bảo đúng thông báo lỗi được hiển thị khi người dùng gửi trang mà không chọn bất kỳ tiêu chí lọc.
    4. Khi có ít nhất một trong các tiêu chí lọc lựa chọn không phải là người sử dụng bắt buộc sẽ có thể gửi trang và mặc định tiêu chí tìm kiếm nên được sử dụng để truy vấn kết quả.
    5. Tin nhắn xác nhận đúng sẽ được hiển thị cho các giá trị hợp lệ cho tiêu chí lọc.

    Kịch bản thử nghiệm cho lưới kết quả

    Kịch bản thử nghiệm cho một cửa sổ

    1. Kiểm tra xem kích thước cửa sổ mặc định là chính xác.
    2. Kiểm tra xem kích thước cửa sổ con là đúng.
    3. Kiểm tra nếu có bất kỳ trường trên trang tập trung mặc định (trọng tâm cần được thiết lập trên trường input đầu tiên của màn hình).
    4. Kiểm tra xem cửa sổ con đang nhận được đóng vào đóng cửa sổ cha / mở window.
    5. Nếu cửa sổ con được mở ra, người sử dụng không nên sử dụng hoặc cập nhật bất kỳ trường trên nền hoặc cửa sổ cha.
    6. Kiểm tra cửa sổ tối thiểu, tối đa và chức năng đóng cửa sổ.
    7. Kiểm tra nếu cửa sổ khá lớn.
    8. Kiểm tra chức năng thanh cuộn cho cửa sổ cha và con.
    9. Kiểm tra hủy bỏ chức năng của nút cho cửa sổ con.

    Cơ sở dữ liệu kiểm tra kịch bản thử nghiệm

    Kịch bản thử nghiệm cho hình ảnh tính năng tải lên

    (Cũng được áp dụng cho các chức năng upload file khác)

    Kịch bản thử nghiệm cho việc gửi email

    1. Gửi email mẫu nên sử dụng CSS tiêu chuẩn cho tất cả các email .
    2. Địa chỉ Email phải được xác nhận trước khi gửi email.
    3. Ký tự đặc biệt trong trường email nên được xử lý đúng cách.
    4. Ký tự ngôn ngữ cụ thể (ví dụ như ký tự ngôn ngữ Nga, Trung, Đức) phải được xử lý đúng cách trong trường email.
    5. Tiêu đề email không nên để trống.
    6. Trường placehoder được sử dụng trong mẫu email phải thay thế bằng giá trị thực tế ví dụ như {FirstName} {Lastname} nên được thay thế với các cá thể đầu tiên và cuối cùng tên đúng cho tất cả người nhận.
    7. Nếu báo cáo với các giá trị động mới có trong nội dung email, dữ liệu báo cáo phải được tính toán một cách chính xác.
    8. Email tên người gửi không nên được trống.
    9. Email nên được kiểm tra trong các khách hàng email khác như Outlook, Gmail, Hotmail, Yahoo! Mail, …
    10. Kiểm tra chức năng gửi email sử dụng TO, CC và BCC.
    11. Kiểm tra văn bản email thô.
    12. Kiểm tra HTML định dạng email.

      13 . Kiểm tra tiêu đề email và footer cho logo của công ty, chính sách bảo mật và các liên kết khác.

    13. Kiểm tra email với file đính kèm.
    14. Kiểm tra chức năng gửi email tới đơn, đa hoặc phân phối người nhận danh sách.
    15. Kiểm tra nếu trả lời vào địa chỉ email là chính xác.
    16. Kiểm tra gửi khối lượng lớn các email.

    Kịch bản thử nghiệm cho chức năng Excel Export

    1. Tập tin nên được xuất trong hợp phần mở rộng tập tin.
    2. Tên tập tin cho tập tin Excel được xuất nên được theo các tiêu chuẩn, ví dụ như nếu tên tập tin được sử dụng dấu thời gian, nó nên được thay thế đúng vào thời điểm thực tế tại thời điểm xuất các tập tin
    3. Kiểm tra định dạng ngày nếu tập tin Excel xuất chứa các cột ngày.
    4. Kiểm tra số định dạng cho giá trị số hoặc tiền tệ. Định dạng nên được giống như hiển thị trên trang.
    5. Tệp tin xuất nên có cột với tên cột thích hợp.
    6. Mặc định trang phân loại phải được tiến hành trong tập tin xuất như vậy.
    7. Dữ liệu tập tin Excel nên được định dạng đúng với tiêu đề và văn bản footer, ngày, số trang, … giá trị cho tất cả các trang.
    8. Kiểm tra xem dữ liệu hiển thị trên trang và tập tin Excel xuất là như nhau.
    9. Chức năng xuất khi pagination được kích hoạt.
    10. Kiểm tra nếu nút xuất là hiển thị biểu tượng thích hợp theo loại tập tin xuất biểu tượng như file Excel là xls.
    11. Kiểm tra chức năng xuất cho các tập tin có kích thước rất lớn.
    12. Kiểm tra chức năng xuất cho các trang có chứa ký tự đặc biệt. Kiểm tra xem các ký tự đặc biệt được xuất đúng trong tập tin Excel.

    Hiệu suất kịch bản thử nghiệm

    1. Kiểm tra thời gian tải trang nằm trong phạm vi chấp nhận được.
    2. Kiểm tra tải trang trên các kết nối chậm.
    3. Kiểm tra thời gian phản ứng đối với bất kỳ hành động dưới ánh sáng, bình thường, trung bình và điều kiện tải nặng.
    4. Kiểm tra thực hiện các thủ tục cơ sở dữ liệu được lưu trữ và gây nên.
    5. Kiểm tra thời gian thực hiện truy vấn cơ sở dữ liệu.
    6. Kiểm tra tải trọng của ứng dụng.
    7. Kiểm tra thử nghiệm stress của ứng dụng.
    8. Kiểm tra CPU và bộ nhớ sử dụng trong điều kiện tải cao điểm.

    An ninh kiểm tra kịch bản thử nghiệm

    Bài viết này cố gắng để đảm bảo tất cả các kịch bản thử nghiệm tiêu chuẩn cho các chức năng ứng dụng web và máy tính để bàn. Nhưng đây không phải là một danh sách kiểm tra đầy đủ. Với các dự án khác nhau có danh sách kiểm tra thử nghiệm của riêng mình dựa trên kinh nghiệm của tester.

    --- Bài cũ hơn ---

  • Viết Test Case Cho Phần Đăng Nhập Của Một App Mobile
  • 13 Mẹo Để Viết Testcase Cho Bất Kỳ Ứng Dụng Nào
  • Mobile Apps Testing: Mẫu Test Case & Kịch Bản Kiểm Thử
  • Cách Viết Test Case Cho Phần Mềm
  • Lập Trình Ứng Dụng Facebook
  • Cách Viết Test Report (Part 1)

    --- Bài mới hơn ---

  • Cách Viết Bài Review Sản Phẩm Hay (Viết Ra Tiền
  • Hướng Dẫn Cách Viết Bài Review Sản Phẩm Từ A
  • Hướng Dẫn Cách Viết Bài Review Hay Và Thu Hút Nhiều Người Đọc
  • Hướng Dẫn Cách Viết Bài Review Chất Lượng Kiếm Tiền Trên Mạng
  • Review Là Gì ? Cách Để Viết Bài Review Xuất Sắc Nhất
  • Hôm nay chúng ta sẽ tìm ra câu trả lời cho những câu hỏi: Làm thế nào để viết Test Report? Tại sao nên viết Test Report? Test Report được chuẩn bị cho ai? Bài viết này sẽ hữu ích cho những chuyên gia không chỉ trong lĩnh vực kiểm thử phần mềm mà còn từ những lĩnh vực khác như Project Managers, Product Owners, Developers …

    Trong phần này mình sẽ làm rõ về những câu hỏi sau:

    1. Test Report là gì, và tại sau chúng ta nên viết Test Report?
    2. Test Report được chuẩn bị cho ai?
    3. Ví dụ về thời gian làm Test Report (báo cáo kiểm thử)

    1. Test Report là gì, và tại sau chúng ta nên viết Test Report?

    Report (báo cáo) là mẫu tài liệu quan trọng và rút gọn về các thông tin thay đổi từ người thực thi tới khách hàng. Nhắc lại về quy trình kiểm thử phần mềm, chúng ta có những trạng thái sau:

    • Project creating (Khởi tạo dự án)
    • Test Plan pparing Execute testing (Chuẩn bị kế hoạch kiểm thử)
    • Test Case execution (Thực thi test case)
    • Finding bugs (Tìm lỗi)
    • Making reports (Làm báo cáo)

    Như bạn có thể thấy các bản báo cáo được chuẩn bị có thể chứa các thông tin về hoạt động từ các trạng thái trước. Nên chúng ta có thể xác định Test Report như một tài liệu chứa các thông tin về các hành động đã được thực thi (Chạy test cases, phát hiện lỗi, thời gian bỏ ra…) và các kết quả của quá trình thực thi này (test case không thành công/thành công, số lượng bugs và crashes…)

    Chúng ta có thật sự cần chuẩn bị Test Reports? Không nghi ngờ gì nữa câu trả lời là “Có”. Thực tế có ít nhất 3 lý do cho việc chuẩn bị Test Reports:

    1. Bản Test Report tốt sẽ cho phép chúng ta (và không chỉ riêng chúng ta) có thể đánh giá trạng thái hiện tại của dự án cũng như chất lượng của sản phẩm.
    2. Có khả năng đưa ra những quyết định sáng suốt nếu cần thiết.
    3. Test Report có thể là tài liệu cuối cùng xác định việc sản phẩm đã sẵn sàng phát hành hay chưa.

    Chất lượng và tính minh bạch là điều kiện bắt tiên quyết để tạo ra một Test Report. Bởi vì đấy là chìa khóa cho khách hàng đánh giá được giá trị công việc của chúng ta

    2. Test Report được chuẩn bị cho ai?

    Khi tạo một bản báo cáo, bạn phải hoàn toàn hiểu rõ bản báo cáo được viết cho ai, ai sẽ đọc nó. Dựa vào mức độ ưu tiên về người đọc mục tiêu, chúng ta cần phải xác định những thông tin nào bản báo cáo nên có. Có thể phân biệt được 3 nhóm mục tiêu sau:

    1. Product Managers Họ tập trung vào việc thực thi theo các mốc deadline (ngày kết thúc), kết quả kiểm thử thuần túy mà không quan tâm đến các chi tiết kỹ thuật và thông số tổng thế.

    2. Business Users (Product Owners) Như một điều luật, đây là những người đưa ra quyết định trong việc kết thúc kiểm thử. Họ cũng xác định chất lượng công việc đã hoàn thành. Điều quan trọng nhất với họ là kết quả cuối cùng, được chuyển thành dạng ngắn và rút gọn nhất (CÓ hay KHÔNG). Thông tin nên được trình bày dưới dạng trực quan (đồ thị, sơ đồ). Điều quan trọng là phải có ý kiến chuyên gia về khả năng phát hành sản phẩm mà không đi sâu vào chi tiết.

    Tất nhiên, hầu như không thể viết một báo cáo mà sẽ phù hợp với tất cả các nhóm. Đó là lý do tại sao phải chắc chắn xác định đối tượng mục tiêu trước khi chuẩn bị một báo cáo kiểm thử. Tùy thuộc vào nó, nội dung sẽ rất khác nhau về cấu trúc và chứa các chi tiết khác nhau cần thiết cho nhóm cụ thể.

    3. Ví dụ về thời gian báo cáo kiểm thử

    Test Report ở khoảng thời gian giữa dự án nên thể hiển tiến độ công việc. Tiến độ không thay đổi nhưng linh động và được xác định bằng cách so sánh trạng thái của dự án ở các khoảng thời gian khác nhau (ngày, tuần, tháng). Trên thực tế, tiến độ là tập hợp các số liệu nhằm hiểu rõ các giai đoạn của dự án như thế nào.

    Số liệu được tạo ra riêng biệt cho từng dự án, dựa trên các mục tiêu đã được xác định cho việc kiểm thử thành công. Chúng cho phép tạo ra sự so sánh tổng thế cho dự án một cách đủ nhanh.

    Phiên bản của Test Report là một điều quan trọng khác và thường được dùng cho các báo cáo ở khoảng thời gian giữa dự án. Nó mô tả các nhiệm vụ được thực hiện bởi đội ngũ kiểm thử cho một phiên bản cụ thể của sản phẩm.

    Bản báo cáo cuối cùng cho thấy một cái nhìn chung về công việc đã thực hiện (trong bối cảnh các thước đo chỉ số đã được thiết lập) và sự tiến triển của sản phẩm. Ngoài ra bạn cần phải cung cấp thông tin đầy đủ về trạng thái của sản phẩm tại thời điểm đó ( số lượng lỗi chưa sửa, liệu sản phẩm đã được kiểm thử đầy đủ chưa, hay là cần thêm chu kỳ kiểm thử nữa, độ sẵn sàng của sản phẩm cho việc phát hành)…

    Trong bài viết sau về Test Report, mình sẽ nói chi tiết về nội dung của 1 Test Report, các gợi ý về các viết Test Report kèm theo ví dụ.

    Tài Liệu Tham Khảo:

    https://geteasyqa.com/qa/write-test-report/

    Link phần 2: https://viblo.asia/p/cach-viet-test-report-part-2-end-LzD5dDYY5jY

    All Rights Reserved

    --- Bài cũ hơn ---

  • Hướng Dẫn Cách Trình Bày Report Tiếng Anh
  • Tuyển Dụng Cộng Tác Viên Viết Bài Review Sách 2022
  • 4 Tips Cần Nhớ Để Có Một Bài Review Sách Xuất Sắc Nhất
  • Hướng Dẫn Cách Review Sách Sáng Tạo, Cuốn Hút
  • 3 Cách Review Sách Độc Đáo Không Cần Viết
  • Web hay
  • Links hay
  • Push
  • Chủ đề top 10
  • Chủ đề top 20
  • Chủ đề top 30
  • Chủ đề top 40
  • Chủ đề top 50
  • Chủ đề top 60
  • Chủ đề top 70
  • Chủ đề top 80
  • Chủ đề top 90
  • Chủ đề top 100
  • Bài viết top 10
  • Bài viết top 20
  • Bài viết top 30
  • Bài viết top 40
  • Bài viết top 50
  • Bài viết top 60
  • Bài viết top 70
  • Bài viết top 80
  • Bài viết top 90
  • Bài viết top 100
  • CẦM ĐỒ TẠI F88
    15 PHÚT DUYỆT
    NHẬN TIỀN NGAY

    VAY TIỀN NHANH
    LÊN ĐẾN 10 TRIỆU
    CHỈ CẦN CMND

    ×