प्रतिगमन परीक्षण वर्डप्रेस वेबसाइटों के लिए सर्वोत्तम अभ्यास?


22

नमस्ते,

मैं यह सुनना चाहता हूं कि वर्डप्रेस वाले ग्राहकों के लिए जटिल गैर-ब्लॉग समाधान देने वाले अन्य क्या एक मंच के रूप में उपयोग कर रहे हैं जो वे स्वचालित प्रतिगमन परीक्षण के लिए उपयोग कर रहे हैं ?

"प्रतिगमन परीक्षण" शब्द से परिचित न होने वालों के लिए विकिपीडिया इसे इस प्रकार परिभाषित करता है:

रिग्रेशन टेस्टिंग किसी भी प्रकार का सॉफ्टवेयर टेस्टिंग है जो प्रोग्राम में बदलाव के बाद सॉफ्टवेयर की त्रुटियों को उजागर करना चाहता है (जैसे बगफिक्स या नई कार्यक्षमता), प्रोग्राम को रिटायर करके बनाया गया है। प्रतिगमन परीक्षण का उद्देश्य यह आश्वस्त करना है कि एक बदलाव, जैसे कि बगफिक्स, ने नए बग का परिचय नहीं दिया।

विकिपीडिया के बारे में अधिक बताते हुए कहा जाता है कि अभी जो मैं इस परियोजना पर अनुभव कर रहा हूं वह निम्नलिखित है:

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

क्रियाओं और फ़िल्टर की वैश्विक प्रकृति के साथ, मुझे लगता है कि जटिलता बढ़ने लगी है क्योंकि मैं अधिक ग्राहक-अनुरोधित कार्यक्षमता जोड़ता हूं और एक जटिल प्लगइन को स्थिर करना कठिन हो जाता है, खासकर यदि यह WP_Queryडेटाबेस को बहुत अधिक कॉल और अपडेट करता है। ।

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

मैं इसे एक समुदाय विकी के रूप में स्थापित कर रहा हूं, उम्मीद है कि हम यहां सर्वोत्तम प्रथाओं को इकट्ठा कर सकते हैं, लेकिन अगर कोई अन्य वर्डप्रेस पेशेवर उपयोग कर रहे हैं तो मैं प्रक्रियाओं को सुनने के लिए वास्तव में उत्सुक हूं।


मुझे लगता है कि आप अपने स्वयं के कोड (थीम / प्लगइन्स) के परीक्षण के बारे में बात कर रहे हैं? जब आप नया कोड बनाते हैं, या जब आप "पर्यावरण" (WP, अन्य प्लगइन्स) को अपडेट करते हैं? अथवा दोनों? मुझे लगता है कि प्रो वेबमास्टर्स भी वेब ऐप्स (सेलेनियम और सामान) का परीक्षण करने के बारे में अच्छी सलाह दे सकते हैं - शायद क्रॉस-पोस्टिंग एक अच्छा विचार है?
जान फेब्री डे

@ जान फेब्री - हाँ, मेरे अपने कोड का परीक्षण। क्रॉस-पोस्टिंग के बारे में अच्छा विचार है, मैं जल्द ही ऐसा करूंगा।
माइकस्किंकेल

जवाबों:


10

PHPUnit के मन में आया होगा, अगर WP परीक्षण सूट इतना टूटा नहीं था, और अगर WP को डिज़ाइन किया गया था और इस तरह से लिखा गया था कि यह वास्तव में ठीक से परीक्षण किया जा सके। ;-)

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

मैंने जिन रंगीन चीजों को देखा है उनमें से एक है:

  • WP एपीआई में एक सूक्ष्म परिवर्तन आपके प्लगइन की कार्यक्षमता को प्रभावित करता है, उदाहरण के लिए जिस हुक पर आप एक शब्द आईडी प्राप्त करने के लिए उपयोग किए जाते हैं और यह अब एक शब्द वर्गीकरण आईडी प्राप्त कर रहा है। (संभावना अच्छी है कि आपके परीक्षण की शर्तों को आसानी से दोनों के लिए एक ही आईडी है)।

  • WP API में एक सूक्ष्म परिवर्तन के परिणामस्वरूप खराब इनपुट WP_Errorके पहले अपेक्षित मूल्य के बजाय आपके ऑब्जेक्ट प्राप्त होते हैं false

  • आपका प्लग-इन म्यू-प्लग फ़ोल्डर से जोड़ा जाता है, जिसके परिणामस्वरूप एक अलग कोड प्रवाह होता है।

  • आपके प्लगइन ने तब तक ठीक काम किया जब तक कि मेमस्कैड या कुछ अन्य लगातार स्टोर सक्षम नहीं हो गए।

  • आपका प्लगइन तब तक ठीक काम करता है जब तक कि तिरछे स्विच_टो_ब्लॉग () को कॉल न हो जाए।

  • एक प्लगइन हुक को बदल देता है जिसे यह कहा जाता है पर रहता है, और अनजाने में इसे साइड इफेक्ट के रूप में बाधित करता है।

  • एक प्लगइन (संयुक्त राष्ट्र?) जानबूझकर आपके इनपुट या आउटपुट डेटा के साथ उस बिंदु पर गड़बड़ करता है जहां चीजें टूटी हुई दिखती हैं, भले ही आप गलती पर न हों।

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

ओह, और ... मुझे भी संलग्नक, ऑटो ड्राफ्ट, संशोधन, मेनू आइटम और जो कि अंत में पोस्ट टेबल में संग्रहीत नहीं हैं, के हमले पर शुरू नहीं मिलता है।

सौभाग्य... :-)


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

1
वास्तव में, ध्यान दें कि कुछ फ्रेमवर्क में उपकरण हैं (Symfony2 और Li3 के नाम लेकिन दो) जो एक काल्पनिक ब्राउज़र का उपयोग करके, वास्तविक साइट का परीक्षण करने की अनुमति देते हैं। प्रश्न में घटक अन्य चीजों के लिए पुन: प्रयोज्य हैं। इस प्रकार, आप वास्तव में अपनी साइट के व्यवस्थापक स्क्रीन में हेरफेर कर सकते हैं और सत्यापित कर सकते हैं कि जो आप कर रहे हैं उसके अपेक्षित परिणाम हैं।
डेनिस डे बर्नार्डी

7

आपको सेलेनियम पर दृढ़ता से विचार करना चाहिए ।

यह आपको क्रियाओं को रिकॉर्ड करने की अनुमति देता है (उदाहरण के लिए एक फॉर्म में डेटा दर्ज करना, एक लिंक पर क्लिक करना) और फिर आप दावे कर सकते हैं। यह PHPUnit के साथ भी एकीकृत है। मैं अत्यधिक दो मिनट के डेमो की जाँच करने की सलाह देता हूं।


सुझाव के लिए धन्यवाद, मैं इसके बारे में पहले सुना था। क्या आपने वास्तव में वर्डप्रेस परियोजनाओं के लिए उपयोग किया है? बस उत्सुक।
माइकस्किंकल

हाँ। मैंने इसका उपयोग एक प्लगइन के परीक्षण के लिए किया है जिस पर मैं काम कर रहा हूं। पिछले जीवन में, हमने इसका इस्तेमाल नैदानिक ​​अनुसंधान के लिए ईडीसी ऐप का परीक्षण करने के लिए किया था।
एथन सीफ़र्ट

1

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

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

आरंभ करने में आपकी सहायता के लिए कई वर्डप्रेस-विशिष्ट पुस्तकालय भी हैं:


1
सेलेनियम और कोड अपवाद अनन्य नहीं हैं। आप सेलेनियम को चलाने के लिए डब्ल्यूपी-ब्राउज़र का उपयोग कर सकते हैं [जो क्रोम जैसे एक वास्तविक ब्राउज़र को चलाता है], प्रेत [जो जेएस समर्थन के साथ एक गैर-गिनी ब्राउज़र है], या यहां तक ​​कि PHPBrowser जो एक गूंगा कर्ल ब्राउज़र है [बहुत तेज़ या कोई जेएस। यानी एपीआई परीक्षण]। WP-Browser उनमें से किसी को भी ड्राइव कर सकता है।
जिम मगुइरे
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.