an excellent way data testing using xml technologies
В SDLC , ако приложението използва модел водопад, в края се планират дейности за тестване. Това крие риск от преработка по отношение на изискванията, дизайна, кода и тестовите случаи, ако екипът за QA установи дефекти. По-добре е да избягвате чакането до края, за да идентифицирате дефектите в дадено приложение.
Тестовете, които не се основават на функционално изпълнение на приложението, могат да открият дефекти, без да се изисква освобождаването на всички компоненти в тестовата среда. Това може да се постигне чрез тестване на данни.
XML и свързаните с него технологии, използвани за комуникация между различни нива на приложение, предоставят възможност за провеждане на тестовете, които не трябва да чакат, докато цялото приложение бъде лесно достъпно за тестване.
Този документ очертава един от възможните начини за разглеждане на опцията за тестване на данни в началото на жизнения цикъл на пускането на продукта.
Какво ще научите:
- Предположение:
- Фокусна група:
- Предназначение:
- Тествайте жизнения цикъл на управление на данните
- Заключение
- Препоръчително четене
Предположение:
Този документ предполага, че читателят е запознат концепции за софтуерно тестване и основно използване на база данни и XML технологии.
Фокусна група:
QA екип (QA), екип за данни (DT), разработчик (DEV)
Предназначение:
The примерни данни идентифициран за тестване на даден продукт определя степента на извършеното тестване, добавя увереност в резултатите от теста и качеството на продукта. Идентифицирането на данните за тест зависи от изискванията на теста, който трябва да се извърши.
Този документ се фокусира върху валидирането на тестовите данни, преди да ги види в потребителския интерфейс.
Този процес се нуждае от управление на данните от теста, за да има ефективни резултати от теста. Данните, както всички знаем, могат да бъдат записани в база данни или плосък файл. Но прехвърлянето на данни от / към база данни може да се обработи с помощта на XML. Съществува много тясна връзка между XML (1), XSD (2), XPATH (3) & XSLT (4). (Вижте всички определения по-долу).
(1) XML - е х напрегната М arkup L мъка. Препоръката на World Wide Web Consortium (W3C) е да описва данни. С прилагането на набор от правилни правила за синтаксис, може да се гарантира, че XML документът е „добре оформен“
(2) XSD - Използва се за обозначаване на структурата на XML документ. „Добре оформен“ XML документ може да бъде валидиран срещу XSD (XML схема), за да го валидира
(3) XPATH - Трябва да се премине през „валиден“ и „добре оформен“ XML, за да се вземат подходящи данни от XML. Изразите XPATH изглеждат като традиционен файлов път в директория.
(4) XSLT - е х напрегната С лист с листа L мъка т ransformations - Докато представляват данните от XML в потребителски интерфейс (UI), всеки стил (шрифт, цвят, размер и т.н.) може да бъде приложен с помощта на XSLT. XSLT използва XPath за намиране на информация от XML.
Данни, представени в XML се проверява срещу схема (XSD файл). XML може да се извежда в различни формати с XSLT и XPATH.
смяна на глас, които работят с раздори
За целите на тази дискусия ще използваме следния пример.
Пример - Издателство има уебсайт, който показва информация за книгите, които е издала. Една от уеб страниците показва обобщение за всяка глава от книга. Тестването трябва да гарантира, че съдържанието е подходящо на тази уеб страница. Издателството до момента е издало милиони книги.
Всяка информация, свързана с публикуваните книги, се записва в база данни. И все пак въпросната уеб страница се нуждае от подмножество от данни (за нова книга и нейните глави), които да бъдат извлечени от базата данни в XML.
Даденият по-долу XML представлява метаданните за книгата.
XML файл Book.xml
A book on test data Jim 2015 Technical English 120 10 Acknowledgement Introduction What is data List of references XML книга със схеми.xsd
Тествайте жизнения цикъл на управление на данните
Подобно на други процеси, управление на тестови данни има свои собствени етапи на жизнения цикъл (LC).
- Идентифицирайте изискванията за данни
- Планиране на събирането на данни
- Изградете данните
- Тествайте данните
- Поддържане на данни (не е подробно описано в този документ, защото не е от значение)
# 1. Идентифицирайте изискванията за данни
В горния пример базата данни съхранява милиони записи. Ако съдържанието на всички книги се извлече в XML файл, това изисква подробна проверка. Тъй като и когато трябва да се извежда нова информация в уеб страницата, XML и схемата може да претърпят промени.
Промените в XML, XSD, XPATH и XSLT изискват правилна проверка. Но това тестване не трябва да чака представяне на презентация, мидълуер и ниво на данни. Екипът за QA може да анализира XSD, за да подготви план за изискване за данни.
отгоре на c ++ въпроси за интервю
| Етап на жизнения цикъл | Критерии за влизане | Дейности / Отговорност | Критерии за изход |
|---|---|---|---|
| Идентифицирайте изискванията за данни от теста | Налични са следните документи Проектиране на база данни, дизайн на потребителския интерфейс, спецификация на изискванията, техническа архитектура, диаграма на потока от данни, диаграми на случаите на употреба | Разберете изискванията за данни, отнасящи се до документите от критериите за влизане (QA, DT, DEV) Изисквания за тестови данни (QA, DT, DEV) - Документира всички нужди от данни за всеки екран, показващ съпоставяне между имената на екрана и съответния XML елемент | Прегледайте документа за изискванията за тестови данни (QA, DEV, DT) |
Процесът на идентифициране на всички изисквания за данни за даден продукт трябва да обхваща следното:
а) Обхват и пълнота - Идентифицираните изисквания обхващат ли всички случаи на употреба?
Пример - Много е важно да тествате комбинациите от данни за заглавие, автор, категория, език в горната XML проба; тъй като схемата налага тези полета.
Това може лесно да се обработи, като се разгледа XML схемата, която описва присъствието на елемент / атрибут и техния ред в XML
б) Качество - Данните събрани ли са с възможно най-добро качество? Използваните данни от теста определят качеството на тестването, извършено върху приложението.
- Положителни и негативни сценарии - Тестването трябва да провери как приложението се държи с валидни / невалидни входни данни
The документ за изисквания за тестови данни изброява нуждите от данни за всички нива на приложението. Данните от базата данни могат да бъдат използвани директно в потребителския интерфейс и / или манипулирани (изчисления, конкатенация и др.). Следователно е необходимо да се обхванат всички нужди от данни.
Таблицата по-долу представлява примерна таблица с данни:
| Име на полето | Тип данни | Данни от теста | Забележки | Резултат от тест |
|---|---|---|---|---|
| Автор | Струна | Празно поле | Тъй като това е задължително поле. Тестът трябва да се провали. | |
| Автор | Струна | Автор + @ | Има специални знаци | Този тест трябва да се провали |
| Автор | Струна | Име на автора | Включва интервал | Този тест трябва да премине |
| Автор | Струна | 123Автор | Започва с номер | Този тест трябва да се провали |
| Автор | Струна | @! Автор | Започва със специални знаци | Този тест трябва да се провали |
| Автор | Струна | Автор | Префикс с интервали | Този тест трябва да се провали |
В горния пример може да се избегне използването на низов тип данни за полето Автор. Вместо това може да се приложи модел.
E.g. само азбуки, започнете с главна буква, без специални символи и т.н. A модел (ограничаваща стойност на елемент, дефинирана в XSD) може да бъде дефинирана като .
Ако това е настроено за автор елемент в горния пример, това означава, че автор елементът трябва да има стойността само с комбинация от главни, малки букви и положителни цели числа.
# 2. Планиране на събирането на данни
| LC етап | Критерии за влизане | Дейности / Отговорност | Критерии за изход |
|---|---|---|---|
| Планиране на събирането на данни | Документ за одобрени данни за изпитване | Идентифицирайте честотата на нуждите от данни (DEV, QA) Списък на данните от теста (QA) Дефинирайте XML схема (DEV) | Прегледайте честотата на нуждите от данни и данните от теста (DT) |
# 3. Изградете данните
| LC етап | Критерии за влизане | Дейности / Отговорност | Критерии за изход |
|---|---|---|---|
| Изграждане на данни | Файл за искане на данни | Изграждане на данните в DB (DT) Извличане на данните от DB в XML (DT) Проверка на XML срещу схема (DT) Споделете XML файла с QA (DT) | XML файлът се получава от екипа за осигуряване на качеството |
# 4. Тествайте данните
| LC етап | Критерии за влизане | Дейности / Отговорност | Критерии за изход |
|---|---|---|---|
| Тествайте данните | XML файл с искане за данни | Проверете XML срещу схема за пълнота и коректност (QA) Актуализирайте картографиращия документ с резултати от теста (QA) | Резултатите от теста се споделят с DEV, DT екип |
Както е изброено в горните таблици, QA валидира XML спрямо схемата, за да провери дали данните са налични според очакванията. След като схемата съвпада, съдържанието и нейната структура могат да бъдат потвърдени, че са добре. И все пак това не потвърждава, че данните се събират точно от системата.
Както знаем XML показва дървовидна структура с p arent-дете-брат-сестра-прародител-низходящ връзка между възлите.
Погледнете таблицата по-долу, за да разберете най-простите конвенции XPATH:
За да се представят полетата от XML на екран (като HTML например) се използва комбинация XSLT - XPATH.
Latest Book
Title Author Publication_Year Category Language Pages
В браузъра накрая полученият XML е представен по-долу. Тъй като данните вече са проверени, фокусът на тестването може да бъде по-скоро във вид и усещане на екрана.
Заключение
- Тестването на данни, проведено в началото на жизнения цикъл на теста за разработка, спестява пари, тъй като разходите за поправяне на грешка по време на изпълнението на функционалния тест са много повече от поправянето им в началото на жизнения цикъл
- Усилията, похарчени първоначално за валидиране на XML файла, XPath и XSLT с XSD документи, помагат да се избегнат множество итерации на изданието
- Екипът на QA може да работи в тясно сътрудничество с екипа за разработки и да предоставя услуга с добавена стойност
- Екипът на QA може да помогне за макетиране на различни комбинации от данни, за да осигури покритие и коректност
Сигурен съм, че тази техника ще ви бъде полезна. Чувствайте се свободни да коментирате, ако имате някакви въпроси.
Препоръчително четене
- Прост подход за тестване на XML към база данни
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Основни разлики между тестване на черна кутия и тестване на бяла кутия
- Топ 10 популярни инструменти за съхранение на данни и технологии за тестване
- Урок за тестване на хранилище на данни за ETL (Пълно ръководство)
- Изтегляне на eBook за тестване на Primer
- Какво е тестване на мутация: Урок с примери
- Как да извършите тестване на данни с помощта на инструмента TestComplete