Thử nghiệm tự động cho REST Api [đã đóng]


84

Tôi muốn viết một bộ thử nghiệm tự động cho REST API. Khi chúng tôi hoàn thành các dịch vụ mới, chúng tôi muốn kiểm tra để đảm bảo rằng tất cả các dịch vụ đã tạo trước đó đang hoạt động như mong đợi. Bất kỳ đề xuất nào về các công cụ tốt nhất để sử dụng để thực hiện điều này? Tôi biết các công cụ như Apigee tồn tại cho phép bạn kiểm tra 1 dịch vụ tại một thời điểm, nhưng chúng tôi muốn có một cách để kiểm tra tất cả các dịch vụ chỉ bằng một nút bấm.


2
Bạn có thể thử vREST . Nó có cả hai, thử nghiệm đơn vị và chế độ giả.
Jangid

1
JMeter là công cụ tốt nhất để kiểm tra REST API - Thêm nhận xét này cho những người đang tìm kiếm một số bước chi tiết để kiểm tra REST API bằng JMeter. testautomationguru.com/how-to-test-rest-api-using-jmeter
vins

Không có gì nhịp đập Frisby - Chỉ cần hoàn hảo và công cụ mạnh mẽ nhất để thử nghiệm REST API
Piyush Chordia

2
JMeter là quá mức cần thiết, chưa kể có giao diện người dùng khủng khiếp, chỉ để kiểm tra chức năng cơ bản của một api REST. Nó có nghĩa là để kiểm tra hiệu suất / tải.
Kevin M

2
JMeter tập trung nhiều hơn vào kiểm tra tải, có lẽ bạn nên kiểm tra 12 Công cụ kiểm tra dịch vụ web tuyệt vời để tìm ra tùy chọn tốt nhất. Một số công cụ từ danh sách này, chẳng hạn như SOAPUI hoặc HttpMaster , có hỗ trợ tự động hóa khá tốt cho các điểm cuối API REST.
Joxi

Câu trả lời:


36

Trong công việc của tôi, chúng tôi gần đây đã tập hợp một số bộ thử nghiệm được viết bằng Java để kiểm tra một số API RESTful mà chúng tôi đã xây dựng. Dịch vụ của chúng tôi có thể gọi các API RESTful khác mà chúng phụ thuộc vào. Chúng tôi chia nó thành hai dãy phòng.


  • Suite 1 - Thử nghiệm từng dịch vụ một cách riêng biệt
    • Mô phỏng bất kỳ dịch vụ ngang hàng nào mà API phụ thuộc vào việc sử dụng restito . Các lựa chọn thay thế khác bao gồm trình điều khiển nghỉ ngơi , wiremockbetamax .
    • Kiểm tra dịch vụ chúng tôi đang thử nghiệm và tất cả các mô hình đều chạy trong một JVM duy nhất
    • Ra mắt dịch vụ ở Jetty

Tôi chắc chắn sẽ khuyên bạn nên làm điều này. Nó đã hoạt động thực sự tốt cho chúng tôi. Những lợi thế chính là:

  • Các dịch vụ ngang hàng được làm giả, vì vậy bạn không cần thực hiện bất kỳ thiết lập dữ liệu phức tạp nào. Trước mỗi bài kiểm tra, bạn chỉ cần sử dụng restito để xác định cách bạn muốn các dịch vụ ngang hàng hoạt động, giống như cách bạn làm với các lớp trong bài kiểm tra đơn vị với Mockito.
  • Bạn có thể hỏi các dịch vụ ngang hàng bị chế nhạo nếu họ được gọi. Bạn không thể thực hiện những khẳng định này một cách dễ dàng với các dịch vụ ngang hàng thực.
  • Bộ ứng dụng này có tốc độ cực nhanh vì các dịch vụ chế nhạo phục vụ các phản hồi trong bộ nhớ được soạn trước. Vì vậy, chúng tôi có thể có được mức độ phủ sóng tốt mà không cần bộ phần mềm cần một thời gian để chạy.
  • Bộ phần mềm này đáng tin cậy và có thể lặp lại vì nó được tách biệt trong JVM của riêng nó, vì vậy không cần phải lo lắng về việc các bộ / người khác liên quan đến môi trường chia sẻ cùng lúc bộ đang chạy và khiến các thử nghiệm không thành công.

  • Suite 2 - Full End to End
    • Suite chạy trên một môi trường đầy đủ được triển khai trên nhiều máy
    • API được triển khai trên Tomcat trong môi trường
    • Các dịch vụ ngang hàng được triển khai đầy đủ 'như thật'

Bộ phần mềm này yêu cầu chúng tôi thiết lập dữ liệu trong các dịch vụ ngang hàng, có nghĩa là các bài kiểm tra thường mất nhiều thời gian hơn để viết. Càng nhiều càng tốt, chúng tôi sử dụng máy khách REST để thiết lập dữ liệu trong các dịch vụ ngang hàng.

Các bài kiểm tra trong bộ phần mềm này thường mất nhiều thời gian hơn để viết, vì vậy chúng tôi đặt hầu hết phạm vi bảo hiểm của mình vào Suite 1. Điều đó được cho là vẫn có giá trị rõ ràng trong bộ phần mềm này vì các bản sao của chúng tôi trong Suite 1 có thể không hoạt động hoàn toàn giống như các dịch vụ thực.



25

Frisby là một khung kiểm tra API REST được xây dựng trên node.js và Jasmine giúp kiểm tra các điểm cuối API dễ dàng, nhanh chóng và thú vị. http://frisbyjs.com

Thí dụ:

var frisby = require('../lib/frisby');

var URL = 'http://localhost:3000/';
var URL_AUTH = 'http://username:password@localhost:3000/';

frisby.globalSetup({ // globalSetup is for ALL requests
  request: {
    headers: { 'X-Auth-Token': 'fa8426a0-8eaf-4d22-8e13-7c1b16a9370c' }
  }
});

frisby.create('GET user johndoe')
  .get(URL + '/users/3.json')
  .expectStatus(200)
  .expectJSONTypes({
    id: Number,
    username: String,
    is_admin: Boolean
  })
  .expectJSON({
    id: 3,
    username: 'johndoe',
    is_admin: false
  })
  // 'afterJSON' automatically parses response body as JSON and passes it as an argument
  .afterJSON(function(user) {
    // You can use any normal jasmine-style assertions here
    expect(1+1).toEqual(2);

    // Use data from previous result in next test
    frisby.create('Update user')
      .put(URL_AUTH + '/users/' + user.id + '.json', {tags: ['jasmine', 'bdd']})
      .expectStatus(200)
    .toss();
  })
.toss();

Tôi đã bình chọn bài viết này, tôi đã sử dụng nó trong công việc hàng ngày của mình và bây giờ tất cả những điều thú vị của nó đang được tung ra khắp nơi. Tôi đã chia sẻ về cùng trên blog của tôi: cubicrace.com/2016/04/frisby-rest-api-automation-framework.html
Piyush Chordia


Frisby rất dễ bắt đầu và đủ mạnh để kiểm tra các luồng API nâng cao. Đáng buồn thay, kết quả báo cáo để lại rất nhiều điều mong muốn. Các thông báo lỗi khi API bị lỗi gần như vô dụng. Điều kỳ lạ là kết quả đầu ra khi bạn chạy các bài kiểm tra theo cách thủ công là khá tốt. Thật đáng tiếc.
Kasper Holdum

1
Trong trường hợp ai đó vấp phải điều này theo cách tôi đã làm, frisby dường như vẫn chưa chết như một bình luận đã lưu ý ở trên. Git có các bản cập nhật gần đây. github.com/vlucas/frisby
S.Huston 14/09/17

21

Tôi đã cộng tác với một trong những đồng nghiệp của mình để bắt đầu khung PyRestTest vì lý do này: https://github.com/svanoort/pyresttest

Mặc dù bạn có thể làm việc với các bài kiểm tra bằng Python, nhưng định dạng bài kiểm tra bình thường là bằng YAML.

Bộ thử nghiệm mẫu cho một ứng dụng REST cơ bản - xác minh rằng các API phản hồi chính xác, kiểm tra mã trạng thái HTTP, mặc dù bạn cũng có thể làm cho nó kiểm tra các cơ quan phản hồi:

---
- config:
    - testset: "Tests using test app"

- test: # create entity
    - name: "Basic get"
    - url: "/api/person/"
- test: # create entity
    - name: "Get single person"
    - url: "/api/person/1/"
- test: # create entity
    - name: "Get single person"
    - url: "/api/person/1/"
    - method: 'DELETE'
- test: # create entity by PUT
    - name: "Create/update person"
    - url: "/api/person/1/"
    - method: "PUT"
    - body: '{"first_name": "Gaius","id": 1,"last_name": "Baltar","login": "gbaltar"}'
    - headers: {'Content-Type': 'application/json'}
- test: # create entity by POST
    - name: "Create person"
    - url: "/api/person/"
    - method: "POST"
    - body: '{"first_name": "Willim","last_name": "Adama","login": "theadmiral"}'
    - headers: {Content-Type: application/json}

Với xác thực, bạn thêm bên dưới vào mỗi bài kiểm tra được tham chiếu từ github.com/svanoort/pyresttest/blob/master/quickstart.md với các tiêu đề bên dưới; - auth_username: "foobar" - auth_password: "secret" - dự
kiến_status

2

Tôi đã sử dụng SOAP UI để kiểm tra chức năng và tự động. SOAP UI cho phép bạn chạy các bài kiểm tra chỉ bằng một nút bấm. Ngoài ra còn có một trang thử nghiệm bộ điều khiển mùa xuân do Ted Young tạo ra. Tôi đã sử dụng bài viết này để tạo các bài kiểm tra đơn vị Rest trong ứng dụng của chúng tôi.



2

Một trong những vấn đề khi thực hiện kiểm thử tự động cho các API là nhiều công cụ yêu cầu bạn phải thiết lập và chạy máy chủ API trước khi chạy bộ thử nghiệm của mình. Có thể là một lợi thế thực sự khi có một khung kiểm thử đơn vị có khả năng chạy và truy vấn các API trong một môi trường kiểm tra hoàn toàn tự động.

Một tùy chọn tốt cho các API được triển khai với Node.JS / Express là sử dụng mocha để kiểm tra tự động. Ngoài các bài kiểm tra đơn vị, nó dễ dàng viết các bài kiểm tra chức năng dựa trên các API, được tách thành các bộ kiểm tra khác nhau. Bạn có thể khởi động máy chủ API tự động trong môi trường thử nghiệm cục bộ và thiết lập cơ sở dữ liệu thử nghiệm cục bộ. Sử dụng make, npm và máy chủ bản dựng, bạn có thể tạo mục tiêu "tạo thử nghiệm" và bản dựng tăng dần sẽ chạy toàn bộ bộ thử nghiệm mỗi khi một đoạn mã được gửi tới kho lưu trữ của bạn. Đối với nhà phát triển thực sự khó tính, nó thậm chí sẽ tạo ra một báo cáo phù hợp mã HTML đẹp cho bạn biết phần nào trong cơ sở mã của bạn có được kiểm tra hay không. Nếu điều này nghe có vẻ thú vị, đây là một bài đăng trên blog cung cấp tất cả các chi tiết kỹ thuật.

Nếu bạn không sử dụng nút, thì bất kể khung kiểm tra đơn vị defacto cho ngôn ngữ là gì (jUnit, dưa chuột / capybara, v.v.) - hãy xem hỗ trợ của nó để quay các máy chủ trong môi trường thử nghiệm cục bộ và chạy các truy vấn HTTP. Nếu đó là một dự án lớn, nỗ lực kiểm tra API tự động và hoạt động tích hợp liên tục sẽ được đền đáp khá nhanh chóng.

Hy vọng rằng sẽ giúp.


2

Runscope là một dịch vụ dựa trên đám mây có thể giám sát các API Web bằng một tập hợp các bài kiểm tra. Các bài kiểm tra có thể được lên lịch và / hoặc chạy thông qua các móc web được tham số hóa. Các thử nghiệm cũng có thể được thực hiện từ các trung tâm dữ liệu trên khắp thế giới để đảm bảo thời gian phản hồi có thể chấp nhận được đối với cơ sở khách hàng toàn cầu.

Cấp miễn phí của Runscope hỗ trợ tối đa 10 nghìn yêu cầu mỗi tháng.

Tuyên bố từ chối trách nhiệm: Tôi là nhà phát triển ủng hộ Runscope.


1

Tôi đã triển khai nhiều trường hợp tự động hóa dựa trên REST Assured, một DSL jave để thử nghiệm dịch vụ ổn định. https://code.google.com/p/rest-assured/

Cú pháp rất dễ dàng, nó hỗ trợ json và xml. https://code.google.com/p/rest-assured/wiki/Usage

Trước đó, tôi đã thử SOAPUI và gặp một số vấn đề với phiên bản miễn phí. Thêm vào đó, các trường hợp nằm trong tệp xml khó mở rộng và sử dụng lại, đơn giản là tôi không thích



0

Tự động hóa kiểm tra API, tối đa một lần mỗi phút, là một dịch vụ có sẵn thông qua theRightAPI . Bạn tạo các kịch bản thử nghiệm của mình và thực hiện chúng. Khi những bài kiểm tra đó làm được những gì bạn mong đợi, bạn có thể lên lịch cho chúng. Các thử nghiệm có thể được 'xâu chuỗi' với nhau cho các tình huống yêu cầu xác thực. Ví dụ: bạn có thể có một bài kiểm tra thực hiện một yêu cầu OAuth tới Twitter và tạo một mã thông báo được chia sẻ sau đó có thể được sử dụng bởi bất kỳ bài kiểm tra nào khác. Kiểm tra cũng có thể có tiêu chí xác thực đính kèm để đảm bảo mã trạng thái http hoặc thậm chí kiểm tra chi tiết các phản hồi bằng cách sử dụng javascript hoặc xác thực lược đồ. Sau khi các thử nghiệm được lên lịch, bạn có thể nhận được cảnh báo ngay khi một thử nghiệm cụ thể không được xác thực hoặc đang hoạt động ngoài phạm vi đã thiết lập về thời gian phản hồi hoặc kích thước phản hồi.


Liên kết dường như bị phá vỡ.
Rao

0

Tôi đã sử dụng các lớp TestNG và Apache HTTP để xây dựng khung kiểm tra REST API của riêng mình, tôi đã phát triển khái niệm này sau khi làm việc trong Selenium trong hai năm.

Mọi thứ đều giống nhau, ngoại trừ bạn nên sử dụng các lớp Apache HTTP thay vì các lớp Selenium.

hãy thử, nó thực sự dễ thương và tốt, bạn có tất cả sức mạnh để tùy chỉnh khung thử nghiệm của mình theo khả năng tối đa của bạn.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.