एकाधिक उपयोगकर्ता खातों और ब्राउज़र वातावरण का उपयोग करके किसी वेबसाइट का परीक्षण कैसे करें

एक भूमिका-और-क्षमता मैट्रिक्स बनाएं

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

परीक्षण से मेल खाने वाला अलगाव चुनें

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

केवल स्थिर पृष्ठों का ही नहीं, क्रॉस-उपयोगकर्ता घटनाओं का भी परीक्षण करें

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

परीक्षण डेटा को डिस्पोजेबल और ऑडिट योग्य रखें

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

भूमिका मैट्रिक्स परीक्षण: एक निमंत्रण को अतिरिक्त अनुमतियाँ नहीं देनी चाहिए

स्थिति

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

इसे सुरक्षित तरीके से कैसे चलाएं

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

वर्कफ़्लो कैसे विफल हो सकता है

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

पूर्णता के रूप में क्या गिना जाता है

प्रतिगमन परिणाम प्रत्येक परीक्षण खाते की भूमिका, अपेक्षित अनुमति/अस्वीकार मैट्रिक्स और परीक्षण की गई सटीक कार्रवाई की पहचान करता है। असफल परीक्षणों को नए संदर्भों में पुन: प्रस्तुत किया जाना चाहिए, जिसमें कोई भी स्क्रीनशॉट अनावश्यक निजी डेटा से मुक्त हो।

व्यावहारिक सत्यापन चरण

1. मालिक, संपादक और दर्शक सत्र को अलग करें
2. सर्वर प्राधिकरण के साथ-साथ दृश्यमान नियंत्रणों पर जोर दें
3. सक्रिय सत्र के दौरान परीक्षण अनुमति में परिवर्तन
4. सुइट के बाद परीक्षण फिक्स्चर को नष्ट या रीसेट करें

उदाहरण: मार्गदर्शन को व्यवहार में लाना

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

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

क्या अलग-अलग टैब अलग-अलग उपयोगकर्ताओं का अनुकरण कर सकते हैं?

यदि अलग-अलग संदर्भ कॉन्फ़िगर किए गए हैं तो वे ऐसा कर सकते हैं, लेकिन एक ही प्रोफ़ाइल में सामान्य टैब अक्सर समान-साइट कुकीज़ साझा करते हैं।

क्या एक समर्पित प्रोफ़ाइल सर्वर अनुमति परीक्षणों की जगह लेती है?

नहीं। प्राधिकरण को एप्लिकेशन बैकएंड के साथ-साथ यूआई द्वारा प्रस्तुत किया जाना चाहिए।

आधिकारिक दस्तावेज़ीकरण और आगे पढ़ना

प्रासंगिक प्लेटफ़ॉर्म क्षमताओं और अनुमतियों को सत्यापित करने के लिए इन प्राथमिक संदर्भों का उपयोग करें। विक्रेता दस्तावेज़ बदल सकते हैं; कार्रवाई करने से पहले वर्तमान शर्तों और उत्पाद संस्करण की पुष्टि करें।

• नाटककार: ब्राउज़र संदर्भ