बीडीडी टेस्टिंग क्या है? व्यवहार-संचालित विकास ढांचा

बीडीडी (व्यवहार संचालित विकास) परीक्षण क्या है?

बीडीडी (व्यवहार-संचालित विकास) परीक्षण बीडीडी एजाइल सॉफ्टवेयर डेवलपमेंट की एक तकनीक है और यह टीडीडी (टेस्ट ड्रिवन डेवलपमेंट) का विस्तार है। बीडीडी में, टेस्ट केस एक ऐसी सामान्य भाषा में लिखे जाते हैं जिसे गैर-प्रोग्रामर भी पढ़ सकते हैं।

बीडीडी परीक्षण कैसे काम करता है?

मान लीजिए कि आपको नेट बैंकिंग एप्लिकेशन में फंड ट्रांसफर मॉड्यूल बनाने का काम सौंपा गया है।

इसे जांचने के कई तरीके हैं:

1. स्रोत खाते में पर्याप्त शेष राशि होने पर ही धनराशि का हस्तांतरण होना चाहिए।
2. यदि गंतव्य खाते का विवरण सही है तो निधि स्थानांतरण होना चाहिए
3. यदि उपयोगकर्ता द्वारा दर्ज किया गया लेनदेन पासवर्ड / RSA कोड / सुरक्षा प्रमाणीकरण सही है, तो धनराशि हस्तांतरण हो जाना चाहिए।
4. बैंक अवकाश होने पर भी धनराशि का हस्तांतरण होना चाहिए।
5. निधि अंतरण खाताधारक द्वारा निर्धारित भविष्य की तिथि पर होना चाहिए

RSI परिदृश्य का परीक्षण करें जैसे-जैसे हम अतिरिक्त सुविधाओं पर विचार करते हैं, जैसे कि Y दिनों या महीनों के अंतराल के लिए X राशि का हस्तांतरण करना, रोकना, यह और अधिक विस्तृत और जटिल हो जाता है।ping कुल राशि Z तक पहुँचने पर निर्धारित समय पर धन हस्तांतरण किया जाएगा, और इसी प्रकार आगे भी।

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

इस समस्या को दूर करने के लिए, बिहेवियर ड्रिवन डेवलपमेंट (बीडीडी) की अवधारणा विकसित की गई। यह डेवलपर के लिए संपूर्ण परीक्षण प्रक्रिया को आसान बना देता है।

BDD में, आप जो भी लिखते हैं, उसे इसमें शामिल होना चाहिए. दिया गया-जब-तब चरण। आइए ऊपर दिए गए उदाहरण को बीडीडी में देखें:

Given that a fund transfer module in net banking application has been developed
And I am accessing it with proper authentication

When I shall transfer with enough balance in my source account
Or I shall transfer on a Bank Holiday
Or I shall transfer on a future date
And destination a/c details are correct
And transaction password / rsa code / security authentication for the transaction is correct
And press or click send button

Then amount must be transferred
And the event will be logged in log file

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

बीडीडी बनाम टीडीडी: मुख्य अंतर

दोनों पद्धतियाँ परीक्षण-प्रधान हैं और दोनों ही फीडबैक प्रक्रिया को छोटा करती हैं। इनमें अंतर यह है कि परीक्षण कौन लिखता है, उन परीक्षणों में किस भाषा का उपयोग किया जाता है और वे एप्लिकेशन के किस स्तर का वर्णन करते हैं।

ये दोनों एक-दूसरे के पूरक हैं, प्रतिस्पर्धी नहीं। टीमें आमतौर पर इन्हें अपने पास रखती हैं। TDD यूनिट-लेवल डिज़ाइन के लिए, स्टेकहोल्डर्स द्वारा स्वीकृत व्यवहार का वर्णन करने के लिए BDD परिदृश्यों को शामिल करें। चूंकि REST एंडपॉइंट्स ठीक उसी स्वीकृति स्तर पर स्थित होते हैं, इसलिए वे BDD के लिए स्वाभाविक रूप से उपयुक्त हैं।

REST API परीक्षण क्या है?

REST API निर्माण की एक लोकप्रिय शैली बन गई है, इसलिए UI परीक्षण मामलों के साथ-साथ REST API परीक्षण मामलों को स्वचालित करना भी उतना ही महत्वपूर्ण हो गया है। एपीआई परीक्षण इसमें POST, GET, PUT और DELETE विधियों का उपयोग करके CRUD (Create-Read-Update-Delete) क्रियाओं का परीक्षण करना शामिल है।

व्यवहार क्या है?

व्यवहार लोकप्रिय में से एक है Python बीडीडी परीक्षण फ्रेमवर्क। बिहेव इस प्रकार कार्य करता है:

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

प्रत्येक फ़ाइल की भूमिका स्पष्ट हो जाने के बाद, अब फ्रेमवर्क को स्थापित किया जा सकता है।

BDD परीक्षण फ्रेमवर्क व्यवहार की स्थापना Windows

स्थापना:

• डाउनलोड करो और इंस्टॉल करो Python 3 से https://www.python.org/
• Behave को इंस्टॉल करने के लिए कमांड प्रॉम्प्ट पर निम्नलिखित कमांड चलाएँ।
• pip install behave
• आईडीई: PyCharm यहां कम्युनिटी एडिशन का उपयोग किया गया है — https://www.jetbrains.com/pycharm/download/

परियोजना सेटअप:

• एक नया प्रोजेक्ट बनाएं
• निम्नलिखित निर्देशिका संरचना बनाएं

ऊपर दिए गए स्क्रीनशॉट में वह लेआउट दिखाया गया है जिसकी Behave को अपेक्षा है: a विशेषताएं फीचर फाइलों को रखने वाली निर्देशिका, और एक नेस्टेड कदम निर्देशिका जिसमें शामिल है Python कार्यान्वयन। बिहेव दोनों को नाम से खोजता है, इसलिए फ़ोल्डर के नाम बिल्कुल मेल खाने चाहिए।

फ़ीचर फ़ाइलें:

अब आइए फीचर फाइल बनाते हैं नमूना_REST_API_परीक्षण.विशेषताइस फीचर का उद्देश्य 'पोस्ट' सेवा पर CRUD ऑपरेशन करना है।

यह उदाहरण उपयोग करता है https://jsonplaceholder.typicode.com/ यह पोस्ट सैंपल रेस्ट सर्विस, एक मुफ्त नकली एपीआई है जो राइट रिक्वेस्ट स्वीकार करती है और बदलावों को सहेजे बिना वास्तविक प्रतिक्रियाएं लौटाती है।

उदाहरण POST परिदृश्य

Scenario: POST post example -> creating a new post item using the 'posts' service
Given I set post posts API endpoint          -> prerequisite: sets the URL of the posts service
When I set HEADER param request content type as "application/json"
And set request body
And send POST HTTP request                    -> the actual test step
Then I receive valid HTTP response code 201
And Response body "POST" is non-empty       -> verification of the response body

इसी प्रकार, आप शेष परिदृश्यों को निम्नानुसार लिख सकते हैं:

नमूना_REST_API_परीक्षण.विशेषता

Feature: Test CRUD methods in Sample REST API testing framework

Background:
    Given I set sample REST API url

Scenario: POST post example
    Given I Set POST posts api endpoint
    When I Set HEADER param request content type as "application/json"
    And Set request Body
    And Send a POST HTTP request
    Then I receive valid HTTP response code 201
    And Response BODY "POST" is non-empty

Scenario: GET posts example
    Given I Set GET posts api endpoint "1"
    When I Set HEADER param request content type as "application/json"
    And Send GET HTTP request
    Then I receive valid HTTP response code 200 for "GET"
    And Response BODY "GET" is non-empty

Scenario: UPDATE posts example
    Given I Set PUT posts api endpoint for "1"
    When I Set Update request Body
    And Send PUT HTTP request
    Then I receive valid HTTP response code 200 for "PUT"
    And Response BODY "PUT" is non-empty

Scenario: DELETE posts example
    Given I Set DELETE posts api endpoint for "1"
    When I Send DELETE HTTP request
    Then I receive valid HTTP response code 200 for "DELETE"

कार्यान्वयन के चरण

अब, ऊपर दिए गए परिदृश्यों में उपयोग किए गए फ़ीचर चरणों के लिए, आप कार्यान्वयन लिख सकते हैं Python “steps” डायरेक्टरी के अंदर की फाइलें।

बिहेव फ्रेमवर्क फीचर फाइल प्रेडिकेट के विरुद्ध डेकोरेटर का मिलान करके स्टेप फंक्शन की पहचान करता है। उदाहरण के लिए, एक यह देखते हुए फीचर फाइल परिदृश्य में प्रेडिकेट एक स्टेप फंक्शन की खोज करता है जो निम्नलिखित को वहन करता है: @given डेकोरेटर। यही मिलान इसके लिए भी होता है। . और फिर'But' और 'And' के मामले में, स्टेप फ़ंक्शन अपने पिछले स्टेप के समान डेकोरेटर लेता है। उदाहरण के लिए, यदि 'And' किसी दिए गए के बाद आता है, तो मिलान करने वाला स्टेप फ़ंक्शन डेकोरेटर यह है: @given.

उदाहरण के लिए, POST के लिए When चरण को निम्नानुसार लागू किया जा सकता है। ध्यान दें कि कैसे "application/json" फीचर फाइल से ब्रेस्ड प्लेसहोल्डर में डेटा पास किया जाता है - इसे पैरामीटराइजेशन कहा जाता है।

# Decorator: the braced name captures a value from the feature file
@when(u'I Set HEADER param request content type as "{header_content_type}"')
def step_impl(context, header_content_type):
    # Step implementation: set the content type on the request header
    request_headers['Content-Type'] = header_content_type

इसी प्रकार, चरण में अन्य चरणों का कार्यान्वयन Python फ़ाइल इस तरह दिखाई देगी:

नमूना_चरण_कार्यान्वयन.py

from behave import given, when, then, step
import requests

api_endpoints = {}
request_headers = {}
response_codes = {}
response_texts = {}
request_bodies = {}
api_url = None

@given(u'I set sample REST API url')
def step_impl(context):
    global api_url
    api_url = 'https://jsonplaceholder.typicode.com'

# START POST Scenario
@given(u'I Set POST posts api endpoint')
def step_impl(context):
    api_endpoints['POST_URL'] = api_url + '/posts'
    print('url :' + api_endpoints['POST_URL'])

@when(u'I Set HEADER param request content type as "{header_content_type}"')
def step_impl(context, header_content_type):
    request_headers['Content-Type'] = header_content_type

# "And" or "But" steps are renamed by behave to match their preceding step
@when(u'Set request Body')
def step_impl(context):
    request_bodies['POST'] = {"title": "foo", "body": "bar", "userId": "1"}

@when(u'Send POST HTTP request')
def step_impl(context):
    # send the request and save the response object
    response = requests.post(url=api_endpoints['POST_URL'],
                             json=request_bodies['POST'],
                             headers=request_headers)
    response_texts['POST'] = response.text
    print("post response :" + response.text)
    response_codes['POST'] = response.status_code

@then(u'I receive valid HTTP response code 201')
def step_impl(context):
    print('Post rep code ;' + str(response_codes['POST']))
    assert response_codes['POST'] == 201
# END POST Scenario

# START GET Scenario
@given(u'I Set GET posts api endpoint "{id}"')
def step_impl(context, id):
    api_endpoints['GET_URL'] = api_url + '/posts/' + id
    print('url :' + api_endpoints['GET_URL'])

@when(u'Send GET HTTP request')
def step_impl(context):
    response = requests.get(url=api_endpoints['GET_URL'], headers=request_headers)
    response_texts['GET'] = response.text
    response_codes['GET'] = response.status_code

@then(u'I receive valid HTTP response code 200 for "{request_name}"')
def step_impl(context, request_name):
    print('Get rep code for ' + request_name + ':' + str(response_codes[request_name]))
    assert response_codes[request_name] == 200

@then(u'Response BODY "{request_name}" is non-empty')
def step_impl(context, request_name):
    print('request_name: ' + request_name)
    print(response_texts)
    assert response_texts[request_name] is not None
# END GET Scenario

# START PUT/UPDATE
@given(u'I Set PUT posts api endpoint for "{id}"')
def step_impl(context, id):
    api_endpoints['PUT_URL'] = api_url + '/posts/' + id
    print('url :' + api_endpoints['PUT_URL'])

@when(u'I Set Update request Body')
def step_impl(context):
    request_bodies['PUT'] = {"title": "foo", "body": "bar",
                             "userId": "1", "id": "1"}

@when(u'Send PUT HTTP request')
def step_impl(context):
    response = requests.put(url=api_endpoints['PUT_URL'],
                            json=request_bodies['PUT'],
                            headers=request_headers)
    response_texts['PUT'] = response.text
    print("update response :" + response.text)
    response_codes['PUT'] = response.status_code
# END PUT/UPDATE

# START DELETE
@given(u'I Set DELETE posts api endpoint for "{id}"')
def step_impl(context, id):
    api_endpoints['DELETE_URL'] = api_url + '/posts/' + id
    print('url :' + api_endpoints['DELETE_URL'])

@when(u'I Send DELETE HTTP request')
def step_impl(context):
    response = requests.delete(url=api_endpoints['DELETE_URL'])
    response_texts['DELETE'] = response.text
    print("DELETE response :" + response.text)
    response_codes['DELETE'] = response.status_code
# END DELETE

⚠️ नोट: स्टेटस कोड की तुलना करना == बजाय is मामले। is ऑपरेटर ऑब्जेक्ट की पहचान का परीक्षण करता है, समानता का नहीं, और Python 3.8 और बाद में इसे बढ़ाएं SyntaxWarning: “is” with a literal उस पैटर्न के लिए। कोई भी अभिकथन इस प्रकार लिखा गया है assert code is 201 इसे इस प्रकार पुनः लिखा जाना चाहिए assert code == 201.

परीक्षण चलाना

टेस्ट स्क्रिप्ट का विकास पूरा हो चुका है, तो चलिए अब टेस्ट चलाते हैं। फ़ीचर फ़ाइल को चलाने के लिए कमांड प्रॉम्प्ट पर निम्न कमांड निष्पादित करें:

:: Run a single feature file with the pretty formatter
behave -f pretty features\feature_files_folder\Sample_REST_API_Testing.feature

:: Run every feature in the project
behave

इससे परीक्षण निष्पादन के परिणाम इस प्रकार प्रदर्शित होते हैं:

कंसोल पर रिपोर्ट प्रदर्शित करें

विकास के दौरान कंसोल आउटपुट सुविधाजनक होता है, लेकिन हितधारक आमतौर पर एक पठनीय रिपोर्ट पसंद करते हैं, जो एल्योर प्रदान करता है।

रिपोर्ट

सबसे पहले, Allure Behave फॉर्मेटर और Allure कमांड लाइन टूल इंस्टॉल करें। फॉर्मेटर एक Python पैकेज; कमांड लाइन टूल एक अलग डाउनलोड है जिसका विवरण दिया गया है एल्योर रिपोर्ट दस्तावेज़ीकरण.

:: 1. Install the formatter
pip install allure-behave

:: 2. Run the tests and write raw results to a folder
behave -f allure_behave.formatter:AllureFormatter -o reports/allure-results features/

:: 3. Render and open the HTML report
allure serve reports/allure-results

इससे परीक्षण परिणामों की रिपोर्ट एक आकर्षक और जानकारीपूर्ण प्रारूप में इस प्रकार तैयार होती है:

HTML प्रारूप में परीक्षण रिपोर्ट

व्यक्तिगत परिदृश्य परिणाम प्रदर्शित करने वाली परीक्षण रिपोर्ट

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

बिहेव फीचर फाइल लिखने के लिए सर्वोत्तम अभ्यास

जब परिदृश्य व्यवहार के बजाय क्लिक और पेलोड का वर्णन करते हैं, तो बिहेव सूट जल्दी खराब हो जाता है। नीचे दिए गए तरीके व्यावसायिक हितधारकों के लिए फ़ीचर फ़ाइलों को पठनीय बनाए रखते हैं, साथ हीping la Python इंजीनियरों के लिए लेयर को बनाए रखना आसान है।

1. व्यवहार का वर्णन करें, कार्यान्वयन का नहीं। “यदि ग्राहक के पास पर्याप्त शेष राशि है” लिखें, न कि “यदि शेष राशि कॉलम 500 के बराबर है”। फ़ीचर फ़ाइल बताती है कि सिस्टम क्या करता है; स्टेप फ़ाइल बताती है कि इसकी जाँच कैसे की जाती है।
2. प्रत्येक परिदृश्य के लिए एक ही व्यवहार रखें। एक ऐसा परिदृश्य जिसमें स्टेटस कोड, रिस्पॉन्स बॉडी और डेटाबेस रो शामिल होते हैं, वास्तव में तीन अलग-अलग परिदृश्य हैं। इन्हें अलग-अलग करने से विफलताएं सीधे कारण की ओर इंगित करती हैं।
3. साझा सेटअप को पृष्ठभूमि में ले जाएं। ऊपर दिए गए उदाहरण में इसका उपयोग किया गया है। Background: Given I set sample REST API url ताकि हर परिदृश्य आधार को विरासत में प्राप्त करे URL इसे दोहराए बिना।
4. डुप्लिकेट करने के बजाय पैरामीटर का उपयोग करें। ब्रेस्ड प्लेसहोल्डर जैसे कि "{request_name}" एक ही स्टेप फंक्शन को GET, PUT और DELETE अभिकथनों के लिए उपयोग करने दें, यही कारण है कि उदाहरण में परिदृश्यों की तुलना में बहुत कम स्टेप परिभाषाओं की आवश्यकता होती है।
5. डेटा में होने वाले बदलावों के लिए परिदृश्य रूपरेखा का उपयोग करें। जब एक ही व्यवहार को कई इनपुट के लिए सिद्ध करना हो, तो Examples: तालिका, नकल किए गए परिदृश्यों की तुलना में अधिक स्पष्ट है।
6. विभिन्न परिदृश्यों के बीच निर्भरता से बचें। Behave यह गारंटी नहीं देता कि हर कॉन्फ़िगरेशन में GET सिनेरियो से पहले POST सिनेरियो चलेगा। प्रत्येक सिनेरियो को अपनी आवश्यकतानुसार स्थिति बनानी चाहिए।
7. मॉड्यूल-स्तर के वैश्विक चरों को संदर्भ से बदलें। संक्षिप्तता के लिए, उदाहरण में एंडपॉइंट और प्रतिक्रियाओं को मॉड्यूल शब्दकोशों में संग्रहीत किया गया है। प्रोडक्शन सूट में, इन्हें Behave के मॉड्यूल शब्दकोशों में संग्रहीत करें। context ऑब्जेक्ट की स्थिति विभिन्न परिदृश्यों के बीच सुचारू रूप से रीसेट हो जाती है।
8. चुनिंदा रन के लिए टैग परिदृश्य। टैग जैसे @smoke or @regression अनुमति देना behave --tags=@smokeजिससे पाइपलाइन फीडबैक त्वरित रहता है।

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

अक्सर पूछे जाने वाले प्रश्न