ഒരു ഡിബിഎംഎസിലെ യൂണിറ്റ് ടെസ്റ്റുകൾ - സ്‌പോർട്‌മാസ്റ്ററിൽ ഞങ്ങൾ ഇത് എങ്ങനെ ചെയ്യുന്നു, ഒന്നാം ഭാഗം

ഹേ ഹബർ!

എന്റെ പേര് മാക്സിം പൊനോമരെങ്കോ, ഞാൻ സ്‌പോർട്‌മാസ്റ്ററിലെ ഒരു ഡെവലപ്പറാണ്. ഐടി മേഖലയിൽ എനിക്ക് 10 വർഷത്തെ പരിചയമുണ്ട്. മാനുവൽ ടെസ്റ്റിംഗിൽ അദ്ദേഹം തന്റെ കരിയർ ആരംഭിച്ചു, തുടർന്ന് ഡാറ്റാബേസ് വികസനത്തിലേക്ക് മാറി. കഴിഞ്ഞ 4 വർഷമായി, ടെസ്റ്റിംഗിലും വികസനത്തിലും നേടിയ അറിവ് ശേഖരിച്ച്, ഞാൻ DBMS തലത്തിൽ ടെസ്റ്റിംഗ് ഓട്ടോമേറ്റ് ചെയ്യുന്നു.

ഞാൻ ഒരു വർഷത്തിലേറെയായി സ്‌പോർട്‌സ് മാസ്റ്റർ ടീമിലുണ്ട്, കൂടാതെ പ്രധാന പ്രോജക്‌റ്റുകളിലൊന്നിൽ ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് വികസിപ്പിക്കുകയും ചെയ്യുന്നു. ഏപ്രിലിൽ, സ്‌പോർട്‌മാസ്റ്റർ ലാബിലെ കുട്ടികളും ഞാനും ക്രാസ്‌നോഡറിലെ ഒരു കോൺഫറൻസിൽ സംസാരിച്ചു, എന്റെ റിപ്പോർട്ടിനെ “ഒരു ഡിബിഎംഎസിലെ യൂണിറ്റ് ടെസ്റ്റുകൾ” എന്ന് വിളിച്ചിരുന്നു, ഇപ്പോൾ ഞാൻ അത് നിങ്ങളുമായി പങ്കിടാൻ ആഗ്രഹിക്കുന്നു. ധാരാളം വാചകങ്ങൾ ഉണ്ടാകും, അതിനാൽ റിപ്പോർട്ട് രണ്ട് പോസ്റ്റുകളായി വിഭജിക്കാൻ ഞാൻ തീരുമാനിച്ചു. ആദ്യത്തേതിൽ, ഞങ്ങൾ പൊതുവായി ഓട്ടോടെസ്റ്റുകളെക്കുറിച്ചും പരിശോധനകളെക്കുറിച്ചും സംസാരിക്കും, രണ്ടാമത്തേതിൽ, ഞങ്ങളുടെ യൂണിറ്റ് ടെസ്റ്റിംഗ് സിസ്റ്റത്തെക്കുറിച്ചും അതിന്റെ ആപ്ലിക്കേഷന്റെ ഫലങ്ങളെക്കുറിച്ചും ഞാൻ കൂടുതൽ വിശദമായി സംസാരിക്കും.

ആദ്യം, ഒരു ചെറിയ ബോറടിപ്പിക്കുന്ന സിദ്ധാന്തം. എന്താണ് ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ്? ഇത് സോഫ്‌റ്റ്‌വെയർ ഉപയോഗിച്ച് നടത്തുന്ന പരിശോധനയാണ്, ആധുനിക ഐടിയിൽ ഇത് സോഫ്റ്റ്‌വെയർ വികസനത്തിൽ കൂടുതലായി ഉപയോഗിക്കുന്നു. കമ്പനികൾ വളരുന്നതും അവരുടെ വിവര സംവിധാനങ്ങൾ വളരുന്നതും അതനുസരിച്ച്, പരിശോധിക്കേണ്ട പ്രവർത്തനങ്ങളുടെ അളവ് വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്നതുമാണ് ഇതിന് കാരണം. മാനുവൽ ടെസ്റ്റിംഗ് നടത്തുന്നത് കൂടുതൽ ചെലവേറിയതായി മാറുകയാണ്.

ഓരോ രണ്ട് മാസത്തിലും റിലീസുകൾ വരുന്ന ഒരു വലിയ കമ്പനിയിൽ ഞാൻ ജോലി ചെയ്തു. അതേ സമയം, ഒരു ഡസൻ പരീക്ഷകർ സ്വമേധയാ പ്രവർത്തനം പരിശോധിക്കുന്നതിനായി ഒരു മാസം മുഴുവൻ ചെലവഴിച്ചു. ഡെവലപ്പർമാരുടെ ഒരു ചെറിയ ടീം ഓട്ടോമേഷൻ നടപ്പിലാക്കിയതിന് നന്ദി, ഒന്നര വർഷത്തിനുള്ളിൽ ടെസ്റ്റിംഗ് സമയം 2 ആഴ്ചയായി കുറയ്ക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. ഞങ്ങൾ പരിശോധനയുടെ വേഗത വർദ്ധിപ്പിക്കുക മാത്രമല്ല, അതിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുകയും ചെയ്തു. ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ പതിവായി സമാരംഭിക്കുന്നു, അവയിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന മുഴുവൻ പരിശോധനകളും അവ എല്ലായ്പ്പോഴും നടപ്പിലാക്കുന്നു, അതായത്, ഞങ്ങൾ മാനുഷിക ഘടകം ഒഴിവാക്കുന്നു.

ഉൽപ്പന്ന കോഡ് എഴുതാൻ മാത്രമല്ല, ഈ കോഡ് പരിശോധിക്കുന്ന യൂണിറ്റ് ടെസ്റ്റുകൾ എഴുതാനും ഒരു ഡവലപ്പർ ആവശ്യമായി വന്നേക്കാം എന്നതാണ് ആധുനിക ഐടിയുടെ സവിശേഷത.

എന്നാൽ നിങ്ങളുടെ സിസ്റ്റം പ്രാഥമികമായി സെർവർ ലോജിക്കിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണെങ്കിൽ എന്തുചെയ്യും? വിപണിയിൽ സാർവത്രിക പരിഹാരമോ മികച്ച രീതികളോ ഇല്ല. ചട്ടം പോലെ, കമ്പനികൾ സ്വന്തം സ്വയം എഴുതിയ ടെസ്റ്റിംഗ് സിസ്റ്റം സൃഷ്ടിച്ച് ഈ പ്രശ്നം പരിഹരിക്കുന്നു. ഇത് ഞങ്ങളുടെ പ്രോജക്റ്റിൽ സൃഷ്ടിച്ച ഞങ്ങളുടെ സ്വന്തം സ്വയമേവ എഴുതിയ ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് സിസ്റ്റമാണ്, ഞാൻ അതിനെക്കുറിച്ച് എന്റെ റിപ്പോർട്ടിൽ സംസാരിക്കും.

വിശ്വസ്തത പരിശോധിക്കുന്നു

ആദ്യം, ഞങ്ങൾ ഒരു ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് സിസ്റ്റം വിന്യസിച്ച പ്രോജക്റ്റിനെക്കുറിച്ച് സംസാരിക്കാം. ഞങ്ങളുടെ പ്രോജക്റ്റ് സ്‌പോർട്‌മാസ്റ്റർ ലോയൽറ്റി സിസ്റ്റമാണ് (വഴി, ഞങ്ങൾ ഇതിനെക്കുറിച്ച് ഇതിനകം എഴുതിയിട്ടുണ്ട് ഈ പോസ്റ്റ്).

നിങ്ങളുടെ കമ്പനി ആവശ്യത്തിന് വലുതാണെങ്കിൽ, നിങ്ങളുടെ ലോയൽറ്റി സിസ്റ്റത്തിന് മൂന്ന് സ്റ്റാൻഡേർഡ് പ്രോപ്പർട്ടികൾ ഉണ്ടായിരിക്കും:

• നിങ്ങളുടെ സിസ്റ്റം ഉയർന്ന തോതിൽ ലോഡ് ചെയ്യും
• നിങ്ങളുടെ സിസ്റ്റത്തിൽ സങ്കീർണ്ണമായ കമ്പ്യൂട്ടിംഗ് പ്രക്രിയകൾ അടങ്ങിയിരിക്കും
• നിങ്ങളുടെ സിസ്റ്റം സജീവമായി മെച്ചപ്പെടുത്തും.

നമുക്ക് ക്രമത്തിൽ പോകാം ... മൊത്തത്തിൽ, ഞങ്ങൾ എല്ലാ സ്‌പോർട്‌സ് മാസ്റ്റർ ബ്രാൻഡുകളും പരിഗണിക്കുകയാണെങ്കിൽ, റഷ്യ, ഉക്രെയ്ൻ, ചൈന, കസാക്കിസ്ഥാൻ, ബെലാറസ് എന്നിവിടങ്ങളിൽ ഞങ്ങൾക്ക് 1000-ലധികം സ്റ്റോറുകളുണ്ട്. ഈ സ്റ്റോറുകളിൽ പ്രതിദിനം ഏകദേശം 300 വാങ്ങലുകൾ നടക്കുന്നു. അതായത്, ഓരോ സെക്കൻഡിലും 000-3 പരിശോധനകൾ ഞങ്ങളുടെ സിസ്റ്റത്തിൽ പ്രവേശിക്കുന്നു. സ്വാഭാവികമായും, ഞങ്ങളുടെ ലോയൽറ്റി സിസ്റ്റം വളരെ ലോഡ് ആണ്. ഇത് സജീവമായി ഉപയോഗിക്കുന്നതിനാൽ, അതിന്റെ ഗുണനിലവാരത്തിന്റെ ഉയർന്ന നിലവാരം ഞങ്ങൾ നൽകണം, കാരണം സോഫ്റ്റ്വെയറിലെ ഏതെങ്കിലും പിശക് വലിയ പണവും പ്രശസ്തിയും മറ്റ് നഷ്ടങ്ങളും അർത്ഥമാക്കുന്നു.

അതേ സമയം, സ്‌പോർട്‌മാസ്റ്റർ നൂറിലധികം വ്യത്യസ്ത പ്രമോഷനുകൾ നടത്തുന്നു. വൈവിധ്യമാർന്ന പ്രമോഷനുകൾ ഉണ്ട്: ഉൽപ്പന്ന പ്രമോഷനുകൾ ഉണ്ട്, ആഴ്ചയിലെ ദിവസത്തിനായി സമർപ്പിച്ചവയുണ്ട്, ഒരു പ്രത്യേക സ്റ്റോറുമായി ബന്ധിപ്പിച്ചവയുണ്ട്, രസീത് തുകയ്ക്ക് പ്രമോഷനുകൾ ഉണ്ട്, സാധനങ്ങളുടെ എണ്ണത്തിന് ഉണ്ട്. പൊതുവേ, മോശമല്ല. ഉപഭോക്താക്കൾക്ക് ബോണസും പ്രൊമോഷണൽ കോഡുകളും ഉണ്ട്, അവ വാങ്ങലുകൾ നടത്തുമ്പോൾ ഉപയോഗിക്കുന്നു. ഏതൊരു ഓർഡറും കണക്കാക്കുന്നത് വളരെ നിസ്സാരമല്ലാത്ത ഒരു ജോലിയാണെന്ന വസ്തുതയിലേക്ക് ഇതെല്ലാം നയിക്കുന്നു.

ഓർഡർ പ്രോസസ്സിംഗ് നടപ്പിലാക്കുന്ന അൽഗോരിതം ശരിക്കും ഭയങ്കരവും സങ്കീർണ്ണവുമാണ്. ഈ അൽഗോരിതത്തിലെ ഏത് മാറ്റവും വളരെ അപകടകരമാണ്. ഏറ്റവും നിസ്സാരമെന്ന് തോന്നുന്ന മാറ്റങ്ങൾ തികച്ചും പ്രവചനാതീതമായ പ്രത്യാഘാതങ്ങൾക്ക് ഇടയാക്കുമെന്ന് തോന്നി. എന്നാൽ ഇത് കൃത്യമായി അത്തരം സങ്കീർണ്ണമായ കമ്പ്യൂട്ടിംഗ് പ്രക്രിയകളാണ്, പ്രത്യേകിച്ച് നിർണായകമായ പ്രവർത്തനം നടപ്പിലാക്കുന്നവ, ഓട്ടോമേഷന്റെ ഏറ്റവും മികച്ച സ്ഥാനാർത്ഥികളാണ്. സമാനമായ ഡസൻ കണക്കിന് കേസുകൾ കൈകൊണ്ട് പരിശോധിക്കുന്നത് വളരെ സമയമെടുക്കുന്നതാണ്. പ്രക്രിയയിലേക്കുള്ള പ്രവേശന പോയിന്റ് മാറ്റമില്ലാത്തതിനാൽ, ഒരിക്കൽ വിവരിച്ചതിനാൽ, നിങ്ങൾക്ക് വേഗത്തിൽ യാന്ത്രിക പരിശോധനകൾ സൃഷ്ടിക്കാനും പ്രവർത്തനം പ്രവർത്തിക്കുമെന്ന് ആത്മവിശ്വാസം പുലർത്താനും കഴിയും.

ഞങ്ങളുടെ സിസ്റ്റം സജീവമായി ഉപയോഗിക്കുന്നതിനാൽ, ബിസിനസ്സ് നിങ്ങളിൽ നിന്ന് പുതിയ എന്തെങ്കിലും ആവശ്യപ്പെടും, കാലത്തിനനുസരിച്ച് ജീവിക്കുകയും ഉപഭോക്താവിനെ അടിസ്ഥാനമാക്കിയുള്ളവരായിരിക്കുകയും ചെയ്യും. ഞങ്ങളുടെ ലോയൽറ്റി സിസ്റ്റത്തിൽ, ഓരോ രണ്ട് മാസത്തിലും റിലീസുകൾ പുറത്തുവരും. ഇതിനർത്ഥം ഓരോ രണ്ട് മാസത്തിലും ഞങ്ങൾ മുഴുവൻ സിസ്റ്റത്തിന്റെയും പൂർണ്ണമായ റിഗ്രഷൻ നടത്തേണ്ടതുണ്ട് എന്നാണ്. അതേ സമയം, സ്വാഭാവികമായും, ഏതൊരു ആധുനിക ഐടിയിലെയും പോലെ, വികസനം ഉടനടി ഡെവലപ്പറിൽ നിന്ന് ഉൽപാദനത്തിലേക്ക് പോകുന്നില്ല. ഇത് ഡെവലപ്പറുടെ സർക്യൂട്ടിൽ നിന്ന് ഉത്ഭവിക്കുന്നു, തുടർന്ന് ടെസ്റ്റ് ബെഞ്ച്, റിലീസ്, സ്വീകാര്യത എന്നിവയിലൂടെ തുടർച്ചയായി കടന്നുപോകുന്നു, അതിനുശേഷം മാത്രമേ ഉൽപാദനത്തിൽ അവസാനിക്കൂ. കുറഞ്ഞത്, ടെസ്റ്റ്, റിലീസ് സർക്യൂട്ടുകളിൽ, മുഴുവൻ സിസ്റ്റത്തിന്റെയും പൂർണ്ണമായ റിഗ്രഷൻ ഞങ്ങൾ നടത്തേണ്ടതുണ്ട്.

വിവരിച്ച പ്രോപ്പർട്ടികൾ മിക്കവാറും എല്ലാ ലോയൽറ്റി സിസ്റ്റത്തിനും സ്റ്റാൻഡേർഡാണ്. ഞങ്ങളുടെ പ്രോജക്റ്റിന്റെ സവിശേഷതകളെക്കുറിച്ച് സംസാരിക്കാം.

സാങ്കേതികമായി, ഞങ്ങളുടെ ലോയൽറ്റി സിസ്റ്റത്തിന്റെ ലോജിക്കിന്റെ 90% സെർവർ അടിസ്ഥാനമാക്കിയുള്ളതും ഒറാക്കിളിൽ നടപ്പിലാക്കിയതുമാണ്. ഒരു ഓട്ടോമേറ്റഡ് വർക്ക്‌പ്ലേസ് അഡ്‌മിനിസ്‌ട്രേറ്ററുടെ പ്രവർത്തനം നിർവ്വഹിക്കുന്ന ഒരു ക്ലയന്റ് ഡെൽഫിയിൽ ഉണ്ട്. ബാഹ്യ ആപ്ലിക്കേഷനുകൾക്കായി തുറന്ന വെബ് സേവനങ്ങളുണ്ട് (ഉദാഹരണത്തിന് ഒരു വെബ്സൈറ്റ്). അതിനാൽ, ഞങ്ങൾ ഒരു ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് സിസ്റ്റം വിന്യസിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ അത് ഒറാക്കിളിൽ ചെയ്യും എന്നത് വളരെ യുക്തിസഹമാണ്.

സ്‌പോർട്‌മാസ്റ്ററിലെ ലോയൽറ്റി സിസ്റ്റം 7 വർഷത്തിലേറെയായി നിലവിലുണ്ട്, അത് സൃഷ്‌ടിച്ചത് സിംഗിൾ ഡെവലപ്പർമാരാണ്... ഈ 7 വർഷത്തിനിടയിൽ ഞങ്ങളുടെ പ്രോജക്‌റ്റിലെ ഡെവലപ്പർമാരുടെ ശരാശരി എണ്ണം 3-4 ആളുകളാണ്. എന്നാൽ കഴിഞ്ഞ ഒരു വർഷമായി, ഞങ്ങളുടെ ടീം ഗണ്യമായി വളർന്നു, ഇപ്പോൾ പ്രോജക്റ്റിൽ 10 പേർ പ്രവർത്തിക്കുന്നു. അതായത്, സാധാരണ ജോലികൾ, പ്രക്രിയകൾ, വാസ്തുവിദ്യ എന്നിവയെക്കുറിച്ച് പരിചിതമല്ലാത്ത ആളുകൾ പ്രോജക്റ്റിലേക്ക് വരുന്നു. കൂടാതെ നമുക്ക് തെറ്റുകൾ നഷ്ടപ്പെടാനുള്ള സാധ്യത കൂടുതലാണ്.

സ്റ്റാഫ് യൂണിറ്റുകളായി സമർപ്പിത ടെസ്റ്റർമാരുടെ അഭാവമാണ് പദ്ധതിയുടെ സവിശേഷത. തീർച്ചയായും, പരിശോധനയുണ്ട്, പക്ഷേ അവരുടെ മറ്റ് പ്രധാന ഉത്തരവാദിത്തങ്ങൾക്ക് പുറമേ, വിശകലന വിദഗ്ധരാണ് പരിശോധന നടത്തുന്നത്: ബിസിനസ്സ് ഉപഭോക്താക്കളുമായും ഉപയോക്താക്കളുമായും ആശയവിനിമയം നടത്തുക, സിസ്റ്റം ആവശ്യകതകൾ വികസിപ്പിക്കുക തുടങ്ങിയവ. മുതലായവ... വളരെ ഉയർന്ന നിലവാരത്തിലാണ് പരിശോധന നടത്തുന്നത് എന്ന വസ്തുത ഉണ്ടായിരുന്നിട്ടും (ഇത് പരാമർശിക്കുന്നത് പ്രത്യേകിച്ചും ഉചിതമാണ്, കാരണം ചില വിശകലന വിദഗ്ധർ ഈ റിപ്പോർട്ടിന്റെ ശ്രദ്ധയിൽപ്പെട്ടേക്കാം), സ്പെഷ്യലൈസേഷന്റെ ഫലപ്രാപ്തിയും ഒരു കാര്യത്തിലുള്ള ഏകാഗ്രതയും റദ്ദാക്കിയിട്ടില്ല. .

മേൽപ്പറഞ്ഞവയെല്ലാം കണക്കിലെടുക്കുമ്പോൾ, വിതരണം ചെയ്ത ഉൽപ്പന്നത്തിന്റെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുന്നതിനും വികസന സമയം കുറയ്ക്കുന്നതിനും, ഒരു പ്രോജക്റ്റിലെ ടെസ്റ്റിംഗ് ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള ആശയം വളരെ യുക്തിസഹമാണെന്ന് തോന്നുന്നു. ലോയൽറ്റി സിസ്റ്റത്തിന്റെ നിലനിൽപ്പിന്റെ വിവിധ ഘട്ടങ്ങളിൽ, വ്യക്തിഗത ഡെവലപ്പർമാർ അവരുടെ കോഡ് യൂണിറ്റ് ടെസ്റ്റുകൾ ഉപയോഗിച്ച് മറയ്ക്കാൻ ശ്രമിച്ചു. മൊത്തത്തിൽ ഇത് തികച്ചും വിയോജിപ്പുള്ള ഒരു പ്രക്രിയയായിരുന്നു, എല്ലാവരും അവരവരുടെ വാസ്തുവിദ്യയും രീതികളും ഉപയോഗിക്കുന്നു. അന്തിമ ഫലങ്ങൾ യൂണിറ്റ് ടെസ്റ്റുകൾക്ക് സാധാരണമായിരുന്നു: ടെസ്റ്റുകൾ വികസിപ്പിച്ചെടുത്തു, കുറച്ച് സമയത്തേക്ക് ഉപയോഗിച്ചു, ഒരു പതിപ്പ് ഫയൽ സ്റ്റോറേജിൽ സംഭരിച്ചു, പക്ഷേ ചില ഘട്ടങ്ങളിൽ അവ പ്രവർത്തിക്കുന്നത് നിർത്തി, മറന്നുപോയി. ഒന്നാമതായി, ടെസ്റ്റുകൾ ഒരു നിർദ്ദിഷ്ട പ്രകടനക്കാരനുമായി കൂടുതൽ ബന്ധിപ്പിച്ചതാണ് ഇതിന് കാരണം, അല്ലാതെ പ്രോജക്റ്റുമായിട്ടല്ല.

utPLSQL രക്ഷാപ്രവർത്തനത്തിലേക്ക് വരുന്നു

സ്റ്റീഫൻ ഫ്യൂർസ്റ്റീനെ കുറിച്ച് നിങ്ങൾക്ക് എന്തെങ്കിലും അറിയാമോ?

ഒറാക്കിൾ, 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 വികസനത്തിന് ഒരു നിയന്ത്രണവും ഏർപ്പെടുത്തുന്നില്ല, കൂടാതെ Oracle, തത്വത്തിൽ, വിവിധ കാര്യങ്ങൾ നടപ്പിലാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. മിക്ക പ്രശ്നങ്ങൾക്കും ഒരു പരിഹാരമുണ്ട്, ഇത് സമയത്തിന്റെയും പരിശ്രമത്തിന്റെയും കാര്യമാണ്.
6. വിന്യാസം. ഞങ്ങൾക്ക് ടെസ്റ്റുകൾ നടത്തേണ്ട നിരവധി സ്റ്റാൻഡുകളുണ്ട്. ഓരോ സ്റ്റാൻഡിലും, എപ്പോൾ വേണമെങ്കിലും ഒരു ഡാറ്റ ഡംപ് അപ്ഡേറ്റ് ചെയ്യാം. നിങ്ങൾക്ക് വേദനയില്ലാതെ അതിന്റെ പൂർണ്ണമായോ ഭാഗികമായോ ഇൻസ്റ്റാളേഷൻ നടത്താൻ കഴിയുന്ന തരത്തിൽ യാന്ത്രിക പരിശോധനകളുള്ള ഒരു പ്രോജക്റ്റ് നടത്തേണ്ടത് ആവശ്യമാണ്.

രണ്ട് ദിവസത്തിനുള്ളിൽ രണ്ടാമത്തെ പോസ്റ്റിൽ ഞങ്ങൾ എന്താണ് ചെയ്തതെന്നും എന്ത് ഫലങ്ങൾ നേടിയെന്നും ഞാൻ നിങ്ങളോട് പറയും.

അവലംബം: www.habr.com