मुझे बॉट और मेरे awl

मेरा नाम दशा है, और मैं 4 साल के लिए एक परीक्षण इंजीनियर हूं। इसका मतलब है कि नए समाधानों की तलाश में "जून" के उत्साह के साथ आप जो दिलचस्प कार्य करते हैं, वे कम और कम दिखाई देते हैं। वही प्रोजेक्ट, प्रोडक्शंस और केस! नहीं, मैं ऐसा नहीं खेलता हूँ! परीक्षण हमेशा एक चुनौती है, और बेहतर के लिए दुनिया को बदलने की इच्छा नहीं मरनी चाहिए। और एक बार जब मैं इस समस्या को लेकर आया: तो आपको टेलीग्राम में एक साधारण चैट बॉट का परीक्षण करना होगा।



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

जश्न मनाने के लिए, मैंने इस मामले को सभी जिम्मेदारी के साथ संपर्क करने का फैसला किया, अधिकतम सरलता दिखाने के लिए, और बस काम का आनंद लें।

परीक्षण काले और ग्रे बॉक्स विधि का उपयोग करके किया गया था। इसलिए, आप कस्टम स्क्रिप्ट के साथ आने के लिए अपनी सभी कल्पना का उपयोग कर सकते हैं।

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

एक विवरण है, पेंसिल तेज, चेकलिस्ट तैयार, कुकीज़ सभी खाए गए। मैं शुरू करने के लिए तैयार हूं! हर दूसरे नए सवाल पैदा हुए ...

रुक रुक के रुक! शांत रहें और परीक्षण शुरू करें। तो, क्रम में:

1. किस रूप में तारीख प्रदर्शित करें? हमेशा दिनांक के साथ एक समस्या होती है: प्रारूप, समय क्षेत्र, आदि।
हम बाहरी प्रणाली से सटीक आवश्यकताएं प्राप्त नहीं कर सकते थे, इसलिए हमने उस तिथि को उस रूप में प्रदर्शित करने का निर्णय लिया जिसमें इसे मूल रूप से प्राप्त किया गया था। यह भविष्यवाणी करना बहुत मुश्किल है कि तारीख किस प्रारूप में प्राप्त होगी (यहां तक ​​कि एक जादुई गेंद भी ऐसा नहीं कर सकती थी)।

2. यदि संदेश में बड़ी मात्रा में जानकारी है तो छवि की गुणवत्ता कितनी प्रभावित होगी?
तस्वीर की गुणवत्ता बाहर से प्राप्त जानकारी की मात्रा पर निर्भर करती है। टेलीग्राम ही छवि की गुणवत्ता को कम करता है। यदि बड़ी मात्रा में जानकारी है, तो एक दस्तावेज़ के साथ संचारित करके, हमें एक पठनीय रूप में तालिका मिल जाएगी, लेकिन तब उपयोगकर्ता को उत्पन्न पीडीएफ फाइल को खोलने के लिए तीसरे पक्ष के आवेदन का उपयोग करने की आवश्यकता होती है। यह जीवन को जटिल करेगा, और कोई भी कठिनाइयों को पसंद नहीं करता है (लेकिन हर कोई कुकीज़ को प्यार करता है!)। उसी समय, यदि आप एक तस्वीर भेजते हैं, तो यह केवल तभी पढ़ा जा सकेगा जब थोड़ा डेटा प्राप्त किया गया हो, लेकिन तब उपयोगकर्ता छवि को देखने के लिए टेलीग्राम की कार्यक्षमता का उपयोग कर सकता है। हमने तय किया कि चित्र के साथ प्रदर्शन को छोड़ना बेहतर था, क्योंकि इसके साथ काम करना अधिक सुविधाजनक है, और इसे बड़ी मात्रा में जानकारी मिलने की संभावना नहीं है।

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

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

5. यदि उपयोगकर्ता ने अभी तक पुराने संदेशों पर निर्णय नहीं लिया है, तो सिस्टम को क्या करना चाहिए, लेकिन नए पहले ही प्राप्त हो चुके हैं?
इस मामले में, हमारी प्रणाली अनुमोदन के लिए एक ही संदेश देती है (कोई भी हमारी उपेक्षा करने की हिम्मत नहीं करता है!)।

6. हम कितने संदेश स्वीकार कर सकते हैं?
इस प्रश्न का उत्तर देने के लिए, मैंने SOAP UI में एक साधारण टेस्ट सूट बनाने का निर्णय लिया। पसंद इस एप्लिकेशन पर गिर गई, क्योंकि इसमें एक व्यापक गुंजाइश है (वेब ​​सेवाओं के सत्यापन, सिमुलेशन, कार्यात्मक परीक्षण, लोड परीक्षण आदि को शामिल किया गया है)।
मैंने आपको एक साधारण टेस्ट सूट बनाने के बारे में नहीं बताया, क्योंकि वे पहले ही इस बारे में पर्याप्त लिख चुके हैं, मैं सिर्फ समस्या और मेरे समाधान का वर्णन करना चाहूंगा।
मुख्य पकड़ यह थी कि प्रत्येक नए अनुरोध के लिए एक नया पहचानकर्ता उत्पन्न किया जाना था, और यह उत्पन्न मूल्य उसी एक्सएमएल के भीतर पुन: उपयोग किया गया था।

समाधान पाया गया था:

एक परीक्षण मामले में, एक संपत्ति ID_Calc विशेषता के साथ बनाई जाती है।



फिर, सेटअप स्क्रिप्ट टैब में, स्क्रिप्ट पेस्ट करें:
testCase.setPropertyValue ("ID_Calc", नया java.util.Random ()। NextInt (99999) .toString ())



उसके बाद, अनुरोध में ही, उन टैग्स में जहां पहचानकर्ता का उपयोग किया जाता है, लिखना आवश्यक है:
$ {# TestCase # ID}



इस प्रकार, प्रत्येक अनुरोध में एक विशिष्ट पहचानकर्ता था, लेकिन एक अलग संदेश के ढांचे के भीतर, पहचानकर्ता समान थे।

विकास और परीक्षण का कार्य बहुत तेज़ी से और सामंजस्यपूर्वक किया गया था, इसलिए हम जल्द से जल्द परिणाम प्राप्त करने में सफल रहे। संशोधन तुरंत ग्राहक को सौंप दिया गया था, और वह संतुष्ट था।

यहां तक ​​कि सबसे सरल और सबसे सांसारिक कार्य से, आप एक शांत खोज कर सकते हैं, जिसके पारित होने पर आप गर्व कर सकते हैं! ठीक है, अगर आप ऊब गए हैं, लेकिन ज्वलंत भावनाओं को चाहते हैं, तो बस अपनी परियोजना पर समस्याओं को ढूंढें और उन्हें असामान्य तरीके से हल करें :)

सौभाग्य है