- Системні вимоги
- Шаблон проекту автоматизації тестування
- Малюнок 1. Архітектурна схема
- сценарій
- Крок 1. Створення XML-схеми для даних контрольного тесту
- Лістинг 1. XML-схема для даних контрольного тесту
- Лістинг 2. Файл специфікації сервера
- Крок 3. Створення прикладу XML-файла контрольного тесту
- Лістинг 3. Приклад XML-файла контрольного тесту
- Крок 4. Виконання сценаріїв автоматизації тестування
- Малюнок 2. Конструктор збережених процедур в Visual Studio
- Малюнок 3. Log-файл результату
- Малюнок 4. Файл журналу трасування
- Створення Java-класів контрольного тесту з використанням JAXB
- Лістинг 4. Використання демаршалізованного API JAXB для доступу до даних контрольного тесту
- Лістинг 5. Використання об'єктів даних контрольного тесту
- Виконання контрольних тестів
- Можливість розширення
- резюме
- Ресурси для скачування
Вимоги замовників до скорочення часу розробки і поліпшенню якості програмного забезпечення змушують організації шукати способи автоматизації та оптимізації своїх процесів, щоб залишатися конкурентоспроможними. У цій статті описується шаблон проекту автоматизації тестування, який може бути використаний для автоматизації тестування інструментальних засобів, заснованих на графічному інтерфейсі (graphical user interface - GUI), з метою суттєвого скорочення часу, необхідного для виконання тестування при контролі якості (QA). Крім того, шаблон проекту спрямований на пом'якшення цих проблем і допомагає створити ідеальне середовище з урахуванням вимог автоматизації тестування. Він пропонує наступні можливості:
- Незалежність від платформи. Автоматизація тестування можлива для безлічі платформ і варіантів з'єднань з серверами.
- Можливість розширення. Можливість безперервного додавання нових тестів без зміни існуючих тестів і артефактів.
- Звітність та регресійні порівняння. Прозора автоматична звітність з порівнянням очікуваних і фактичних результатах тесту.
- Простата налагодження. Простота створення журналів і трасування з метою налагодження.
Середа IBM® Database Add-Ins for Microsoft® Visual Studio® надає розробникам інтуїтивно зрозумілі засоби взаємодії і інтеграції компонентів бази даних для додатків в стадії розробки. Цей інструмент, який використовує потужні графічні конструктори, майстри і меню, пропонує інтегроване середовище розробки для життєвого циклу та обслуговування об'єктів баз даних IBM (включаючи таблиці, представлення, збережені процедури, функції і т.д.). Програма підтримує всі типи серверів IBM DB2 і IDS. Більш детальну інформацію про цей інструмент можна знайти в керівництві Що нового в IBM Database Add-Ins for Visual Studio 2005 (EN).
Системні вимоги
Щоб працювати з пропонованим шаблоном проекту, необхідні наступні технології і артефакти середовища розробки:
Шаблон проекту автоматизації тестування
Шаблон проекту, що розглядається в цьому документі, зображений нижче у вигляді архітектурної схеми.
Малюнок 1. Архітектурна схема
Пояснення компонентів архітектури
Для продовження роботи важливо зрозуміти, що знаходиться усередині шаблону проекту. У число архітектурних компонентів шаблону входять наступні:
Test Case Schema (схема контрольного тесту)
Цей файл визначає XML-схему і метадані для вираження даних тесту. Test Case XML (XML контрольного тесту) Цей файл, заснований на Test Case Schema, містить фактичні дані тесту, які сценарії автоматизації тестування будуть читати при виконанні тестів. Binding Compiler & Schema Derived Classes & Interfaces (компілятор зв'язування + похідні класи схеми + інтерфейси) Компілятор зв'язування JAXB автоматично генерує необхідні пакети для інтеграції зі сценаріями автоматизації тестування. Automation Framework and JAXB API (інфраструктура автоматизації і JAXB API) Сценарій інфраструктури автоматизації імпортує пакет (и), згенеровані компілятором зв'язування. Для читання XML-даних контрольного тесту використовуються API JAXB. Test Application (тестоване додаток) Це базове додаток, яке буде тестуватися. Trace Log and Result Log (журнал трасування і журнал результату) Вихідні дані інфраструктури автоматизації тесту являють собою набір представлених в зрозумілому форматі журналів трасування і результатів. У журналах відображаються потік управління і трасування стека при збоях тесту.
сценарій
У цьому розділі показано, як наш шаблон проекту використовується при розробці механізму автоматизації тестування для IBM Visual Studio Add-ins. Короткий огляд IBM Visual Studio Add-Ins для розробників GUI наведено в документі Що нового в керівництві IBM Database Add-Ins for Visual Studio 2005 (EN).
Крок 1. Створення XML-схеми для даних контрольного тесту
Почнемо зі створення схеми для даних контрольного тесту. Схема, наведена нижче, призначена для зберігання даних, необхідних для збережених процедур тесту при роботі з IBM Visual Studio Add-In.
- Кореневим елементом є testCaseData.
- Елемент servers містить serverType, який зберігає різні типи серверів, які повинні бути протестовані. Типів серверів може бути декілька.
- Procedures - це елемент, який містить всі дані, що стосуються створення збереженої процедури, такі як ім'я, параметри і їх властивості, а також тіло процедури, і очікуваний результат.
Лістинг 1. XML-схема для даних контрольного тесту
<? Xml version = "1.0"?> <Xsd: schema xmlns: xsd = "http://www.w3.org/2001/XMLSchema"> <xsd: element name = "testCaseData"> <xsd: complexType> < xsd: sequence> <xsd: element name = "servers"> <xsd: complexType> <xsd: sequence> <xsd: element maxOccurs = "unbounded" name = "serverType" type = "xsd: string" /> </ xsd : sequence> </ xsd: complexType> </ xsd: element> <xsd: element name = "procedures"> <xsd: complexType> <xsd: sequence> <xsd: element maxOccurs = "unbounded" name = "sp"> <xsd: complexType> <xsd: sequence> <xsd: element name = "name" type = "xsd: string" /> <xsd: element name = "description" type = "xsd: string" /> <xsd: element maxOccurs = "unbounded" name = "param"> <xsd: complexType> <xsd: sequence> <xsd: element name = "name" type = "xsd: string" /> <xsd: element name = "mode" type = "xsd: string" /> <xsd: element name = "type" type = "xsd: string" /> <xsd: element name = "value" type = "xsd: string" /> </ xsd: sequence> < / xsd: complexType> </ xsd: element> <xsd: element name = "body" type = "xsd: string" /> <xsd: element name = "expectedResult" type = "xsd: string" /> </ xsd : Sequence> </ xsd: complexType> </ xsd: element> </ xsd: sequence> </ xsd: complexType> </ xsd: element> </ xsd: sequence> </ xsd: complexType> </ xsd: element > </ xsd: schema>
Тепер запустимо компілятор зв'язування JAXB для створення Java-пакета, який містить всі Java-класи, засновані на схемі контрольного тесту.
Після завершення скомпілюємо Java-пакет, щоб згенерувати файли класів і імпортувати створені класи в сценарій автоматизації тестування.
Ці кроки описані (з прикладом) в наступному розділі статті.
Задайте дані сервера в файлі специфікації сервера. Цей файл специфічний для тестової програми. Дані про сервер не включаються в XML-файл контрольного тесту, тому що вони не змінюються так часто, як дані файлу контрольного тесту. Файл специфікації сервера є загальним для всіх контрольних тестів, і інформація в цьому файлі змінюється тільки тоді, коли відбуваються будь-які зміни в параметрах підключення до сервера. На цю інформацію посилається елемент serverType схеми, розглянутої на кроці 1.
Лістинг 2. Файл специфікації сервера
# Yes / no для тесту LUW97 gsTestLUW97 = yes #URL тесту LUW97Server gsTestLUW97URL = server1.test.ibm.com: 50000 #ID тесту LUW97user gsTestLUW97UserID = UserName # Пароль тесту LUW97user gsTestLUW97Password = password # Тест LUW97dbname gsTestLUW97DBName = SAMPLE # Інформація про версію тесту LUW97dbname gsTestLUW97DBVersion = [DB2 / NT 09.07.0001] # yes / no для тесту LUW95 gsTestLUW95 = yes #URL тесту LUW95Server gsTestLUW95URL = server2.test.ibm.com: 50000 #ID тесту LUW95user gsTestLUW95UserID = UserName # Пароль тесту LUW95user gsTestLUW95Password = password # Тест LUW95dbname gsTestLUW95DBName = SAMPLE # Інформація про версію тесту LUW97dbname gsTestLUW97DBVersion = [DB2 / NT 09.05.0005]
У наведеному вище файлі властивостей всі вирази, що починаються з #, є коментарями.
- gsTestLUW97URL містить URL сервера для підключення LUW v97.
- gsTestLUW97UserID і gsTestLUW97Password містять ідентифікатор користувача і пароль для підключення до цього сервера.
Аналогічним чином в цьому файлі задається інша інформація, необхідна для підтримання зв'язку з сервером.
Крок 3. Створення прикладу XML-файла контрольного тесту
Тепер створимо приклад XML-файла контрольного тесту. Цей XML-файл, який базується на вищезгаданій схемі, містить фактичні дані тесту. Щоб додати новий контрольний тест, користувач повинен створити цей файл. Контрольний тест, наведений нижче, надає збережену процедуру і інформацію про сервер. В елементі <serverType> користувач повинен вказати один або кілька серверів, згаданих на першому кроці.
Лістинг 3. Приклад XML-файла контрольного тесту
<? Xml version = "1.0"?> <TestCaseData> <servers> <serverType> LUWV97 </ serverType> </ servers> <procedures> <sp> <name> vsai_fvt0001 </ name> <description> Stored Procedure with 1 INTEGER IN parameters </ description> <param> <name> Zipcode </ name> <mode> IN </ mode> <type> INTEGER </ type> <value> 95054 </ value> </ param> <body> </ body> <expectedResult> \ expectedResult \ SP \ vsai_fvt0001.xml </ expectedResult> </ sp> </ procedures> </ testCaseData>
Вищевказаний XML-документ заснований на схемі, описаній на кроці 1.
- <TestCaseData> є кореневим елементом документа.
- <ServerType> містить ім'я сервера LUWV97, на якому будуть виконуватися контрольні тести.
- <Procedures> містить створювані збережені процедури <sp>. У наведеному вище прикладі є тільки одна <sp>.
- <Sp> містить ім'я vsai_fvt0001, деталі параметрів в тезі <param>, а в <expectedResult> - шлях до файлу очікуваних результатів для збереженої процедури. Приклад процедури має один вхідний параметр з ім'ям ZIPCODE, типом INTEGER і значенням 95054.
Крок 4. Виконання сценаріїв автоматизації тестування
Виконайте сценарій автоматизації, що містить код для читання даних контрольного тесту, у вашому середовищі Rational Functional Tester. Це призведе до запуску IBM Database Add-Ins for Visual Studio, і тестоване додаток створить процедуру, що зберігається з даними, зазначеними в XML-файлі контрольного тесту, як показано нижче.
Малюнок 2. Конструктор збережених процедур в Visual Studio
Тепер подивіться на журнали, щоб визначити результат тесту.
Малюнок 3. Log-файл результату
Якщо тест не пройшов, можна подивитися згенерований файл журналу трасування, щоб усунути проблему. Приклад файлу трасування наведено нижче.
Малюнок 4. Файл журналу трасування
Реалізація інфраструктури автоматизації
Тепер, коли ви можете працювати з інфраструктурою автоматизації, ваша середовище розробки GUI отримує ряд переваг, що надаються цим рішенням. Інфраструктура автоматизації дозволяє ефективно реалізувати наступні можливості:
Створення Java-класів контрольного тесту з використанням JAXB
Наведена нижче команда зв'язування бере файл testCaseData.xsd, описаний на кроці 1, і генерує пакет jaxb.testData, який буде містити всі похідні класи, засновані на схемі.
зв'язування:
Xjc -p jaxb.testData testCaseData.xsd -d autoClasses
Опція -p визначає пакет для створених класів, а опція -d - цільової каталог. Таким чином, дана команда упаковує класи в пакет jaxb.testData в каталозі autoClasses.
Компілятор зв'язування створює набір класів, які представляють елементи в схемі.
компіляція:
javac jaxb / testData / *. java
Дана команда компілює всі вихідні Java-файли, створені процесом зв'язування, і створює файли класів.
Сценарій автоматизації повинен імпортувати пакет, створений процесом зв'язування, і може отримати доступ до даних у файлі testCaseData.xml, використовуючи демаршалізованний API JAXB, як показано нижче в лістингу 4.
Лістинг 4. Використання демаршалізованного API JAXB для доступу до даних контрольного тесту
private TestCaseData GetTestCaseData () {TestCaseData tcData = null; try {JAXBContext jc = JAXBContext.newInstance ( "jaxb.testData"); Unmarshaller u = jc.createUnmarshaller (); // Перевірка схеми за допомогою XML-файла u.setEventHandler (new javax.xml.bind.helpers.DefaultValidationEventHandler ()); tcData = (TestCaseData) u.unmarshal (new FileInputStream ( "TestCaseData.xml")); return (tcData); } Catch (JAXBException je) {je.printStackTrace (); } Catch (IOException ioe) {ioe.printStackTrace (); } Return (null); }
Як тільки XML-файл демаршалізован, дані XML-файла можуть бути використані в якості об'єктів (див. Лістинг 5).
Лістинг 5. Використання об'єктів даних контрольного тесту
// Отримати xml-файл testCaseData як об'єкт TestCaseData tcData = GetTestCaseData (); // Отримати всі сервери, очікувані для тесту List serverList = tcData.getServers (). GetServerType (); List spList = tcData.getProcedures (). GetSp ();
Перевага цього методу полягає в тому, що користувач може додавати нові контрольні тести, не вникаючи в подробиці Rational Functional Tester і інфраструктури автоматизації. При використанні JAXB дані контрольного тесту автоматично перетворюються в Java-класи, що полегшує інтеграцію в інфраструктуру. Крім того, побудований таким чином документ контрольного тесту може бути прочитаний будь-який інший інфраструктурою автоматизації, написаної на Java.
Виконання контрольних тестів
Інфраструктура автоматизації виконує для кожного контрольного тесту наступні кроки:
- Відкриває тестоване додаток.
- Запускає трасування.
- Читає файл даних контрольного тесту.
- Обходить всі сервери і додає підключення до сервера бази даних в IBM Database Add-Ins, грунтуючись на даних файлу даних контрольного тесту.
- Для кожного типу сервера, згаданого в файлі даних контрольного тесту, перебирає всі дані процедури, що і створює збережену процедуру.
- Виконує збережену процедуру і записує результат в файл журналу результатів.
- Додає запис в файл журналу трасування на початку і в кінці кожного викликається методу, а також при виникненні виняткової ситуації.
- Порівнює результат тесту з очікуваним результатом і оновлює файл журналу результатів.
Можливість розширення
Тепер, коли ви можете працювати в фреймворку автоматизації, ваша середовище розробки GUI отримує ряд переваг, що надаються цим рішенням. Фреймворк автоматизації дозволяє з вигодою використовувати такі можливості:
- Просте додавання нових контрольних тестів.
- Просте зміна існуючих контрольних тестів.
- Будь-які модифікації даних серверів шляхом зміни файлу сервера.
- Зміни користувальницького інтерфейсу, наприклад розміру, положення і т.д., не вимагають ніяких змін в реалізації автоматизації.
- Проста поширення автоматизації на інші компоненти.
- Можливість спільної розробки сценаріїв автоматизації в рамках інфраструктури.
резюме
Розгорнувши шаблон тесту за допомогою описаних вище дій, ви отримуєте в своє розпорядження інфраструктуру автоматизації тестування, яка дозволяє здійснювати автоматизоване тестування IBM Database Add-Ins for Visual Studio. В даний час реалізується інфраструктура для автоматизованого тестування збережених процедур. Подальша робота буде спрямована на розширення інфраструктури з метою автоматизації тестування інших елементів, таких як таблиці, функції та подання.
Ресурси для скачування
Схожі теми
Підпишіть мене на повідомлення до коментарів
