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

હે હબર!

મારું નામ મેક્સિમ પોનોમારેન્કો છે અને હું સ્પોર્ટમાસ્ટરનો ડેવલપર છું. મારી પાસે IT ક્ષેત્રમાં 10 વર્ષનો અનુભવ છે. તેણે મેન્યુઅલ ટેસ્ટિંગમાં તેની કારકિર્દીની શરૂઆત કરી, પછી ડેટાબેઝ ડેવલપમેન્ટ પર સ્વિચ કર્યું. છેલ્લા 4 વર્ષથી, પરીક્ષણ અને વિકાસમાં મેળવેલા જ્ઞાનને સંચિત કરીને, હું DBMS સ્તરે સ્વચાલિત પરીક્ષણ કરી રહ્યો છું.

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

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

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

આધુનિક આઇટી એ હકીકત દ્વારા વર્ગીકૃત થયેલ છે કે વિકાસકર્તાને માત્ર ઉત્પાદન કોડ લખવા માટે જ નહીં, પણ આ કોડને તપાસતા એકમ પરીક્ષણો લખવાની પણ જરૂર પડી શકે છે.

પરંતુ જો તમારી સિસ્ટમ મુખ્યત્વે સર્વર લોજિક પર આધારિત હોય તો શું? બજારમાં કોઈ સાર્વત્રિક ઉકેલ અથવા શ્રેષ્ઠ પ્રયાસો નથી. એક નિયમ તરીકે, કંપનીઓ તેમની પોતાની સ્વ-લેખિત પરીક્ષણ સિસ્ટમ બનાવીને આ સમસ્યાને હલ કરે છે. આ અમારી પોતાની સ્વ-લેખિત સ્વચાલિત પરીક્ષણ સિસ્ટમ છે જે અમારા પ્રોજેક્ટ પર બનાવવામાં આવી હતી અને હું મારા અહેવાલમાં તેના વિશે વાત કરીશ.

વફાદારીનું પરીક્ષણ

પ્રથમ, ચાલો તે પ્રોજેક્ટ વિશે વાત કરીએ જ્યાં અમે એક સ્વચાલિત પરીક્ષણ સિસ્ટમ ગોઠવી છે. અમારો પ્રોજેક્ટ સ્પોર્ટમાસ્ટર લોયલ્ટી સિસ્ટમ છે (માર્ગ દ્વારા, અમે તેના વિશે પહેલેથી જ લખ્યું છે આ પોસ્ટ).

જો તમારી કંપની પૂરતી મોટી છે, તો તમારી લોયલ્ટી સિસ્ટમમાં ત્રણ પ્રમાણભૂત ગુણધર્મો હશે:

• તમારી સિસ્ટમ ખૂબ જ લોડ થશે
• તમારી સિસ્ટમમાં જટિલ કમ્પ્યુટિંગ પ્રક્રિયાઓ હશે
• તમારી સિસ્ટમ સક્રિય રીતે સુધારવામાં આવશે.

ચાલો ક્રમમાં જઈએ... એકંદરે, જો આપણે તમામ સ્પોર્ટમાસ્ટર બ્રાન્ડ્સને ધ્યાનમાં લઈએ, તો અમારી પાસે રશિયા, યુક્રેન, ચીન, કઝાકિસ્તાન અને બેલારુસમાં 1000 થી વધુ સ્ટોર્સ છે. આ સ્ટોર્સમાં દરરોજ લગભગ 300 ખરીદી કરવામાં આવે છે. એટલે કે, દર સેકન્ડે 000-3 ચેક અમારી સિસ્ટમમાં દાખલ થાય છે. સ્વાભાવિક રીતે, અમારી વફાદારી સિસ્ટમ અત્યંત લોડ થયેલ છે. અને તે સક્રિય રીતે ઉપયોગમાં લેવાતું હોવાથી, આપણે તેની ગુણવત્તાના ઉચ્ચતમ ધોરણો પ્રદાન કરવા જોઈએ, કારણ કે સૉફ્ટવેરમાં કોઈપણ ભૂલનો અર્થ છે મોટા નાણાકીય, પ્રતિષ્ઠા અને અન્ય નુકસાન.

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

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

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

વર્ણવેલ ગુણધર્મો લગભગ કોઈપણ વફાદારી સિસ્ટમ માટે પ્રમાણભૂત છે. ચાલો આપણા પ્રોજેક્ટની વિશેષતાઓ વિશે વાત કરીએ.

તકનીકી રીતે, અમારી લોયલ્ટી સિસ્ટમનો 90% તર્ક સર્વર-આધારિત છે અને Oracle પર અમલમાં છે. ડેલ્ફીમાં એક ક્લાયંટ ખુલ્લું છે, જે ઓટોમેટેડ વર્કપ્લેસ એડમિનિસ્ટ્રેટરનું કાર્ય કરે છે. બાહ્ય એપ્લિકેશનો (ઉદાહરણ તરીકે વેબસાઇટ) માટે ખુલ્લી વેબ સેવાઓ છે. તેથી, તે ખૂબ જ તાર્કિક છે કે જો આપણે ઓટોમેટેડ ટેસ્ટિંગ સિસ્ટમનો ઉપયોગ કરીએ, તો અમે તેને ઓરેકલ પર કરીશું.

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

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

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

utPLSQL બચાવમાં આવે છે

શું તમે સ્ટીફન ફ્યુરસ્ટેઈન વિશે કંઈ જાણો છો?

આ એક સ્માર્ટ વ્યક્તિ છે જેણે તેની કારકિર્દીનો લાંબો ભાગ Oracle અને 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. ઑટોટેસ્ટ્સે સ્થિર રીતે કામ કરવું જોઈએ. દિવસનો સમય, લોંચ સ્ટેન્ડ અને અન્ય સિસ્ટમ સેટિંગ્સને ધ્યાનમાં લીધા વિના, ટેસ્ટ રન સમાન પરિણામ તરફ દોરી જાય છે. એક નિયમ તરીકે, આ હકીકત દ્વારા સુનિશ્ચિત કરવામાં આવે છે કે ઓટોટેસ્ટ્સ નિશ્ચિત સિસ્ટમ સેટિંગ્સ સાથે વિશિષ્ટ પરીક્ષણ ડેટા સાથે કામ કરે છે.
4. ઑટોટેસ્ટ્સે તમારા પ્રોજેક્ટ માટે સ્વીકાર્ય ગતિએ કામ કરવું જોઈએ. આ સમય દરેક સિસ્ટમ માટે વ્યક્તિગત રીતે નક્કી કરવામાં આવે છે. કેટલાક લોકો આખો દિવસ કામ કરવા પરવડી શકે છે, જ્યારે અન્યને તે સેકન્ડોમાં કરવું મહત્વપૂર્ણ લાગે છે. હું તમને થોડા સમય પછી કહીશ કે અમે અમારા પ્રોજેક્ટમાં કયા ઝડપના ધોરણો પ્રાપ્ત કર્યા છે.
5. ઓટોટેસ્ટ ડેવલપમેન્ટ લવચીક હોવું જોઈએ. કોઈપણ કાર્યક્ષમતાને ચકાસવાનો ઇનકાર કરવો એ સલાહભર્યું નથી કારણ કે અમે તે પહેલાં અથવા કોઈ અન્ય કારણોસર કર્યું નથી. utPLSQL વિકાસ પર કોઈ નિયંત્રણો લાદતું નથી, અને ઓરેકલ, સૈદ્ધાંતિક રીતે, તમને વિવિધ વસ્તુઓનો અમલ કરવાની મંજૂરી આપે છે. મોટાભાગની સમસ્યાઓનો ઉકેલ હોય છે, તે માત્ર સમય અને પ્રયત્નની બાબત છે.
6. જમાવટક્ષમતા. અમારી પાસે ઘણા સ્ટેન્ડ છે જ્યાં અમારે પરીક્ષણો ચલાવવાની જરૂર છે. દરેક સ્ટેન્ડ પર, ડેટા ડમ્પ કોઈપણ સમયે અપડેટ કરી શકાય છે. સ્વયંસંચાલિત પરીક્ષણો સાથેનો પ્રોજેક્ટ એવી રીતે હાથ ધરવો જરૂરી છે કે તમે તેની સંપૂર્ણ અથવા આંશિક ઇન્સ્ટોલેશન પીડારહિત રીતે કરી શકો.

અને બે દિવસમાં બીજી પોસ્ટમાં હું તમને કહીશ કે અમે શું કર્યું અને અમે શું પરિણામો પ્રાપ્ત કર્યા.

સોર્સ: www.habr.com