რეალური ელფოსტის სატესტო გეგმა: რეგისტრაცია, პაროლის გადატვირთვა, მოწვევა და ელფოსტის შეცვლა

„ელფოსტა მივიდა“ არ არის საკმარისი სატესტო შედეგი.

რეგისტრაციის შეტყობინება შეიძლება დაემატოს შემოსულ ყუთში არასწორ მიმღებით, გადაცილებული ბმულით, დაზიანებული მობილური განლაგებით, პროდუქციის ჰოსტნეიმით, ან საგანით, რომელიც სხვა ენაზე აზრი არ აქვს. კარგი ელფოსტის ტესტირება მიჰყურება მთლიანი მომხმარებლის მოგზაურობას და დატოვებს საკმარის მტკიცებულებებს შეცდომის დიაგნოსტიკისთვის.

დროებით შემოსული ყუთები აქ სასარგებლოა, რადგან თითოეული გაშვება შეიძლება დაიწყოს სუფთა მისამართით. შემოსული ყუთი უნდა იყოს ერთჯერადი; სატესტო შედეგი კი არა.

შექმენით პატარა, მიზანშეწონილი მატრიცა

დაიწყეთ ნაკადებით, რომლებიც შეიძლება მომხმარებელს დაბლოკოთ:

• ახალი ანგარიშის გადამოწმება;
• პაროლის გადატვირთვა;
• გუნდის ან სამუშაო სივრცის მოწვევა;
• ელფოსტის შეცვლის დადასტურება;
• შესვლის ბმული ან ერთჯერადი კოდი;
• უსაფრთხოების გაფრთხილება მგრძნობიარე ქმედების შემდეგ.

თითოეული ნაკადისათვის, ტესტირეთ ბედნიერი გზა, ერთი გადაცილებული ან თავიდან გამოყენებული ავტორიზაციის დეტალი, და ერთი მიმღების-გვერდის შეცდომა. ეს უფრო მეტი რეალური შეცდომა იპოვის, ვიდრე დათავსოთ ათასობით ერთნაირი ბედნიერი-გზის შეტყობინება.

გამოიყენეთ ერთი შემოსული ყუთი თითო სცენარისთვის

ერთმისამართის მრავალჯერადი გამოყენება ქმნის გაურკვევლობას. ძველი გადატვირთვის შეტყობინება შეიძლება შეცვალოს უახლესს, ხოლო პარალელური ტესტები შეიძლება ერთმანეთს ბმულებს მოხმარებინათ.

გენერირეთ უნიკალური მისამართი თითოეული სატესტო შემთხვევის ან სატესტო გაშვებისათვის. ჩანაწერით მას ერთად ბილდინგის ნომერი, გარემო, ლოკალი და სცენარი. თუ ტესტი ვერ მოხერხდება, მისამართი გახდება მტკიცებულებების ნაწილი და შეიძლება დაინახოს, სანამ შენახვის ვადა არ გადის.

არ გამოიყენოთ რეალური მომხმარებლის მისამართები სტაჟინგში. ეს იწვევს არასასურველ შეტყობინებებს, ბინდება ანალიტიკას, და აეროვნებს ავტომატურ გასუფთავებას.

დადასტურეთ კონვერტი ბოდიშის წინ

პირველივე რამეზე დაწკაპირებამდე, გადამოწმეთ:

1. შეტყობინება გაიგზავნა ზუსტად იმ მისამართზე, რომელიც შექმნილია ამ ტესტისთვის.
2. გამგზავნის დომენი არის იმ გარემოსთვის მოსალოდნელი.
3. საგანი იდენტიფიცირებს ქმედებას, არ გამჟღავნებს მგრძნობიარე მონაცემებს.
4. მივიდა მხოლოდ იმ რაოდენობის შეტყობინება, რომელიც უნდა იყოს.
5. ტაიმსტამპი უფრო გვიანია, ვიდრე ქმედება, რომელიც მას გამოიწვია.

ეს შემოწმებები იპოვენ რაუტინგის და დუბლირების პრობლემებს, სანამ ბოდიშის პარსერი მათ დაიმალავს.

ტესტირეთ შინაარსი როგორც მომხმარებელი ხედავს

გახსნათ შეტყობინება როგორც ნაზად, ისე ფართოდ viewport-ით. დარწმუნდით, რომ მთავარი ქმედება ხილულია, ტექსტის ცარიელი ვერსია გასაგებია, და გრძელი მისამართები ან URL-ები არ ბლოკირებენ განლაგებას.

კოდზე დაფუძნებული ნაკადისათვის, გადამოწმეთ, რომ უახლესი კოდი მუშაობს ერთხელ და შემდეგ ვერ მუშაობს. ბმულზე დაფუძნებული ნაკადისათვის, დადასტურეთ ჰოსტი და გარემო, სანამ გახსნით მას. სტაჟინგის შეტყობინება, რომელიც მიმართავს პროდუქციას, არის რელიზის ბლოკერი, მიუხედავად იმისა, რომ ბმული ტექნიკურად მუშაობს.

ასევე შემოწმეთ ნაკლებად შთამბეჭდავი დეტალები: პასუხის ქმედება, მხარდაჭერის კონტაქტი, ვადის ფორმულირება, ლოკალი, და ანგარიშის ან სამუშაო სივრცის სახელი, რომელიც გამოჩნდება შეტყობინებაში.

უარყოფითი შემთხვევები, რომლებიც ღირს თავიანთი ადგილას

სასარგებლო უარყოფითი ტესტები მოიცავს:

• მეორე კოდის მოთხოვნა და პირველის გაუქმების დადასტურება;
• გადაცილებული ბმულის გახსნა;
• იგივე ბმულის ორიჯერ გახსნა;
• ანგარიშის მდგომარეობის შეცვლა შეტყობინების გამოყენებამდე;
• მისამართის მოწვევა, რომელიც უკვე ეკუთვნის წევრს;
• მხარდაუჭერელი ან არასწორ ფორმატში არსებული მისამართის შეყვანა;
• მიწოდების დაყოვნება, რომელიც საკმარისად დიდია, რომ გადაცილებული ვადის საზღვარი გადალახოს.

ეს ტესტები იპოვენ race condition-ებს და შეცდომის შეტყობინებებს, რომლებიც მარტივი შემოსული ყუთის შემოწმებით არასდროს იპოვება.

პროდუქტის შეცდომის გამოყოფა მიწოდების დაყოვნებიდან

როცა შეტყობინება აკლია, შეინახეთ დროის ნიშნები მომხმარებლის ქმედებისთვის, აპლიკაციის რიგში დასაყენებლად, პროვაიდერის გადაცემის, და შემოსული ყუთის მიღების, როდესაც ეს სიგნალები ხელმისაწვდომია. ცარიელი შემოსული ყუთის სქრინშოტი აჩვენებს მხოლოდ, რომ შეტყობინება იმ მომენტში არ იყო ხილული.

გამოიყენეთ დიაგნოსტიკური სეკვენცია ელფოსტის გადამოწმება არ მოდის: იპოვეთ დაზიანებული ნაბიჯი სანამ გაგზავნით გაურკვეველ “ელფოსტა დაზიანებულია” საკითხს.

რა ავტომატიზაცია

ავტომატიზირეთ სტაბილური კონტრაქტები:

• გენერირება უნიკალური მისამართის;
• პროდუქტის ქმედების ტრიგერი;
• პოლინგი შეზღუდული დროის ლიმიტით და ბექოფით;
• მოთხოვნის შესაბამისი გამგზავრი და საგანი;
• ახალესი შესაბამისი შეტყობინების წაკითხვა;
• კოდის ან ბმულის გადამოწმება პროდუქტის მიმართ;
• სასარგებლო შეცდომის მტკიცებულებების შენახვა;
• გასუფთავება.

შეინარჩუნეთ ვიზუალური მიმოხილვა, ტექსტის ხარისხი, და უცნაური კლიენტის ქცევა ფოკუსირებულ მანუალურ გადახედვაში. ავტომატიზაცია კარგია განმეორებით, არა გემოვნებით.

სანდო დროებით-ინბოქსი API ავტომატიზაცია მოიცავს API მხარეს, მათ შორის პოლინგსა და გასუფთავებას.

სასარგებლო შეცდომის ანგარიში

ანგარიში, რომელსაც დეველოპერებს შეუძლია მოქმედება, შეიცავს სცენარს, გარემოს, მისამართს, ტრიგერის დროის, მოსალოდნელი გამგზავრი, დაკვირვებული შეტყობინებები, ბოლო პოლინგის დრო, პასუხის სტატუსი, და სქრინშოტს ან სანსანიტიზირებულ ბოდიშის ნაწერს. არასოდეს მიმაგრეთ ცოცხალი საიდუმლოების ან მრავალჯერად გადამოწმების ბმულები საჯარო საკითხზე.

მიზანი არაა ელფოსტის არასანდოობის დამადასტურება. მიზანია, რომ გამოვიყენოთ, რომელი კონტრაქტი ჩავარდა და დავტოვოთ განმეორებად გზა გასწორებისთვის.