UI டெஸ்ட் ஆட்டோமேஷன்: AI உடன் செலினியம், பிளேரைட் மற்றும் சைப்ரஸ் குறியீட்டை உருவாக்குதல்

ஆதாயங்கள்:

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

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

இந்த யூனிட்டில், AI உடன் வலுவான, பராமரிக்கக்கூடிய மற்றும் உண்மையாகச் சரிபார்க்கக்கூடிய UI சோதனைகளை உருவாக்குவதை நோக்கமாகக் கொண்டுள்ளோம்; பலவீனமான சோதனைகளைத் தவிர்க்க கற்றுக்கொள்வீர்கள்.

திட UI சோதனையின் மூன்று தூண்கள்

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

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

3. அர்த்தமுள்ள கூற்று. சோதனையானது பயனர் உண்மையில் பார்க்கும் முடிவைச் சரிபார்க்க வேண்டும் - "ஆர்டர் எண் திரையில் தோன்றியது" போன்றது, "பக்கம் ஏற்றப்பட்டது" மட்டும் அல்ல. AI ஆல் தயாரிக்கப்பட்ட சோதனைக்கு உறுதிப்பாடு இல்லை அல்லது முக்கியமற்றதாக இருந்தால், அந்த சோதனை போலி-பாஸ் (1வது அலகு) உருவாக்குகிறது.

எச்சரிக்கை: AI-உருவாக்கப்பட்ட UI சோதனையை நீங்கள் முதலில் பார்க்கும்போது, ​​அதிகபட்சம் மூன்று விஷயங்களைச் சரிபார்க்கவும்: தேர்வாளர்கள் உறுதியுடன் (டேட்டா-டெஸ்டிட்), காத்திருக்கிறார்களா (குருட்டுத் தூக்கம் இல்லை), மேலும் உறுதியானது உண்மையான பயனர் முடிவைச் சரிபார்க்கிறதா? இந்த மூன்றும் சரியாக இருந்தால், சோதனை உறுதியாக இருக்கும்.

பக்கம் பொருள் மாதிரி

சோதனைகள் பெரிதாக வளரும்போது, ஒவ்வொரு சோதனையிலும் தேர்வாளர்களை எழுதுவது ஒரு பராமரிப்பு கனவாக மாறும். பேஜ் ஆப்ஜெக்ட் மாடல் (POM — ஒவ்வொரு பக்கம்/திரைக்கான தேர்வாளர்கள் மற்றும் செயல்களை ஒரு வகுப்பில் சேகரிக்கும் வடிவமைப்பு முறை) தேர்வாளரை ஒரே இடத்தில் வைக்கிறது; இடைமுகம் மாறும்போது, ​​அதை ஒரே கோப்பில் புதுப்பிக்கலாம். AI சோதனைகளை நேரடியாக இல்லாமல், POM கட்டமைப்பில் தயாரிக்க வேண்டும்; இது பராமரிப்பை தீவிரமாக எளிதாக்குகிறது.

பலவீனமான வரியில் / வலுவான வரியில்

பலவீனமானது: "உள்நுழைவு பக்கத்திற்கு செலினியம் சோதனையை எழுதுங்கள்."

வலிமையானது: "ப்ளேரைட் (டைப்ஸ்கிரிப்ட்) மூலம் உள்நுழைவு சோதனையை எழுதவும். தேர்வாளர்கள் தரவு-சோதனையை மட்டுமே பயன்படுத்துகின்றனர்; பயனர் பார்ப்பதைக் கட்டுப்படுத்த வேண்டாம், பக்கத்தின் தலைப்பைப் பயன்படுத்த வேண்டாம்."

சக்திவாய்ந்த உடனடி; கருவி மொழி, தேர்வாளர் கொள்கை, காத்திருப்பு உத்தி, கட்டிடக்கலை (POM) மற்றும் வெளிப்படையான உறுதியான எதிர்பார்ப்பு ஆகியவற்றை வழங்குகிறது.

சோதனை தரவு மற்றும் சுற்றுச்சூழல் சுதந்திரம்

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

மற்றொரு முக்கியமான விஷயம், உண்மையான பயனர் தரவுகளுடன் UI சோதனை செய்யக்கூடாது. சோதனை சூழலில் தயாரிப்பு தரவுத்தள நகல் பயன்படுத்தப்பட்டால், இந்த பதிவுகள் உண்மையான நபர்களின் தரவு; ஸ்கிரீன்ஷாட்கள் மற்றும் சோதனை பதிவுகள் இந்தத் தரவை வெளிப்படுத்தலாம். செயற்கை (கற்பனை) சோதனைக் கணக்குகளைப் பயன்படுத்தவும்; இவை இரண்டும் ரகசியத்தன்மையைப் பாதுகாக்கிறது மற்றும் சோதனைகளை மீண்டும் உருவாக்குகிறது. உண்மையான வாடிக்கையாளர் கணக்கைக் கொண்டு "ஆர்டர் ரத்து" சோதனையை நடத்துவது நெறிமுறை மற்றும் செயல்பாட்டுத் தவறு.

உதவிக்குறிப்பு: UI சோதனைகளை முடிந்தவரை குறைவாக வைத்திருங்கள்; உண்மையான சரிபார்ப்பை API மற்றும் யூனிட் சோதனைகளுக்கு விடுங்கள், அவை வேகமாகவும் நிலையானதாகவும் இருக்கும். UI சோதனையானது விலை உயர்ந்தது மற்றும் உடையக்கூடியது - உண்மையான இறுதி முதல் இறுதி பயனர் ஓட்டத்தை (சோதனை பிரமிட் லாஜிக்) சரிபார்க்க மட்டுமே பயன்படுத்தவும்.

வாகன ஒப்பீடு

அம்சம்

செலினியம்

நாடக ஆசிரியர்

சைப்ரஸ்

மொழிகள்

ஜாவா, சி#, பைதான், ஜே.எஸ்

JS/TS, பைதான், .NET, ஜாவா

ஜாவாஸ்கிரிப்ட்/டைப்ஸ்கிரிப்ட்

தானாக காத்திருப்பு

இல்லை (கையால்)

ஆம் (வலுவான)

ஆம்

பல உலாவி

பரந்த

Chromium/Firefox/WebKit

குரோமியம்-ஆதிக்கம்

உடையக்கூடிய தன்மை

உயர் (கையேடு காத்திருப்பு)

குறைந்த

குறைந்த

கற்றல் எளிமை

நடுத்தர

எளிதாக

எளிதாக

இணை செயல்பாடு

கட்டம் தேவை

உள்ளமைக்கப்பட்ட

குடியிருப்பாளர்/பணம் செலுத்தியவர்

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

நகலெடுக்கக்கூடிய நான்கு வார்ப்புருக்கள்

1) திட UI சோதனை உருவாக்கம்:

உங்கள் பங்கு: மூத்த சோதனை ஆட்டோமேஷன் பொறியாளர். பின்வரும் ஓட்டத்திற்கு [கருவி + மொழி] மூலம் சோதனைகளை எழுதவும்: [ஓட்டம்]. விதிகள்:- தேர்வாளர்கள் தரவு-சோதனை மட்டுமே; XPath/CSS-வகுப்பைப் பயன்படுத்துதல். - குருட்டு தூக்கம் இல்லை; வெளிப்படையான/தானியங்கி காத்திருப்பைப் பயன்படுத்தவும். - பக்கம் பொருள் மாதிரியைப் பயன்படுத்தவும். - ஒவ்வொரு உறுதிமொழியும் உண்மையான பயனர் முடிவைச் சரிபார்க்கட்டும். ஒவ்வொரு சோதனையின் தொடக்கத்திலும் நீங்கள் சரிபார்க்கும் ஏற்றுக்கொள்ளும் அளவுகோலைக் குறிப்பிடவும்.

2) பலவீனம் கட்டுப்பாடு:

உடையக்கூடிய தன்மைக்கான பின்வரும் UI சோதனையை ஆராயவும்:- நிலையற்ற தேர்வி உள்ளதா (நீண்டது

3) பக்க பொருளாக மாற்றுதல்:

பின்வரும் எளிய சோதனைக் குறியீட்டை பக்க பொருள் மாதிரி அமைப்பாக மாற்றவும். தேர்வாளர்களையும் செயல்களையும் பக்க வகுப்புகளுக்கு நகர்த்தவும்; சோதனைக் கோப்பு காட்சி ஓட்டத்தை மட்டும் படிக்கட்டும். [கருவிகள்/மொழி]. குறியீடு: [ஒட்டு குறியீடு]

4) போலி-மாற்ற ஆதாரம்:

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

மூன்று சிறிய வழக்குகள்

வழக்கு 1 - உடையக்கூடிய தேர்வாளரிடமிருந்து விடுதலை. AI உடன் ஒரு குழு தயாரித்த 40 சோதனைகளில், 70% இடைமுகப் புதுப்பித்தலுக்குப் பிறகு உடைக்கப்பட்டது; அவை எதுவும் உண்மையான பிழைகள் அல்ல, அவை அனைத்தும் உடையக்கூடிய XPath தேர்வாளர்கள். குழுவானது சோதனைகளை டேட்டா-டெஸ்டிட் பேஸ்டாக "பிளேகிலிட்டி செக்" டெம்ப்ளேட்டுடன் மாற்றியது. அடுத்த மூன்று இடைமுக புதுப்பிப்புகளில், தவறான இடைவெளிகளின் எண்ணிக்கை பூஜ்ஜியமாகக் குறைந்தது; பராமரிப்பு நேரம் வாரத்திற்கு 6 மணி நேரத்திலிருந்து 30 நிமிடங்களாக குறைக்கப்பட்டது.

வழக்கு 2 - போலி-பாஸிங் UI சோதனை. AI ஒரு "கார்ட்டில் சேர்" சோதனையை உருவாக்கியது; சோதனை பச்சையாக இருந்தது. "போலி-ஆதாரம்-பாதி" டெம்ப்ளேட்டை இயக்கியபோது, ​​சோதனையானது பட்டன் கிளிக் மற்றும் பக்கத்தின் தலைப்பை மட்டுமே சரிபார்க்கத் தோன்றியது, கார்ட் கவுண்டர் அதிகரித்ததா இல்லையா என்பதை ஒருபோதும் சரிபார்க்கவில்லை. வண்டி லாஜிக் முற்றிலுமாக உடைந்தாலும், சோதனை வெற்றியடைந்தது. உண்மையான உறுதிமொழி சேர்க்கப்பட்டது (கார்ட் பேட்ஜ் "1").

வழக்கு 3 - குருட்டு காத்திருப்பு பொறி. AI ஆல் தயாரிக்கப்பட்ட செலினியம் சோதனையில், ஒவ்வொரு அடியிலும் தூக்கம்(2) இருந்தது; 60 சோதனைகள் 14 நிமிடங்கள் எடுத்தன, இன்னும் எப்போதாவது உடைந்தன. திறந்த காத்திருப்புக்கு மாறிய பிறகு (உறுப்பு கிளிக் செய்யக்கூடியதாக இருக்கும் வரை காத்திருங்கள்) நேரம் 5 நிமிடங்களுக்குச் சென்றது மற்றும் உடையக்கூடிய தன்மை மறைந்தது. குருட்டு காத்திருப்பு மெதுவாகவும் நம்பமுடியாததாகவும் இருந்தது.

பொதுவான தவறுகள்

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

சுருக்கமாக

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

விண்ணப்ப பணி

உங்கள் சொந்த திட்டத்திலிருந்து ஒரு பயனர் ஓட்டத்தைத் தேர்ந்தெடுக்கவும் (எ.கா. உள்நுழைவு அல்லது தேடல்). "வலுவான UI சோதனை உருவாக்கம்" டெம்ப்ளேட்டுடன் AI சோதனைகளை எழுத வேண்டும். பிறகு: (1) தேர்வாளர்களைச் சரிபார்த்து சரிசெய்து, "பலவீனமான சோதனை" மூலம் காத்திருக்கவும், (2) ஒவ்வொரு சோதனையும் உண்மையில் "போலி-பாஸ் ஆதாரம்" மூலம் சரிபார்க்கிறது என்பதை நிரூபிக்கவும், (3) குறியீட்டை உடைத்து சோதனை சிவப்பு நிறமாக மாறுவதைக் கவனிக்கவும். தயாரிக்கப்பட்ட மற்றும் சரிசெய்யப்பட்ட சோதனைகளின் எண்ணிக்கை மற்றும் நீங்கள் கண்டறிந்த பாதிப்புகள் மற்றும் போலி-பாஸ்களின் எண்ணிக்கையைப் புகாரளிக்கவும்.

சரிபார்ப்பு பட்டியல்

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