लेआउट का प्रतिगमन परीक्षण। स्वचालन का विचार

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

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

किस वजह से पूरा उपद्रव

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

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

किसी भी स्थिति में, एक ब्लॉक में परिवर्तन के कारण होने वाले सभी परिवर्तनों को हमें ज्ञात होना चाहिए और नियंत्रित किया जाना चाहिए।
हमें एक सार्वभौमिक विधि की आवश्यकता है जो हमें अधिकतम लेआउट त्रुटियों (और अधिमानतः न केवल लेआउट) को खोजने की अनुमति देता है, चाहे उनके कारणों की परवाह किए बिना।

एल्गोरिदम का आइडिया

वह सरल है। द्वारा और बड़े, दस्तावेज़ के लेआउट को बदलने के लिए एकमात्र उद्देश्य मशीन-सुलभ मानदंड कुछ नियंत्रण बिंदुओं की स्थिति को बदलना है। यानी चरण इस तरह दिखते हैं:

1. दस्तावेज़ों में (सरल ब्लॉकों के लिए स्रोत कोड, यौगिक ब्लॉक, एक देव सर्वर पर पृष्ठ) हम कुछ ब्रेकप्वाइंट सेट करते हैं
2. सत्यापनकर्ता कार्यक्रम समन्वय प्रणाली के सापेक्ष इन बिंदुओं के निर्देशांक को निर्धारित करता है (उदाहरण के लिए, क्षैतिज और ऊर्ध्वाधर अक्षों के साथ ब्राउज़र कार्यक्षेत्र के ऊपरी बाएं बिंदु) और डेटाबेस के लिए उनके मान लिखते हैं
3. सत्यापनकर्ता कार्यक्रम वर्तमान वाले बिंदुओं के पिछले निर्देशांक की तुलना करता है और फॉर्म की विसंगतियों की एक सूची देता है "पृष्ठ का पता - बिंदु आईडी - पुराने निर्देशांक - नए निर्देशांक"
4. मैनुअल मोड में, डेवलपर इन पृष्ठों को स्कैन करता है और नए मानों को सही के रूप में चिह्नित करता है (यदि यह किए गए परिवर्तनों के अपेक्षित परिणाम के अनुरूप है) या गलत है

इस प्रकार, हम विकास प्रक्रिया और बग फिक्सिंग दोनों में एक समान विधि का उपयोग कर सकते हैं।

मान्यकर्ता और मील के पत्थर

मेरी समझ में, भौतिक अर्थ में, डॉट्स दस्तावेज़ कोड में कुछ टेम्पलेट के HTML टिप्पणियों की तरह दिखते हैं, उदाहरण के लिए, <!-- ###testing:id1### --> । प्रत्येक पृष्ठ और HTML स्रोत में एम्बेडेड JS उपयोगिता के माध्यम से, उन्हें शून्य ऊंचाई के साथ एक खाली ब्लॉक से बदल दिया जाता है। फिर इस ब्लॉक की स्थिति की गणना, जेएस के माध्यम से भी की जाती है।

निम्नलिखित तर्क के अनुसार अंक निर्धारित किए जाने चाहिए:

• ब्लॉक स्रोतों में एक ब्लॉक के कोड के बाद
• विशेषता स्थानों में ब्लॉक कोड में (प्रत्येक विशिष्ट मामले पर निर्भर करता है)
• पृष्ठ कोड में विशेषता स्थानों में, और दस्तावेज़ ग्रिड के सशर्त गाइड के स्थानों में।

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

सारांश

मुझे नहीं पता कि, सिद्धांत रूप में, लेआउट स्वचालन के परीक्षण के लिए तरीके हैं। Googling ने कोई परिणाम नहीं दिया, इसलिए मैंने अपनी पद्धति के साथ आने की कोशिश की। यदि आप तैयार टूलकिट जानते हैं, तो कृपया इसे टिप्पणियों में साझा करें।
मैंने पूरी तरह से सार्वभौमिक परीक्षण प्रणाली पर अपने विचारों को औपचारिक रूप देने की कोशिश की, जो लेआउट को लागू करने के तरीकों से अमूर्त होगा, और इसलिए किसी भी परियोजना पर लागू होगा। जबकि ये एल्गोरिथम पर केवल पहले स्केच हैं, मेरे पास केवल सामान्य विचार हैं जो सॉफ़्टवेयर के संचालन के बारे में ऊपर वर्णित हैं। मैं इस दृष्टिकोण में अत्यंत विश्वासयोग्य और प्रभावी होने का दावा नहीं करता। काम के पहले परिणामों के बाद ही पहला निष्कर्ष निकाला जा सकता है।
और, सबसे महत्वपूर्ण बात, मैं आम जनता से टिप्पणियों में उन सभी बातों पर चर्चा करने का आग्रह करता हूं, जो टिप्पणियों और सुझावों के साथ-साथ सॉफ्टवेयर के कार्यान्वयन में मदद करने के लिए उत्साही हैं ।
मैं उन सभी का आभारी रहूँगा, जो इस पोस्ट का लिंक डालते हैं, अपने ब्लॉग, ट्वीट पर घोषणा पोस्ट करते हैं और आम तौर पर इस विषय की विस्तृत चर्चा यहाँ या मेरे ब्लॉग पर हर तरह से करते हैं।