Тест приложения Win API на С++
1 Часть задания
Писать приложение с помощью функций WinAPI на языке про¬граммирования C++ (Borland C++ Builder, Visual C++ 6.0 или Visual C++ 7.1)
Написать программу, используя функции WinAPI (WinMain, MessageBox, CreateWindow, ShowWindow, TextOut), которая при за¬пуске создает окно, используемое для вывода результатов работы, и завершает свое выполнение при его закрытии. Содержимое окна должно сохраняться при изменении его размера, закрытии его другим окном и т.п.
Написать программу, реализующую заданную функцию с ука¬занными параметрами.
Задать функцию fun22 с параметром а (тип integer). Функция fun22 выводит один столбик таблицы умножения параметра а.
2 часть задания
Составить полный тест для проверки работоспособности программ (см. Приложение 2).
Проверить работу программы на тестах.
Отчет должен содержать:
• постановку задачи
• текст главной программы с комментариями
• текст реализованной функции с комментариями
• текст полного теста в виде таблицы
• протоколы тестирования программы
• заключение
Приложение 2
ТЕСТИРОВАНИЕ ПРОГРАММ
Аксиомы тестирования
Сформулированные ниже рекомендации названы нами "аксиома¬ми" потому, что необходимость их неукоснительного соблюдения до¬казана многолетним опытом работы программистов.
1. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.
2. Выполнить полный тест удается только для весьма ограничен¬ного класса схем алгоритмов. Разумно заканчивать тестирование, ко¬гда выполнено конечное число примеров, дающих максимальную ве¬роятность обнаружения ошибки.
3. Чем больше ошибок обнаружено в модуле, тем выше вероятность, что в нем остались необнаруженные ошибки. Это вызвано тем, что ошибки образуют группы, определяемые "почерком" программиста.
4. Невозможно тестировать удовлетворительно собственную про¬грамму, поскольку это и вопрос престижа. Тестирование должна вы¬полнять внешняя группа. Обычно тесты для модулей нижних уровней готовить программист, разрабатывающий вызывающий модуль.
5. Тестирование следует поручать самым способным программистам.
6. Необходимая часть всякого теста — описание ожидаемых ре¬зультатов (эталонов для последующего сравнения).
7. Необходимо тщательно изучать результаты каждого теста пре¬жде, чем выполнять остальные.
8. Необходимо готовить тесты как для правильных, так и для не правильных данных.
9. Проект системы должен быть таким, чтобы каждый модуль подключался к системе один раз.
10. Никогда не меняйте программу, чтобы облегчить тестирова¬ние. Так, если у Вас есть оператор цикла
DO 1000 К = 1, 1000
а Вы заменили его оператором
DO 1000 К = 1, 10
то знайте - Вы тестируете другую программу!
Правила выбора тестов
Для проверки модуля или заглушки требуются исходные данные. Сколько их должно быть? Как их выбирать? Приведенные ниже ре¬комендации помогут Вам ответить на это вопросы.
1. Начинайте с простых тестов, постепенно переходя к более сложным.
2. Учитывайте логику программы. Каждый оператор программы должен быть выполнен в процессе тестирования хотя бы 1 раз! Для этого по структурной схеме программы проверьте, в каждом ли на¬правлении выполняются условные переходы.
3. Обеспечьте проверку функционирования программы в нор¬мальных условиях, стараясь использовать по возможности и простые данные и ограничивать их объем.
4. Используйте для проверки специальные значения. К ним отно¬сятся константы 0, 1 и пустая символьная строка.
5. Обеспечьте проверку функционирования программы в экстре¬мальных условиях, когда задаются:
а) граничные значения данных (значение находится на границе области допустимых величин)
• очень большие значения,
• очень малые значения,
• отсутствие значений,
б) граничные объемы информации
• 0 элементов в массиве,
• 1 элемент в массиве,
• 1 строка (1 столбец) матрицы.
6. Обеспечьте проверку функционирования программы в исклю¬чительных ситуациях (выход за пределы границ).
7. Для циклов обеспечьте, по крайней мере, тройную проверку:
• обход тела цикла,
• однократное выполнение,
• максимальное число повторений цикла.
Иногда бывает полезно проверить отрицательное число повторе¬ний цикла.
Из приведенных рекомендаций следует, что тесты нужно гото¬вить для каждой ситуации в программе, для каждой границы области допустимых значений входных данных, для области изменения дан¬ных, для всех недопустимых условий. Исходной информацией для этого служат внешние спецификации модуля, таблицы решений, используемые на этапе проектирования модуля.