oracle real application testing solution test oracle db before moving production
Стигнахме до последната част на серия от Oracle Database Testing.
Досега се справихме методи за тестване на базата данни на Oracle. Продължавайки този фокус, ще се потопим в повече подробности по отношение на реалното тестване на приложения на Oracle.
Днес ще научим Oracle Real Application Testing - ефективна система за гарантиране на промяната, която оценява системната промяна в самата тестова среда, преди да я въведе в производството.
Това е водещото решение на Oracle за улавяне на реалното натоварване на DB на производствената среда и замяната му на t е околната среда .
Както беше посочено многократно, винаги трябва да се уверим, че тестваме базата данни във всяко възможно измерение, за да премахнем нестабилностите и да се уверим, че не срещаме непредвидени проблеми в нашата производствена инстанция.
Можем да категоризираме Реално тестване на приложения на Oracle в две широки секции:
- SQL Performance Analyzer
- Възпроизвеждане на база данни
Преди да продължим по-нататък, моля, обърнете внимание, че анализаторът на производителността на SQL и възпроизвеждането на база данни изискват допълнително лицензиране, т.е.то се предлага срещу допълнително заплащане и опция за Enterprise Edition.
Какво ще научите:
SQL Performance Analyzer
GUI, използван за достъп до анализатора на производителността на SQL и възпроизвеждането на база данни, е Enterprise Manager, както е показано по-долу:
За да получите достъп до SQL Performance Analyzer, просто кликнете върху връзката „SQL Performance Analyzer“
(Щракнете върху изображението, за да видите увеличено)
SQL Performance Analyzer ни позволява да измерим въздействието върху производителността на всяка промяна в системата, която може да окаже влияние върху изпълнението и производителността на SQL.
Те са изключително полезни в случаи като:
- Надстройка на база данни, кръпка
- Промени в конфигурацията на операционната система - Софтуер или хардуер
- Статистическите промени в Oracle Optimizer се променят
- Промени на потребителя / схемата
Винаги се препоръчва да стартирате SQL Performance Analysis на тест или a UAT (тестване на потребителски приложения) система, а не на производствена система. Тъй като, докато тествахме ефектите от промяната по отношение на производителността, бихме могли неволно да повлияем на потребителите, работещи в производствения екземпляр. Също така, стартирането му на тест ще гарантира, че няма да подправяме каквито и да е текущи процеси в производството.
ДА СЕ основният преглед на работния процес на SQL Performance Analyzer е показан по-долу:
Анализът на производителността на SQL включва следните стъпки.
Етап 1)Заснемане на SQL натоварване
Определете SQL изразите, които биха били част от натоварването ви в SQL от производствения ви екземпляр, който искате да анализирате. Това натоварване в идеалния случай трябва да представлява натоварването, което може да имате във вашето производство.
Ние улавяме тези изрази в набор за настройка на SQL и подаваме този комплект за настройка на SQL в анализатора на производителността на SQL.
Тъй като анализаторът консумира много ресурси във вашата система, ние винаги препоръчваме те да бъдат стартирани на тест или UAT система. За да го стартираме на тестова система, ще трябва да експортираме набора за настройка на SQL, който вече сме създали, в тестовата система.
Стъпка 2)Създаване на задача за анализ на SQL производителността
За да стартирате анализатора, първо трябва да създадете задача за SQL Performance Analyzer. Тази задача не е нищо друго освен хранилище, което консолидира всички данни за анализа, който се изпълнява от SQL Performance Analyzer. Както беше посочено по-рано, наборът за настройка на SQL се подава като стимулатор към анализатора.
как да използвам .swf файлове
Стъпка # 3)Предпромяна на пробната версия на SQL
След като създадохме задачата за SQL Performance Analyzer и SQL Tuning Set, трябва да изградим инфраструктурата на тестовата система.
Моля, обърнете внимание, че когато планираме да използваме система за тестване, трябва да се уверим, че тя е много подобна на производствената система по отношение на хардуер, софтуер и съхранение, за да можем да репликираме подобна среда.
След като системата за тестване бъде конфигурирана по подходящ начин, можем да изградим версията на данните преди промяната с помощта на SQL Performance Analyzer.
Това може да се постигне чрез използване на Enterprise Manager или API (вградени процедури).
Стъпка # 4)Пробна версия за промяна на SQL след промяна
Опитът след промяна се извършва на тестовата система след извършване на някои промени в системата.
След като това приключи, ще имаме две пробни версии на SQL - една пробна промяна и пробна промяна за сравнение.
Подобно на пробната версия на SQL за промяна на производителността, ние можем да създадем пробна версия за промяна на SQL след промяна, използвайки Enterprise Manager или API (вградени процедури).
Стъпка # 5)Генериране на отчет
След изпълнението на пробните промени преди и след промяната, данните за производителността, събрани в тях, могат да бъдат сравнени чрез стартиране на сравнителен анализ с помощта на SQL Performance Analyzer.
След като тази задача за сравнение приключи, можем да генерираме отчет, за да идентифицираме производителността на SQL изявлението, което е част от натоварването, което възнамеряваме да тестваме.
Преглеждайки доклада, можем да преценим и да направим заключения относно работата на SQL
Изявления и след това внедряване на системните промени в производството.
По същия начин можем да тестваме различни натоварвания с различни системни промени и да се уверим, че тестваме всеки един от тях, преди да ги внедрим в производството.
Илюстрираният по-горе работен поток може да бъде графично представен, както е показано по-долу.
Възпроизвеждане на база данни
За да стартирате инструмента чрез Enterprise Manager:
(Щракнете върху изображението, за да видите увеличено)
Възпроизвеждането на база данни позволява реалистично тестване на системни промени, като по същество репликира вашата производствена среда на тестова система. Това се прави чрез улавяне на желано работно натоварване в производствената система и повторно възпроизвеждане на тестова система с точните характеристики на ресурсите на първоначалното работно натоварване, като изпълнение на SQL, транзакции, извлечения и процедури.
Това се извършва, за да се уверим, че разглеждаме всички възможни въздействия на всяка промяна, включително нежелани резултати като продуктови грешки, неподходящи резултати или регресия на ефективността.
Обширният анализ и генерираните отчети също помагат да се идентифицират всички потенциални проблеми, като възникнали грешни обстоятелства и различия в производителността.
В резултат на това организациите могат да бъдат спокойни, когато се справят с промяната, и да бъдат доходоносни при оценката на общия успех на системната промяна. Това значително ще намали всеки риск, когато искаме да внедрим промените в производството. Промяната е неизбежна и като се уверим, че тестваме всеки аспект на тази промяна от всички степени, ще направим производството по-стабилно и стабилно.
Основният работен поток на повторението на базата данни е показан по-долу:
Промените, поддържани от възпроизвеждане на база данни, са:
- Надстройки на базата данни на Oracle, закърпване на софтуер
- Потребител / Схема, Екземпляр на база данни Параметри като памет, I / O
- Хардуерни / софтуерни промени в RAC (Real Application Cluster) възли
- Промени в операционната система, корекция на операционната система
- CPU, памет, съхранение
Възпроизвеждането на база данни ни позволява да тестваме различни ефекти от възможни промени в системата чрез възпроизвеждане на практическото натоварване на действителна производствена система върху тестова система, преди тя да бъде изложена на първата. Натоварването на производството се наблюдава, анализира и записва за определен количествен период от време. Тези данни се записват с течение на времето и се използват за повторно натоварване на тестовите системи.
Изпълнявайки това, можем успешно да тестваме последиците от натоварването, преди да приложим каквито и да е промени, които могат да повлияят неблагоприятно на производството.
Работният процес е както следва:
Етап 1) Заснемане на натоварване
Ние записваме всички заявки, направени от клиенти, във файлове, наречени „Capture files“ във файловата система (хранилище). Тези файлове съдържат цялата жизненоважна информация относно клиентските заявки като SQL, обвързвания, процедури и информация за транзакциите. След това тези файлове могат да бъдат експортирани във всяка система, в случай че искаме да ги възпроизведем на друга система.
Стъпка 2)Предварителна обработка на натоварването
След като уловим информацията в „Capture files“, трябва да ги обработим предварително. В тази стъпка ние създаваме метаданни, които предоставят описание на всички данни, необходими за повторно възпроизвеждане на натоварването.
Тъй като тази стъпка използва огромно количество ресурси от системата, препоръчително е да стартирате на друга система, освен производствена, където натоварването може да бъде преиграно. В случай, че нямате друга система за тестване и бихте искали да ги пуснете в производство, уверете се, че ги изпълнявате в не пикови часове, така че потребителите и процесите, които се изпълняват в производството, да не бъдат засегнати.
Стъпка # 3)Възпроизвеждане на натоварването
Сега можем да ги възпроизведем на тестовата система. Понастоящем възпроизвеждаме всички транзакции, контекст, процедури и SQL, които са били заловени първоначално по време на фазата на улавяне, натрупвайки данни, тъй като всеки процес преминава през този преход.
Стъпка # 4)Генериране на отчети
Подобно на Performance Analyzer, можете също да генерирате и преглеждате отчети, за да сравнявате всеки от тестовете, които сте изпълнили.
В заключение предлагаме няколко бързи съвета, докато тестваме Replay Database:
- Използвайте идентична тест система, когато и когато е възможно
- Тествайте една промяна в даден момент, за да разберете нейното въздействие
- Не забравяйте да започнете с опциите за повторно възпроизвеждане по подразбиране и след това направете промени, ако е необходимо, въз основа на вашите изисквания.
- Преди да извършите второто повторение, не забравяйте да разберете всички аспекти на тестването
- Не забравяйте да запазите резултатите от теста си и да документирате всички необходими промени / действия за тестване
- Уверете се, че никое друго работно натоварване или потребители не използват системата по време на някое от тестовите пускове
Заключение:
С различни аспекти и различни методи за тестване на база данни и приложения на Oracle, моля, уверете се, че винаги тествате възможно най-често и по-задълбочено; да разбере приложението и потребителската среда преди да внедри каквито и да е промени или да въведе нови параметри в Производството.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Разлика между тестване на настолни компютри, клиентски сървър и уеб тестване
- Как да тествате базата данни на Oracle
- Ръководство за тестване на сигурността на уеб приложения
- Тестване на приложения - в основите на софтуерното тестване!
- Инсталирайте приложението си на устройство и започнете да тествате от Eclipse
- Изтегляне на eBook за тестване на Primer
- Урок за деструктивно изпитване и безразрушително тестване