இது நீங்கள் அல்ல; ஒரு தர உத்தரவாதமாக இருப்பதில் ஒரு பெரிய பகுதி குறைபாடு உள்ளூராக்கல் ஆகும்

QA ஆக இருப்பதன் ஒரு பெரிய பகுதி குறைபாடு உள்ளூராக்கல் ஆகும்.

நிச்சயமாக, சோதனை வடிவமைப்பு நுட்பங்கள், சோதனைக் காட்சிகளைத் தேர்வுசெய்து, விஷயங்களைச் சிறப்பாகச் செய்ய உதவுகின்றன. ஆனால் குறைபாடுள்ள உள்ளூர்மயமாக்கல் என்றால் என்ன, அதை எவ்வாறு குறைவான வலியை ஏற்படுத்துவது?

அடிப்படைகளுடன் ஆரம்பிக்கலாம்

உள்ளூர்மயமாக்கல் துப்பறியும் விளையாட்டைப் போன்றது: "எங்கே, எப்போது விஷயங்கள் தவறாக நடந்தன?" சரியான உள்ளூர்மயமாக்கல் இல்லாமல், ஒரு குறைபாடு முன்பக்கம், பின்தளம் மற்றும் எந்தவொரு மேம்பாட்டுக் குழுவிற்கும் இடையில் தூக்கி எறியப்பட்ட சூடான உருளைக்கிழங்காக மாறும். நேரம் வீணாகிறது, மற்றும், சாத்தியமான, சூழல் கூட.

பயன்பாட்டுக் கோரிக்கைகள் மற்றும் பதிவுகளை உங்கள் நூலாகக் கொண்டு, ஒரு தளம் வழிசெலுத்துவதாக குறைபாடு உள்ளூர்மயமாக்கலைக் கருதுங்கள். ஆனால், நூலுடன் தடுமாறிக் கொண்டிருப்பதற்குப் பதிலாக, இந்த லேபிரிந்தின் வரைபடத்தை, ஒரு ஓவியமாக கூட வைத்திருப்பது எளிதாக இருக்கும் அல்லவா? அங்குதான் பயன்பாட்டின் கட்டமைப்பு வருகிறது.

பயன்பாட்டு கட்டமைப்பு என்றால் என்ன?

கணினியின் வெவ்வேறு பகுதிகள் ஒன்றாகச் செயல்படுவது இதுதான். எங்கள் தளம் உருவகத்தின் அடிப்படையில், ஒரு பிரிவு மற்றொன்றுடன் எவ்வாறு இணைகிறது, எந்தப் பாதைகள் எங்கு செல்கின்றன.

நான் இரண்டு முக்கிய கட்டமைப்புகளை வேறுபடுத்துகிறேன்: கிளையன்ட்-சர்வர் மற்றும் பின்தளம்.

• கிளையண்ட்-சர்வர் கட்டமைப்பானது கிளையண்ட் மற்றும் சர்வர் எவ்வாறு தொடர்பு கொள்கிறது என்பதைக் காட்டுகிறது.
• கிளையன்ட் கோரிக்கைகளை பின்தளம் எவ்வாறு கையாளுகிறது என்பதை பின்தள கட்டமைப்பு தீர்மானிக்கிறது.

கிளையன்ட்-சர்வர் கட்டமைப்பைப் பற்றி சில வார்த்தைகள்

பொதுவாக இரண்டு வகைகள் உள்ளன:

• மெல்லிய வாடிக்கையாளர்
• தடித்த வாடிக்கையாளர்

கிளையன்ட் எந்தளவு தகவலைச் சொந்தமாக வைத்திருக்கிறார் மற்றும் செயலாக்குகிறார் என்பதை இந்த வகை பாதிக்கிறது. இதை அமைப்பதற்கு வேறு வழிகள் உள்ளன, ஆனால் நான் உண்மையில் வேலை செய்தவற்றில் ஒட்டிக்கொள்வேன்.

பெரும்பாலான மொபைல் மற்றும் இணைய பயன்பாடுகள் மெல்லிய கிளையண்டுகள். அனைத்து தகவல்களும் சேவையகத்தில் சேமிக்கப்படும், மேலும் கிளையன்ட் பயன்பாடு தரவைக் கோருகிறது அல்லது அதைச் செயலாக்கும்படி கேட்கிறது. பதிவு செய்தல், உள்நுழைதல், அறிவிப்புகளுக்கு சந்தா செலுத்துதல் - இவை அனைத்தும் சேவையகத்திற்கான அழைப்புகள். சேவையகத்தின் முழு செயலாக்கமும் கிளையண்டிலிருந்து மறைக்கப்பட்டுள்ளது. கோரிக்கைக்கு பதிலளிக்கும் விதமாக, வாடிக்கையாளர் தரவுத்தளத்திலிருந்து சேகரிக்கப்பட்ட மற்றும் செயலாக்கப்பட்ட தகவலைப் பெறுகிறார் அல்லது கோரிக்கை வெற்றிகரமாக முடிக்கப்பட்டதை உறுதிப்படுத்துகிறார்.

தடிமனான கிளையன்ட் பயன்பாடுகளில், கிளையன்ட் பெரும்பாலான செயலாக்கங்களைச் செய்கிறார்: தரவுத்தளத்தில் தரவைச் சேர்த்தல், அறிக்கைகளை உருவாக்குதல், தொகைகளைக் கணக்கிடுதல் மற்றும் ஆவணங்களை உருவாக்குதல். அவை பெரும்பாலும் உள்நாட்டில் நிறுவப்படுகின்றன, ஆனால் எப்போதும் இல்லை. தடிமனான வாடிக்கையாளர்களின் எடுத்துக்காட்டுகளில் ஆஃப்லைன் கேம்கள், ஆட்டோகேட் மற்றும் 1C இன் சில பதிப்புகள் அடங்கும்.

இப்போது, பின்தள கட்டமைப்பை ஆராய்வோம்

இரண்டு பொதுவான அணுகுமுறைகள்:

• ஒற்றைக்கல்
• நுண் சேவைகள்

ஏறக்குறைய அனைத்தும் ஒரே இடத்தில் செயலாக்கப்பட்டால், அது ஒரு ஒற்றைக்கல்.

செயலாக்கத்திற்கான கோரிக்கைகள் கணினியில் உள்ள பிற சேவைகளுக்கு அனுப்பப்பட்டால், நீங்கள் மைக்ரோ சர்வீஸ் கட்டமைப்பைக் கையாள்வீர்கள்.

ஒரு ஒற்றைக் கட்டிடக்கலையில், குறைபாட்டின் மூலத்தைக் குறிப்பிடுவது தந்திரமானதாக இருக்கலாம், ஏனெனில் வெவ்வேறு அணிகளும் சேவைகளும் பொதுவாக ஒரே குறியீட்டுத் தளத்தைப் பகிர்ந்துகொள்கின்றன, அதாவது மாற்றங்கள் எதிர்பாராத விளைவுகளை ஏற்படுத்தும்.

இரண்டாவது வழக்கில், சேவைகள் பிரிக்கப்படுகின்றன, ஒவ்வொன்றும் அதன் சொந்த கோட்பேஸுடன், அதாவது ஒரு சேவையில் ஏற்படும் மாற்றங்கள் மற்றவற்றில் சிறிய தாக்கத்தை ஏற்படுத்துகின்றன.

நிறுவன அமைப்பு மற்றும் பொறுப்பு பகுதிகள்

தலைப்பு பயமாகத் தெரிகிறது, ஆனால் யார் என்ன செய்கிறார்கள், எந்தப் பகுதிக்கு யார் பொறுப்பு (பயன்பாடு) என்பதை இது உங்களுக்குச் சொல்கிறது. எங்களிடம் ஒரு பெரிய நிறுவனம் இருப்பதாக கற்பனை செய்து பாருங்கள்: ஒரு வங்கி, ஒரு சந்தை, உணவு விநியோக சேவை - நீங்கள் அதை பெயரிடுங்கள். எங்கள் பயன்பாடு எவ்வளவு பெரியது மற்றும் மிகவும் சிக்கலானது, அதிகமான மக்கள் அதில் வேலை செய்கிறார்கள். மேலும் அதிகமான மக்கள், அவர்களை அணிகளாகப் பிரிக்க வேண்டும், ஒவ்வொன்றும் அவரவர் வளர்ச்சிப் பகுதிக்கு பொறுப்பாகும்.

எடுத்துக்காட்டாக, ஒரு குழு பதவி உயர்வுகளைக் கையாளலாம், மற்றொரு குழு பணம் செலுத்துவதற்குப் பொறுப்பாகும். எங்கள் பயன்பாடு வெவ்வேறு சேவைகளை வழங்கினால், மின்னணு ஆவண மேலாண்மை, கணக்கியல் அல்லது அரசாங்க கொள்முதல் போன்ற தனிப்பட்ட சேவைகளுக்கு குழுக்கள் பொறுப்பாகும்.

நீங்கள் எல்லாவற்றையும் மற்றும் அனைவரையும் தெரிந்து கொள்ள வேண்டிய அவசியமில்லை, ஆனால் எந்தப் பகுதிக்கு எந்த அணி பொறுப்பு என்பதை கோடிட்டுக் காட்டும் ஆவணங்கள் இருந்தால், அதை புக்மார்க் செய்து வைத்திருப்பது நல்லது.

அனைத்தையும் ஒன்றாக சேர்த்து

கையில் வரைபடம், நூல் தயாராக உள்ளது, நம் தளத்தை ஆராய்ந்து, குறைபாட்டின் மூலத்தை வேட்டையாடுவோம். ஒரு சில காட்சிகளை கற்பனை செய்வோம்.

காட்சி 1

இதைப் படியுங்கள்: உரையாடல் கிளப்பிற்கான இணையதளத்தை நாங்கள் சோதித்து வருகிறோம்.

நாங்கள் வகுப்பு அட்டவணையை உலாவுகிறோம், வரவிருக்கும் அமர்வுகளைப் பற்றி படிக்கிறோம், சில சமயங்களில் எழுத்துப்பிழையைக் கண்டோம்.

இப்போது, அது எங்கிருந்து உருவானது என்பதைக் கண்டுபிடிப்பது எப்படி? சாகசம் தொடங்கட்டும்!

நாங்கள் devTools ஐத் திறந்து, பக்கத்தைப் புதுப்பித்து, கோரிக்கைகள் மற்றும் பதில்களைப் பார்க்கிறோம். எங்களிடம் ஒரு மெல்லிய கிளையண்ட் இருப்பதால், பதில்களில் ஒன்றில் எங்கள் எழுத்துப்பிழையைக் காண்கிறோம் - இது பின்தளத்தில் இருந்து வந்தது.

இப்போது, நாங்கள் பதிவுகளைத் திறந்து பின்தளத்தின் கோரிக்கை அல்லது பதிலின் செயலாக்கத்தைத் தேடுகிறோம் - இது மாயப் பந்திலிருந்து எங்களின் நூல். கோரிக்கை மற்றும் பதிலில் இருந்து ஏதேனும் தகவலைப் பயன்படுத்தி பதிவுகளைத் தேடலாம், ஆனால் தனிப்பட்ட மதிப்புகளைப் பயன்படுத்துவது நல்லது: கோரிக்கை xiid, கோரிக்கையிலிருந்து ஐடி, தொலைபேசி எண் மற்றும் பல.

உள்ளீட்டைக் கண்டறிந்து சரிபார்த்தோம்: வகுப்புத் தகவலை தரவுத்தளத்தில் இருந்தோ அல்லது வேறொரு சேவையிலிருந்து பெற்றோமா?

தரவுத்தளத்திலிருந்து தகவல் வந்திருந்தால், தரவுத்தளத்தில் உள்ள எழுத்துப்பிழையைச் சரிசெய்வதற்காக, சிக்கலை தொழில்நுட்ப ஆதரவிற்கு அனுப்பலாம்.

வேறொரு சேவையிலிருந்து தகவல் வந்திருந்தால், அந்த குறைபாட்டை அவர்களுக்கு அனுப்பலாம்.

வாழ்த்துகள்! எங்கள் முதல் தளத்தை நாங்கள் வென்றுள்ளோம்: குறைபாடு உள்ளூர்மயமாக்கப்பட்டு புகாரளிக்கப்பட்டது.

காட்சி 2

இப்போது பதிவு படிவத்தை சோதனை செய்கிறோம்.

நாங்கள் ஒரு மின்னஞ்சல், சில தரவு மற்றும் உருவாக்கப்பட்ட கடவுச்சொல்லை உள்ளிடுகிறோம். நாங்கள் பதிவு பொத்தானைக் கிளிக் செய்து, எதிர்பாராத விதமாக பிழையைப் பெறுகிறோம்.

எங்கள் மாயப் பந்தை அவிழ்க்க வேண்டிய நேரம் இது! devTools இல் உள்ள எங்கள் அன்பான நெட்வொர்க் தாவலுக்குச் சென்று என்ன தவறு நடந்தது என்பதைப் பார்க்கிறோம்: நாங்கள் எல்லா படிகளையும் மீண்டும் செய்கிறோம் மற்றும் சேவையகத்தின் பதிலைச் சரிபார்க்கிறோம்.

கோரிக்கைக்கு பதிலளிக்கும் விதமாக, வெற்று மறுமொழி அமைப்புடன் 400 குறியீட்டைப் பெறுகிறோம். நாம் ஓடிப்போய் முன்முனைக்கு எதிராக ஒரு குறைபாட்டை தாக்கல் செய்ய வேண்டுமா? ஆனால் சரியாக என்ன தவறு நேர்ந்தது, எது சரி செய்யப்பட வேண்டும் என்று எங்களுக்கு இன்னும் தெரியவில்லை. கிளையன்ட் அனுப்பியதற்கும் சர்வர் எதிர்பார்த்ததற்கும் இடையே முரண்பாடு இருக்கும்போது பெரும்பாலும் 400 பிழை ஏற்படுகிறது. இதற்கு பல காரணங்கள் இருக்கலாம், அவற்றுள்:

• பணியில் காலாவதியான ஆவணங்கள்
• ஆவணங்கள் இல்லாமல் செய்யப்பட்ட மாற்றங்கள்
• எழுத்துப் பிழைகள்

வாடிக்கையாளரின் கோரிக்கையைச் சரிபார்ப்போம்

கைமுறையாக எழுதப்பட்ட அல்லது Swagger அல்லது OpenAPI இல் உருவாக்கப்பட்ட ஆவணங்கள் எங்களிடம் இருந்தால், அதைச் சரிபார்க்க அதைப் பயன்படுத்துவோம்:

• தேவையான அனைத்து அளவுருக்களையும் அனுப்புகிறோம்
• அளவுரு மதிப்புகள் சரியான தரவு வகைகளைக் கொண்டுள்ளன (எ.கா., முழு அளவுருக்களுக்கான எண் மதிப்புகள்)

கோரிக்கையை வேறு எப்படி சரிபார்க்கலாம்?

எங்களிடம் ஆவணங்கள் இல்லாவிட்டாலும், நாங்கள் சரிபார்க்கலாம்:

• தொடரியல் இணக்கம் (எ.கா., கோரிக்கை JSON வடிவத்தில் அனுப்பப்பட்டால், அது JSON தொடரியல் பின்பற்ற வேண்டும்)
• அளவுரு பெயர்களில் எழுத்துப் பிழைகள் (எ.கா., "பணம்" என்பதற்குப் பதிலாக "பணம்", "உடல்" என்பதற்குப் பதிலாக "டோபி")
• லத்தீன் எழுத்துக்களில் சிரிலிக் எழுத்துக்கள் (எ.கா., "பெயர்" ஒரு சிரிலிக் "e" உடன் எழுதப்பட்டது)

எல்லாம் ஒழுங்காக இருக்கிறதா? அதற்குப் பிறகு விடையைக் கண்டுபிடிக்க தளம் வழியாக எங்கள் பயணத்தைத் தொடர வேண்டிய நேரம் இது. நாங்கள் எங்கள் வரைபடத்தை எடுத்து பதிவுகளில் "இறங்குகிறோம்".

பதிவு பகுப்பாய்வு

இங்கே, இரண்டு காட்சிகள் சாத்தியமாகும்:

• கோரிக்கை செயலாக்கத்தின் போது ஒரு பிழை உள்நுழைந்தது
• எந்த பிழையும் பதிவு செய்யப்படவில்லை, ஆனால் கோரிக்கைகள் பதிவு செய்யப்பட்டுள்ளன

பிந்தைய வழக்கில், மைக்ரோ சர்வீஸ் லேபிரிந்த் வழியாக எங்கள் பயணத்தைத் தொடர வேண்டும் மற்றும் எங்கள் கோரிக்கை செயலாக்கப்பட்ட இடத்தைத் தேட வேண்டும்.

பிழைப் பதிவைக் கண்டறிவதன் மூலம், சரியாக என்ன தவறு நடந்தது என்பதை நாங்கள் அறிவோம், அதாவது எங்கள் உள்ளூர்மயமாக்கலும் எங்கள் பயணமும் முடிந்தது! குறைபாடு அறிக்கைக்கு பின்வரும் தகவல்களைச் சேகரிப்பது மட்டுமே எஞ்சியுள்ளது:

• பின்தள கோரிக்கை
• பிழை பதிவு
• பரிந்துரைக்கப்பட்ட திருத்தம்

முடிவுரை

குறைபாடு உள்ளூர்மயமாக்கல் சவாலாக இருக்கலாம். சில நேரங்களில் நீங்கள் ஒரு சுவரில் அடிப்பீர்கள்: நீங்கள் பின்தொடரும் பதிவு பிழைக்கு வழிவகுக்காது அல்லது விஷயங்களை மேலும் குழப்பமடையச் செய்யாது. இதுபோன்ற சூழ்நிலைகளில், நான் வழக்கமாக இரண்டு படிகள் பின்வாங்குவேன் அல்லது ஆரம்பத்தில் இருந்து தொடங்குவேன்.

தளம் ஆராய நிறைய நேரம் ஆகலாம். பயணம் கடினமாக இருக்கலாம் மற்றும் ஆபத்து நிறைந்ததாக இருக்கலாம்: சில கோரிக்கைகளின் செயலாக்கம் சுருங்கி பல்வேறு சேவைகளுக்கு கோரிக்கைகளை அனுப்பலாம். சில நேரங்களில் பணியை எளிதாக்குவது மற்றும் தளம் கட்டிடக் கலைஞர்களை - டெவலப்பர்களைத் தொடர்புகொள்வது அர்த்தமுள்ளதாக இருக்கும்.