ஒரு புரோகிராமரின் வாழ்க்கையில் சோதனை

புரோகிராமர்களுக்கு ஏன் சோதனை தேவை?

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

மென்பொருளைப் பொறுத்தவரை, சோதனையின் பணி நிரலை சரிபார்க்க வேண்டும் என்று நாம் கூறலாம்:

• அவள் செய்ய வேண்டியதை செய்கிறாள்
• அவள் செய்யக்கூடாததைச் செய்வதில்லை

இரண்டாவது புள்ளி, மூலம், முதல் விட குறைவான முக்கியத்துவம் இல்லை, ஆனால் பின்னர் அது இன்னும்.

முதல் புள்ளியுடன் ஆரம்பிக்கலாம். "நிரல் அது செய்ய வேண்டியதைச் செய்கிறது" என்றால் என்ன?

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

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

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

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

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

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

ஆனால் அனைவரும் பிழைகள் என அங்கீகரிக்கும் பிழைகளுக்குத் திரும்பு: நிரல் வெளிப்படையாக ஏதாவது தவறு செய்கிறது, விழுந்தது, உடைந்தது, முதலியன. இத்தகைய பிழைகளை நிபந்தனையுடன் 3 வகைகளாகப் பிரிக்கலாம்: பெரிய, நடுத்தர மற்றும் சிறிய.

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

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

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

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

சோதனை ஆட்டோமேஷன்

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

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

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

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

இங்கே அனைத்து மென்பொருளையும் இரண்டு பகுதிகளாகப் பிரிக்கலாம்:

• நிரல் நபருடன் தொடர்பு கொள்கிறது
• நிரல் மற்றொரு நிரலுடன் தொடர்பு கொள்கிறது

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

ஆனால் இரண்டாவது விருப்பத்தை சுயாதீனமாக தானியங்கு செய்ய முடியும். உங்களிடம் ஏதேனும் மென்பொருள் இருந்தால்:

• நன்றாக வேலை செய்கிறது
• ஏற்கனவே சோதிக்கப்பட்டது
• ஒரு தனி தொகுதி அல்லது தருக்க தொகுதியாக செயல்படுத்தப்பட்டது
• மாற்ற திட்டமிடவில்லை
• மற்ற தொகுதிகள் அல்லது திட்டங்கள் அதை சார்ந்தது
• செயல்பாட்டு தோல்வி விலை உயர்ந்தது

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

தேர்வுக்காக தேர்வு எழுத தேவையில்லை.

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

சோதனை வகைகள்

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

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

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

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

இது நடப்பதைத் தடுக்க, இதுபோன்ற சிக்கல்களை முன்கூட்டியே கண்டறிந்து அவற்றை அகற்ற நடவடிக்கை எடுக்க வேண்டும். இது சுமை சோதனையைப் பயன்படுத்தி செய்யப்படுகிறது , அல்லது இது செயல்திறன் சோதனை என்றும் அழைக்கப்படுகிறது.

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

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

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

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

இன்னும் பல வகையான சோதனைகள் இருக்கலாம்: தயாரிப்பு மிகவும் சிக்கலானது, அதன் வளர்ச்சியின் கூடுதல் அம்சங்களைக் கட்டுப்படுத்த வேண்டும்.