2009-05-07 9 views
5

मैं अब और अधिक औपचारिक आवश्यकताओं और परीक्षण प्रक्रियाओं को स्थापित करने की कोशिश कर रहा हूं, तो हमारे पास अब दस्तावेजों का कोई अच्छा संदर्भ उदाहरण नहीं मिल रहा है।अच्छा परीक्षण केस टेम्पलेट्स/उदाहरण कहां खोजें?

फिलहाल, फीचर फ्रीज टेस्टर्स के बाद तैनाती से पहले "एप्लिकेशन के माध्यम से क्लिक करें" के बाद, हालांकि कोई औपचारिक विनिर्देश नहीं है जिसे परीक्षण करने की आवश्यकता है।

पहले, मैं, एक दस्तावेज है जो हर सुविधा परीक्षण किया जाना चाहिए कि निर्दिष्ट करता है के बारे में सोच रहा हूँ कुछ इस तरह (इस को बनाने):

  1. उपयोगकर्ता पंजीकरण फार्म
    1. देश लटकती (हैं देशों को सही ढंग से सर्वर से लाना?)
    2. पासवर्ड सत्यापन (सभी पासवर्ड नियम मनाया जाता है, उपयोगकर्ता को सूचित किया जाता है, तो पासवर्ड बहुत कमज़ोर है?)
  2. धन्यवाद-पंजीकरण के लिए

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

दूसरे, मैं, परीक्षकों के लिए परीक्षण मामलों में सोच रहा हूँ की तरह विस्तृत चरणों के साथ:

  1. लोड उपयोगकर्ता पंजीकरण फार्म।
  2. (फ़ीचर 1.1) देश ड्रॉपडाउन मेनू की जांच करें।
    1. देश के साथ देश में गिरावट आ रही है?
    2. देशों के नाम स्थानीय हैं?
    3. क्या सॉर्ट ऑर्डर प्रत्येक भाषा के लिए सही है?
  3. (फ़ीचर 1.2) इस पासवर्ड को दर्ज करें: "ए", "बॉब", "पासवर्ड", "पासवर्ड 123", "पासवर्ड 123 #"। केवल अंतिम पासवर्ड स्वीकार किया जाना चाहिए।
  4. "ठीक" दबाएं।
  5. (फ़ीचर 2) धन्यवाद-नोट नोट करें।
    1. क्या टेक्स्ट प्रत्येक समर्थित भाषा में स्थानीयकृत है?

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

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

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

  1. अपराह्न सुविधाओं की सूची बनाता है। ग्राहक इसे संकेत देता है। (दस्तावेज़ 1 बनाया गया है।)
  2. टेस्ट केस बनाए गए हैं। (दस्तावेज़ 2.)
  3. प्रोग्रामर सुविधाएं लागू करते हैं।
  4. परीक्षण मामलों के अनुसार टेस्टर्स परीक्षण सुविधाएं। (और दस्तावेज़ 1 के माध्यम से बग की रिपोर्ट करें।)
  5. प्रोग्रामर बग ठीक करते हैं।
  6. गोटो 4 जब तक सभी बग ठीक नहीं हो जाते हैं।
  7. आंतरिक परीक्षण का अंत; उत्पाद ग्राहक को दिखाया गया है।

क्या किसी के पास पॉइंटर्स हैं जहां परीक्षण मामलों के साथ कुछ नमूना दस्तावेज मिल सकते हैं? साथ ही, ऊपर उल्लिखित प्रक्रिया के संबंध में सभी युक्तियां आपका स्वागत है। :)

उत्तर

2

ive मैंने उपयोग किए गए दो दस्तावेज़ विकसित किए।

एक अपने और अधिक 'मानक वेबसाइटों' (जैसे व्यापार वेब उपस्थिति) के लिए है:

http://pm4web.blogspot.com/2008/07/quality-test-plan.html

एक दूसरे मैं वेब आधारित अनुप्रयोगों के लिए उपयोग करें:

http://pm4web.blogspot.com/2008/07/writing-system-test-plan.html

आशा यह सहायता करता है।

1

सबसे पहले, मुझे लगता है कि परीक्षण केस दस्तावेज़ के साथ आवश्यकताओं के दस्तावेज़ को जोड़ना सबसे अधिक समझ में आता है क्योंकि अधिकांश जानकारी दोनों के लिए समान है और परीक्षकों के सामने आवश्यकताओं और परीक्षण मामलों के सामने उपयोगकर्ता और डेवलपर आवश्यकता को मजबूत करते हैं और उनमें से अलग-अलग दृश्य बिंदु प्रदान करते हैं। यहां दस्तावेज़ लेआउट के लिए एक अच्छा प्रारंभिक बिंदु है: http://www.volere.co.uk/template.htm#anchor326763 - यदि आप जोड़ते हैं: परीक्षण करने के लिए चरण, परीक्षण की अपेक्षाओं की अपेक्षा, किनारे/बाध्य मामलों - आपके पास एक ठोस ठोस आवश्यकता का नमूना होना चाहिए और एक में परीक्षण का नमूना होना चाहिए।

चरणों के लिए, एक मूल्यांकन चरण शामिल करना न भूलें, जहां आप, परीक्षक, डेवलपर इत्यादि परीक्षण परिणामों का मूल्यांकन करते हैं और अगले दौर के लिए आवश्यकता/परीक्षण दस्तावेज़ अपडेट करते हैं (आप अक्सर चीजों में भाग लेंगे कि आप कल्पना में शामिल नहीं हो सकते थे और spec में जोड़ना चाहिए ... एक आवश्यकताओं परिप्रेक्ष्य और परीक्षण दोनों से)।

मैं यह भी सुनिश्चित करने के लिए दिमाग/कार्य-टूटने-संरचना का उपयोग करने की अत्यधिक अनुशंसा करता हूं कि आपके पास सभी आवश्यकताओं को सही ढंग से कैप्चर किया गया हो।

0

आपको काम शुरू करने से पहले एक विस्तृत विनिर्देश की आवश्यकता है; अन्यथा आपके डेवलपर्स को नहीं पता कि क्या लिखना है या जब वे समाप्त हो गए हैं। जोएल स्पॉस्की ने इस विषय पर उदाहरण के साथ a good essay लिखा है। विकास के दौरान कल्पना को अपरिवर्तित रहने की उम्मीद न करें हालांकि: योजना में संशोधन का निर्माण करें।

मीड, ऊपर, परीक्षण के साथ spec संयोजन की सिफारिश की है। इसे Test Driven Development के रूप में जाना जाता है और यह एक बहुत अच्छा विचार है। यह चीजों को इस तरह से नीचे रखता है कि प्राकृतिक भाषा अक्सर नहीं होती है, और काम की मात्रा में कटौती करती है।

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

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

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

+0

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

1

डेविड पीटरसन का Concordion web-site अच्छा विनिर्देश लिखने के लिए तकनीक पर एक बहुत अच्छा पृष्ठ है (साथ ही विनिर्देशों को निष्पादित करने के लिए एक ढांचा)। उनकी सलाह सरल और संक्षिप्त है।

साथ ही आप व्यवहार-प्रेरित विकास (बीडीडी) पर दान नॉर्थ के classic blog post को देखना चाह सकते हैं। बहुत उपयोगी!

0

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

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

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