क्या हमें परीक्षण डेटा की आवश्यकता है या हम यूनिट परीक्षणों और मैनुअल परीक्षण पर भरोसा कर सकते हैं?

Question

वर्तमान में हम एक मध्यम / बड़े PHP / MySQL प्रोजेक्ट पर काम कर रहे हैं। हम PHPUnit और Qunit के साथ इकाई परीक्षण कर रहे हैं और हमारे पास दो पूर्णकालिक परीक्षक हैं जो मैन्युअल रूप से एप्लिकेशन का परीक्षण कर रहे हैं। हमारा परीक्षण (नकली) डेटा वर्तमान में SQL स्क्रिप्ट के साथ बनाया गया है।

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

मैं वास्तव में स्क्रिप्ट में परीक्षण डेटा को बनाए रखने के बिंदु को नहीं देखता हूं, क्योंकि UI के साथ लगभग 5 मिनट में सब कुछ मैन्युअल रूप से एप्लिकेशन में जोड़ा जा सकता है। हमारे प्रधानमंत्री असहमत हैं और कहते हैं कि परियोजना है कि हम परीक्षण डेटा के साथ तैनात नहीं कर सकते एक बुरा अभ्यास है।

क्या हमें परीक्षण डेटा के साथ स्क्रिप्ट के रखरखाव को छोड़ देना चाहिए और केवल परीक्षकों को डेटा के बिना एप्लिकेशन का परीक्षण करने देना चाहिए? सबसे अच्छा अभ्यास क्या है?

Answer 1

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

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

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

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

Comments

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

— क्रिश्चियन पी

@ christian.p आपके सवाल के स्पष्टीकरण के बारे में मेरे अपडेट की जाँच करें।

— एजेसी

तो आपका समाधान स्क्रिप्ट को त्यागने और यूआई के माध्यम से मैन्युअल रूप से परीक्षण डेटा जोड़ने के लिए है? P.Brian.Mackey द्वारा प्रदान किए गए उत्तर और UI के साथ डेटा को युग्मित करने के लिए उसके उत्तर के बारे में क्या?

— ईसाई पी

@ christian.p खैर, मैं सहमत हूं कि आपको स्क्रिप्ट का उपयोग करना चाहिए। लेकिन कोई औपचारिकता, या नियम नहीं है जो कहता है कि आप के पास है। नकली डेटा उत्पन्न करने के लिए स्क्रिप्ट का उपयोग करने का मुख्य कारण गति (स्वचालन) और पहुंच (परीक्षण वातावरण के लिए) है। यदि आपके पास पहुंच है और यह मैन्युअल रूप से करने के लिए तेज़ और आसान है, तो ऐसा कोई कारण नहीं है जो आप ऐसा नहीं कर सकते। (लेकिन आपके द्वारा परीक्षण किए गए डेटा का एक लॉग रखें)।

— एजेसी

प्रत्येक परीक्षक का अपना परीक्षण वातावरण होता है और परीक्षक दिन में कई बार पूरी तरह से db छोड़ रहे होते हैं, इसलिए मैन्युअल रूप से परीक्षण डेटा जोड़ना अव्यावहारिक है, लेकिन हम उन्हें विनम्रतापूर्वक परीक्षण के लिए कुछ डेटा जोड़ने के लिए कह सकते हैं।

— क्रिश्चियन पी

Answer 2

हां, यूनिट टेस्ट और डेटा मॉक-अप्स करना सबसे अच्छा अभ्यास है। प्रोजेक्ट मैनेजर सही है। चूंकि परीक्षण डेटा में "सरल" परिवर्तन करने से अक्सर कीड़े पैदा होते हैं, तो यह समस्या का मूल है।

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

रिफ्लेक्टर करना शुरू करें। सुधार छोटे रखें ताकि वे प्रबंधनीय हों। भगवान कक्षाओं / विधियों जैसे एंटी-पैटर्न की तलाश करें, DRY, एकल-जिम्मेदारी, आदि का पालन न करें ...

अंत में, टीडीडी में देखें कि क्या यह टीम के लिए काम करता है। TDD यह सुनिश्चित करने के लिए अच्छी तरह से काम करता है कि आपका सभी कोड परीक्षण-योग्य है (क्योंकि आप परीक्षण पहले लिखते हैं) और यह भी सुनिश्चित करने के लिए कि परीक्षण पास करने के लिए सिर्फ पर्याप्त कोड लिखकर आप दुबले रहें (इंजीनियरिंग पर कम से कम)।

सामान्य तौर पर, यदि जटिल व्यावसायिक तर्क प्रक्रियाओं की एक श्रृंखला डेटा का एक सेट पैदा करती है, तो मैं इसे एक रिपोर्ट के रूप में देखता हूं। रिपोर्ट को इनकैप्सुलेट करें। रिपोर्ट को चलाएं और परिणामी वस्तु को अगले परीक्षण के इनपुट के रूप में उपयोग करें।

Comments

मुझे चीजों को थोड़ा स्पष्ट करने की आवश्यकता है: "परीक्षण डेटा में साधारण परिवर्तन बग पैदा करता है" - यहाँ समस्या आवेदन में नहीं है - डेटा ठीक होने पर ऐप ठीक काम करता है (और आप मैन्युअल रूप से अमान्य डेटा नहीं जोड़ सकते हैं) । यहां मुद्दा यह है कि अमान्य परीक्षण डेटा उस डेटा पर काम करने की कोशिश करते समय त्रुटियों का उत्पादन कर सकता है। तो हम परीक्षण डेटा भी परीक्षण की जरूरत है?

— क्रिश्चियन पी

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

— पी। ब्रायन। मैके 13

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

— क्रिश्चियन पी

"मैं वास्तव में स्क्रिप्ट में परीक्षण डेटा को बनाए रखने के बिंदु को नहीं देखता हूं" <- परीक्षण समर्थन का समर्थन करता हूं जो मैं कह रहा हूं। पुराने परीक्षणों का विलोपन नहीं। यह एक बुरा विचार है। आप reproducibility को कम कर रहे हैं और अपने आप को UI पर युग्मित कर रहे हैं जो कि उस चीज़ का एक हिस्सा है जिसे आप परीक्षण करने और परिवर्तन के लिए अनुकूल बनाने में सक्षम हैं। UI से खुद को अलग करें। डेटा स्वचालन रखें।

— पी। ब्रायन। मैके

लेकिन हम अवैध नकली डेटा की समस्या से कैसे निपटेंगे? यदि हम डेटाबेस के लिए नकली डेटा बनाना जारी रखते हैं तो हम कैसे चेक करते हैं कि नकली डेटा ठीक है या नहीं? यदि व्यावसायिक नियम के लिए उस मान X = 2 की आवश्यकता होती है और डेटाबेस X = 100 को स्वीकार करता है - व्यावसायिक नियम के जटिल होने पर हम परीक्षण डेटा की अखंडता की जांच कैसे करते हैं?

— क्रिश्चियन पी

Answer 3

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

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

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