Под тестированием понимается процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.

     Одним из способов изучения поставленного  вопроса является исследование метода тестирования:

     Метод «черного ящика», тестирование с управлением по данным или тестирование с управлением по входу – выходу. При использовании этой стратегии программа рассматривается как «черный ящик». Иными словами, такое тестирование имеет целью выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Тестовые же данные используются только в соответствии со спецификацией программы (т. е. без учета знаний о ее внутренней структуре). При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных. Если такое испытание представляется сложным, то еще сложнее создать исчерпывающий тест для большой программы. Построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами: во-первых, нельзя создать тест, гарантирующий наличие ошибок; во-вторых, разработка таких тестов противоречит экономическим требованиям. Поскольку исчерпывающее тестирование исключается, целью тестирующего должна стать максимизация числа ошибок, обнаруживаемых одним тестом. Для этого можно рассматривать внутреннюю структуру программы и делать достоверные предположения.

     Другим  способом тестирования является метод  «белого ящика», управляемого логикой программы. Данный способ позволяет исследовать внутреннюю структуру программы. В этом случае тестирующий получает тестовые данные путем анализа логики программы (к сожалению, здесь часто не используется спецификация программы). Сравним способ построения тестов при данном методе с исчерпывающим входным тестированием стратегии «черного ящика». Не  знающему может показаться, что достаточно построить такой набор тестов, в котором каждый оператор выполняется хотя бы один раз, но это предположение ошибочно. Не вдаваясь в детали, укажем лишь, что исчерпывающему входному тестированию может быть поставлено в соответствие исчерпывающее тестирование маршрутов. Подразумевается, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам ее потока передач управления.

     Последнее утверждение имеет два слабых пункта. Первый из них состоит в  том, что число не повторяющих  друг друга маршрутов в программе  очень велико. Второй слабый пункт  утверждения заключается в том, что, хотя исчерпывающее тестирование маршрутов является полным тестом, и хотя каждый маршрут программы может быть проверен, сама программа будет содержать ошибки. Это объясняется следующим образом:

        Во-первых, исчерпывающее  тестирование маршрутов не может дать гарантии того, что программа соответствует описанию. Например, вместо требуемой программы сортировки по возрастанию случайно была написана сортировка по убыванию. В этом случае ценность тестирования маршрутов невелика, поскольку после тестирования в программе окажется одна ошибка, т. е. программа неверна.

        Во-вторых, программа  может быть неверной в силу того, что пропущены некоторые маршруты. Исчерпывающее тестирование маршрутов  не обнаружит их отсутствия.

        В-третьих, исчерпывающее  тестирование маршрутов не может обнаружить ошибок, появление которых зависит от обрабатываемых данных.

     Кроме вышеперечисленных методов тестирования существуют также следующие:

• монолитный метод (или метод большого удара);
• метод пошагового тестирования;
• метод восходящего тестирования;
• метод нисходящего тестирования;
• метод большого скачка;
• метод сандвича;
• модифицированный метод сандвича.

     Монолитный  метод – каждый модуль тестируется отдельно, а затем их комбинируют и формируют рабочую программу.

     Метод пошагового тестирования – модули тестируются не отдельно друг от друга, а подключаются поочередно для выполнения теста к набору уже ранее оттестированных модулей. Пошаговый процесс продолжается до тех пор, пока к набору оттестированных модулей не будет подключен последний модуль.

     Монолитный  метод и метод пошагового тестирования являются подходами к комбинированию модулей. Рассмотрим особенности этих методов:

1. монолитное тестирование требует больших затрат труда. При пошаговом же тестировании «снизу-вверх» затраты труда сокращаются;
2. расход машинного времени при монолитном тестировании меньше;
3. использование монолитного метода предоставляет большие возможности для параллельной организации работы на начальной фазе тестирования (тестирования всех модулей одновременно). Это положение может иметь важное значение при выполнении больших проектов, поскольку численность персонала, участвующего в проекте, максимальна на начальной стадии;
4. при пошаговом тестировании раньше обнаруживаются ошибки в интерфейсах между модулями, поскольку раньше начинается сборка программы. В противоположность этому при монолитном тестировании модули «не видят друг друга» до последней фазы процесса тестирования;
5. отладка программ при пошаговом тестировании легче. Если есть ошибки в межмодульных интерфейсах, а обычно так и бывает, то при монолитном тестировании они могут быть обнаружены лишь тогда, когда собрана вся программа. В этот момент локализовать ошибку довольно трудно, поскольку она может находиться в любом месте программы. Напротив, при пошаговом тестировании ошибки такого типа в основном связаны с тем модулем, который подключается последним;
6. результаты пошагового тестирования более совершенны.

     По  вышеперечисленным пунктам напрашивается  вывод, что пошаговое тестирование является наиболее предпочтительным из этих двух методов.

     Далее исследуем две возможные стратегии  тестирования: нисходящее и восходящее.

     При «восходящем тестировании» программа собирается и тестируется «снизу - вверх».

     Только  модули самого нижнего уровня тестируются  изолированно, автономно.

     Затем тестируются модули более высокого уровня вместе с уже проверенными модулями более низкого уровня. Процесс продолжается до тех пор, пока не буде достигнута вершина.

     «Нисходящий метод» имеет как достоинства, так и недостатки по сравнению с «восходящим». Самое значительное достоинство – то, что этот метод совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций. С этим же связано и другое его достоинство: когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения осуществимости программы в целом или когда в проекте программы могут оказаться серьезные дефекты. Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах; вместо драйверов просто следует написать «заглушки». Нисходящий метод тестирования имеет некоторые недостатки. Основным из них является то, что модуль редко тестируется досконально сразу после его подключения. Второй недостаток состоит в том, что данный подход может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. При использовании метода «большого скачка» каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу (имеет много недостатков).

     Тестирование  методом «сандвича» представляет собой компромисс между восходящим и нисходящим тестированием. Тестирование начинается одновременно сверху и снизу. Точка встречи зависит от конкретной тестируемой программы и должна быть заранее определена при изучении ее структуры.

     В данном дипломном проекте приводится тестирование системы по методу «черного» и «белого ящика».

      Тестированию  подверглись все хранимые процедуры через соответствующие функции клиентского приложения (некорректный ввод, повторяющиеся поля и др.). Также проведена проверка правильности формирования всех выходных документов. Особой проверке подлежал контроль за доступностью некоторых пунктов меню и операций над данными, хранящимися в таблицах.

      Тестирование  на доступность пунктов  меню:

        1) администратору доступны все пункты меню, включая таблицу пользователей;

        2) сотрудник, заполняющий БД может вводить данные из анкет детей, доступно изменение «Справочников», «Анкет», получение выходных документов. Так же доступна постановка и снятие анкеты с учета;

        3) сотрудникам ОГОУ «ЦПМСС» доступно получение выходных документов, поиск анкет в БД, просмотр анкет.

      Тестирование  на ввод записей, уже имеющейся в таблице БД

      Если  в таблицу вводится запись, в которой  поля повторяются с уже имеющимися (например, вводится в таблице «Гражданство»  одно и то же наименование), то выдается сообщение об ошибке.

      Тестирование  на правильность выходных документов

      Данные  всех выходных документов должны соответствовать действительности. По результатам тестирования можно сказать, что они совпали с ожидаемыми.

      Проведенное тестирование показывает, что разработанная  система соответствует тем требованиям, которые были предъявлены к ней  в постановке задачи.

Глава 3. Организационно-экономическая  часть

3.1. Оценка затрат  на разработку  АС

      Оценка  затрат на разработку АС предполагает выполнение следующих шагов:

• оценка размера проекта, этапов работы, выявление необходимых ресурсов для каждого этапа;
• составление таблицы, в которой указывается для каждой работы графика ее продолжительность и требуемы ресурсы;
• составление календарного графика в виде сетевой модели (для крупных проектов) или графика Ганнта (для небольших проектов);
• оценка стоимости проекта.

     В определении ресурсов наиболее сложным  является определение затрат труда. Общей практикой оценки трудозатрат  является экспертные оценки исполнителей с выделением резервов от 30 до 50%.

     В стоимость программного продукта включаются все затраты, связанные с выполнением работы, независимо от источников финансирования:

• материальные затраты;
• основная заработная плата;
• дополнительная заработная плата;
• страховые взносы;
• затраты на электроэнергию;
• затраты на эксплуатацию и обслуживание средств ВТ;
• амортизационные отчисления;
• накладные расходы.

     Основные  виды работ, выполнение которых необходимо для разработки данного программного продукта (см. таблица 1).

     График  Ганнта для планирования работ (см. приложение 8).

     Таблица 1.

Календарный график