Xslt наложение xslt-преобразования.
Пример простого сценария сборки приведен ниже.
П
ервая
строка содержит общую информацию о
собираемом проекте.
<project name=”simpleCompile” default=”deploy” basedir=”.”>
Самые важные атрибуты элемента project это default (по умолчанию) и basedir (базовая директория). Атрибут default указывает на target (задание), определенное для выполнения по умолчанию.
Ant работает из командной строки, поэтому вполне реально указать только подмножество необходимых задач из всего файла сборки. Например, запустив следующую команду:
% ant -buildfile simple.xml init
Запустив такую команду, обработчик Ant'а выполнит только задание (target) с атрибутом name, которого равно init. Итак, в нашем примере заданием по умолчанию является deploy. Следующий пример команды запуска Ant выполнит именно задание указанное по умолчанию, так как нет указания в командной строке на какое-либо конкретное задание:
% ant -buildfile simple.xml
<target name=”init”>
<target name=”clean” dependens= ”init”>
В общем случае элемент target содержит пять атрибутов: name, if, unless, depends и description. Обязательным атрибутом является name, когда как остальные — необязательные.
Указывая значение атрибута depends, вы можете указать Ant'у, что данное задание зависит от других заданий и не может быть выполнено пока не выполнятся все задания из указанных в атрибуте. В приведенном выше примере, задание clean не запустится до тех пор, пока не завершится задание init. Атрибут depends может включать несколько значений имен заданий через запятую, тем самым указывая, что зависит от нескольких заданий. Атрибуты if и unless дают вам возможность указать задания, которые выполнятся если указанное свойство установлено (в случае if) или наоборот, в случае unless не установлено. Вы можете использовать команду available для установки свойств, как показано в следующем примере, либо в командной строке.
<available classname="org.whatever.Myclass"
property="Myclass.present"/>
Задание init из нашего примера содержит установку четырех свойств вида:
<property name="sourceDir" value="src" />
Очень часто property (свойствам) присваивают часто используемые директории или файлы. Атрибуты элемента property это пары name(имя) и value(значение). Установка свойств позволит логически подвязать необходимые директории или файлы вместо их прямого использования. Если нужно сослаться на свойство с именем sourceDir где-либо позднее в файле, вы можете использовать следующий синтаксис, указывающий Ant'у подставить соответствующее значение установленное в элементе property ранее: ${sourceDir}. Пример:
<javac srcdir="${src.dir}"
destdir="${build.classes}"
classpath="${classpath}"
debug="on"
deprecation="off"
optimize="on">
<include name="**/*.java"/>
<exclude name="**/Script.java"
unless="bsf.present" />
<exclude name="**/version.txt" />
< /javac>
Автоматизация тестирования
Unit-тестирование
Модульное тестирование или юнит-тестирование (англ. unit testing) — процесс, позволяющий проверить корректность отдельных модулей исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
Хорошие юнит тесты:
● Автоматизированы
● Выполняются быстро: выполнение сотни или даже тысячи юнит-тестов должно занимать считанные секунды
● Написаны в рамках эффективного фреймворка
● Независимыми друг от друга
● Результат работы теста воспроизводим и повторяем
● Легко поддаются отладке
● Написаны автором кода
● Оставляют конфигурацию / окружение в неизменном состоянии
● Имеют высокое покрытие кода
● Поддаются хранению и сопровождению
● Тестируют как функциональность, так и аварийные ситуации
● Покрывают граничные значения входных параметров.
Эти тесты имеют и некоторые ограничения:
● Юнит-тестирование не находит все ошибки в коде: оно показывает только наличие ошибок, а не их отсутствие
● У юнит-тестирования ограниченные рамки: это тестирование «белого ящика»
● Юнит-тестирование не покрывает сценарии и интеграцию между компонентами
Одной из наиболее важных техник, которые позволяют создать хорошие юнит-тесты, является техника использование mock- объектов (mock objects). Mock-объект - это симуляция реального объекта там, где использование самого объекта невозможно или нарушает принципы юнит- тестирования, например когда реальный объект:
● предоставляет недетерминированные результаты (например текущее время или температуру)
● имеет трудно воспроизводимые состояния (например ошибка сети)
● медленный (например полная база данных или файл на диске)
● ещё не существует или может изменить поведение
● должен содержать информацию или методы, необходимые только для тестирования
Для большинства популярных языков программирования высокого уровня существуют инструменты и библиотеки модульного тестирования. Некоторые из них:
Для Java
● JUnit JUnit.org
● TestNG testNG.org
● JavaTESK UniTESK.ru
NUnit [1] — для языков платформы .NET: C#, Visual Basic .NET и др.
Для C
● CUnit cunit
● CTESK UniTESK.ru
● cfix cfix
● API Sanity Autotest — для динамических C/C++ библиотек в Unix-подобных ОС.
● Для Objective-C
● OCUnit [2]
Для C++
● CPPUnit [3]
● Boost Test [4]
● Google C++ Testing Framework [5]
● Symbian[6] — фреймворк для Symbian OS всех версий.
● API Sanity Autotest — для динамических C/C++ библиотек в Unix-подобных ОС.
Для PHP
● SimpleTest [12]
● PHPUnit [13]
Разработка тестов и тестирование выполняется по схеме рис. 41.
Р
ис.
41
С
хема
алгоритма тестирования приведена на
рисунке 42.
Рис. 42
Тестирование интеграции
Это тестирование всей системы, при котором, в основном, выявляются ошибки интерфейса. Основные категории ошибок интерфейса:
● Потеря данных при прохождении через интерфейс;
● Отсутствие в модуле необходимой ссылки;
● Негативное влияние одного модуля на другой;
● Подфункции при объединении не выполняют требуемую функцию;
● Неточности интерграции выходят за допустимый уровень;
● Проблемы при работе с глобальными структурами данных.
Виды тестирования:
Нисходящее;
Восходящее.
Структура первого приведена на рис. 43. А второго – на рис. 44.
Р
ис.
43
Типы заглушек
A – трассирует сообщение;
B – выводит входные параметры;
C – возвращает значения из таблицы, заданного набора;
D – возвращает результат из таблицы для конкретного входного значения.
Р
ис.
44
Типы драйверов
A – вызывает подчиненный модуль;
B – посылает элемент данных (параметр) из внутренней таблицы;
C – отображает параметр из подчиненного модуля;
D – является комбинацией драйверов B и C.
Синтетические тесты на производительность СУБД
Они играют важную роль. Такие тесты называют TPC. Их целью является предоставление объективных данных о производительности системы. Для того, чтобы достичь этой цели, спецификации TPC регламентируют, чтобы тестировалась производительность систем, продуктов, технологий, отвечающих следующим требованиям:
● продукт должен быть доступен пользователям;
● продукт должен относиться к соответствующему сегменту рынка (обработка транзакций);
● при тестировании продукта должны быть обязательно воспроизведены действия некоторого числа пользователей этой системы.
Пример представления результатов тестирования приведен на рис. 45.
Р
ис.
45
Существует целый ряд систем тестирования, которые можно применять в учебных целях. К ним относятся
Selenium —инструмент для тестирования Web- приложений. Selenium - это Java-приложение, которое может анализировать файлы определенной структуры для того, чтобы находить в них команды для манипуляции браузером и команды для выполнения определенных действий и проверок. Selenium поддерживается Microsoft Internet Explorer, Google Chrome, Mozilla Suite и Mozilla Firefox для Microsoft Windows, Linux и Apple Macintosh.
IBM Rational TestManager и др.
Работа над ошибками происходит в соответствии со схемой рис. 46.
Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.
Р
ис.
46
Средства Bug tracking
● Bugzilla
● Mantis
● Trac
● JIRA
● YouTrack
● StarTeam
● TUTOS