परीक्षण करें कि आप क्या उड़ते हैं, आप जो परीक्षण करते हैं उसे उड़ें। [नासा सिद्धांत]

Question

मैं बस एक सिद्धांत पर ठोकर खाई जिसे मैं समझ नहीं पा रहा हूं।

"टेस्ट तुम क्या मक्खी, उड़ान भरने के आप क्या परीक्षण" मतलब यह है कि आप और असली बात हर समय के लिए परीक्षण का विकास करना चाहिए?

इस बारे में सोच रही थी, मुझे आश्चर्य है

1. हम अग्रिम में उत्पादन की स्थिति के लिए तैयार करना चाहिए बनाते हैं?
2. क्या हमें सिस्टम को पहले दिन लॉन्च करना चाहिए?
   1. उपकरण बिल्ड सुनिश्चित करने के लिए त्रुटि लॉग पुनः प्राप्त किया जा सकता है (अंत उपयोगकर्ताओं को सूचित किया जा सकता है नहीं)

   उदाहरण के लिए,।

3. सुनिश्चित त्रुटि लॉग विश्लेषण किया जा सकता (आंकड़ा उपकरण और/या अच्छा Log Level Design का उपयोग)
4. सुनिश्चित करें हम प्रणाली में किए गए परिवर्तनों की दुकान। परिवर्तन का इतिहास।
5. सुनिश्चित करें कि बग के मामले में हमारे पास एक छोटा अपडेट चक्र है।

वहाँ अधिक उदाहरण हैं? इससे एक नई प्रणाली का कम जोखिम लॉन्च सुनिश्चित होगा?

मैं थोड़ा उलझन में हूँ। यह सब कुछ है।

Nasa http://ecsv.gsfc.nasa.gov/ecsv_emd/GIFS/nasa_logo.gif

Answer 1

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

दूसरा मंत्र "हम श्री कॉकप के घर नहीं हैं", जो एक हंसी थी, क्योंकि उन्होंने स्थायी निवास किया था।

Answer 2

इसका मतलब है कि यदि आप वास्तव में क्या आप लॉन्च करने की योजना का परीक्षण नहीं करते हैं, आप नहीं जानते कि कैसे आप क्या लांच व्यवहार करेगा।

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

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

Answer 3

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

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

Answer 4

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

(कम से कम यह हबल के लिए किया गया था।)

Answer 5

नासा मंत्र wordedslightly differently है:

"परीक्षण आप के लिए उड़ान भरने, और उड़ान भरने के रूप में आप परीक्षण के रूप में"

एक से सॉफ्टवेयर परिप्रेक्ष्य, मैं इसे

• के रूप में परीक्षण करता है के रूप में संभव
• उत्पादन वातावरण के अनुकरण खो उन परीक्षण पास है, तो आप लाइव वातावरण में है कि परीक्षण लेख तैनात कर सकते हैं, और आप केवल जिस तरह से आप के अनुकूलन से अधिक