🥇 DBMS માં એકમ પરીક્ષણો - અમે તેને સ્પોર્ટમાસ્ટરમાં કેવી રીતે કરીએ છીએ, ભાગ બે

પ્રથમ ભાગ - અહીં.

પરિસ્થિતિની કલ્પના કરો. તમે નવી કાર્યક્ષમતા વિકસાવવાના કાર્યનો સામનો કરી રહ્યા છો. તમારી પાસે તમારા પુરોગામી પાસેથી વિકાસ છે. જો અમે ધારીએ કે તમારી કોઈ નૈતિક જવાબદારી નથી, તો તમે શું કરશો?

મોટેભાગે, તમામ જૂના વિકાસ ભૂલી જાય છે અને બધું ફરીથી શરૂ થાય છે. કોઈને કોઈ બીજાના કોડમાં ડિગ કરવાનું પસંદ નથી, પરંતુ જો તમારી પાસે સમય હોય, તો શા માટે તમારી પોતાની સિસ્ટમ બનાવવાનું શરૂ ન કરો? આ એક લાક્ષણિક અભિગમ છે, અને તે મોટે ભાગે સાચો છે. પરંતુ અમારા પ્રોજેક્ટમાં અમે તે ખોટું કર્યું. અમે અમારા પુરોગામી utPLSQL પરના એકમ પરીક્ષણોમાં વિકાસ પર ભાવિ સ્વચાલિત પરીક્ષણ સિસ્ટમ આધારિત, અને પછી ઘણી સમાંતર દિશાઓમાં કામ કરવા ગયા.

જૂના એકમ પરીક્ષણો પુનઃસ્થાપિત કરી રહ્યા છીએ. પુનઃપ્રાપ્તિ એટલે લોયલ્ટી સિસ્ટમની હાલની સ્થિતિને અનુરૂપ પરીક્ષણો અને utPLSQL ધોરણો માટે પરીક્ષણોને અનુકૂલિત કરવા.
ઑટોટેસ્ટ્સ સાથે બરાબર શું, કઈ પદ્ધતિઓ અને પ્રક્રિયાઓ આવરી લેવામાં આવી છે તેની સમજ સાથે સમસ્યાનું નિરાકરણ. તમારે કાં તો આ માહિતી તમારા મગજમાં રાખવી જોઈએ, અથવા ઑટોટેસ્ટ કોડના આધારે સીધા જ તારણો કાઢો. તેથી, અમે એક સૂચિ બનાવવાનું નક્કી કર્યું. અમે દરેક ઓટોટેસ્ટ માટે એક અનન્ય નેમોનિક કોડ અસાઇન કર્યો છે, એક વર્ણન બનાવ્યું છે અને સેટિંગ્સ રેકોર્ડ કરી છે (ઉદાહરણ તરીકે, તેને કઈ પરિસ્થિતિઓમાં લોન્ચ કરવું જોઈએ, અથવા જો ટેસ્ટ લોન્ચ નિષ્ફળ જાય તો શું થવું જોઈએ). અનિવાર્યપણે, અમે ઑટોટેસ્ટ વિશે મેટાડેટા બનાવ્યા અને તે મેટાડેટાને પ્રમાણભૂત utPLSQL સ્કીમા કોષ્ટકોમાં મૂક્યા.
વિસ્તરણ વ્યૂહરચના વ્યાખ્યાયિત કરવી, એટલે કે. કાર્યક્ષમતાની પસંદગી કે જે સ્વચાલિત પરીક્ષણો દ્વારા ચકાસણીને આધીન છે. અમે ત્રણ બાબતો પર ધ્યાન આપવાનું નક્કી કર્યું: નવી સિસ્ટમ સુધારણા, ઉત્પાદન ઘટનાઓ અને મુખ્ય સિસ્ટમ પ્રક્રિયાઓ. આમ, અમે પ્રકાશન સાથે સમાંતર વિકાસ કરી રહ્યા છીએ, તેની ઉચ્ચ ગુણવત્તાની ખાતરી કરી રહ્યા છીએ, સાથે સાથે રીગ્રેશનના અવકાશને વિસ્તૃત કરી રહ્યા છીએ અને નિર્ણાયક સ્થળોએ સિસ્ટમની વિશ્વસનીયતા સુનિશ્ચિત કરી રહ્યા છીએ. આવી પ્રથમ અડચણ ચેક પર ડિસ્કાઉન્ટ અને બોનસ વહેંચવાની પ્રક્રિયા હતી.
સ્વાભાવિક રીતે, અમે નવા ઓટોટેસ્ટ વિકસાવવાનું શરૂ કર્યું. પ્રથમ પ્રકાશન કાર્યોમાંનું એક લોયલ્ટી સિસ્ટમના પૂર્વવ્યાખ્યાયિત નમૂનાઓના પ્રદર્શનનું મૂલ્યાંકન કરવાનું હતું. અમારા પ્રોજેક્ટમાં સખત રીતે નિશ્ચિત SQL ક્વેરીઝનો બ્લોક છે જે શરતોના આધારે ક્લાયંટ પસંદ કરે છે. ઉદાહરણ તરીકે, એવા તમામ ગ્રાહકોની યાદી મેળવો કે જેમની છેલ્લી ખરીદી ચોક્કસ શહેરમાં થઈ હતી, અથવા એવા ગ્રાહકોની યાદી મેળવો કે જેમની ખરીદીની સરેરાશ રકમ ચોક્કસ મૂલ્ય કરતાં વધુ છે. લેખિત સ્વતઃ પરીક્ષણો કર્યા પછી, અમે પૂર્વવ્યાખ્યાયિત નમૂનાઓ, રેકોર્ડ કરેલ બેન્ચમાર્ક પ્રદર્શન પરિમાણો તપાસ્યા અને વધુમાં અમારી પાસે લોડ પરીક્ષણ હતું.
ઑટોટેસ્ટ્સ સાથે કામ કરવું અનુકૂળ હોવું જોઈએ. બે સૌથી સામાન્ય ક્રિયાઓ ઓટોટેસ્ટ ચલાવવી અને ટેસ્ટ ડેટા બનાવવાની છે. આ રીતે અમારી સિસ્ટમમાં બે સહાયક મોડ્યુલ દેખાયા: લોન્ચ મોડ્યુલ અને ડેટા જનરેશન મોડ્યુલ.
લૉન્ચરને એક ટેક્સ્ટ ઇનપુટ પેરામીટર સાથે એક સાર્વત્રિક પ્રક્રિયા તરીકે રજૂ કરવામાં આવે છે. પરિમાણ તરીકે, તમે ઓટોટેસ્ટ નેમોનિક કોડ, પેકેજ નામ, ટેસ્ટ નામ, ઓટોટેસ્ટ સેટિંગ અથવા અનામત કીવર્ડ પાસ કરી શકો છો. પ્રક્રિયા તમામ ઓટોટેસ્ટ પસંદ કરે છે અને ચલાવે છે જે શરતોને સંતોષે છે.

ડેટા જનરેશન મોડ્યુલ એક પેકેજના રૂપમાં રજૂ કરવામાં આવે છે જેમાં પરીક્ષણ હેઠળના સિસ્ટમના દરેક ઑબ્જેક્ટ માટે (ડેટાબેઝમાં એક ટેબલ), એક ખાસ પ્રક્રિયા બનાવવામાં આવી છે જે ત્યાં ડેટા દાખલ કરે છે. આ પ્રક્રિયામાં, ડિફૉલ્ટ મૂલ્યો શક્ય તેટલું ભરવામાં આવે છે, જે આંગળીના ક્લિક પર શાબ્દિક રીતે ઑબ્જેક્ટ બનાવવાની ખાતરી કરે છે. અને ઉપયોગમાં સરળતા માટે, જનરેટ કરેલા ડેટા માટે નમૂનાઓ બનાવવામાં આવ્યા હતા. ઉદાહરણ તરીકે, ટેસ્ટ ફોન અને પૂર્ણ ખરીદી સાથે ચોક્કસ વયનો ક્લાયન્ટ બનાવો.
ઑટોટેસ્ટ તમારી સિસ્ટમ માટે સ્વીકાર્ય હોય તેવા સમયમાં શરૂ અને ચાલવા જોઈએ. તેથી, દૈનિક રાત્રિ પ્રક્ષેપણનું આયોજન કરવામાં આવ્યું હતું, જેના પરિણામોના આધારે પરિણામોનો અહેવાલ તૈયાર કરવામાં આવે છે અને કોર્પોરેટ મેઇલ દ્વારા સમગ્ર વિકાસ ટીમને મોકલવામાં આવે છે. જૂના ઓટોટેસ્ટને પુનઃસ્થાપિત કર્યા પછી અને નવા બનાવ્યા પછી, કુલ ઓપરેટિંગ સમય 30 મિનિટનો હતો. આ પ્રદર્શન દરેકને અનુકૂળ હતું, કારણ કે લોન્ચ કામના કલાકોની બહાર થયું હતું.
પરંતુ અમારે કામની ઝડપને ઑપ્ટિમાઇઝ કરવા પર કામ કરવાનું હતું. ઉત્પાદનમાં વફાદારી સિસ્ટમ રાત્રે અપડેટ કરવામાં આવે છે. એક રિલીઝના ભાગ રૂપે, અમારે રાત્રે તાત્કાલિક ફેરફારો કરવા પડ્યા. સવારે ત્રણ વાગ્યે ઑટોટેસ્ટના પરિણામો માટે અડધો કલાક રાહ જોવી એ પ્રકાશન માટે જવાબદાર વ્યક્તિને ખુશ કરી શક્યો નહીં (એલેક્સી વાસ્યુકોવને પ્રખર શુભેચ્છાઓ!), અને બીજા દિવસે સવારે અમારી સિસ્ટમ પ્રત્યે ઘણા દયાળુ શબ્દો કહેવામાં આવ્યા. પરંતુ પરિણામે, કામ માટે 5-મિનિટનું ધોરણ સ્થાપિત થયું.

કામગીરીને વેગ આપવા માટે, અમે બે પદ્ધતિઓનો ઉપયોગ કર્યો: ઑટોટેસ્ટ ત્રણ સમાંતર થ્રેડોમાં ચાલવાનું શરૂ કર્યું, સદભાગ્યે અમારી લોયલ્ટી સિસ્ટમના આર્કિટેક્ચરને કારણે આ ખૂબ અનુકૂળ છે. અને અમે એ અભિગમ છોડી દીધો છે જ્યાં ઑટોટેસ્ટ પોતાના માટે ટેસ્ટ ડેટા બનાવતું નથી, પરંતુ સિસ્ટમમાં કંઈક યોગ્ય શોધવાનો પ્રયાસ કરે છે. ફેરફારો કર્યા પછી, કુલ ઓપરેટિંગ સમય ઘટાડીને 3-4 મિનિટ કરવામાં આવ્યો હતો.
સ્વયંસંચાલિત પરીક્ષણો સાથેનો પ્રોજેક્ટ વિવિધ સ્ટેન્ડ પર જમાવવામાં સક્ષમ હોવો જોઈએ. અમારી મુસાફરીની શરૂઆતમાં, અમારી પોતાની બેચ ફાઇલો લખવાના પ્રયાસો થયા હતા, પરંતુ તે સ્પષ્ટ થઈ ગયું કે સ્વ-લેખિત સ્વયંસંચાલિત ઇન્સ્ટોલેશન સંપૂર્ણ ભયાનક હતું, અને અમે ઔદ્યોગિક ઉકેલો તરફ વળ્યા. એ હકીકતને કારણે કે પ્રોજેક્ટમાં ઘણા બધા ડાયરેક્ટ કોડ છે (સૌ પ્રથમ, અમે ઑટોટેસ્ટ કોડ સ્ટોર કરીએ છીએ) અને ખૂબ જ ઓછો ડેટા (મુખ્ય ડેટા ઑટોટેસ્ટ વિશેનો મેટાડેટા છે), લિક્વિબેઝ પ્રોજેક્ટમાં અમલીકરણ ખૂબ જ સરળ બન્યું.
તે ડેટાબેઝ સ્કીમા ફેરફારોને ટ્રેક કરવા, મેનેજ કરવા અને લાગુ કરવા માટે એક ઓપન-સોર્સ, ડેટાબેઝ-સ્વતંત્ર પુસ્તકાલય છે. કમાન્ડ લાઇન અથવા ફ્રેમવર્ક જેમ કે Apache Maven દ્વારા સંચાલિત. લિક્વિબેઝનું સંચાલન સિદ્ધાંત એકદમ સરળ છે. અમારી પાસે ચોક્કસ રીતે સંગઠિત પ્રોજેક્ટ છે, જેમાં ફેરફારો અથવા સ્ક્રિપ્ટનો સમાવેશ થાય છે જેને લક્ષ્ય સર્વર પર રોલ આઉટ કરવાની જરૂર છે, અને નિયંત્રણ ફાઇલો કે જે નક્કી કરે છે કે કયા ક્રમમાં અને કયા પરિમાણો સાથે આ ફેરફારો ઇન્સ્ટોલ કરવા જોઈએ.

ડીબીએમએસ સ્તરે, એક વિશિષ્ટ કોષ્ટક બનાવવામાં આવે છે જેમાં લિક્વિબેઝ રોલઓવર લોગને સંગ્રહિત કરે છે. દરેક ફેરફારમાં ગણતરી કરેલ હેશ હોય છે, જેની દર વખતે ડેટાબેઝમાં પ્રોજેક્ટ અને રાજ્ય વચ્ચે સરખામણી કરવામાં આવે છે. લિક્વિબેઝનો આભાર, અમે અમારી સિસ્ટમમાં કોઈપણ સર્કિટમાં સરળતાથી ફેરફાર કરી શકીએ છીએ. ઑટોટેસ્ટ હવે ટેસ્ટ અને રિલીઝ સર્કિટ તેમજ કન્ટેનર (વિકાસકર્તાઓની વ્યક્તિગત સર્કિટ) પર શરૂ કરવામાં આવે છે.

તેથી, ચાલો અમારી એકમ પરીક્ષણ સિસ્ટમનો ઉપયોગ કરવાના પરિણામો વિશે વાત કરીએ.

અલબત્ત, સૌ પ્રથમ, અમને ખાતરી છે કે અમે વધુ સારા સોફ્ટવેર વિકસાવવાનું શરૂ કર્યું છે. ઑટોટેસ્ટ્સ દરરોજ શરૂ કરવામાં આવે છે અને દરેક રિલીઝમાં ડઝનેક ભૂલો જોવા મળે છે. તદુપરાંત, આમાંની કેટલીક ભૂલો ફક્ત આડકતરી રીતે તે કાર્યક્ષમતા સાથે સંબંધિત છે જે અમે ખરેખર બદલવા માંગીએ છીએ. ત્યાં ગંભીર શંકા છે કે આ ભૂલો મેન્યુઅલ પરીક્ષણ દ્વારા મળી આવી હતી.
ટીમને હવે વિશ્વાસ છે કે ચોક્કસ કાર્યક્ષમતા યોગ્ય રીતે કામ કરી રહી છે... સૌ પ્રથમ, આ અમારી જટિલ પ્રક્રિયાઓની ચિંતા કરે છે. ઉદાહરણ તરીકે, પાછલા છ મહિનામાં અમને રસીદો પર ડિસ્કાઉન્ટ અને બોનસના વિતરણમાં કોઈ સમસ્યા આવી નથી, રિલીઝ ફેરફારો હોવા છતાં, જો કે અગાઉના સમયગાળામાં કેટલીક આવર્તન સાથે ભૂલો આવી હતી.
અમે પરીક્ષણ પુનરાવર્તનોની સંખ્યા ઘટાડવામાં વ્યવસ્થાપિત છીએ. નવી કાર્યક્ષમતા માટે ઓટોટેસ્ટ લખવામાં આવે છે તે હકીકતને કારણે, વિશ્લેષકો અને પાર્ટ-ટાઇમ ટેસ્ટર્સ ઉચ્ચ ગુણવત્તાનો કોડ મેળવે છે, કારણ કે તે પહેલાથી જ ચકાસાયેલ છે.
સ્વચાલિત પરીક્ષણમાં કેટલાક વિકાસનો ઉપયોગ વિકાસકર્તાઓ દ્વારા કરવામાં આવે છે. ઉદાહરણ તરીકે, ઑબ્જેક્ટ જનરેશન મોડ્યુલનો ઉપયોગ કરીને કન્ટેનર પર ટેસ્ટ ડેટા બનાવવામાં આવે છે.
તે મહત્વપૂર્ણ છે કે અમે વિકાસકર્તાઓ તરફથી સ્વચાલિત પરીક્ષણ સિસ્ટમની "સ્વીકૃતિ" વિકસાવી છે. એક સમજ છે કે આ મહત્વપૂર્ણ અને ઉપયોગી છે. પરંતુ મારા પોતાના અનુભવ પરથી હું કહી શકું છું કે આ કેસથી દૂર છે. ઑટોટેસ્ટ્સ લખવાની જરૂર છે, તેઓને સમર્થન અને વિકસિત કરવાની જરૂર છે, પરિણામોનું વિશ્લેષણ કરવું આવશ્યક છે, અને ઘણી વખત આ સમયનો ખર્ચ ફક્ત તેના માટે યોગ્ય નથી. ઉત્પાદનમાં જવું અને ત્યાં સમસ્યાઓનો સામનો કરવો ખૂબ સરળ છે. અહીં, વિકાસકર્તાઓ લાઇન કરે છે અને અમને તેમની કાર્યક્ષમતાને ઓટોટેસ્ટ સાથે આવરી લેવા માટે કહે છે.

આગળ શું છે

ચાલો સ્વચાલિત પરીક્ષણ પ્રોજેક્ટ માટે વિકાસ યોજનાઓ વિશે વાત કરીએ.

અલબત્ત, જ્યાં સુધી સ્પોર્ટમાસ્ટરની વફાદારી પ્રણાલી જીવંત છે અને વિકાસ કરવાનું ચાલુ રાખે છે, ત્યાં સુધી લગભગ અવિરતપણે ઑટોટેસ્ટ્સ વિકસાવવાનું પણ શક્ય છે. તેથી, વિકાસની મુખ્ય દિશા કવરેજ વિસ્તારને વિસ્તૃત કરી રહી છે.

જેમ જેમ ઓટોટેસ્ટની સંખ્યામાં વધારો થશે તેમ તેમ તેમનો કુલ ઓપરેટિંગ સમય સતત વધશે અને આપણે ફરીથી કામગીરીના મુદ્દા પર પાછા ફરવું પડશે. મોટે ભાગે, ઉકેલ સમાંતર થ્રેડોની સંખ્યામાં વધારો કરવાનો હશે.

પરંતુ આ વિકાસના સ્પષ્ટ માર્ગો છે. જો આપણે કંઈક વધુ બિન-તુચ્છ વિશે વાત કરીએ, તો અમે નીચેનાને પ્રકાશિત કરીએ છીએ:

હાલમાં, ઓટોટેસ્ટ મેનેજમેન્ટ ડીબીએમએસ સ્તરે કરવામાં આવે છે, એટલે કે. સફળ કાર્ય માટે PL/SQL નું જ્ઞાન જરૂરી છે. જો જરૂરી હોય તો, સિસ્ટમ મેનેજમેન્ટ (ઉદાહરણ તરીકે, મેટાડેટા લોંચ કરવું અથવા બનાવવું), તમે જેનકિન્સ અથવા તેના જેવું કંઈક ઉપયોગ કરીને અમુક પ્રકારની એડમિન પેનલ બનાવી શકો છો.
દરેક વ્યક્તિને માત્રાત્મક અને ગુણાત્મક સૂચકાંકો પસંદ છે. સ્વયંસંચાલિત પરીક્ષણ માટે, આવા સાર્વત્રિક સૂચક કોડ કવરેજ અથવા કોડ કવરેજ મેટ્રિક છે. આ સૂચકનો ઉપયોગ કરીને, અમે નક્કી કરી શકીએ છીએ કે પરીક્ષણ હેઠળની અમારી સિસ્ટમના કોડની કેટલી ટકાવારી ઓટોટેસ્ટ દ્વારા આવરી લેવામાં આવી છે. સંસ્કરણ 12.2 થી શરૂ કરીને, Oracle આ મેટ્રિકની ગણતરી કરવાની ક્ષમતા પ્રદાન કરે છે અને પ્રમાણભૂત DBMS_PLSQL_CODE_COVERAGE પેકેજનો ઉપયોગ ઓફર કરે છે.
અમારી ઓટોટેસ્ટ સિસ્ટમ માત્ર એક વર્ષથી જૂની છે અને કદાચ હવે અમારા કવરેજનું મૂલ્યાંકન કરવાનો સમય છે. મારા છેલ્લા પ્રોજેક્ટમાં (સ્પોર્ટમાસ્ટર પ્રોજેક્ટ નહીં) આવું જ થયું. ઑટોટેસ્ટ પર કામ કર્યાના એક વર્ષ પછી, મેનેજમેન્ટે અમે કેટલા ટકા કોડ આવરી લઈએ છીએ તેનું મૂલ્યાંકન કરવાનું કાર્ય સેટ કર્યું. 1% કરતા વધુના કવરેજ સાથે, મેનેજમેન્ટ ખુશ થશે. અમે, વિકાસકર્તાઓ, લગભગ 10% પરિણામની અપેક્ષા રાખીએ છીએ. અમે કોડ કવરેજ ઇન્સ્ટોલ કર્યું, તેને માપ્યું અને 20% મળ્યું. ઉજવણી કરવા માટે, અમે ઇનામ લેવા ગયા હતા, પરંતુ અમે તે કેવી રીતે મેળવવા ગયા અને અમે પછી ક્યાં ગયા તે સંપૂર્ણપણે અલગ વાર્તા છે.
ઑટોટેસ્ટ્સ ખુલ્લી વેબ સેવાઓને ચકાસી શકે છે. ઓરેકલ અમને આ ખૂબ સારી રીતે કરવાની મંજૂરી આપે છે, અને અમને હવે ઘણી સમસ્યાઓનો સામનો કરવો પડશે નહીં.
અને, અલબત્ત, અમારી સ્વચાલિત પરીક્ષણ સિસ્ટમ અન્ય પ્રોજેક્ટ પર લાગુ કરી શકાય છે. અમને મળેલ સોલ્યુશન સાર્વત્રિક છે અને માત્ર Oracle નો ઉપયોગ જરૂરી છે. મેં સાંભળ્યું છે કે અન્ય સ્પોર્ટમાસ્ટર પ્રોજેક્ટ્સ સ્વચાલિત પરીક્ષણમાં રસ ધરાવે છે અને કદાચ અમે તેમની પાસે જઈશું.

તારણો

ચાલો સારાંશ આપીએ. સ્પોર્ટમાસ્ટરમાં લોયલ્ટી સિસ્ટમ પ્રોજેક્ટ પર, અમે ઓટોમેટેડ ટેસ્ટિંગ સિસ્ટમ લાગુ કરવામાં સફળ થયા. તે સ્ટીફન ફ્યુરસ્ટેઇનના utPLSQL સોલ્યુશન પર આધારિત છે. utPLSQL ની આસપાસ ઓટોટેસ્ટ કોડ અને સહાયક સ્વ-લેખિત મોડ્યુલો છે: લોન્ચ મોડ્યુલ, ડેટા જનરેશન મોડ્યુલ અને અન્ય. ઑટોટેસ્ટ્સ દરરોજ શરૂ કરવામાં આવે છે અને, સૌથી અગત્યનું, તેઓ કામ કરે છે અને ઉપયોગી છે. અમને વિશ્વાસ છે કે અમે ઉચ્ચ ગુણવત્તાવાળા સૉફ્ટવેર રિલીઝ કરવાનું શરૂ કર્યું છે. તે જ સમયે, પરિણામી ઉકેલ સાર્વત્રિક છે અને કોઈપણ પ્રોજેક્ટ પર મુક્તપણે લાગુ કરી શકાય છે જ્યાં ઓરેકલ DBMS પર સ્વચાલિત પરીક્ષણનું આયોજન કરવું જરૂરી છે.

પી.એસ. આ લેખ ખૂબ ચોક્કસ નથી: ત્યાં ઘણું બધું લખાણ છે અને વ્યવહારીક રીતે કોઈ તકનીકી ઉદાહરણો નથી. જો વિષય સામાન્ય રીતે રસપ્રદ હોય, તો અમે તેને ચાલુ રાખવા અને ચાલુ રાખવા માટે તૈયાર છીએ, જ્યાં અમે તમને જણાવીશું કે છેલ્લા છ મહિનામાં શું બદલાયું છે અને કોડ ઉદાહરણો પ્રદાન કરીશું.

જો એવા મુદ્દાઓ હોય કે જેના પર ભવિષ્યમાં ભાર મૂકવો જોઈએ, અથવા એવા પ્રશ્નો કે જેને જાહેર કરવાની જરૂર હોય તો ટિપ્પણીઓ લખો.

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું આપણે આ વિશે વધુ લખીએ?

હા અલબત્ત
ના આભાર

12 વપરાશકર્તાઓએ મત આપ્યો. 4 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com

DBMS માં એકમ પરીક્ષણો - અમે તેને Sportmaster, ભાગ બેમાં કેવી રીતે કરીએ છીએ

આગળ શું છે

તારણો

શું આપણે આ વિશે વધુ લખીએ?

એક ટિપ્પણી ઉમેરો જવાબ રદ