ਇੱਕ ਅਣਭਰੋਸੇਯੋਗ ਈਮੇਲ ਟੈਸਟ ਛੋਟਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਪਤਾ ਬਣਾਓ, ਪੰਜ ਸਕਿੰਟ ਲਈ ਸੌਂ, ਪਹਿਲਾ ਸੁਨੇਹਾ ਪੜ੍ਹੋ, ਅਤੇ ਉਮੀਦ ਕਰੋ ਕਿ ਇਹ ਇਸ ਚਲਾਉਣ ਨਾਲ ਸੰਬੰਧਤ ਹੈ।
ਭਰੋਸੇਯੋਗ ਵਰਜਨ ਹਾਲੇ ਵੀ ਸਧਾਰਨ ਹੈ, ਪਰ ਇਹ ਡਿਲੀਵਰੀ ਨੂੰ ਅਸਿੰਕਰੋਨਸ ਮੰਨਦਾ ਹੈ। ਇਹ ਇੱਕ ਵਿਲੱਖਣ ਪਤਾ ਬਣਾਉਂਦਾ ਹੈ, ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ ਦਰਜ ਕਰਦਾ ਹੈ, ਡੈਡਲਾਈਨ ਦੇ ਅੰਦਰ ਪੋਲ ਕਰਦਾ ਹੈ, ਇਰਾਦੇ ਵਾਲਾ ਸੁਨੇਹਾ ਮੇਲ ਕਰਦਾ ਹੈ, ਉਤਪਾਦ ਕਾਰਵਾਈ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਗਲਤ ਹੋਣ 'ਤੇ ਕਾਫ਼ੀ ਸੰਦਰਭ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ।
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 ਟੈਸਟ ਆਉਟਪੁੱਟ ਵਿੱਚ ਸੰਭਾਲੋ ਤਾਂ ਕਿ ਰੀਟ੍ਰਾਈਜ਼ ਅਣਜਾਣੇ ਵਿੱਚ ਇਸਨੂੰ ਦੁਬਾਰਾ ਵਰਤ ਨਾ ਸਕਣ।
ਸੂਚੀ ਮੇਲ ਤੋਂ ਬਾਅਦ ਹੀ ਪੜ੍ਹੋ
ਇਨਬਾਕਸ ਲਿਸਟਿੰਗ ਸਸਤੀ ਖੋਜ ਕਦਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਚੁਣੀ ਗਈ ਉਮੀਦਵਾਰ ਲਈ ਹੀ ਪੂਰਾ ਸੁਨੇਹਾ ਲਿਆਓ। ਇਸ ਨਾਲ ਬੇਲੋੜੀ ਕੰਮ ਘਟਦੀ ਹੈ ਅਤੇ ਅਸੰਬੰਧਤ ਪ੍ਰਮੋਸ਼ਨਲ ਮੇਲ ਦੀ ਪਾਰਸਿੰਗ ਤੋਂ ਬਚਿਆ ਜਾਂਦਾ ਹੈ।
ਕਾਰੋਬਾਰੀ ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਸਿਰਫ਼ ਛੇ-ਅੰਕ ਦੀ ਸਤਰ ਦੀ ਮੌਜੂਦਗੀ ਨਹੀਂ। ਕੋਡ ਜਮ੍ਹਾਂ ਕਰੋ ਜਾਂ ਉਮੀਦਿਤ ਲਿੰਕ ਖੋਲ੍ਹੋ, ਫਿਰ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਖਾਤਾ ਸਹੀ ਹਾਲਤ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।
ਰੇਟ ਲਿਮਿਟ ਨੂੰ ਸੰਕੇਤ ਵਜੋਂ ਸੰਭਾਲੋ
ਜੇ API ਕੋਟਾ ਜਾਂ ਰੇਟ-ਲਿਮਿਟ ਰਿਸਪਾਂਸ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਮੌਜੂਦਾ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਰੋਕੋ ਅਤੇ ਰੀਸੈਟ ਜਾਣਕਾਰੀ ਦਿਖਾਓ। ਤੀਬਰ ਰੀਟ੍ਰਾਈਜ਼ ਇੱਕ ਸਪਸ਼ਟ ਸਮਰੱਥਾ ਸੰਕੇਤ ਨੂੰ ਸ਼ੋਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਅਤੇ ਅਸੰਬੰਧਤ ਟੈਸਟਾਂ ਨੂੰ ਦੇਰੀ ਕਰ ਸਕਦੇ ਹਨ।
ਟੈਸਟ ਰਨਰ 'ਤੇ ਸਮਕਾਲੀਤਾ ਨੂੰ ਸੀਮਿਤ ਕਰੋ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਇੱਕ ਸੂਟ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਪਤੇ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਵਰਕਰ ਪੂਲ ਸੈਂਕੜਿਆਂ ਸਮਕਾਲੀ ਪੋਲਿੰਗ ਲੂਪਾਂ ਨਾਲੋਂ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੀ ਹੈ।
ਫੇਲ੍ਹ ਹੋਣ ਨੂੰ ਲੁਕਾਏ ਬਿਨਾਂ ਸਫਾਈ ਕਰੋ
ਸਬੂਤ ਕੈਪਚਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕਲੀਨਅਪ ਚਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਫਲਤਾ 'ਤੇ, ਸੁਨੇਹੇ ਹਟਾਓ ਜਾਂ ਛੋਟੀ ਰਿਟੇਂਸ਼ਨ ਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦਿਓ। ਅਸਫਲਤਾ 'ਤੇ, ਜਾਂਚ ਲਈ ਪਤੇ ਅਤੇ ਸੁਨੇਹਾ ID ਨੂੰ ਸੁਰੱਖਿਅਤ CI ਆਰਟੀਫੈਕਟਸ ਵਿੱਚ ਕਾਫੀ ਸਮੇਂ ਲਈ ਰੱਖੋ, ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਮਿਟਾ ਦਿਓ।
ਪੁਬਲਿਕ ਬਿਲਡ ਲਾਗਜ਼ ਵਿੱਚ ਕਦੇ ਵੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕੋਡ, ਪ੍ਰਾਈਵੇਟ ਲਿੰਕ ਜਾਂ ਪੂਰੇ HTML ਬਾਡੀ ਪ੍ਰਿੰਟ ਨਾ ਕਰੋ।
ਰੀਟ੍ਰਾਈਜ਼ ਨੂੰ ਆਈਡੈਮਪੋਟੈਂਟ ਬਣਾਓ
ਟੈਸਟ ਨੂੰ ਨਵੇਂ ਪਤੇ ਨਾਲ ਇੱਕ ਨਵੀਂ ਰਨ ਵਜੋਂ ਦੁਬਾਰਾ ਚਲਾਓ। ਇਹ ਮੰਨੋ ਨਾ ਕਿ ਇੱਕੋ ਖਾਤੇ ਅਤੇ ਇਨਬਾਕਸ 'ਤੇ ਇੱਕੋ ਬੇਨਤੀ ਨੂੰ ਦੁਹਰਾਉਣਾ ਸਾਫ਼ ਹਾਲਤ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਭੇਜਣ ਵਾਲਾ ਪੁਰਾਣੇ ਕੋਡ ਨੂੰ ਅਵੈਧ ਕਰ ਸਕਦਾ ਹੈ, ਦੁਹਰਾਈਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਥਰੋਟਲ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਡੁਪਲੀਕੇਟ ਨਿਮੰਤਰਣ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ।
ਜੇਕਰ ਨੈੱਟਵਰਕ ਬੇਨਤੀ ਟਾਈਮ ਆਉਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ “ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਮਿਲਿਆ” ਨੂੰ “ਕਾਰਵਾਈ ਨਹੀਂ ਹੋਈ” ਤੋਂ ਵੱਖਰਾ ਕਰੋ। ਵਿਨਾਸ਼ਕਾਰੀ ਰੀਟ੍ਰਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਿੱਖਣ ਵਾਲੀ ਹਾਲਤ ਦੀ ਜਾਂਚ ਕਰੋ।
ਵਿਫਲਤਾ ਦਾ ਬਿੰਦੂ ਰਿਪੋਰਟ ਕਰੋ
ਇੱਕ ਲਾਭਦਾਇਕ ਆਟੋਮੇਸ਼ਨ ਵਿਫਲਤਾ ਇਨ੍ਹਾਂ ਚਰਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ:
- ਪਤਾ ਬਣਾਉਣਾ ਫੇਲ੍ਹ ਹੋਇਆ;
- ਉਤਪਾਦ ਕਾਰਵਾਈ ਈਮੇਲ ਕਤਾਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ੍ਹ ਹੋਈ;
- ਸਮਾਂ ਸੀਮਾ ਤੋਂ ਪਹਿਲਾਂ ਕੋਈ ਮਿਲਦੀ-ਜੁਲਦੀ ਸੁਨੇਹਾ ਨਹੀਂ ਆਇਆ;
- ਸੁਨੇਹਾ ਆ ਗਿਆ ਪਰ ਸਮੱਗਰੀ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ;
- ਪੁਸ਼ਟੀ ਕਾਰਵਾਈ ਫੇਲ੍ਹ ਹੋਈ;
- ਸਫਾਈ ਫੇਲ੍ਹ ਹੋਈ।
ਉਹ ਵਰਗੀਕਰਨ ਇੱਕ ਅਸਥਾਈ “ਈਮੇਲ ਟੈਸਟ ਫੇਲ੍ਹ ਹੋਇਆ” ਨੂੰ ਟੀਮ ਦੁਆਰਾ ਸੰਭਾਲੀ ਜਾ ਸਕਦੀ ਕੰਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਵੱਡੇ ਟੈਸਟ ਮੈਟ੍ਰਿਕਸ ਲਈ, ਅਸਲ ਈਮੇਲ ਟੈਸਟ ਯੋਜਨਾ ਪੜ੍ਹੋ। ਡਿਲਿਵਰੀ ਨਿਦਾਨ ਲਈ, ਪੁਸ਼ਟੀ ਈਮੇਲ ਨਹੀਂ ਆ ਰਹੀ: ਟੁੱਟਿਆ ਕਦਮ ਲੱਭੋ ਵਰਤੋ।