1 Введение
Представим ситуацию: Вы немного модифицировали код, который писали очень давно и не помните, что он делает. Но Вам надо его еще запустить, Вы его компилируете, а компилятор выдает ошибки, начинается процесс поиска ошибок - тестирование. В конце концов, вы находите ошибки, но на это ушло много времени, и не факт, что исправив эти ошибки вы не внесете новые.
Решение 1. Умный компилятор
Идеальным решением был бы умный компилятор, который бы не только бы проверял, что код синтаксически правильный, но и что логика программы тоже правильна. Такое средство выдает ошибки в логике, либо сигнализирует тогда когда вы что-нибудь поменяв, испортили логику программы. Таким образом, Вам нужно думать, вносить либо не вносить изменения? Но, к сожалению таких компиляторов не существует. [7]
Решение 2. Автоматизированное тестирование юнитов
Идеального компилятора не существует, поэтому надо найти другой способ тестирования. И этот способ называется «Автоматизированное тестирование юнитов - АТЮ».
Во первых АТЮ – это не тестирование по черному ящику.
Во вторых АТЮ – это не функциональное тестирование. Программа не проверяется на функциональные спецификации. [2,9]
АТЮ – это возможность определить множество тестов для класса. И тестировать программный интерфейс какого-то объекта: заполняем свойства объекта, какими-то данными, вызываем методы, и сверяем результаты, которые получили и которые хотели получить.
Так если есть приложение, которое работает с классом, устанавливает какие-то значения, то АТЮ создаст объект, который проделает все те же операции, а так же сверит с тем, что ожидалось на выходе.
1.1 Неформальная постановка задачи
В настоящее время существует множество средств тестирования, но они имеют высокую стоимость, большой объем, их сложно конфигурировать, только единицы работают с языком программирования Delphi.
Поэтому было решено создать такое программное средство (библиотеку подключаемых модулей) для автоматизированного тестирования юнитов (units) на языке Delphi, используя технологию получения RTTI (Runtime Type Information - Информация о типах времени исполнения), которое бы позволяло пользователю: использовать объектно-ориентированную запись тестов; объединять тесты в группы; запускать, как отдельные тесты, так и группы тестов, правильно перехватывать возникающие исключения.
То есть нужно создать, встраиваемый в программу пользователя, менеджер тестов, который может встраиваться в программу. [2]
Для обеспечения эффективной работы требуется обрабатывать конечное число тестовых наборов за определенный промежуток времени; осуществлять взаимодействия с пользовательским интерфейсом; запускать либо отдельные тесты, либо наборы тестов.
1.2 Описание предметной области
1.2.1 Что тестировать
Назначение функционального теста - доказать Заказчику (и показать Разработчику) то, что система работает так, как необходимо. Следовательно, тестировать надо то, и только то, что должно быть в работающем виде.
У разработчика всегда есть соблазн написать функциональный тест в терминах внутренней структуры системы. Например, если система должна рассчитывать комиссионные, то можно захотеть в коде создать объект, который их считает, и протестировать правильность его работы. Это ошибка, так как корректность работы какой-то части системы не дает гарантии работы бизнес-функции. Может быть, этот объект и не вызывается вовсе.
Функциональный тест должен работать в терминах пользователя. Если для пользователя расчет комиссионных выглядит как появление нужных сумм в окне просмотра, то и функциональный тест должен тестировать это. [1]
1.2.2 Как тестировать
|