Лабораторная работа №3
.docxФГБОУ ВО
«Уфимский государственный авиационный технический университет»
Кафедра ТК
ОТЧЕТ
по лабораторной работе № 3
по дисциплине «Технологии программирования»
Выполнил: студенты гр. ИВТ-227Б
Проверил: доцент каф. ТК
Федорова Н. И.
Уфа 2022
Тема работы: Тестирование программ методами “Черного ящика”.
Цель работы: Усвоение студентами методов функционального тестирования
программного обеспечения.
Задачи работы:
Написать программу, реализующую заданный алгоритм обработки данных;
Отобразить алгоритм решения задачи в виде блок-схемы программы.
Отобразить граф передачи управления для решаемой задачи.
Выбрать метод тестирования, который может дать наибольшую вероятность обнаружения ошибок в программе.
Протестировать разработанную программу.
Задание:
Идентифицировать треугольник по трем сторонам (остроугольный, прямоугольный, тупоугольный, равносторонний, равнобедренный).
Текст программы:
#include <iostream>
#include <stdlib.h>
using namespace std;
void main()
{
int a, b, c;
setlocale(LC_ALL, "Russian");
cout << "Программа позволяет идентифицировать треугольник по трем сторонам.\n\nВведите значения углов:\n";
cout << "Введите размер стороны а: ";
cin >> a;
cout << "Введите размер стороны б: ";
cin >> b;
cout << "Введите размер стороны с: ";
cin >> c;
if (((a <= 0) || (b <= 0) || (c <= 0)) || ((a >= b + c) || (b >= a + c) || (c >= a + b)))
{
cout << "\nОшибка: Треугольник неверный\n";
exit(1);
}
cout << "\nОтвет:\n";
if ((a == b) & (a == c) & (b == c))
cout << "Треугольник равносторонний\n";
else if ((a == b) || (b == c) || (a == c))
cout << "Треугольник равнобедренный\n";
if ((a * a == (b * b + c * c)) || (b * b == (a * a + c * c)) || (c * c == (a * a + b * b)))
{
cout << "Треугольник прямоугольный\n";
}
if ((a * a < (b * b + c * c)) & (b * b < (a * a + c * c)) & (c * c < (b * b + a * a)))
{
cout << "Треугольник остроугольный\n";
}
if ((a * a > (b * b + c * c)) || (b * b > (a * a + c * c)) || (c * c > (b * b + a * a)))
{
cout << "Треугольник тупоугольный\n";
}
}
Причинно-следственный граф:
Причины:
(((a <= 0) или (b <= 0) или (c <= 0)) или ((a >= b + c) или (b >= a + c) или (c >= a + b)))
((a = b) и (a = c) и (b = c))
((a = b) или (b = c) или (a = c))
((a * a = (b * b + c * c)) или (b * b = (a * a + c * c)) или (c * c = (a * a + b * b)))
((a * a < (b * b + c * c)) и (b * b < (a * a + c * c)) и (c * c < (b * b + a * a)))
((a * a > (b * b + c * c)) или (b * b > (a * a + c * c)) или (c * c > (b * b + a * a)))
Следствия:
Треугольник неверный
Треугольник равносторонний
Треугольник равнобедренный
Треугольник прямоугольный
Треугольник остроугольный
Треугольник тупоугольный
Таблица тестирования программы:
-
Тест
Путь
Ожидаемый результат
Ожидаемый результат
Результат
тестирования
1
2
3
4
5
1
2
3
4
5
60,60, 70
1-2-3-14
Н
-
-
-
-
Н
-
-
-
-
Не успешно
60,60,60
1-2-4-5-13
Д
Д
-
-
-
Д
Д
-
-
-
Не успешно
30,30,120
1-2-6-7-12-13
Д
Н
Д
Н
Н
Д
Н
Д
Н
Н
Не успешно
45,45, 90
1-2-8-9-13
Д
Н
Д
Д
-
Д
Н
Д
Д
-
Не успешно
50,50,80
1-2-6-7-10-11-13
Д
Н
Д
Н
Д
Д
Н
Д
Д
Д
Не успешно
110,50,20
1-2-10-12-13
Д
Н
Н
Н
Н
Д
Н
Н
Н
Н
Не успешно
90,20,70
1-2-8-9-13
Д
Н
Н
Д
-
Д
Н
Н
Н
-
Не успешно
58,74,48
1-2-10-11-13
Д
Н
Н
Н
Д
Д
Н
Н
Н
Д
Не успешно
Вывод: В ходе выполнения работы были усвоены методы тестирования логики программы, формализованного описания результатов тестирования и стандартов по составлению схем программ.
Контрольные вопросы:
Тестирование “белым” и “черным” ящиком.
“Белый ящик”. Существо подхода “белого ящика” – в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается. Тестирование по принципу белого ящика характеризуется степенью, какой тесты выполняют или покрывают логику (исходный текст программы).
“Черный ящик”.
Для обнаружения всех ошибок в программе, используя управление по данным, необходимо выполнить исчерпывающее тестирование, т.е. тестирование на всех возможных наборах данных. Для тех же программ, где исполнение команды зависит от предшествующих ей событий, необходимо проверить и все возможные последовательности. Очевидно, что проведение исчерпывающего тестирования для подавляющего большинства случаев невозможно. Поэтому обычно выполняют «разумное» или «приемлемое» тестирование, которое ограничивается прогонами программы на небольшом подмножестве всех возможных входных данных. Этот вариант не дает гарантии отсутствия отклонений от спецификаций.
В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Функциональный подход основывается на том, что алгоритм работы программного обеспечения не известен. Тесты строят, опираясь на функциональные спецификации. Программа рассматривается как «черный ящик», и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствует требованиям.
Методы структурного тестирования. Для получения эффективных тестовых наборов данных при структурном тестировании используются следующие критерии:
Покрытие операторов. Этот критерий предполагает выбор такого тестового набора данных, который вызывает выполнение каждого оператора в программе хотя бы один раз.
Покрытие узлов ветвления (покрытия решений). Этот критерий предполагает разработку такого количества тестов, чтобы в каждом узле ветвления был обеспечен переход по веткам "истина" и "ложь" хотя бы один раз.
Покрытие условий. Если узел ветвления содержит более одного условия (сложное условие), тогда нужно разрабатывать число тестов, достаточное для того, чтобы возможные результаты каждого условия в решении выполнялись по крайней мере 1 раз.
Комбинаторное покрытие условий. Этот критерий требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись хотя бы 1 раз
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Программа как объект исследования. Схема программы – это математическая модель программы, отвечающая следующим требованиям: Модель позволяет изучать свойства достаточно широких классов программ, а не отдельных конкретных программ. Сохраняет все интересующие исследователя свойства и особенности рассматриваемого класса программ.
Правила применения символов:
1. Символ предназначен для графической идентификации функции, которую он отображает, независимо от текста внутри этого символа.
2. Символы в схеме должны быть расположены равномерно. Следует придерживаться разумной длины соединений и минимального числа длинных линий.
3. Большинство символов задумано так, чтобы дать возможность включения текста внутри символа. Формы символов, установленные ГОСТом, должны служить руководством для фактически используемых символов. Не должны изменяться углы и другие параметры, влияющие на соответствующую форму символов. Символы должны быть, по возможности, одного размера.
4. Символы могут быть вычерчены в любой ориентации, но, по возможности, предпочтительной является горизонтальная ориентация. Зеркальное изображение формы символа обозначает одну и ту же функцию, но не является предпочтительным.
5. Минимальное количество текста, необходимого для понимания функции данного символа, следует помещать внутри данного символа. Текст для чтения должен записываться слева направо и сверху вниз независимо от направления потока.
6. Если объем текста, помещаемого внутри символа, превышает его размеры, следует использовать символ комментария. Если использование символов комментария может запутать или разрушить ход схемы, текст следует помещать на отдельном листе и давать перекрестную ссылку на символ.
7. В схемах может использоваться идентификатор символов. Это связанный с данным символом идентификатор, который определяет символ для использования в справочных целях в других элементах документации (например, в листинге программы). Идентификатор символа должен располагаться слева над символом (рис. 1).