உற்பத்திச் சூழலில் புதிய பதிப்புப் பயன்பாடுகளைத் தொடங்குவதற்கு எங்கள் பிரிவு முழுமையாக தானியங்கி பைப்லைன்களை உருவாக்குகிறது. நிச்சயமாக, இதற்கு தானியங்கு செயல்பாட்டு சோதனைகள் தேவை. லோக்கல் மெஷினில் சிங்கிள்-த்ரெட் டெஸ்டிங்கில் தொடங்கி, கிட்லேப் பக்கங்களில் உள்ள அலுர் ரிப்போர்ட் மூலம் பில்ட் பைப்லைனில் செலினாய்டில் இயங்கும் மல்டி-த்ரெட் ஆட்டோடெஸ்ட்களுக்குச் சென்று, இறுதியில் ஒரு கூல் ஆட்டோமேஷன் கருவியை எப்படிப் பெற்றோம் என்பது பற்றிய கதை கீழே உள்ளது. எதிர்கால மக்கள் அணிகளைப் பயன்படுத்தலாம்.
எங்கிருந்து ஆரம்பித்தோம்?
தன்னியக்க சோதனைகளைச் செயல்படுத்தவும், அவற்றை பைப்லைனில் ஒருங்கிணைக்கவும், எங்கள் தேவைகளுக்கு ஏற்றவாறு நெகிழ்வாக மாற்றக்கூடிய ஒரு ஆட்டோமேஷன் கட்டமைப்பு தேவை. சிறந்த முறையில், ஆட்டோடெஸ்டிங் இன்ஜினுக்கான ஒற்றை தரநிலையைப் பெற விரும்பினேன், இது பைப்லைனில் ஆட்டோடெஸ்ட்களை உட்பொதிப்பதற்கு ஏற்றது. செயல்படுத்த, நாங்கள் பின்வரும் தொழில்நுட்பங்களைத் தேர்ந்தெடுத்தோம்:
- ஜாவா,
- மேவன்,
- செலினியம்,
- வெள்ளரிக்காய்+ஜூனிட் 4,
- கவர்ச்சி,
- கிட்லாப்.
ஏன் இந்த குறிப்பிட்ட தொகுப்பு? தன்னியக்க சோதனைகளுக்கு ஜாவா மிகவும் பிரபலமான மொழிகளில் ஒன்றாகும், மேலும் அனைத்து குழு உறுப்பினர்களும் அதை பேசுகிறார்கள். செலினியம் ஒரு தெளிவான தீர்வு. வெள்ளரிக்காய், மற்றவற்றுடன், கையேடு சோதனையில் ஈடுபட்டுள்ள துறைகளின் தரப்பில் தானியங்கி சோதனைகளின் முடிவுகளில் நம்பிக்கையை அதிகரிக்க வேண்டும்.
ஒற்றை திரிக்கப்பட்ட சோதனைகள்
சக்கரத்தை மீண்டும் கண்டுபிடிக்காமல் இருப்பதற்காக, கிட்ஹப்பில் உள்ள பல்வேறு களஞ்சியங்களிலிருந்து மேம்பாடுகளை கட்டமைப்பின் அடிப்படையாக எடுத்து, அவற்றை நமக்கு ஏற்றவாறு மாற்றிக்கொண்டோம். ஆட்டோடெஸ்ட் கட்டமைப்பின் மையத்துடன் பிரதான நூலகத்திற்கான களஞ்சியத்தையும், எங்கள் மையத்தில் தன்னியக்க சோதனைகளை செயல்படுத்துவதற்கான தங்க உதாரணத்துடன் ஒரு களஞ்சியத்தையும் உருவாக்கியுள்ளோம். ஒவ்வொரு குழுவும் தங்கப் படத்தை எடுத்து அதில் சோதனைகளை உருவாக்க வேண்டும், அதை தங்கள் திட்டத்திற்கு மாற்றியமைக்க வேண்டும். நாங்கள் அதை GitLab-CI வங்கியில் பயன்படுத்தினோம், அதில் நாங்கள் கட்டமைத்தோம்:
- ஒவ்வொரு திட்டத்திற்கும் எழுதப்பட்ட அனைத்து தன்னியக்க சோதனைகளின் தினசரி ரன்கள்;
- கட்டுமானக் குழாயில் தொடங்குகிறது.
முதலில் சில சோதனைகள் இருந்தன, அவை ஒரே ஸ்ட்ரீமில் மேற்கொள்ளப்பட்டன. Windows ரன்னர் GitLab இல் இயங்கும் ஒற்றை-திரிகை எங்களுக்கு மிகவும் பொருத்தமானது: சோதனைகள் சோதனை பெஞ்சை மிக இலகுவாக ஏற்றியது மற்றும் கிட்டத்தட்ட எந்த ஆதாரங்களையும் பயன்படுத்தவில்லை.
காலப்போக்கில், தன்னியக்க சோதனைகளின் எண்ணிக்கை மேலும் மேலும் அதிகரித்தது, மேலும் அவற்றை இணையாக இயக்குவது பற்றி நாங்கள் நினைத்தோம், ஒரு முழு ஓட்டம் சுமார் மூன்று மணிநேரம் எடுக்கத் தொடங்கியது. பிற சிக்கல்களும் தோன்றின:
- சோதனைகள் நிலையானவை என்பதை எங்களால் சரிபார்க்க முடியவில்லை;
- உள்ளூர் இயந்திரத்தில் தொடர்ச்சியாக பல முறை நடத்தப்பட்ட சோதனைகள் சில நேரங்களில் CI இல் செயலிழந்தன.
தன்னியக்க சோதனைகளை அமைப்பதற்கான எடுத்துக்காட்டு:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
<configuration>
<skipTests>${skipTests}</skipTests>
<testFailureIgnore>false</testFailureIgnore>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>io.qameta.allure</groupId>
<artifactId>allure-maven</artifactId>
<version>2.9</version>
</plugin>
</plugins>
அல்லூர் அறிக்கை உதாரணம்
சோதனைகளின் போது ரன்னர் சுமை (8 கோர்கள், 8 ஜிபி ரேம், 1 நூல்)
ஒற்றை-திரிக்கப்பட்ட சோதனைகளின் நன்மைகள்:
- அமைக்க மற்றும் இயக்க எளிதானது;
- CI இல் ஏவுதல்கள் நடைமுறையில் உள்ளூர் வெளியீடுகளிலிருந்து வேறுபட்டவை அல்ல;
- சோதனைகள் ஒன்றையொன்று பாதிக்காது;
- ரன்னர் வளங்களுக்கான குறைந்தபட்ச தேவைகள்.
ஒற்றை-திரிக்கப்பட்ட சோதனைகளின் தீமைகள்:
- முடிக்க மிக நீண்ட நேரம் எடுக்கும்;
- சோதனைகளின் நீண்ட நிலைப்படுத்தல்;
- ரன்னர் வளங்களின் திறமையற்ற பயன்பாடு, மிகக் குறைந்த பயன்பாடு.
ஜேவிஎம் ஃபோர்க்குகளில் சோதனைகள்
அடிப்படை கட்டமைப்பை செயல்படுத்தும் போது நூல்-பாதுகாப்பான குறியீட்டை நாங்கள் கவனிக்கவில்லை என்பதால், இணையாக இயங்குவதற்கான மிகத் தெளிவான வழி மேவனுக்கு. சொருகி கட்டமைக்க எளிதானது, ஆனால் சரியான இணையான செயல்பாட்டிற்கு, தானியங்கு சோதனைகள் தனி உலாவிகளில் இயக்கப்பட வேண்டும். செய்ய ஒன்றுமில்லை, நான் செலினாய்டைப் பயன்படுத்த வேண்டியிருந்தது.
செலினாய்டு சேவையகம் 32 கோர்கள் மற்றும் 24 ஜிபி ரேம் கொண்ட கணினியில் தொடங்கப்பட்டது. வரம்பு 48 உலாவிகளில் அமைக்கப்பட்டது - ஒரு மையத்திற்கு 1,5 த்ரெட்கள் மற்றும் 400 எம்பி ரேம். இதன் விளைவாக, சோதனை நேரம் மூன்று மணி நேரத்தில் இருந்து 40 நிமிடங்களாக குறைக்கப்பட்டது. ரன்களை விரைவுபடுத்துவது உறுதிப்படுத்தல் சிக்கலைத் தீர்க்க உதவியது: இப்போது புதிய தன்னியக்க சோதனைகளை 20-30 முறை விரைவாக இயக்க முடியும், அவை நம்பகத்தன்மையுடன் இயங்குகின்றன என்பதை நாங்கள் உறுதிசெய்யும் வரை.
தீர்வின் முதல் குறைபாடானது, குறைந்த எண்ணிக்கையிலான இணையான நூல்களைக் கொண்ட ரன்னர் வளங்களை அதிக அளவில் பயன்படுத்துவதாகும்: 4 கோர்கள் மற்றும் 8 ஜிபி ரேம் ஆகியவற்றில், சோதனைகள் 6 த்ரெட்களுக்கு மேல் நிலையானதாக இயங்கவில்லை. இரண்டாவது குறைபாடு: சொருகி ஒவ்வொரு சூழ்நிலையிலும் ரன்னர் வகுப்புகளை உருவாக்குகிறது, அவற்றில் எத்தனை தொடங்கப்பட்டாலும் பரவாயில்லை.
முக்கியம்! குறிச்சொற்கள் கொண்ட மாறியை அனுப்ப வேண்டாம் argLine, எடுத்துக்காட்டாக, இது போன்றது:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
இந்த வழியில் நீங்கள் குறிச்சொல்லை அனுப்பினால், செருகுநிரல் அனைத்து சோதனைகளுக்கும் ரன்னர்களை உருவாக்கும், அதாவது, அனைத்து சோதனைகளையும் இயக்க முயற்சிக்கும், தொடங்கப்பட்ட உடனேயே அவற்றைத் தவிர்த்து, பல JVM ஃபோர்க்குகளை உருவாக்கும்.
ஒரு குறிச்சொல்லுடன் ஒரு மாறியை எறிவது சரியானது குறிச்சொற்களை செருகுநிரல் அமைப்புகளில், கீழே உள்ள உதாரணத்தைப் பார்க்கவும். நாங்கள் சோதித்த மற்ற முறைகள் Allure செருகுநிரலை இணைப்பதில் சிக்கல்கள் உள்ளன.
தவறான அமைப்புகளுடன் 6 குறுகிய சோதனைகளுக்கான இயங்கும் நேரத்தின் எடுத்துக்காட்டு:
[INFO] Total time: 03:17 min
நீங்கள் குறிச்சொல்லை நேரடியாக மாற்றினால், சோதனை நேரத்தின் எடுத்துக்காட்டு mvn... –Dcucumber.options:
[INFO] Total time: 44.467 s
தன்னியக்க சோதனைகளை அமைப்பதற்கான எடுத்துக்காட்டு:
<profiles>
<profile>
<id>parallel</id>
<build>
<plugins>
<plugin>
<groupId>com.github.temyers</groupId>
<artifactId>cucumber-jvm-parallel-plugin</artifactId>
<version>5.0.0</version>
<executions>
<execution>
<id>generateRunners</id>
<phase>generate-test-sources</phase>
<goals>
<goal>generateRunners</goal>
</goals>
<configuration>
<tags>
<tag>${TAGS}</tag>
</tags>
<glue>
<package>stepdefs</package>
</glue>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
<forkCount>12</forkCount>
<reuseForks>false</reuseForks>
<includes>**/*IT.class</includes>
<testFailureIgnore>false</testFailureIgnore>
<!--suppress UnresolvedMavenProperty -->
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar" -Dcucumber.options="--plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm TagPFAllureReporter --plugin pretty"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
ஒரு அல்லூர் அறிக்கையின் எடுத்துக்காட்டு (மிகவும் நிலையற்ற சோதனை, 4 மறு இயக்கங்கள்)
சோதனைகளின் போது ரன்னர் சுமை (8 கோர்கள், 8 ஜிபி ரேம், 12 இழைகள்)
நன்மை:
- எளிதான அமைப்பு - நீங்கள் ஒரு சொருகி சேர்க்க வேண்டும்;
- ஒரே நேரத்தில் அதிக எண்ணிக்கையிலான சோதனைகளைச் செய்யும் திறன்;
- சோதனை நிலைப்படுத்தலின் முடுக்கம் படி 1 க்கு நன்றி.
தீமைகள்:
- பல OS/கன்டெய்னர்கள் தேவை;
- ஒவ்வொரு முட்கரண்டிக்கும் அதிக வள நுகர்வு;
- செருகுநிரல் காலாவதியானது மற்றும் இனி ஆதரிக்கப்படாது.
உறுதியற்ற தன்மையை எவ்வாறு சமாளிப்பது
தன்னியக்க சோதனைகளைப் போலவே டெஸ்ட் பெஞ்சுகளும் சிறந்தவை அல்ல. எங்களிடம் பல தட்டையான சோதனைகள் இருப்பதில் ஆச்சரியமில்லை. உதவிக்கு வந்தார், தோல்வியுற்ற சோதனைகளை மறுதொடக்கம் செய்வதை பெட்டிக்கு வெளியே ஆதரிக்கிறது. நீங்கள் செருகுநிரல் பதிப்பை குறைந்தபட்சம் 2.21 க்கு புதுப்பிக்க வேண்டும் மற்றும் போம் கோப்பில் மறுதொடக்கம் செய்யப்பட்ட எண்ணிக்கையுடன் ஒரு வரியை எழுத வேண்டும் அல்லது அதை மேவனுக்கு ஒரு வாதமாக அனுப்ப வேண்டும்.
தன்னியக்க சோதனைகளை அமைப்பதற்கான எடுத்துக்காட்டு:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
அல்லது தொடக்கத்தில்: mvn … -Dsurefire.rerunFailingTestsCount=2 …
ஒரு விருப்பமாக, பவர்ஷெல் ஸ்கிரிப்ட்டுக்கு (PS1) மேவன் விருப்பங்களை அமைக்கவும்:
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"நன்மை:
- ஒரு நிலையற்ற சோதனை செயலிழக்கும்போது அதை பகுப்பாய்வு செய்வதில் நேரத்தை வீணடிக்க வேண்டிய அவசியமில்லை;
- சோதனை பெஞ்ச் ஸ்திரத்தன்மை சிக்கல்களைத் தணிக்க முடியும்.
தீமைகள்:
- மிதக்கும் குறைபாடுகள் தவறவிடப்படலாம்;
- இயக்க நேரம் அதிகரிக்கிறது.
வெள்ளரி 4 நூலகத்துடன் இணையான சோதனைகள்
ஒவ்வொரு நாளும் சோதனைகளின் எண்ணிக்கை அதிகரித்தது. ரன்களை விரைவுபடுத்துவது பற்றி மீண்டும் யோசித்தோம். கூடுதலாக, அப்ளிகேஷன் அசெம்பிளி பைப்லைனில் முடிந்தவரை பல சோதனைகளை ஒருங்கிணைக்க விரும்பினேன். முக்கியமான காரணி என்னவென்றால், மேவன் செருகுநிரலைப் பயன்படுத்தி இணையாக இயங்கும் போது ரன்னர்களின் தலைமுறை அதிக நேரம் எடுத்தது.
அந்த நேரத்தில், வெள்ளரி 4 ஏற்கனவே வெளியிடப்பட்டது, எனவே இந்த பதிப்பிற்கான கர்னலை மீண்டும் எழுத முடிவு செய்தோம். வெளியீட்டு குறிப்புகளில், நூல் மட்டத்தில் இணையான துவக்கம் எங்களுக்கு உறுதியளிக்கப்பட்டது. கோட்பாட்டளவில் இது இருந்திருக்க வேண்டும்:
- நூல்களின் எண்ணிக்கையை அதிகரிப்பதன் மூலம் ஆட்டோடெஸ்ட்களின் இயக்கத்தை கணிசமாக விரைவுபடுத்துகிறது;
- ஒவ்வொரு தன்னியக்க சோதனைக்கும் ரன்னர்களை உருவாக்கும் நேர இழப்பை நீக்குகிறது.
பல-திரிக்கப்பட்ட தன்னியக்க சோதனைகளுக்கான கட்டமைப்பை மேம்படுத்துவது அவ்வளவு கடினம் அல்ல. வெள்ளரிக்காய் 4 ஒவ்வொரு தனிப்பட்ட சோதனையையும் தொடக்கத்திலிருந்து இறுதி வரை ஒரு பிரத்யேக நூலில் இயக்குகிறது, எனவே சில பொதுவான நிலையான விஷயங்கள் ThreadLocal மாறிகளாக மாற்றப்பட்டன.
ஐடியா மறுசீரமைப்பு கருவிகளைப் பயன்படுத்தி மாற்றும்போது முக்கிய விஷயம், மாறி ஒப்பிடப்பட்ட இடங்களைச் சரிபார்க்க வேண்டும் (எடுத்துக்காட்டாக, பூஜ்யத்தை சரிபார்க்கிறது). கூடுதலாக, நீங்கள் ஜூனிட் ரன்னர் வகுப்பு சிறுகுறிப்பில் அல்லூர் செருகுநிரலைச் சேர்க்க வேண்டும்.
தன்னியக்க சோதனைகளை அமைப்பதற்கான எடுத்துக்காட்டு:
<profile>
<id>parallel</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<useFile>false</useFile>
<testFailureIgnore>false</testFailureIgnore>
<parallel>methods</parallel>
<threadCount>6</threadCount>
<perCoreThreadCount>true</perCoreThreadCount>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
ஒரு அல்லூர் அறிக்கையின் எடுத்துக்காட்டு (மிகவும் நிலையற்ற சோதனை, 5 மறு இயக்கங்கள்)
சோதனைகளின் போது ரன்னர் சுமை (8 கோர்கள், 8 ஜிபி ரேம், 24 இழைகள்)
நன்மை:
- குறைந்த வள நுகர்வு;
- வெள்ளரிக்காய் இருந்து சொந்த ஆதரவு - கூடுதல் கருவிகள் தேவையில்லை;
- ஒரு செயலி மையத்திற்கு 6 இழைகளுக்கு மேல் இயக்கும் திறன்.
தீமைகள்:
- குறியீடு பல-திரிக்கப்பட்ட செயலாக்கத்தை ஆதரிக்கிறது என்பதை நீங்கள் உறுதிப்படுத்த வேண்டும்;
- நுழைவு வரம்பு அதிகரிக்கிறது.
GitLab பக்கங்களில் Allure அறிக்கைகள்
மல்டி-த்ரெட் எக்ஸிகியூஷனை அறிமுகப்படுத்திய பிறகு, அறிக்கைகளை பகுப்பாய்வு செய்வதில் அதிக நேரம் செலவிடத் தொடங்கினோம். அந்த நேரத்தில், நாங்கள் ஒவ்வொரு அறிக்கையையும் ஒரு கலைப்பொருளாக GitLab இல் பதிவேற்ற வேண்டும், பின்னர் அதைப் பதிவிறக்கி அதைத் திறக்க வேண்டும். இது மிகவும் வசதியானது அல்ல மற்றும் நீண்ட நேரம் எடுக்கும். மேலும் யாராவது அந்த அறிக்கையை தாங்களாகவே பார்க்க விரும்பினால், அவர்களும் அதே செயல்பாடுகளைச் செய்ய வேண்டும். நாங்கள் கருத்துக்களை விரைவாகப் பெற விரும்புகிறோம், மேலும் ஒரு தீர்வைக் கண்டோம் - GitLab பக்கங்கள். இது உள்ளமைக்கப்பட்ட அம்சமாகும், இது GitLab இன் அனைத்து சமீபத்திய பதிப்புகளிலும் கிடைக்கும். உங்கள் சர்வரில் நிலையான தளங்களை வரிசைப்படுத்தவும், நேரடி இணைப்பு வழியாக அவற்றை அணுகவும் உங்களை அனுமதிக்கிறது.
Allure அறிக்கைகளின் அனைத்து ஸ்கிரீன்ஷாட்களும் GitLab பக்கங்களில் எடுக்கப்பட்டது. GitLab பக்கங்களுக்கு அறிக்கையை வரிசைப்படுத்துவதற்கான ஸ்கிரிப்ட் - Windows PowerShell இல் (இதற்கு முன் நீங்கள் தானியங்கு சோதனைகளை இயக்க வேண்டும்):
New-Item -ItemType directory -Path $testresulthistory | Out-Null
try {Invoke-WebRequest -Uri $hst -OutFile $outputhst}
Catch{echo "fail copy history"}
try {Invoke-WebRequest -Uri $hsttrend -OutFile $outputhsttrnd}
Catch{echo "fail copy history trend"}
mvn allure:report
#mvn assembly:single -PzipAllureReport
xcopy $buildlocationtargetsiteallure-maven-plugin* $buildlocationpublic /s /i /Y
இறுதியில் என்ன
எனவே, வெள்ளரிக்காய் தன்னியக்க சோதனை கட்டமைப்பில் உங்களுக்கு நூல் பாதுகாப்பான குறியீடு தேவையா என்று நீங்கள் யோசித்துக்கொண்டிருந்தால், இப்போது பதில் தெளிவாக உள்ளது - வெள்ளரி 4 உடன் அதைச் செயல்படுத்துவது எளிது, இதன் மூலம் ஒரே நேரத்தில் தொடங்கப்பட்ட நூல்களின் எண்ணிக்கையை கணிசமாக அதிகரிக்கிறது. சோதனைகளை இயக்கும் இந்த முறையின் மூலம், செலினாய்டு மற்றும் சோதனை பெஞ்ச் கொண்ட இயந்திரத்தின் செயல்திறன் பற்றிய கேள்வி இப்போது எழுகிறது.
த்ரெட்களில் தானியங்கு சோதனைகளை இயக்குவது சிறந்த செயல்திறனுடன் வள நுகர்வுகளை குறைந்தபட்சமாக குறைக்க உங்களை அனுமதிக்கிறது என்பதை பயிற்சி காட்டுகிறது. வரைபடங்களில் இருந்து பார்க்க முடிவது போல், இரட்டிப்பு நூல்கள் செயல்திறன் சோதனைகளில் இதேபோன்ற முடுக்கத்திற்கு வழிவகுக்காது. இருப்பினும், எங்களால் 2 க்கும் மேற்பட்ட தானியங்கு சோதனைகளை அப்ளிகேஷன் உருவாக்கத்தில் சேர்க்க முடிந்தது, இது 200 ரீரன்களுடன் கூட சுமார் 5 நிமிடங்களில் இயங்கும். இது அவர்களிடமிருந்து விரைவான கருத்துக்களைப் பெற உங்களை அனுமதிக்கிறது, தேவைப்பட்டால், மாற்றங்களைச் செய்து, நடைமுறையை மீண்டும் செய்யவும்.
ஆதாரம்: www.habr.com