क्यूए स्टाफ कैशिंग लॉजिक का परीक्षण कैसे कर सकता है जो वे नहीं देख सकते हैं?

33

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

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

लेकिन क्या कोई इस स्थिति के लिए कुछ बेहतर प्रथाओं का सुझाव दे सकता है?

testing caching

— जोशुआ फ्रैंक
स्रोत

6

संबंधित: लोड टेस्ट मेथोडोलॉजी

— gnat

5

अन्य संबंधित प्रश्न: यूनिट परीक्षण विधियों के लिए सर्वोत्तम प्रथाएं जो कैश का भारी उपयोग करती हैं? वास्तविक समय इकाई परीक्षण - या "अब नकली कैसे करें"? यूनिट परीक्षण समयबद्ध कोड?

— रोंगोंग १15

5

मैं पूरे दिन प्रदर्शन पर काम करता हूं और "क्यूए आपके परिवर्तन का परीक्षण कैसे कर सकता है?" एक सवाल है जो मुझे लगातार पूछा जाता है।

— ब्रैंडन

1

आम तौर पर एक कैश का मतलब मेमोरी में परिणाम को स्टोर करके एक ऑपरेशन को गति देना होता है जो अन्यथा किसी अन्य स्रोत (डीबी, रिमोट सर्वर, कम्प्यूटेशनल रूप से महंगी विधि, आदि) से आएगा। इसलिए समय को मापने के लिए जब कैश को मारना सबसे आसान तरीका लगता है तो इसे लेना चाहिए। इसके अलावा बासी कैश समस्याओं के लिए जाँच करें (वास्तविक डेटा दिखाई नहीं देने के कारण पिछले संस्करण को अभी भी कैश किया गया है)

— गॉर्डन

37

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

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

अपने दृष्टिकोण का उपयोग करना भी अच्छा है। यदि इनमें से कोई भी स्वचालित परीक्षणों में लिपटे हुए हैं जो परिणामों की जांच करते हैं, तो किसी को उत्तर खोजने के लिए लॉग के माध्यम से नहीं देखना होगा।

— एंडी विसेंडांगर
स्रोत

कैशिंग के बजाय परीक्षण प्रदर्शन के लिए +1। व्यवसाय मूल्य क्या है? (कोई नहीं।) निश्चित रूप से आप किसी चीज पर ध्यान देने योग्य प्रभाव की दिशा में काम कर रहे हैं - आप इसे लागू करने में समय क्यों व्यतीत करेंगे? उस प्रभाव के लिए परीक्षण करें।

— अलेक्जेंडरबर्ड

74

आपने कैश लागू किया (मुझे लगता है) क्योंकि सिस्टम काफी अच्छा प्रदर्शन नहीं कर रहा था। यह कुछ ऐसा है जो उपयोगकर्ता के लिए प्रासंगिक है। यहां ऐसी चीजें हैं जो QA जांच सकती हैं:

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

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

— durron597
स्रोत

1

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

— एरिक

4

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

— jpmc26

3

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

— jpmc26

1

@ एरिक कृपया मुझे यह तर्क न दें कि भाषा और शब्दार्थ आपके साथ कैसे काम करते हैं। मैं आपको इस StackExchange पर 5 उदाहरण खोजने के लिए चुनौती देता हूँ जहाँ इस शब्द का उपयोग 30 मिनट से कम समय में किया जाता है। इसके अलावा, उस परिभाषा के अनुसार, सबसे अच्छा एक अलग क्यूए समूह उत्पाद से परे समस्याओं को संबोधित करने के लिए कर सकता है, डेवलपर्स पर नीतियां लागू करना है, और जब नीति और प्रक्रिया अच्छे उत्पाद बनाने से ऊपर उठती है, तो आप आमतौर पर खराब उत्पादों के साथ समाप्त होते हैं। इसके अलावा, मैं आपको आश्वस्त कर सकता हूं कि "क्यूए" जिन लोगों के साथ मैं काम करता हूं, वे निश्चित रूप से परीक्षक हैं, और मेरी विकास प्रक्रिया के बारे में बहुत कम कहते हैं।

— jpmc26

4

@ ईरिक: अधिक समग्र दृष्टिकोण के बारे में "क्यूए" को परिभाषित करने वाली कंपनी या लोगों के समूह को रोकना नहीं है। हालाँकि, मेरे अनुभव में (5 बहुत अलग-अलग कंपनियों में) क्यूए स्टेज जैसा कि नाम दिया गया है - और जो इसमें विशेषज्ञ हैं - सॉफ्टवेयर विकास में आमतौर पर सिस्टम व्यवहार के ब्लैक-बॉक्स परीक्षण पर ध्यान केंद्रित किया जाता है। जबकि हमारे पास व्यापक गुणवत्ता के मुद्दों पर विशेषज्ञ कोणों को कवर करने के लिए "गुणवत्ता नियंत्रण", "क्वालिट" और अधिक आविष्कार किए गए नाम भी हो सकते हैं।

— नील स्लेटर

3

एक ब्लैक बॉक्स में गहरी स्थित महत्वपूर्ण व्यावसायिक तर्क या सिस्टम स्थिति को दफन करना सही सिस्टम व्यवहार को सत्यापित करना मुश्किल बनाता है। संपूर्ण प्रणाली की तुलना में सिस्टम में किसी एकल घटक के व्यवहार का आसानी से परीक्षण करना आसान है। मैं स्पष्ट रूप से कुछ तंत्रों के माध्यम से ऐसी चीजों को उजागर करने का पक्ष लेता हूं ताकि यह इकाई / प्रतिगमन / एकीकरण / क्यूए कुछ सार्थक फैशन में परीक्षण किया जा सके।

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

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

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

— एरिक
स्रोत

3

टेस्ट प्रदर्शन, जैसा कि एंडी के जवाब में संकेत दिया गया है।

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

ऐसा करने के लिए, आपको एक प्रदर्शन परीक्षण वातावरण सेट करना चाहिए , जितना संभव हो सके, और लागत, दर्पण उत्पादन की अनुमति देता है। यह संभवत: आपका वर्तमान विकास वातावरण नहीं होगा जो तेजी से अनुप्रयोग विकास की अनुमति देने के लिए छोटा और अधिक आत्म-निहित होना चाहिए। विकास वातावरण भी कम कैशिंग का उपयोग करते हैं और इसलिए प्रदर्शन परीक्षण के लिए उत्पादन का अच्छी तरह से प्रतिनिधित्व नहीं करते हैं।

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

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

स्पष्ट होना

बेस लाइन प्रदर्शन परीक्षण उस समय का परीक्षण करने के लिए है जो एक अनुरोध करता है।
लोड परीक्षण प्रदर्शन परीक्षण के समान है, लेकिन जब सिस्टम अन्य अनुरोधों से लोड के तहत भी प्रतिक्रिया को देखता है।

आपको निम्न लिंक भी मददगार लग सकते हैं:

— माइकल डुरंट
स्रोत

2

सर्वर रिबूट करने के लिए परीक्षकों को प्राप्त करना याद रखें और जांचें कि उनके द्वारा दर्ज किया गया डेटा अभी भी है। मैंने एक प्रणाली देखी जिसमें परीक्षण के कई महीने थे, जब ऐसा किया गया था तो असफल हो गए थे!

परीक्षण करने के लिए सबसे कठिन हिस्सा यह है कि हालांकि डेटा अपडेट किया गया है, कैश से लौटाए गए परिणाम कभी भी आउट-ऑफ-डेट नहीं होते हैं।

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

— इयान
स्रोत

1

यह वास्तव में एक बहुत ही सीधा जवाब है और यह कैशिंग के स्तर से संबंधित है। कैशिंग सही होने पर आप क्या निरीक्षण करेंगे अनुरोधों के लक्ष्य पर अनुरोधों की अनुपस्थिति है। तो, यह "अपेक्षित परिणाम" के हैकने क्यूए वाक्यांश के लिए नीचे आता है।

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

आदि...

— जेम्स पुली
स्रोत

0

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

— एलेक्स डी
स्रोत

0

कैशिंग तर्क कुछ ऐसा है जो डेवलपर द्वारा परीक्षण किया जाना चाहिए क्योंकि क्यूए मुख्य रूप से ब्लैक-बॉक्स परीक्षण करता है।

QA केवल प्रदर्शन पहलुओं या इस प्रकार आपके द्वारा कार्यान्वित किए गए किसी भी सुधार के बारे में परवाह करेगा, आप कैशिंग को सक्षम / अक्षम करने के लिए एक तंत्र प्रदान कर सकते हैं या प्रदर्शन में सुधार के लिए जो भी तंत्र आप उपयोग करते हैं, और फिर वे प्रदर्शन अंतर को सत्यापित कर सकते हैं। बेशक QA भी आपके प्रदर्शन में सुधार के साथ-साथ पुरानी रिलीज को भी सत्यापित कर सकता है।

— फ्रेड थॉमसन
स्रोत

-4

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

— user204667
स्रोत

3

मुझे पूरा यकीन नहीं है कि मैं समझता हूं कि आप क्या कह रहे हैं, या आपका उत्तर जो कहता है वह सात पिछले उत्तर में नहीं है।