REST Api के लिए स्वचालित परीक्षण [बंद]

Question

मैं REST API के लिए एक स्वचालित परीक्षण सूट लिखना चाहूंगा। जब हम नई सेवाओं को पूरा करते हैं, तो हम यह सुनिश्चित करना चाहते हैं कि पहले की गई सभी सेवाएँ अपेक्षित रूप से काम कर रही हैं। इसे पूरा करने के लिए उपयोग करने के लिए सबसे अच्छा उपकरण पर कोई सुझाव? मुझे पता है कि Apigee जैसे उपकरण मौजूद हैं जो आपको एक समय में 1 सेवा का परीक्षण करने की अनुमति देते हैं, लेकिन हम एक बटन के क्लिक के साथ सभी सेवाओं का परीक्षण करने का तरीका चाहते हैं।

Comments

आप vREST को एक कोशिश दे सकते हैं । इसमें यूनिट टेस्टिंग और मॉक दोनों हैं।

— जांगिड़

JMeter REST API परीक्षण के लिए सबसे अच्छा साधन है - इस टिप्पणी को उन लोगों के लिए जोड़ना जो JMeter का उपयोग करके REST API का परीक्षण करने के लिए कुछ विस्तृत चरणों की तलाश कर रहे हैं। testautomationguru.com/how-to-test-rest-api-using-jmeter

— vins

कुछ नहीं धड़कता है FRISBY - बस सही और सबसे शक्तिशाली उपकरण के लिए REST API परीक्षण

— पीयूष चोरडिया

JMeter ओवरकल है, उल्लेख करने के लिए एक भयानक यूआई नहीं है, बस एक रीस्ट एपी के बुनियादी कार्यात्मक परीक्षण के लिए। यह प्रदर्शन / लोड परीक्षण के लिए है।

— केविन एम

JMeter लोड परीक्षण पर अधिक केंद्रित है, शायद आपको सबसे अच्छा विकल्प खोजने के लिए 12 महान वेब सेवा परीक्षण उपकरण की जांच करनी चाहिए । इस सूची के कुछ उपकरण, उदाहरण के लिए SOAPUI या HttpMaster , के पास REST API एंडपॉइंट्स के लिए एक बहुत अच्छा स्वचालन समर्थन है।

— २०:५० पर जॉक्सि

Answer 1

मेरे काम पर हमने हाल ही में जावा में लिखे गए कुछ परीक्षण सूटों को एक साथ रखा है जो हमारे द्वारा बनाए गए कुछ मूल्यवान एपीआई का परीक्षण करने के लिए हैं। हमारी सेवाएं उन पर निर्भर अन्य विश्वसनीय API को लागू कर सकती हैं। हमने इसे दो सुइट्स में विभाजित किया।

---

• सुइट 1 - अलगाव में प्रत्येक सेवा का परीक्षण
  • किसी भी सहकर्मी की सेवा को मॉक करें जो एपीआई रेस्टिटो का उपयोग करने पर निर्भर करता है । अन्य विकल्प शामिल बाकी चालक , wiremock और Betamax ।
  • हम जिस सेवा का परीक्षण कर रहे हैं और जो सभी एक ही जेवीएम में चलती है, उसका परीक्षण करता है
  • जेट्टी में सेवा शुरू की

मैं निश्चित रूप से ऐसा करने की सिफारिश करूंगा। इसने हमारे लिए वास्तव में अच्छा काम किया है। मुख्य लाभ हैं:

• सहकर्मी सेवाओं का मज़ाक उड़ाया जाता है, इसलिए आपको कोई जटिल डेटा सेटअप करने की आवश्यकता नहीं है। प्रत्येक परीक्षण से पहले आप बस यह निर्धारित करने के लिए कि आप सहकर्मी सेवाओं को कैसे व्यवहार करना चाहते हैं, को परिभाषित करने के लिए रेस्टिटो का उपयोग करते हैं, ठीक उसी तरह जैसे कि आप मॉकिटो के साथ यूनिट टेस्ट में कक्षाएं लेते हैं।
• यदि आप बुलाए गए थे, तो आप नकली साथी सेवाओं से पूछ सकते हैं। आप इन मुखर को असली सहकर्मी सेवाओं के साथ आसानी से नहीं कर सकते।
• सुइट सुपर फास्ट है क्योंकि नकली सेवाएं प्री-कैन्ड-इन-मेमोरी प्रतिक्रियाओं की सेवा करती हैं। तो हम बिना सूट के अच्छी कवरेज प्राप्त कर सकते हैं।
• सुइट विश्वसनीय है और अपने स्वयं के JVM में अलग-थलग होने के कारण यह दोहराव योग्य है, इसलिए एक ही समय में एक साझा वातावरण के साथ अन्य सुइट्स / लोगों के बारे में चिंता करने की कोई आवश्यकता नहीं है, जो सूट चल रहा है और परीक्षण विफल होने का कारण है।

---

• सुइट 2 - पूर्ण अंत से अंत तक
  • सुइट कई मशीनों में तैनात एक पूर्ण वातावरण के खिलाफ चलता है
  • एपीआई पर्यावरण में टॉमकैट पर तैनात किया गया
  • सहकर्मी सेवाएं वास्तविक 'लाइव' के रूप में पूर्ण तैनाती हैं

इस सूट के लिए हमें सहकर्मी सेवाओं में डेटा सेट करने की आवश्यकता होती है, जिसका अर्थ है कि परीक्षण आमतौर पर लिखने में अधिक समय लेते हैं। जितना संभव हो हम सहकर्मी सेवाओं में डेटा सेट करने के लिए REST क्लाइंट का उपयोग करते हैं।

इस सुइट में टेस्ट आमतौर पर लिखने में अधिक समय लेते हैं, इसलिए हम अपना अधिकांश कवरेज सुइट 1 में रखते हैं। कहा जा रहा है कि इस सुइट में अभी भी स्पष्ट मूल्य है क्योंकि सुइट 1 में हमारे मोक्स वास्तविक सेवाओं की तरह काफी व्यवहार नहीं कर सकते हैं।

---

Answer 2

फ्रिस्बी नोड.जेएस और जैस्मीन पर निर्मित एक रीस्ट एपीआई टेस्टिंग फ्रेमवर्क है जो एपीआई एंडपॉइंट्स की टेस्टिंग को आसान, तेज और मजेदार बनाता है। http://frisbyjs.com

उदाहरण:

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();

Comments

मैंने इस लेख को वोट दिया, मैंने इसे अपने दैनिक कार्य में उपयोग किया और अब इसके सभी तामझाम चारों ओर उछाले जा रहे हैं। मैंने अपने ब्लॉग पर उसी के बारे में साझा किया है: cubicrace.com/2016/04/frisby-rest-ap-automation-framework.html

— पीयूष

फ्रिसबी मर चुका है github.com/vlucas/frisby/issues/347

— अर्न्स्ट अर्न्स्ट

फ्रिसबी उन्नत एपीआई प्रवाह का परीक्षण करने के लिए पर्याप्त और शक्तिशाली के साथ शुरू करना आसान है। अफसोस की बात है कि रिपोर्ट आउटपुट वांछित होने के लिए बहुत कुछ छोड़ देता है। एपीआई विफल होने पर त्रुटि संदेश लगभग बेकार होने की बात है। जो अजीब है कि जब आप मैन्युअल रूप से परीक्षण चलाते हैं तो आउटपुट काफी अच्छा होता है। यह शर्मनाक है।

— कास्पर होल्डम

यदि कोई इस तरह से ठोकर खाता है, जैसा मैंने किया है, तो फ्रिसबी को अभी तक मृत नहीं लगता है जैसा कि ऊपर उल्लेखित टिप्पणी है। Git के पास हाल के अपडेट हैं। github.com/vlucas/frisby

— S.Huston

Answer 3

मैंने अपने सहकर्मियों के साथ PyRestTest ढांचे को शुरू करने के लिए इस कारण से सहयोग किया: https://github.com/svanoort/pyresttest

यद्यपि आप पायथन में परीक्षणों के साथ काम कर सकते हैं, सामान्य परीक्षण प्रारूप YAML में है।

बेसिक रीस्ट ऐप के लिए सैंपल टेस्ट सूट - सत्यापित करता है कि एपीआई सही तरीके से प्रतिक्रिया देते हैं, HTTP स्टेटस कोड की जाँच करते हैं, हालांकि आप इसे प्रतिक्रिया निकायों की भी जाँच कर सकते हैं:

---
- 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}

Comments

प्रमाणीकरण के साथ, आप नीचे दिए गए शीर्षकों के साथ github.com/svanoort/pyresttest/blob/master/quickstart.md से संदर्भित प्रत्येक परीक्षा में नीचे जोड़ते हैं ; - dif_username: "foobar" - dif_password: "secret" - अपेक्षित_स्टैटस: [200]

— agfe2

Answer 4

मैंने कार्यात्मक और स्वचालित परीक्षण के लिए SOAP UI का उपयोग किया । सोप यूआई आपको एक बटन के क्लिक पर परीक्षण चलाने की अनुमति देता है। टेड यंग द्वारा बनाया गया एक स्प्रिंग कंट्रोलर टेस्टिंग पेज भी है । हमने इस लेख का उपयोग हमारे आवेदन में रेस्ट यूनिट टेस्ट बनाने के लिए किया है।

Comments

अपडेट किया गया लिंक: theodoreyoung.wordpress.com/2011/02/14/...

— EverDream

Answer 5

एपीआई के लिए स्वचालित परीक्षण करने की समस्याओं में से एक यह है कि आपके परीक्षण सूट को चलाने से पहले कई उपकरण आपको एपीआई सर्वर को चलाने और चलाने की आवश्यकता होती है। यूनिट टेस्टिंग फ्रेमवर्क का वास्तविक लाभ हो सकता है जो पूरी तरह से स्वचालित परीक्षण वातावरण में एपीआई को चलाने और क्वेरी करने में सक्षम है।

नोड.जेएस / एक्सप्रेस के साथ कार्यान्वित एपीआई के लिए एक विकल्प स्वचालित परीक्षण के लिए मोचा का उपयोग करना है। यूनिट परीक्षणों के अलावा, एपीआई के खिलाफ कार्यात्मक परीक्षण लिखना आसान है, अलग-अलग परीक्षण सूट में अलग किया गया। आप स्थानीय परीक्षण वातावरण में स्वचालित रूप से एपीआई सर्वर शुरू कर सकते हैं और स्थानीय परीक्षण डेटाबेस सेट कर सकते हैं। मेक, एनपीएम और एक बिल्ड सर्वर का उपयोग करके, आप "मेक टेस्ट" लक्ष्य बना सकते हैं और एक वृद्धिशील बिल्ड बना सकते हैं जो पूरे टेस्ट सूट को हर बार कोड का एक टुकड़ा आपके रिपॉजिटरी में सबमिट किया जाएगा। सही मायने में व्रत रखने वाले डेवलपर के लिए, यह एक अच्छी HTML कोड-कवरेज रिपोर्ट भी उत्पन्न करेगा, जिसमें दिखाया जाएगा कि आपके कोड आधार के कौन से भाग परीक्षण द्वारा कवर किए गए हैं या नहीं। यदि यह दिलचस्प लगता है, तो यहां एक ब्लॉग पोस्ट है जो सभी तकनीकी विवरण प्रदान करता है।

यदि आप नोड का उपयोग नहीं कर रहे हैं, तो जो भी भाषा के लिए डिफैक्टो यूनिट परीक्षण रूपरेखा है (jUnit, ककड़ी / कैपिबारा, आदि) - स्थानीय परीक्षण वातावरण में सर्वर को स्पिन करने और HTTP प्रश्नों को चलाने के लिए इसके समर्थन को देखें। यदि यह एक बड़ी परियोजना है, तो स्वचालित एपीआई परीक्षण और लगातार एकीकरण काम पाने का प्रयास बहुत जल्दी भुगतान करेगा।

उम्मीद है की वो मदद करदे।

Answer 6

Runscope एक क्लाउड आधारित सेवा है जो परीक्षणों के एक सेट का उपयोग करके Web API की निगरानी कर सकती है। टेस्ट, शेड्यूल किए जा सकते हैं और / या पैरामीटर किए गए वेब हुक के माध्यम से चलाए जा सकते हैं। वैश्विक ग्राहक आधार के लिए प्रतिक्रिया समय स्वीकार्य होने को सुनिश्चित करने के लिए दुनिया भर के डेटा केंद्रों से टेस्ट भी निष्पादित किए जा सकते हैं।

Runscope का मुफ्त टियर प्रति माह 10K अनुरोधों का समर्थन करता है।

अस्वीकरण: मैं Runscope के लिए एक डेवलपर वकील हूं।

Answer 7

मैंने रेस्ट एश्योर्ड पर आधारित कई ऑटोमेशन के मामलों को लागू किया, जो कि रेस्टेबल सर्विस की टेस्टिंग के लिए एक जेवीएस डीएसएल है। https://code.google.com/p/rest-assured/

वाक्यविन्यास आसान है, यह json और xml का समर्थन करता है। https://code.google.com/p/rest-assured/wiki/Usage

इससे पहले, मैंने SOAPUI की कोशिश की और मुफ्त संस्करण के साथ कुछ मुद्दे थे। इसके अलावा मामले एक्सएमएल फाइलों में हैं जिनका विस्तार करना और पुन: उपयोग करना मुश्किल है, बस मुझे पसंद नहीं है

Answer 8

आप रेस्ट एश्योर्ड लाइब्रेरी का भी उपयोग कर सकते हैं। नमूना स्क्रिप्ट वाले डेमो के लिए, http://artoftesting.com/automationTesting/restAPIAutomationGetRequien.html देखें

Answer 9

एपीआई टेस्ट ऑटोमेशन, प्रति मिनट एक बार तक, एक सेवा है जो आरएआरएटीआईआई के माध्यम से उपलब्ध है । आप अपने परीक्षण परिदृश्य बनाते हैं, और उन्हें निष्पादित करते हैं। एक बार जब वे परीक्षण करते हैं जो आप उनसे उम्मीद करते हैं, तो आप उन्हें शेड्यूल कर सकते हैं। प्रमाणीकरण की आवश्यकता वाले परिदृश्यों के लिए परीक्षण एक साथ 'जंजीर' हो सकते हैं। उदाहरण के लिए, आपके पास एक परीक्षण हो सकता है जो ट्विटर पर OAuth अनुरोध करता है, और एक साझा टोकन बनाता है जिसे तब किसी अन्य परीक्षण द्वारा उपयोग किया जा सकता है। परीक्षण में http मान कोड सुनिश्चित करने के लिए सत्यापन मानदंड भी संलग्न हो सकते हैं, या जावास्क्रिप्ट या स्कीमा सत्यापन का उपयोग करके प्रतिक्रियाओं का विस्तृत निरीक्षण भी किया जा सकता है। एक बार परीक्षण निर्धारित होने के बाद, आप तब अलर्ट भेज सकते हैं जैसे ही एक विशेष परीक्षण सत्यापन विफल हो जाता है, या प्रतिक्रिया समय या प्रतिक्रिया आकार के लिए स्थापित सीमाओं से बाहर व्यवहार कर रहा है।

Comments

लिंक टूटने लगता है।

— राव

Answer 10

मैंने अपने स्वयं के REST API परीक्षण ढांचे के निर्माण के लिए TestNG और Apache HTTP कक्षाओं का उपयोग किया है, मैंने दो साल तक सेलेनियम में काम करने के बाद इस अवधारणा को विकसित किया।

सब कुछ समान है, सिवाय इसके कि आपको सेलेनियम कक्षाओं के बजाय अपाचे HTTP कक्षाओं का उपयोग करना चाहिए।

एक कोशिश दे, वास्तव में प्यारा और अच्छा है, आप अपनी पूरी संभावनाओं के लिए अपने परीक्षण ढांचे को अनुकूलित करने की पूरी शक्ति रखते हैं।

Comments

automationextra.blogspot.in/2015/03/...

— Karthic.K