மாற்றம் தொடர்பான சோதனை வகைகள்

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

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

புகை பரிசோதனை என்றால் என்ன

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

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

ஒரு எளிய உதாரணத்தைப் பார்ப்போம். எங்கள் பயன்பாட்டின் முன் தயாரிப்பு பதிப்பு bryak.com இல் உள்ளது (உண்மையான தளங்களுடனான ஏதேனும் ஒற்றுமைகள் சீரற்றவை). சோதனைக்காக ஒரு புதிய வெளியீட்டை நாங்கள் தயார் செய்து பதிவேற்றியுள்ளோம். முதலில் எதைச் சரிபார்க்க வேண்டும்? பயன்பாடு இன்னும் திறக்கப்படுகிறதா என்பதைச் சரிபார்ப்பதன் மூலம் தொடங்குவேன். வலை சேவையகம் எங்களுக்கு “200” என்று பதிலளித்தால், எல்லாம் நன்றாக இருக்கிறது, செயல்பாட்டைச் சரிபார்க்க ஆரம்பிக்கலாம்.

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

எங்களின் முதல் புகைப் பரிசோதனை

Badoo இல், சர்வர் பக்கமானது பெரும்பாலும் PHP இல் எழுதப்பட்டுள்ளது. வெளிப்படையான காரணங்களுக்காக, அலகு சோதனைகள் அதில் எழுதப்பட்டுள்ளன. எனவே எங்களிடம் ஏற்கனவே PHPUnit உள்ளது. தேவையில்லாமல் தொழில்நுட்பங்களை பெருக்காமல் இருக்க, PHP-யிலும் புகை சோதனைகளை எழுத முடிவு செய்தோம். PHPUnit ஐத் தவிர, URLகள் (libcurl) உடன் பணிபுரிய ஒரு கிளையன்ட் லைப்ரரி மற்றும் அதனுடன் பணிபுரிய ஒரு PHP நீட்டிப்பு - cURL.

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

முறையே இதுபோல் தெரிகிறது:

பொது செயல்பாடு getCurlResponse($url, array $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ எதிர்பார்த்த_பதிலளிப்பு = '200 சரி') ($ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, என்றால் (1); $params['cookies']) && $params['cookies']) ($cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) என்றால் isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) என்றால் (isset($params['post_data']) &&& $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POST_Post_line); ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) என்றால் (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy) ']);
கொடுக்கப்பட்ட URL ஐ அடிப்படையாகக் கொண்டு இந்த முறையே சேவையகப் பதிலை அளிக்கும். இது குக்கீகள், தலைப்புகள், பயனர் முகவர் மற்றும் கோரிக்கையை உருவாக்க தேவையான பிற தரவு போன்ற அளவுருக்களை உள்ளீடாக ஏற்றுக்கொள்கிறது. சேவையகத்திலிருந்து பதிலைப் பெறும்போது, ​​மறுமொழி குறியீடு எதிர்பார்க்கப்படும் குறியீட்டுடன் பொருந்துகிறதா என்பதை முறை சரிபார்க்கிறது. இது அவ்வாறு இல்லையென்றால், இதைச் சுட்டிக்காட்டும் பிழையுடன் சோதனை தோல்வியடையும். வீழ்ச்சிக்கான காரணத்தை எளிதாக தீர்மானிக்க இது செய்யப்படுகிறது. சில உறுதிமொழிகளில் சோதனை தோல்வியுற்றால், பக்கத்தில் எந்த உறுப்பும் இல்லை என்று எங்களிடம் கூறினால், பதில் குறியீடு, எடுத்துக்காட்டாக, எதிர்பார்க்கப்படும் "200" க்கு பதிலாக "404" என்று ஒரு செய்தியை விட பிழை குறைவாக இருக்கும்.

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

எளிமையான சோதனை இதுபோல் தெரிகிறது:

பொதுச் செயல்பாடு testStartPage() ( $url = ‘bryak.com’; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
இந்த சோதனை ஒரு வினாடிக்கும் குறைவாகவே ஆகும். இந்த நேரத்தில், தொடக்கப் பக்கம் “200” என்று பதிலளிக்கிறது மற்றும் உடல் உறுப்பு உள்ளது என்பதை நாங்கள் சரிபார்த்தோம். அதே வெற்றியுடன், பக்கத்தில் உள்ள உறுப்புகளின் எண்ணிக்கையை நாம் சோதிக்கலாம், சோதனையின் காலம் கணிசமாக மாறாது.

அத்தகைய சோதனைகளின் நன்மைகள்:

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

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

அங்கீகாரம்

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

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

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

எந்த உலாவியிலும் இந்தப் பக்கத்தைத் திறந்து இன்ஸ்பெக்டரைத் திறக்கவும். பயனர் தரவை உள்ளிட்டு படிவத்தை சமர்ப்பிக்கவும்.

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

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

அத்தகைய கோரிக்கைக்கு பதிலளிக்கும் விதமாக, சேவையகம் குக்கீகளை எங்களிடம் திருப்பித் தரும், அங்கீகரிக்கப்பட்ட பக்கங்களைச் சோதிப்பதற்காக மேலும் கோரிக்கைகளைச் சேர்ப்போம்.

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

பொதுச் செயல்பாடு testAuthPage() ( $url = ‘bryak.com’; $cookies = $this->getAuthCookies(‘ [மின்னஞ்சல் பாதுகாக்கப்பட்டது]', '12345'); $response = $this->getCurlResponse($url, ['cookies' => $cookies]);
$this->உறுதிப்படுத்துHTMLPresent("

", $response, "பிழை: சோதனைப் பக்கத்தில் உடல் உறுப்புகளைக் கண்டறிய முடியவில்லை."); )
கொடுக்கப்பட்ட மின்னஞ்சலில் (உங்கள் விஷயத்தில் அது உள்நுழைவாக இருக்கலாம் அல்லது வேறு ஏதேனும் இருக்கலாம்) முன்பு பெறப்பட்ட அங்கீகார குக்கீ உள்ளதா என்பதை இந்த முறை முதலில் சரிபார்க்கிறது. இருந்தால் திருப்பித் தருகிறார். இல்லையெனில், அது அங்கீகாரப் பக்கத்திற்கு (எடுத்துக்காட்டாக, bryak.com/auth_page_adds) தேவையான அளவுருக்கள்: பயனர் மின்னஞ்சல் மற்றும் கடவுச்சொல்லைக் கோருகிறது. இந்த கோரிக்கைக்கு பதிலளிக்கும் விதமாக, சேவையகம் தலைப்புகளை அனுப்புகிறது, அவற்றில் நாங்கள் ஆர்வமாக உள்ள குக்கீகள் உள்ளன. இது போல் தெரிகிறது:

HTTP/1.1 200 சரி சேவையகம்: nginx உள்ளடக்க வகை: உரை/html; charset=utf-8 Transfer-Encoding: chunked Connection: Keep-alive Set-Cookie: name=value; காலாவதியாகும்=புதன், 30-நவம்பர்-2016 10:06:24 GMT; அதிகபட்ச வயது=-86400; பாதை=/; domain=bryak.com
இந்த தலைப்புகளிலிருந்து, ஒரு எளிய வழக்கமான வெளிப்பாட்டைப் பயன்படுத்தி, குக்கீயின் பெயரையும் அதன் மதிப்பையும் நாம் பெற வேண்டும் (எங்கள் எடுத்துக்காட்டில் இது பெயர்=மதிப்பு). பதிலைப் பாகுபடுத்தும் எங்கள் முறை இதுபோல் தெரிகிறது:

$this->assertTrue((bool)preg_match_all("/Set-Cookie: ([^=]+)=([^;]+);.*)\n/", $response, $mch1), " சேவையக பதிலில் இருந்து "குக்கீகளை" பெற முடியாது: " . $response);
குக்கீகளைப் பெற்றவுடன், அதை அங்கீகரிக்கும் வகையில் எந்த கோரிக்கையிலும் பாதுகாப்பாகச் சேர்க்கலாம்.

தோல்வியுற்ற சோதனைகளின் பகுப்பாய்வு

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

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

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

எடுத்துக்காட்டாக, எங்கள் சோதனை தோல்வியடைந்தது, ஏனெனில் அது பக்கத்தில் HTML இன் ஒரு பகுதியைக் கண்டுபிடிக்க முடியவில்லை:

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

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

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

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

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

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

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

முடிவுகள்

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

இந்த நேரத்தில் நாங்கள் உறுதி செய்கிறோம்:

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

இவை அனைத்திற்கும் செலினியம் வெப்டிரைவரில் சோதனைகள் பல மடங்கு அதிக நேரமும் வளங்களும் தேவைப்படும்.

குறிச்சொற்களைச் சேர்க்கவும்

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

இதன் விளைவாக உருவாக்கம் சோதனைக்கு ஏற்றது என்பதை உறுதிப்படுத்த புகை சோதனை மேற்கொள்ளப்படுகிறது. இது "பூஜ்ஜிய நாள்" சரிபார்ப்பு என்றும் அழைக்கப்படுகிறது.

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

சுகாதார பரிசோதனை:

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

புகை மற்றும் சுகாதார சோதனைக்கு இடையே உள்ள வேறுபாட்டை நன்கு புரிந்துகொள்ள ஒரு எடுத்துக்காட்டு:

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

புகை மற்றும் சுகாதார சோதனைக்கு இடையே இன்னும் சில வேறுபாடுகள்:

• புகை சோதனை டெவலப்பர்கள் மற்றும் சோதனையாளர்கள் இருவரும் மேற்கொள்ளப்படுகிறது;
• சுகாதார சோதனை சோதனையாளர்களால் மட்டுமே மேற்கொள்ளப்படுகிறது.

• புகைப் பரிசோதனையானது ஒரு பயன்பாட்டின் தொடக்கம் முதல் இறுதி வரை அனைத்து முக்கிய செயல்பாடுகளையும் உள்ளடக்கியது;
• துப்புரவு சோதனையானது பயன்பாட்டின் குறிப்பிட்ட கூறுகளை மட்டுமே சோதிக்கிறது.

• புகை சோதனையானது நிலையான மற்றும் நிலையற்ற கட்டமைப்பை கடந்து செல்கிறது;
• கட்டமைப்பின் ஒப்பீட்டளவில் நிலையான பதிப்பு சுகாதார சோதனைக்கு உட்பட்டுள்ளது.

Kirill Flyagin, கேம் டிசைனர், QA Lead

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

மொழிபெயர்ப்பானது ஆசிரியரின் பிரதிபலிப்புகள் மற்றும் அவரது சொந்த அனுபவத்தின் சேர்த்தல்களுடன் நீர்த்தப்பட்டுள்ளது

இதெல்லாம் என்ன?

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

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

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

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

கல்வித் திட்டம்

இன்று நாம் ஒப்பிடும் சோதனை வகைகளின் சுருக்கமான வரையறைகள் கீழே உள்ளன:

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

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

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

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

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

ஆனால் அடிப்படையில்?

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

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

• இது 10 நுழைவு புள்ளிகளைக் கொண்டுள்ளது, எளிமைக்காக, அதே ஐபியில் அமைந்துள்ளது
• அவர்கள் அனைவரும் உள்ளீட்டிற்கான GET கோரிக்கையை ஏற்றுக்கொள்கிறார்கள், சில தரவை json வடிவத்தில் திருப்பி அனுப்புகிறார்கள்.

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

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

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

• இந்த வழக்கில் சுகாதார சோதனையானது, அனைத்து 10 நுழைவு புள்ளிகளுக்கும் api இல் ஒரு கோரிக்கையை செயல்படுத்துதல், பெறப்பட்ட json ஐ எதிர்பார்த்த ஒன்றுடன் சரிபார்த்தல் மற்றும் அதில் தேவையான தரவு இருப்பதைக் கொண்டிருக்கும்.
• பின்னடைவு சோதனைகள் ஒரே குவியலில் ஒன்றாக இயங்கும் புகை + நல்லறிவு + UI ஆகியவற்றைக் கொண்டிருக்கும். இலக்கு: 11வது நுழைவுப் புள்ளியைச் சேர்ப்பது உடைக்கப்படவில்லை என்பதைச் சரிபார்க்கவும், எடுத்துக்காட்டாக, கடவுச்சொல் மீட்பு.
• இந்த எடுத்துக்காட்டில் மறு-சோதனை என்பது ஒரு புள்ளி-மூலம்-புள்ளி சரிபார்ப்பாகும், எடுத்துக்காட்டாக, அடுத்த உருவாக்கத்தில் உடைந்த API நுழைவுப் புள்ளி நோக்கம் கொண்டதாக வேலை செய்கிறது.

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

அதை சுருக்கமாகச் சொல்லலாம்

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

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

உதவிக்குறிப்புக்கு நன்றி

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

- புகை பரிசோதனை(புகை சோதனை)

- பின்னடைவு சோதனை(பின்னடைவு சோதனை)

- கட்டமைப்பை சோதிக்கிறது(கட்டிட சரிபார்ப்பு சோதனை)

- சுகாதார சோதனை அல்லது நிலைத்தன்மை/செயல்பாட்டு சோதனை(நுண்ணறிவு சோதனை)

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

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

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

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

- பிழை பின்னடைவு- திருத்தப்பட்ட பிழை உண்மையில் சரி செய்யப்படவில்லை என்பதை நிரூபிக்கும் முயற்சி.

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

- பக்க விளைவு பின்னடைவு- குறியீடு அல்லது தரவுகளில் சமீபத்திய மாற்றம் உருவாக்கப்பட்டு வரும் பயன்பாட்டின் பிற பகுதிகளை உடைத்துவிட்டது என்பதை நிரூபிக்கும் முயற்சி.

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

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

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

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

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

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

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

உங்களிடம் இன்னும் கேள்விகள் இருந்தால், பார்வையிடுவதன் மூலம் இடைவெளிகளை நிரப்பலாம்

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

காத்திருங்கள், இது பயன்பாடுகளுக்கு எவ்வாறு பொருந்தும்?

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

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

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

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

படி 1: எதைச் சோதிக்க வேண்டும் என்பதைத் தீர்மானிக்கவும்

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

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

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

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

1. பதிவு.
2. ஒரு பயனர்பெயரை உருவாக்கவும்.
3. உங்கள் அவதாரத்தில் ஒரு புகைப்படத்தைப் பதிவேற்றவும்.
4. செய்திகளை எழுதுங்கள்.
5. செய்திகளுக்கு பதில்.

படி 2: முடிவுகளை அட்டவணையில் பதிவு செய்யவும்

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

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

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

படி 3: புகை சோதனைகளை தானியங்குபடுத்துங்கள்

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

புகை பரிசோதனையை நிறுத்த வேண்டாம். ஒருபோதும் இல்லை.

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

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

புகைப் பரிசோதனைக்கான விதி:

• குறைந்தபட்ச நேரம்: 30 நிமிடங்கள்.
• அதிகபட்ச நேரம்: 60 நிமிடங்கள்.

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