इमेल परीक्षणको अविश्वसनीय संस्करण छोटो हुन्छ: ठेगाना सिर्जना गर्नु, पाँच सेकेन्ड सुत्नु, पहिलो सन्देश पढ्नु, र यो चलनसँग सम्बन्धित हो भन्ने आशा गर्नु।
विश्वसनीय संस्करण अझै सरल छ, तर यसले डेलिभरीलाई असिन्क्रोनस रूपमा व्यवहार गर्छ। यो अद्वितीय ठेगाना सिर्जना गर्छ, सुरु समय रेकर्ड गर्छ, समयसीमा भित्र पोल गर्छ, इच्छित सन्देश मिलाउँछ, उत्पादन कार्यलाई मान्य गर्छ, र केही असफल हुँदा पर्याप्त सन्दर्भ रिपोर्ट गर्छ.
API कुञ्जीलाई URL मा नसमावेश गर्नुहोस्
GPTMail कुञ्जीलाई X-API-Key हेडरमा पठाउनुहोस्। यसलाई ?api_key= क्वेरी प्यारामिटरमा नहाल्नुहोस्। URL हरू ब्राउजर इतिहास, पहुँच लग, मोनिटरिङ प्रणाली, र रेफरर डाटा मा नियमित रूपमा संग्रहित हुन्छन्.
X-API-Key: YOUR_API_KEYकुञ्जीलाई तपाईंको CI सिक्रेट म्यानेजरमा संग्रह गर्नुहोस् र लगहरूमा मास्क गर्नुहोस्। अन्वेषणको लागि सार्वजनिक दैनिक कुञ्जी सुविधाजनक हुन्छ; नियन्त्रित अटोमेटेड सूटहरूले यस्तो कुञ्जी प्रयोग गर्नु पर्छ जसको कोटा र प्रयोग तपाईंले ट्र्याक गर्न सक्नुहुन्छ.
वर्तमान एन्डपइन्टहरू र प्रतिक्रिया उदाहरणहरू GPTMail API दस्तावेज पृष्ठ मा राखिएका छन्.
प्रत्येक चलनको लागि एक ठेगाना
प्रत्येक स्वतन्त्र रूपमा चलाउन सकिने परीक्षणको लागि नयाँ ठेगाना उत्पन्न गर्नुहोस्। सम्पूर्ण परीक्षण सूटले साझा गरेको इनबक्सबाट शुद्धता ननिकाल्नुहोस्.
ठेगाना, परिदृश्य ID, वातावरण, र परीक्षण सुरु समय रेकर्ड गर्नुहोस्। यी मानहरूले तपाईंलाई पुराना सन्देशहरू अस्वीकार गर्न र सन्देश गोप्यताहरूलाई लग नगरी टकराव निदान गर्न मद्दत गर्छ.
निश्चित सुताइको सट्टा समयसीमा विरुद्ध पोल गर्नुहोस्
इमेल डेलिभरी समय फरक-फरक हुन्छ। निश्चित पाँच सेकेन्डको सुताइ छिटो डेलिभरीमा बर्बाद हुन्छ र ढिलो डेलिभरीमा अस्थिर.
सीमित लूप प्रयोग गर्नुहोस्:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)समयसीमा परीक्षण सम्झौतामा पर्छ। पासवर्ड‑रिसेट प्रवाहलाई बल्क न्यूजलेटर पूर्वावलोकनभन्दा फरक सीमा चाहिन सक्छ। सीमा स्पष्ट राख्नुहोस् ताकि सुस्त निर्भरताले सम्पूर्ण CI कामलाई चुपचाप विस्तार नहोस्.
सटीक मिलान गर्नुहोस्
“इनबक्सको पहिलो सन्देश” उपयोगी चयनकर्ता होइन। धेरै संकेतहरू मिलाउनुहोस्:
- प्रापक यो चलनको लागि सिर्जना गरिएको ठेगानासँग बराबर हो;
- सिर्जना समय ट्रिगर समयभन्दा पछि हो;
- प्रेषक अपेक्षित सेवासँग सम्बन्धित हो;
- विषय वा सन्देश प्रकार प्रवाहसँग मिल्छ;
- सन्देश ID पहिले नै प्रयोग भएको छैन।
जब प्रेषकले धेरै कोडहरू जारी गर्न सक्छ, सबैभन्दा नयाँ मिल्ने सन्देश चयन गर्नुहोस्। यसको ID परीक्षण आउटपुटमा सुरक्षित राख्नुहोस् ताकि पुनः प्रयासले अनजानेमा यसलाई पुन: प्रयोग नगर्नोस्.
सूची मिलान पछि मात्र पढ्नुहोस्
इनबक्स सूचीकरण सस्तो खोजी चरण हुनुपर्छ। चयनित उम्मेदवारको लागि मात्र पूर्ण सन्देश ल्याउनुहोस्। यसले अनावश्यक काम घटाउँछ र असम्बन्धित प्रोमोशनल मेलको पार्सिङबाट बचाउँछ.
व्यवसायिक परिणामको मान्यतापत्र गर्नुहोस्, केवल छ-अंकीय स्ट्रिङको उपस्थिति मात्र होइन। कोड पेश गर्नुहोस् वा अपेक्षित लिङ्क खोल्नुहोस्, त्यसपछि खाताले सही अवस्थालाई प्राप्त गरेको छ कि छैन पुष्टि गर्नुहोस्.
दर सीमा (rate limits) लाई संकेतको रूपमा ह्यान्डल गर्नुहोस्
यदि API ले कोटा वा दर-सीमा प्रतिक्रिया दिन्छ भने, वर्तमान प्रयास रोक्नुहोस् र रिसेट जानकारी देखाउनुहोस्। आक्रामक पुनः प्रयासहरूले स्पष्ट क्षमता संकेतलाई आवाजमा बदल्छ र असम्बन्धित परीक्षणहरूलाई ढिलाइ गर्न सक्छ.
परीक्षण रनरमा समकालिकता सीमित गर्नुहोस्, विशेष गरी जब सूटले एकै पटक धेरै ठेगाना बनाउँछ। सानो कार्यकर्ता पूल सयौं समकालिक पोलिङ लूपहरू भन्दा डिबग गर्न सजिलो हुन्छ.
असफलताहरू लुकाए बिना सफा गर्नुहोस्
साक्ष्य संकलन पछि सफा प्रक्रिया चल्नुपर्छ। सफलतामा, सन्देशहरू हटाउनुहोस् वा छोटो अवधिको रखरखावलाई काम गर्न दिनुहोस्। असफलतामा, ठेगाना र सन्देश ID लाई सुरक्षित CI कलाकृतिहरूमा पर्याप्त समयसम्म राख्नुहोस्, त्यसपछि हटाउनुहोस्.
कुनै पनि प्रमाणिकरण कोड, निजी लिङ्क, वा पूर्ण HTML बडीहरू सार्वजनिक बिल्ड लगहरूमा कहिल्यै प्रिन्ट नगर्नुहोस्.
पुनः प्रयासहरूलाई इडेम्पोटेन्ट बनाउनुहोस्
परीक्षणलाई नयाँ ठेगानासहित नयाँ चलनको रूपमा पुनः प्रयास गर्नुहोस्। एउटै खाता र इनबक्समा एउटै अनुरोध दोहोर्याउँदा सफा अवस्थाबाट सुरु हुन्छ भन्ने अनुमान नगर्नुहोस्। प्रेषकले पुराना कोडहरू अमान्य गर्न, दोहोरिने अनुरोधहरूलाई थ्रोटल गर्न, वा दोहोरो निमन्त्रणा अस्वीकार गर्न सक्छ.
यदि नेटवर्क अनुरोध टाइमआउट हुन्छ भने, “कुनै प्रतिक्रिया प्राप्त भएन” र “कार्य सम्पन्न भएन” बीच फरक गर्नुहोस्। विनाशकारी पुनः प्रयास गर्नु अघि देखिने अवस्थालाई जाँच गर्नुहोस्.
असफलताको बिन्दु रिपोर्ट गर्नुहोस्
उपयोगी अटोमेशन असफलता यी चरणहरू मध्ये एकलाई पहिचान गर्छ:
- ठेगाना निर्माण असफल भयो;
- इमेल क्युमा राख्नु अघि उत्पादन कार्य असफल भयो;
- समयसीमा अघि मिल्ने सन्देश आएन;
- सन्देश आयो तर सामग्री मिलेन;
- प्रमाणिकरण कार्य असफल भयो;
- सफा प्रक्रिया असफल भयो।
त्यो वर्गीकरणले अस्थायी “इमेल परीक्षण असफल भयो” लाई टोलीले स्वामित्व लिन सक्ने काममा बदल्छ.
ठूलो परीक्षण म्याट्रिक्सको लागि, पढ्नुहोस् एक वास्तविक इमेल परीक्षण योजना. डेलिभरी निदानको लागि, प्रयोग गर्नुहोस् प्रमाणीकरण इमेल नआउँदा: बिग्रेको चरण पत्ता लगाउनुहोस्.