कार्यात्मक/स्वीकृति परीक्षण की उचित संरचना

Question

मैं वर्तमान में एक परियोजना के लिए एक स्वचालित कार्यात्मक/स्वीकृति परीक्षण सूट बनाने पर काम कर रहा हूं, लेकिन मेरे पास इस प्रकार के परीक्षणों को लिखने में बहुत अधिक अनुभव नहीं है, इसलिए मैं कुछ प्राप्त करना चाहता था उन्हें ठीक से संरचित करने पर इनपुट। विशेष रूप से, मैं आर्किलियन के ग्रैफेन एक्सटेंशन के साथ काम कर रहा हूं।

उदाहरण के लिए, मैं 3 टेस्ट मैचों, राशि कहना ए, बी, और सी

टेस्टा: आवेदन में एक खाते में प्रवेश टेस्ट। इसलिए, यदि परीक्षण सफल होता है, तो ब्राउज़र खाते के घर/जानकारी पृष्ठ पर होना चाहिए।

टेस्टबी: किसी खाते के पासवर्ड को संशोधित करने वाले टेस्ट। इसके लिए खाते में लॉग इन करने की आवश्यकता होगी, फिर पासवर्ड परिवर्तन कार्यक्षमता का परीक्षण करना होगा।

टेस्टसी: किसी खाते के ईमेल को संशोधित करने वाले टेस्ट। इसके लिए फिर से खाते में लॉग इन करने की आवश्यकता होगी, फिर ईमेल परिवर्तन कार्यक्षमता का परीक्षण किया जाएगा।

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

प्रश्न: स्वचालित कार्यात्मक/स्वीकृति परीक्षण प्रत्येक प्रक्रिया को डुप्लिकेट करना चाहिए जो परीक्षण की पुष्टि करने के लिए जरूरी है? इस मामले में, टेस्टबी और टेस्टसी को कुछ और करने से पहले खाते में लॉगिन करने की आवश्यकता है। प्रत्येक परीक्षा स्पष्ट रूप से की तरह कुछ बुलाना चाहिए:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assertTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

या मैं सत्र कि टेस्ट बी और सी द्वारा इस्तेमाल किया जा सकता में एक खाता मजाक का किसी तरह का उपयोग करना चाहिए, ताकि वे भी टेस्टा अगर असफल नहीं (वास्तविक लॉगिन परीक्षण) करता है?

चूंकि ये उपयोगकर्ता स्वीकृति परीक्षण हैं, मेरा विचार यह था कि उन्हें वही करना चाहिए जो उपयोगकर्ता करेंगे और जब भी आवश्यक हो, लॉग इन करें, लेकिन मुझे यकीन नहीं है कि यह अनावश्यक नकल है जिसे अलग-अलग संभाला जाना चाहिए (यानी, कार्यक्षमता की इकाइयों की तरह व्यवहार किया जाता है, एक मानक इकाई परीक्षण के समान) और मैं इस क्षेत्र में अधिक अनुभव वाले किसी से प्रतिक्रिया प्राप्त करना चाहता था।

अग्रिम धन्यवाद। उम्मीद है कि मेरा सवाल बहुत गड़बड़ नहीं है। :)

Answer 1

मैंने व्यक्तिगत रूप से ऐसा किया है ताकि प्रत्येक टेस्ट केस जितना संभव हो सके उपयोगकर्ताओं की कार्रवाई को दोहराए, लेकिन जहां आवश्यक हो वहां जगहों को काट दें। उदाहरण के लिए, टेस्टा: लॉग इन, सही वेबसाइट पर जाता है, इसकी एडमिन सिस्टम पर जाता है, उपयोगकर्ता को पाता है, और उपयोगकर्ता की जानकारी (जैसे नाम) का हिस्सा हटा देता है, टेस्टबी: लॉग इन इन, सही वेबसाइट पर जाता है, जाता है यह व्यवस्थापक प्रणाली है, उपयोगकर्ता को पाता है, और पूरी तरह से बटन के माध्यम से उपयोगकर्ताओं को हटाने का प्रयास करता है।

टेस्टा और टेस्टबी उसी पृष्ठ पर समाप्त होता है - उपयोगकर्ता विवरण पृष्ठ। तो परीक्षण ए में, मैं इसे ठीक से कर सकता हूं, बिल्कुल उपयोगकर्ता कैसे करता है, लेकिन परीक्षण बी में, मैं उस उपयोगकर्ता के लिए सीधे विवरण पृष्ठ पर जाता हूं, जैसा मैन्युअल रूप से सही नेविगेशन के माध्यम से जाने के विपरीत होता है। क्यूं कर?

समय बचाता है, परीक्षण बी में नेविगेशन को फिर से क्यों करना चाहिए जब परीक्षण ए पहले से परीक्षण करता है?

याद रखें कि परीक्षण एक दूसरे पर निर्भर नहीं होना चाहिए - अगर सभी तीन परीक्षण असफल क्योंकि आप प्रवेश नहीं कर सकते हैं - कि पूरे मुद्दे, आप प्रवेश नहीं कर सकते, तो आप अन्य कार्यों के किसी भी नहीं कर सकता है।

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

Answer 2

यह वास्तव में एक प्रति-परियोजना प्रश्न है, क्योंकि दोनों वैध दृष्टिकोण हैं लेकिन विभिन्न परिस्थितियों में किसी को और अधिक प्राथमिकता दी जानी चाहिए। एक बड़ी प्रणाली में मैं टेस्ट केस को शुरू से ही खत्म करना पसंद करता हूं इस पर ध्यान दिए बिना कि यह कितनी बार कदम उठाता है (उदाहरण के लिए। मैं प्रत्येक परीक्षण के लिए लॉगिन करता हूं)। मेरा मानना ​​है कि अरान ने पहले ही कहा है (+1!)। कारण मैं आमतौर पर ऐसा करता हूं क्योंकि कभी-कभी पिछली स्क्रीन से ली गई एक स्थिति बाद में एक त्रुटि का कारण बन सकती है और यही वह चीज है जो स्वचालित परीक्षण ढूंढने के लिए बहुत अच्छी है। हालांकि, मैं यह सुनिश्चित करता हूं कि परीक्षण डेटा लीड अप चरणों के लिए मान्य है और सबसे तेज़ समाधान संभव है। उदाहरण के लिए, लॉग इन की जांच करते समय लॉगिन हमेशा सही उपयोगकर्ता और पासवर्ड होना चाहिए, या तो बस मान लें कि इसे बाद में अपवाद से निपटना चाहिए और किसी जटिल 'अधिक महत्वपूर्ण' के बजाय पृष्ठ पर आसानी से पहचाने जाने योग्य तत्व की खोज करना चाहिए।

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

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

Answer 3

एक उपयोगकर्ता स्वीकृति परीक्षण आप उपहास करने के लिए, लेकिन के रूप में के रूप में जिस तरह से एक अंतिम-उपयोगकर्ता प्रणाली का प्रयोग करेंगे करने के लिए संभव के रूप में करीब हो नहीं करना चाहती में नहीं था।

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

जुनीट में, assertTrue के बजाय assumeTrue का उपयोग कर सकते हैं। तो आपका टेस्टबी बन जाएगा:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assumeTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

अब, अगर मान लेता है तो मुकदमा विफल हो जाता है, परीक्षण को केवल अनदेखा किया जाता है। आपका टेस्टा अभी भी असफल रहेगा, हालांकि, आपको और आपके अंतिम उपयोगकर्ता को बताएं कि वास्तविक समस्या क्या है।