Cách Viết Test Case Api / Top 13 Xem Nhiều Nhất & Mới Nhất 10/2023 # Top Trend

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[:first_name]).to eql @traveler.first_name expect(traveler[:last_name]).to eql @traveler.last_name expect(traveler[:gender]).to eql @traveler.gender expect(traveler[:birthday].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

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 Page]” vào trong tiêu đề của test case. Trong một số trường hợp, nếu công cụ bạn đang sử dụng chưa làm điều này, thì bạn cũng nên thêm vào một mã định danh duy nhất trong tiêu đề của test case, khi đó, định danh có thể được tham chiếu thay vì tiêu đề dài

3.2. Phải có một mô tả rõ ràng

Mô tả sẽ cho tester biết họ sẽ test cái gì. Đôi khi phần này cũng có thể bao gồm các thông tin khác như môi trường test, dữ liệu test và các điều kiện tiên quyết/giả định. Một mô tả phải dễ đọc và ngay lập tức truyền đạt mục tiêu test.

3.3. Nên chứa giả định và điều kiện tiên quyết

Bạn nên có một giả định bất kỳ nào áp dụng cho test và bất kỳ điều kiện tiên quyết nào phải được đáp ứng trước khi test được thực hiện. Thông tin này có thể bao gồm trang nào người dùng nên bắt đầu test, phụ thuộc vào môi trường test và bất kỳ yêu cầu thiết lập đặc biệt nào phải được thực hiện trước khi chạy test. Thông tin này cũng giúp giữ cho các bước test ngắn gọn và súc tích.

3.4. Giữ các bước test rõ ràng và súc tích

Các test case nên đơn giản. Hãy nhớ rằng, người viết test case có thể không phải là người thực hiện chính bài test đó. Các bước test phải bao gồm dữ liệu và thông tin cần thiết về cách thực hiện test. Đây có lẽ là phần quan trọng nhất của một test case. Giữ phần này rõ ràng và súc tích, nhưng đừng bỏ qua bất kỳ chi tiết cần thiết nào. Viết một test case để bất cứ ai cũng có thể xem và thực hiện test.

3.5. Phải chứa kết quả mong đợi

Kết quả mong đợi sẽ cho tester biết họ nên nhận được gì khi thực hiện các bước test. Đây là cách tester xác định xem test case pass hay fail.

3.6. Nên viết test case có thể tái sử dụng được

Một test case tốt có thể tái sử dụng và có giá trị lâu dài cho testing team của bạn. Khi viết một test case, hãy ghi nhớ điều này. Bạn có thể tiết kiệm thời gian xuống bằng cách sử dụng lại test case thay vì viết lại.

4. Mẫu của một test case

Title: [Login Page] 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 [Login] page 2. Input username is correct 3. Input password is correct 4. Tap on [Login] 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

Đầ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:

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):

User vào màn hình Profile, sửa lại 2 trường Name và Birthday.

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

Thông tin mới gồm Name và Birthday theo phong bì thư của API cập bến Server.

Server đọc thư và check điều kiện lại 1 lần nữa.

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.

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.

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:

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.

Để 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

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

Brief description: Mô tả ngắn gọn giải thích các trường hợp

Actor: Người dùng hệ thống

Precondition: Là các điều kiện được thỏa mãn trước khi bắt đầu thực hiện

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.

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

Exception flow: Là các luồng ngăn cản người dùng đạt được mục đích của họ

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:

Hệ thống phải có kết nối mạng Internet

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