how find bug application
एक बहुत अच्छा और महत्वपूर्ण बिंदु। सही? यदि आप एक सॉफ्टवेयर टेस्टर या एक क्यूए इंजीनियर हैं तो आप एक आवेदन में एक बग को खोजने के लिए हर मिनट सोच रहे होंगे। और आपको होना चाहिए!
मुझे लगता है कि एक खोज अवरोधक बग किसी तरह सिस्टम खराब होना अक्सर पुरस्कृत होता है! नहीं, मैं ऐसा नहीं सोचता। आपको उन बग्स का पता लगाने की कोशिश करनी चाहिए, जिन्हें ढूंढना सबसे मुश्किल है और जो उपयोगकर्ताओं को हमेशा गुमराह करते हैं।
ऐसे सूक्ष्म कीड़े ढूंढना सबसे चुनौतीपूर्ण काम है और यह आपको अपने काम की संतुष्टि देता है। साथ ही, वरिष्ठों द्वारा इसे पुरस्कृत किया जाना चाहिए। मैं एक ऐसे सूक्ष्म बग के अपने अनुभव को साझा करूंगा जो न केवल पकड़ना मुश्किल था, बल्कि पुन: पेश करना भी मुश्किल था।
मैं अपने खोज इंजन प्रोजेक्ट से एक मॉड्यूल का परीक्षण कर रहा था। मैं इस परियोजना की अधिकांश गतिविधियों को मैन्युअल रूप से करता हूं क्योंकि यह स्वचालित करने के लिए थोड़ा जटिल है। उस मॉड्यूल में विभिन्न सहयोगी और विज्ञापनदाताओं के ट्रैफ़िक और राजस्व आँकड़े शामिल हैं। इसलिए ऐसी खबरों को परखना हमेशा मुश्किल काम होता है।
जब मैंने इस रिपोर्ट का परीक्षण किया तो यह कुछ समय के लिए डेटा को सटीक रूप से संसाधित दिखा रहा था लेकिन जब कुछ समय बाद फिर से परीक्षण करने की कोशिश की गई तो यह भ्रामक परिणाम दिखा रहा था। परिणाम देखने में अजीब और भ्रमित करने वाला था।
एक क्रोन था (क्रोन एक स्वचालित स्क्रिप्ट है जो लॉग फ़ाइलों को संसाधित करने और डेटाबेस को अपडेट करने के लिए निर्दिष्ट समय या स्थिति के बाद चलती है)। कुल डेटा को सिंक्रनाइज़ करने के लिए लॉग फाइल और डीबी पर ऐसी कई फसलें चल रही हैं।
कुछ समय अंतराल के साथ एक टेबल पर दो क्रोन चल रहे थे।
तालिका में एक स्तंभ था जो अन्य क्रोन द्वारा अधिलेखित हो रहा था जिससे कुछ डेटा असंगति हो रही थी। विशाल डीबी प्रक्रियाओं और विभिन्न क्रोन के कारण समस्या का पता लगाने में हमें लंबा समय लगा।
मेरा कहना है कि सिस्टम में छिपे हुए कीड़े का पता लगाने की कोशिश की जा रही है जो विशेष परिस्थितियों के लिए हो सकता है और सिस्टम पर एक मजबूत प्रभाव का कारण बनता है। आप ऐसे बग को कुछ युक्तियों और चाल के साथ पा सकते हैं।
एमपी 3 कनवर्टर करने के लिए सुरक्षित मुक्त यूट्यूब
तो क्या हैं वो टिप्स:
# 1) पूरे आवेदन को समझें या परीक्षण शुरू करने से पहले गहराई में मॉड्यूल।
#दो) तैयार अच्छा टेस्ट केस परीक्षण शुरू करने से पहले। मेरा मतलब है कि कार्यात्मक परीक्षण मामलों पर तनाव दें जिसमें आवेदन का प्रमुख जोखिम शामिल है।
# 3) सृजन करना पर्याप्त टेस्ट डेटा परीक्षणों से पहले, इस डेटासेट में परीक्षण के मामले की शर्तें और डेटाबेस रिकॉर्ड भी शामिल हैं यदि आप डीबी से संबंधित आवेदन का परीक्षण करने जा रहे हैं।
# 4) के साथ दोहराया परीक्षण करें विभिन्न टेस्ट पर्यावरण ।
# 5) जानने की कोशिश करो परिणाम स्वरूप और फिर उन पैटर्न के साथ अपने परिणामों की तुलना करें।
# 6) जब आप सोचते हैं कि आपने परीक्षण की अधिकांश शर्तें पूरी कर ली हैं और जब आपको लगता है कि आप कुछ हद तक थक गए हैं कुछ बंदर परीक्षण करें।
# 7) अपने पिछले का उपयोग करें डेटा पैटर्न का परीक्षण करें परीक्षणों के वर्तमान सेट का विश्लेषण करने के लिए।
# 8) कुछ आजमाओ मानक परीक्षण मामले जिसके लिए आपको कुछ अलग एप्लिकेशन में बग मिले। जैसे यदि आप इनपुट टेक्स्ट बॉक्स का परीक्षण कर रहे हैं तो इनपुट के रूप में कुछ HTML टैग्स डालने की कोशिश करें और आउटपुट को डिस्प्ले पेज पर देखें।
# 9) अंतिम और सबसे अच्छी चाल बग को खोजने के लिए बहुत कठिन प्रयास करना है। जैसे कि आप केवल एप्लिकेशन को तोड़ने के लिए परीक्षण कर रहे हैं!
मैं कुछ आने वाली पोस्टों में अधिक युक्तियों को शामिल करूंगा। इस बीच आप यहां और अधिक टिप्स बता सकते हैं।
अनुशंसित पाठ
- कैसे एक अच्छी बग रिपोर्ट लिखने के लिए? युक्तियाँ और चालें
- टॉप 20 प्रैक्टिकल सॉफ्टवेयर टेस्टिंग टिप्स आपको किसी भी एप्लीकेशन को टेस्ट करने से पहले पढ़ना चाहिए
- सॉफ्टवेयर परीक्षण में बंदर परीक्षण क्या है?
- डेस्कटॉप, क्लाइंट सर्वर परीक्षण और वेब परीक्षण के बीच अंतर
- नमूना बग रिपोर्ट
- स्वास्थ्य देखभाल अनुप्रयोगों का परीक्षण - युक्तियाँ और महत्वपूर्ण परीक्षण परिदृश्य (भाग 2)
- वेब अनुप्रयोग सुरक्षा परीक्षण गाइड
- मल्टी-लिंगुअल वेबसाइट्स की टेस्टिंग के लिए 7 बेसिक टिप्स