டிபிஎம்எஸ்ஸில் யூனிட் சோதனைகள் - ஸ்போர்ட்மாஸ்டரில் அதை எப்படிச் செய்கிறோம், பாகம் ஒன்று

ஹே ஹப்ர்!

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

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

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

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

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

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

விசுவாசத்தை சோதிக்கிறது

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

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

• உங்கள் கணினி மிகவும் ஏற்றப்படும்
• உங்கள் கணினியில் சிக்கலான கணினி செயல்முறைகள் இருக்கும்
• உங்கள் அமைப்பு தீவிரமாக மேம்படுத்தப்படும்.

ஒழுங்காகச் செல்லலாம்... மொத்தத்தில், அனைத்து ஸ்போர்ட்மாஸ்டர் பிராண்டுகளையும் கருத்தில் கொண்டால், ரஷ்யா, உக்ரைன், சீனா, கஜகஸ்தான் மற்றும் பெலாரஸ் ஆகிய நாடுகளில் 1000 க்கும் மேற்பட்ட கடைகள் உள்ளன. இந்த கடைகளில் தினமும் சுமார் 300 கொள்முதல் செய்யப்படுகிறது. அதாவது, ஒவ்வொரு நொடியும் 000-3 காசோலைகள் எங்கள் கணினியில் நுழைகின்றன. இயற்கையாகவே, எங்கள் விசுவாச அமைப்பு மிகவும் ஏற்றப்பட்டது. மேலும் இது தீவிரமாகப் பயன்படுத்தப்படுவதால், அதன் தரத்தின் மிக உயர்ந்த தரத்தை நாங்கள் வழங்க வேண்டும், ஏனெனில் மென்பொருளில் ஏதேனும் பிழை பெரிய பண, நற்பெயர் மற்றும் பிற இழப்புகளைக் குறிக்கிறது.

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

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

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

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

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

ஸ்போர்ட்மாஸ்டரில் லாயல்டி சிஸ்டம் 7 ஆண்டுகளுக்கும் மேலாக உள்ளது, இது ஒரு டெவலப்பர்களால் உருவாக்கப்பட்டது... இந்த 7 ஆண்டுகளில் எங்கள் திட்டத்தில் டெவலப்பர்களின் சராசரி எண்ணிக்கை 3-4 பேர். ஆனால் கடந்த ஆண்டில், எங்கள் குழு கணிசமாக வளர்ந்துள்ளது, இப்போது 10 பேர் திட்டத்தில் பணிபுரிகின்றனர். அதாவது, வழக்கமான பணிகள், செயல்முறைகள் மற்றும் கட்டிடக்கலை பற்றி நன்கு தெரியாத மக்கள் திட்டத்திற்கு வருகிறார்கள். மேலும் நாம் தவறுகளை இழக்கும் அபாயம் உள்ளது.

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

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

utPLSQL மீட்புக்கு வருகிறது

ஸ்டீபன் ஃபியூர்ஸ்டீனைப் பற்றி உங்களுக்கு ஏதாவது தெரியுமா?

ஆரக்கிள் மற்றும் PL/SQL உடன் பணிபுரிவதற்காக தனது தொழில் வாழ்க்கையின் நீண்ட பகுதியை அர்ப்பணித்த புத்திசாலியான இவர், இந்த தலைப்பில் ஏராளமான படைப்புகளை எழுதியுள்ளார். அவரது புகழ்பெற்ற புத்தகங்களில் ஒன்று: "ஆரக்கிள் PL/SQL. தொழில் வல்லுநர்களுக்கு." utPLSQL தீர்வை உருவாக்கியவர் ஸ்டீபன், அல்லது, Oracle PL/SQLக்கான யூனிட் டெஸ்டிங் கட்டமைப்பை உருவாக்கினார். utPLSQL தீர்வு 2016 இல் உருவாக்கப்பட்டது, ஆனால் அது தொடர்ந்து செயலில் உள்ளது மற்றும் புதிய பதிப்புகள் வெளியிடப்படுகின்றன. அறிக்கையிடும் நேரத்தில், சமீபத்திய பதிப்பு மார்ச் 24, 2019 அன்று தொடங்கியது.
அது என்ன. இது ஒரு தனி திறந்த மூல திட்டமாகும். எடுத்துக்காட்டுகள் மற்றும் ஆவணங்கள் உட்பட இது இரண்டு மெகாபைட் எடையைக் கொண்டுள்ளது. இயற்பியல் ரீதியாக, இது ORACLE தரவுத்தளத்தில் ஒரு தனித் திட்டமாகும், இது அலகு சோதனையை ஒழுங்கமைப்பதற்கான தொகுப்புகள் மற்றும் அட்டவணைகளின் தொகுப்பாகும். நிறுவல் சில வினாடிகள் ஆகும். utPLSQL இன் தனித்துவமான அம்சம் அதன் பயன்பாட்டின் எளிமை.
உலகளவில், utPLSQL என்பது யூனிட் சோதனைகளை இயக்குவதற்கான ஒரு பொறிமுறையாகும், அங்கு ஒரு யூனிட் சோதனையானது சாதாரண ஆரக்கிள் தொகுதி செயல்முறைகளாக புரிந்து கொள்ளப்படுகிறது, அதன் அமைப்பு சில விதிகளைப் பின்பற்றுகிறது. தொடங்குவதற்கு கூடுதலாக, utPLSQL உங்கள் அனைத்து சோதனை ஓட்டங்களின் பதிவையும் சேமிக்கிறது, மேலும் உள் அறிக்கையிடல் அமைப்பும் உள்ளது.

இந்த நுட்பத்தைப் பயன்படுத்தி செயல்படுத்தப்பட்ட அலகு சோதனைக் குறியீடு எப்படி இருக்கும் என்பதற்கான உதாரணத்தைப் பார்ப்போம்.

எனவே, யூனிட் சோதனைகளுடன் வழக்கமான தொகுப்பு விவரக்குறிப்புக்கான குறியீட்டை திரை காட்டுகிறது. கட்டாயத் தேவைகள் என்ன? பாக்கெட்டில் "utp_" என்ற முன்னொட்டு இருக்க வேண்டும். சோதனைகள் கொண்ட அனைத்து நடைமுறைகளும் ஒரே முன்னொட்டைக் கொண்டிருக்க வேண்டும். தொகுப்பில் இரண்டு நிலையான நடைமுறைகள் இருக்க வேண்டும்: “utp_setup” மற்றும் “utp_teardown”. ஒவ்வொரு யூனிட் சோதனையையும் மறுதொடக்கம் செய்வதன் மூலம் முதல் செயல்முறை அழைக்கப்படுகிறது, இரண்டாவது - துவக்கத்திற்குப் பிறகு.

“utp_setup”, ஒரு விதியாக, ஒரு யூனிட் சோதனையை இயக்க எங்கள் கணினியைத் தயார்படுத்துகிறது, எடுத்துக்காட்டாக, சோதனைத் தரவை உருவாக்குகிறது. “utp_teardown” - மாறாக, அனைத்தும் அசல் அமைப்புகளுக்குத் திரும்பி, வெளியீட்டு முடிவுகளை மீட்டமைக்கும்.

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

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

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

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

உள் அறிக்கையிடல் முறையின் உதாரணம் இதுவாகும். யூனிட் சோதனையின் முடிவுகளின் அடிப்படையில், utPLSQL ஒரு சிறிய அறிக்கையை உருவாக்குகிறது. அதில் ஒவ்வொரு குறிப்பிட்ட காசோலைக்கான முடிவையும் யூனிட் சோதனையின் ஒட்டுமொத்த முடிவையும் பார்க்கிறோம்.

தன்னியக்க சோதனைகளின் 6 விதிகள்

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

1. தன்னியக்க சோதனைகள் பயனுள்ளதாகவும் பயனுள்ளதாகவும் இருக்க வேண்டும். எங்களிடம் அற்புதமான டெவலப்பர்கள் உள்ளனர், அவர்கள் நிச்சயமாக குறிப்பிடப்பட வேண்டும், ஏனென்றால் அவர்களில் சிலர் இந்த அறிக்கையைப் பார்ப்பார்கள், மேலும் அவர்கள் அற்புதமான குறியீட்டை எழுதுகிறார்கள். ஆனால் அவர்களின் அற்புதமான குறியீடு கூட சரியானதாக இல்லை, மேலும் பிழைகள் உள்ளன, உள்ளன மற்றும் தொடர்ந்து இருக்கும். இந்தப் பிழைகளைக் கண்டறிய தன்னியக்க சோதனைகள் தேவை. இது அவ்வாறு இல்லையென்றால், ஒன்று நாங்கள் மோசமான தன்னியக்க சோதனைகளை எழுதுகிறோம், அல்லது கொள்கையளவில் வளர்ச்சியடையாத ஒரு இறந்த பகுதிக்கு வந்துவிட்டோம். இரண்டு சந்தர்ப்பங்களிலும், நாங்கள் ஏதோ தவறு செய்கிறோம், எங்கள் அணுகுமுறை வெறுமனே அர்த்தமற்றது.
2. தன்னியக்க சோதனைகள் பயன்படுத்தப்பட வேண்டும். ஒரு மென்பொருள் தயாரிப்பை எழுதுவதற்கு நிறைய நேரத்தையும் முயற்சியையும் செலவழித்து, அதை ஒரு களஞ்சியத்தில் வைத்து அதை மறந்துவிடுவதில் அர்த்தமில்லை. சோதனைகள் நடத்தப்பட வேண்டும், முடிந்தவரை தொடர்ந்து இயக்க வேண்டும்.
3. தன்னியக்க சோதனைகள் சீராக செயல்பட வேண்டும். நாளின் நேரம், வெளியீட்டு நிலைப்பாடு மற்றும் பிற கணினி அமைப்புகளைப் பொருட்படுத்தாமல், சோதனை ஓட்டங்கள் அதே முடிவுக்கு வழிவகுக்கும். ஒரு விதியாக, நிலையான கணினி அமைப்புகளுடன் சிறப்பு சோதனை தரவுகளுடன் autotests வேலை செய்வதன் மூலம் இது உறுதி செய்யப்படுகிறது.
4. தன்னியக்க சோதனைகள் உங்கள் திட்டத்திற்கு ஏற்றுக்கொள்ளக்கூடிய வேகத்தில் செயல்பட வேண்டும். இந்த நேரம் ஒவ்வொரு அமைப்பிற்கும் தனித்தனியாக தீர்மானிக்கப்படுகிறது. சிலர் நாள் முழுவதும் வேலை செய்ய முடியும், மற்றவர்கள் அதை நொடிகளில் செய்வது முக்கியமானதாகக் கருதுகின்றனர். எங்கள் திட்டத்தில் நாங்கள் என்ன வேகத் தரங்களை அடைந்தோம் என்பதை சிறிது நேரம் கழித்து நான் உங்களுக்கு சொல்கிறேன்.
5. ஆட்டோடெஸ்ட் வளர்ச்சி நெகிழ்வாக இருக்க வேண்டும். எந்தவொரு செயல்பாட்டையும் நாங்கள் இதற்கு முன் செய்யவில்லை என்பதற்காகவோ அல்லது வேறு சில காரணங்களுக்காகவோ சோதனை செய்ய மறுப்பது நல்லதல்ல. utPLSQL வளர்ச்சியில் எந்த கட்டுப்பாடுகளையும் விதிக்கவில்லை, மேலும் ஆரக்கிள், கொள்கையளவில், பல்வேறு விஷயங்களைச் செயல்படுத்த உங்களை அனுமதிக்கிறது. பெரும்பாலான பிரச்சனைகளுக்கு ஒரு தீர்வு உள்ளது, அது நேரம் மற்றும் முயற்சியின் ஒரு விஷயம்.
6. வரிசைப்படுத்துதல். எங்களிடம் பல ஸ்டாண்டுகள் உள்ளன, அங்கு நாங்கள் சோதனைகளை நடத்த வேண்டும். ஒவ்வொரு ஸ்டாண்டிலும், எந்த நேரத்திலும் டேட்டா டம்ப் புதுப்பிக்கப்படும். அதன் முழு அல்லது பகுதி நிறுவலை நீங்கள் வலியின்றி மேற்கொள்ளக்கூடிய வகையில் தானியங்கி சோதனைகளுடன் ஒரு திட்டத்தை நடத்துவது அவசியம்.

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

ஆதாரம்: www.habr.com