Главная
База знаний "Allbest"
Программирование, компьютеры и кибернетика
Тестирование программного обеспечения
Тестирование программного обеспечения
Тестирование как составляющая часть процесса отладки программного обеспечения, его роль для обеспечения качества продукта. Обнаружение ошибок в программах, выявление причин их возникновения. Подходы к формулированию критериев полноты тестирования.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 20.12.2012 |
| Размер файла | 1,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Содержание
- Введение
- 1. Анализ задания и постановка задачи
- 1.1 Критерии "черного ящика"
- 1.2 Критерии "белого ящика"
- 1.3 Интеграционное тестирование
- 1.4 Функциональное тестирование
- 1.5 Модульное тестирование
- 2. Постановка задачи
- 3. Реализация
- 4. Тестирование
- 4.1 Объект тестирования
- 4.2 Модульное тестирование
- 4.3 Функциональное тестирование
- 4.4 Тестирование производительности
- 4.5 Нагрузочное тестирование
- Заключение
- Список используемой литературы
- Приложения
Введение
Несмотря на то, что роль тестирования на первый взгляд может показаться не столь уж значительной, что особенно характерно для людей плохо знакомых с жизненным циклом ПО, процесс тестирования программного обеспечения представляет собой столь же неотъемлемую часть разработки, как и проектирование.
Какая бы методология разработки программного обеспечения не применялась, роль процесса тестирования для обеспечения качества продукта трудно переоценить.
Роль тестирования еще более возрастает с применением прогрессивной итеративной и инкрементальной методологии разработки ПО. Специфика данной методологии заключается в малой продолжительности отдельных этапов разработки - итераций. В то же время каждая итерация включает в себя все этапы жизненного цикла, вплоть до внедрения разрабатываемого ПО и получения реакции пользователей.
Очевидно, что такой подход, во-первых, требует от тестовой инфраструктуры выявлять значительное количество дефектов программы, на как можно более ранних стадиях, во-вторых, фаза внедрения программного продукта на каждой итерации требует от тестовой подсистемы выявить такое количество ошибок, чтобы продукт мог поступить к конечному пользователю. Все это все более и более повышает требования к качеству тестов и максимально загружает тестовую инфраструктуру.
Тестирование является составляющей частью процесса отладки ПО, после выявления ошибок дефекты в программном коде должны быть устранены разработчиками.
Однако задачами современного тестирования является не только обнаружение ошибок в программах, но и выявление причин их возникновения. Такой подход позволяет разработчикам функционировать максимально эффективно, быстро устраняя возникающие ошибки.
Понимания важности процесса тестирования приводит к возникновению тенденций, направленных на применение промышленных способов проверки качества программного обеспечения. Наиболее важным направлением здесь является внедрение различных систем автоматизированного тестирования.
В рамках данной курсовой работы, мы рассмотрим как автоматизированные, так и ручные системы тестирования.
1. Анализ задания и постановка задачи
Тестирование ПО - это процесс выполнения ПО в контролируемых условиях с целью получения ответа на вопрос "Ведет ли ПО себя так, как специфицировано?".
Цель тестирования - обнаружить ситуацию, когда результаты работы программы не соответствуют входным данным. Самый простой способ сделать это: перебрать все возможные варианты входных данных и проверить правильность получаемых результатов. К сожалению, воспользоваться этим способом почти никогда не удается. Даже для простейших программ количество вариантов входных данных оказывается слишком большим. Т.е. исчерпывающее тестирование (т.е. перебор всех возможных вариантов выполнения) для любой нетривиальной программы невозможно.
Поэтому, обычно выполняется "разумное" тестирование, при котором тестирование программы ограничивается прогонами на небольшом подмножестве всех возможных входных данных. Естественно при этом целесообразно выбрать наиболее подходящее подмножество (подмножество с наивысшей вероятностью обнаружения ошибок).
Правильно выбранный тест подмножества должен обладать следующими свойствами:
1) уменьшать, причем более чем на единицу число других тестов, которые должны быть разработаны для достижения заранее определенной цели "приемлемого" тестирования:
2) покрывать значительную часть других возможных тестов, что в некоторой степени свидетельствует о наличии или отсутствии ошибок до и после применения этого ограниченного множества значений входных данных.
тестирование программное обеспечение
Критерии, по которым проводится классификация всех возможных вариантов выполнения программы с точки зрения проверки правильности программы, называются критериями полноты тестирования.
Существует два подхода к формулированию критериев полноты тестирования: критерии "черного ящика" и критерии "белого ящика".
Критерии черного ящика описывают тестирование с точки зрения поставленной задачи внутреннего устройства программы, а критерии белого ящика учитывают структуры программы.
1.1 Критерии "черного ящика"
Тестирование чёрного ящика или поведенческое тестирование - стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций.
Стратегия "черного ящика" включает в себя следующие методы формирования тестовых наборов:
эквивалентное разбиение;
анализ граничных значений;
анализ причинно-следственных связей;
предположение об ошибке.
Эквивалентное разбиение.
Основу метода составляют два положения:
Исходные данные программы необходимо разбить на конечное число классов эквивалентности, так чтобы можно было предположить, что каждый тест, являющийся представителем некоторого класса, эквивалентен любому другому тесту этого класса. Иными словами, если тест какого-либо класса обнаруживает ошибку, то предполагается, что все другие тесты этого класса эквивалентности тоже обнаружат эту ошибку и наоборот
Каждый тест должен включать по возможности максимальное количество различных входных условий, что позволяет минимизировать общее число необходимых тестов.
Разработка тестов методом эквивалентного разбиения осуществляется в два этапа:
выделение классов эквивалентности;
построение тестов.
Анализ граничных значений.
Граничные условия - это ситуации, возникающие на, выше или ниже границ входных классов эквивалентности. Анализ граничных значений отличается от эквивалентного разбиения следующим:
Выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных условий осуществляется таким образом, чтобы проверить тестом каждую границу этого класса.
При разработке тестов рассматриваются не только входные условия (пространство входов), но и пространство результатов.
Анализ граничных условий, если он применен правильно, является одним из наиболее полезных методов проектирования тестов. Однако следует помнить, что граничные условия могут быть едва уловимы и определение их связано с большими трудностями, что является недостатком этого метода. Второй недостаток связан с тем, что метод анализа граничных условий не позволяет проверять различные сочетания исходных данных.
Анализ причинно-следственных связей.
Метод анализа причинно-следственных связей помогает системно выбирать высоко результативные тесты. Он дает полезный побочный эффект, позволяя обнаруживать неполноту и неоднозначность исходных спецификаций.
Для использования метода необходимо понимание булевской логики. Построение тестов осуществляется в несколько этапов:
1) Спецификация разбивается на "рабочие " участки, так как таблицы причинно-следственных связей становятся громоздкими при применении метода к большим спецификациям.
2) В спецификации определяются множество причин и множество следствий. Причина есть отдельное входное условие или класс эквивалентности входных условий. Следствие есть выходное условие или преобразование системы. Каждым причине и следствию приписывается отдельный номер.
3) На основе анализа семантического (смыслового) содержания спецификации строится таблица истинности, в которой последовательно перебираются все возможные комбинации причин и определяются следствия каждой комбинации причин. Таблица снабжается примечаниями, задающими ограничения и описывающими комбинации причин и/или следствий, которые являются невозможными из-за синтаксических или внешних ограничений. Аналогично, при необходимости строится таблица истинности для класса эквивалентности.
4) Каждая строка таблицы истинности преобразуется в тест.
Предположение об ошибке.
Часто программист с большим опытом выискивает ошибки "без всяких методов". При этом он подсознательно использует метод "предположение об ошибке". Процедура метода предположения об ошибке в значительной степени основана на интуиции. Основная идея метода состоит в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка составить тесты. Другими словами, требуется перечислить те специальные случаи, которые могут быть не учтены при проектировании.
1.2 Критерии "белого ящика"
Техника тестирования по принципу Белого ящика, также называемая техникой тестирования управляемая логикой программы, позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии тестировщик получает тестовые данные путем анализа логики работы программы.
Техника Белого ящика включает в себя следующие методы тестирования:
1. покрытие операторов
2. покрытие решений
3. покрытие условий
4. покрытие решений и условий
5. комбинаторное покрытие условий
Метод покрытия операторов
Если отказаться полностью от тестирования всех путей, можно показать, что критерием покрытия является выполнение каждого оператора программы хотя бы один раз. Это необходимое, но недостаточное условие для приемлемого тестирования по принципу белого ящика.
Метод покрытия решений (покрытия переходов)
Более сильный метод тестирования известен как покрытие решений (покрытие переходов).
Согласно данному методу должно быть написано достаточное число тестов, такое, что каждое направление перехода должно быть реализовано, по крайней мере, один раз.
Покрытие решений обычно удовлетворяет критерию покрытия операторов. Поскольку каждый оператор лежит на некотором пути, исходящем либо из оператора перехода, либо из точки входа программы, при выполнении каждого направления перехода каждый оператор должен быть выполнен.
Метод покрытия условий
Лучшие результаты по сравнению с предыдущими может дать метод покрытия условий. В этом случае записывается число тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз.
Критерий решений (условий)
Критерий покрытия решений/условий требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз, и, кроме того, каждой точке входа передавалось управление, по крайней мере, один раз.
Метод комбинаторного покрытия условий.
Критерием, который решает эти и некоторые другие проблемы, является комбинаторное покрытие условий. Он требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись, по крайней мере, один раз. Набор тестов, удовлетворяющих критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.
1.3 Интеграционное тестирование
Интеграционное тестирование - это тестирование программного обеспечения на корректность взаимодействия нескольких модулей, объединенных в единое целое. Несмотря на то, что результатом тестирования и верификации отдельных модулей, составляющих программную систему, является заключение о том, что эти модули являются внутренне непротиворечивыми и соответствуют требованиям, это не гарантирует их корректную совместную работу. Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц - объединения, множества или группа модулей - выполняются через их интерфейс, используя тестирование "чёрного ящика".
Интеграционное тестирование называют еще тестированием архитектуры системы. Результаты выполнения интеграционных тестов - один из основных источников информации для процесса улучшения и уточнения архитектуры системы, межмодульных и межкомпонентных интерфейсов. Т.е. с интеграционные тесты проверяют корректность взаимодействия компонент системы.
Интеграционное тестирование, как правило, представляет собой итеративный процесс, при котором проверяется функциональность все более и более увеличивающейся в размерах совокупности модулей.
1.4 Функциональное тестирование
Функциональное тестирование - это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.
Функциональные требования включают:
· Функциональная пригодность
· Точность
· Способность к взаимодействию
· Соответствие стандартам и правилам
· Защищенность.
1.5 Модульное тестирование
Модульное тестирование, или юнит-тестирование (англ. unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. В данной работе мы будем использовать юнит-тесты для проверки функциональных требований программы.
Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев. Кроме того, происходит тестирование каждого из модулей по отдельности. Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях, не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования.
2. Постановка задачи
Царю Цопе много раз докладывали о стремительно набирающем популярность сайте Codeforces, на котором собираются светлейшие умы нашего человечества, - ради тренировки и дальнейшего просветления своих умов. И Цопа недавно осознал: если он хочет поработить весь мир, то для этого ему необходимо отдать приказ организовать всемирный турнир Codeforces. Цопа уверен, - после этого его поступка все светлейшие умы добровольно перейдут в его подчинение, и самая сложная часть плана порабощения мира будет осуществлена.
Финальный раунд Codeforces World Finals 20YY назначен на дату DD. MM. YY, где DD - день проведения раунда, MM - месяц, а YY - последние 2 цифры года. Васе посчастливилось стать первым в истории Берляндии участником, вышедшим в финал. Но есть одна проблема: по правилам соревнования, все участники на момент финального раунда должны быть не младше 18 лет, а Вася родился в день BD. BM. BY. Эта дата написана в Васином паспорте, копию которого он уже отправил организаторам соревнования. Но Вася узнал, что в разных странах форматы записи дат отличаются, например, в США обычно сначала записывается номер месяца, затем день, а потом год. Вася хочет узнать, а можно ли так переставить числа в его дате рождения, чтобы на момент DD. MM. YY ему было хотя бы 18 лет. Ведь тогда он сможет сказать, что в его родной Берляндии даты записываются по-другому. Помогите ему справиться с этой задачей.
По еще одному странному правилу, участник должен родиться в том же столетии, в котором проводится финал. Допускается, если участнику исполняется 18 ровно в день финала.
Так как мы рассматриваем годы проведения финала исключительно с 2001 до 2099, то високосным годом будем считать среди них такие, которые делятся на 4.
Входные данные:
В первой строке задана дата DD. MM. YY, во второй строке задана дата BD. BM. BY. Гарантируется, что обе даты корректны, и номера годов YY и BY всегда лежат в отрезке [01; 99].
Могло оказаться, что по паспорту Вася родился уже после финала. В этом случае он все равно может менять местами числа в дате.
Выходные данные:
Если можно переставить числа в дате рождения так, чтобы на момент DD. MM. YY Васе было хотя бы 18 лет, выведите YES. Иначе выведите NO.
Каждое число содержит ровно две цифры, и обозначает день, месяц или год в дате. Учтите, что разрешается переставлять любые числа, но не цифры.
Ограничение по времени на тест 2 seconds.
3. Реализация
Для решения требуется проверить заданную дату XD. XM. XY на корректность (учитывая число дней в каждом месяце, високосность, и т.д.). После этого решение заключалось в переборе всех возможных 6 перестановок трёх чисел (BD,BM,BY), проверке каждой перестановки на корректность, и сравнении полученной даты с датой проведения финала DD. MM. YY. Сравнение делается, прибавив 18 к числу лет, и сравнив эти две даты как тройки чисел (год, месяц, день).
Листинг 1 - Исходный код программы.
package termpapernpo;
import java. util. *;
public class TermPaperNPO {
static Scanner sc = new Scanner (System. in);
static final int [] days = {-1, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
static int dd, mm, yy;
static boolean test (int bd, int bm, int by) {
if (bm < 1 || bm > 12) {
return false;
}
if (bd < 1 || bd > days [bm] + (bm == 2 && by % 4 == 0? 1: 0)) {
return false;
}
if (yy - by < 18) {
return false;
}
if (yy - by > 18) {
return true;
}
if (mm > bm) {
return true;
}
if (mm < bm) {
return true;
}
return dd >= bd;
}
static int setDay (String day) {
try {
int dd = Integer. parseInt (day);
if (dd < 1 || dd > 31) {
throw new ExceptionInInitializerError ();
}
} catch (NumberFormatException ex) {
System. out. println ("Ожидалось число");
} catch (ExceptionInInitializerError ex) {
System. out. println ("Не соответствие интервалу");
}
return dd;
}
static int setMonth (String month) {
try {
int mm = Integer. parseInt (month);
if (mm < 1 || mm > 12) {
throw new ExceptionInInitializerError ();
}
} catch (NumberFormatException ex) {
System. out. println ("Ожидалось число");
} catch (ExceptionInInitializerError ex) {
System. out. println ("Не соответствие интервалу");
}
return mm;
}
static int setYear (String year) {
try {
int yy = Integer. parseInt (year);
if (yy < 1 || yy > 99) {
throw new ExceptionInInitializerError ();
}
} catch (NumberFormatException ex) {
System. out. println ("Ожидалось число");
} catch (ExceptionInInitializerError ex) {
System. out. println ("Не соответствие интервалу");
}
return yy;
}
public static void main (String [] args) {
String [] dmy = sc. next (). split ("\\. ");
try {
dd = setDay (dmy [0]);
mm = setMonth (dmy [1]);
yy = setYear (dmy [2]);
} catch (ArrayIndexOutOfBoundsException ex) {
System. out. println ("Неверный формат даты");
}
dmy = sc. next (). split ("\\. ");
int bd = 0, bm = 0, by = 0;
try {
bd = setDay (dmy [0]);
bm = setMonth (dmy [1]);
by = setYear (dmy [2]);
} catch (ArrayIndexOutOfBoundsException ex) {
System. out. println ("Неверный формат даты");
}
if (test (bd, bm, by) || test (bd, by, bm) || test (bm, bd, by)
|| test (bm, by, bd) || test (by, bd, bm) || test (by, bm, bd)) {
System. out. println ("YES");
} else {
System. out. println ("NO");
}
}
}
4. Тестирование
4.1 Объект тестирования
На языке java в IDE NetBeans написано консольное приложение, реализующее поставленную задачу. Программа содержит следующие классы и методы (см. табл.1):
Таблица 1. "Описание классов и методов"
|
Название класса |
Название метода |
Назначение |
|
|
CodeforcesWorldFinals |
public CodeforcesWorldFinals (int dd, int mm, int yy, int bd, int bm, int by) |
Параметризированный конструктор Parametrs: dd - день проведения финала mm - месяц проведения финала yy - год проведения финала bd - день рождения участника bm - месяц рождения участника by - год рождения участника |
|
|
private boolean test (int bd, int bm, int by) |
Определяет возможно ли участие в олимпиаде Parametrs: bd - день рождения участника bm - месяц рождения участника by - год рождения участника |
||
|
public String isPossible () |
Реализует все возможные варианты перестановки даты рождения. Returns: YES - Участие возможно NO - Участие не возможно |
||
|
Название класса |
Название метода |
Назначение |
|
|
TermPaperNPO |
public static void main (String [] args) |
Главный метод. |
|
|
static int setDay (String day) |
Устанавливает значения поля "день" и проверяет его на корректность. Parametrs: day - значение поля "день” Returns: Возвращает число, если оно прошло проверку на корректность. Throws: NumberFormatException ExceptionInInitializerError |
||
|
static int setMonth (String month) |
Устанавливает значения поля "месяц" и проверяет его на корректность. Parametrs: month - значение поля "месяц” Returns: Возвращает число, если оно прошло проверку на корректность. Throws: NumberFormatException ExceptionInInitializerError |
||
|
static int setYear (String year) |
Устанавливает значения поля "год" и проверяет его на корректность. Parametrs: year - значение поля "год ” Returns: Возвращает число, если оно прошло проверку на корректность. Throws: NumberFormatException ExceptionInInitializerError |
В рамках данной курсовой работы выполним следующие виды тестирования:
· Модульное тестирование
· Тестирование производительности
· Функциональное тестирование
· Нагрузочное тестирование
4.2 Модульное тестирование
Для использования юнит-тестов будем использовать JUnit. JUnit - библиотека для модульного тестирования программного обеспечения на языке Java. Для тестирования классов применялись тестовые драйверы. Предпочтение было отдано реализации тестового драйвера в виде отдельного класса.
При разработке тестов за основу был взят "критерий решений".Т. е был разработан такой тестовый набор, при котором все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз, и, кроме того, каждой точке входа передавалось управление, по крайней мере, один раз. Набор тестов представлен в листинге 2.
Листинг 2 - Набор тестов модульного тестирования.
public class MyTestCase extends TestCase{
public void testCondition1 () {
CodeforcesWorldFinals cwf1 = new CodeforcesWorldFinals (28, 2, 74, 28, 2, 64);
String expected = "NO";
String result = cwf1. isPossible ();
Assert. assertTrue (expected. equals (result));
}
public void testCondition2 () {
CodeforcesWorldFinals cwf1 = new CodeforcesWorldFinals (20, 10, 20, 10, 02, 30);
String expected = "NO";
String result = cwf1. isPossible ();
Assert. assertTrue (expected. equals (result));
}
public void testCondition3 () {
CodeforcesWorldFinals cwf1 = new CodeforcesWorldFinals (1, 1, 98, 1, 1, 80);
String expected = "YES";
String result = cwf1. isPossible ();
Assert. assertTrue (expected. equals (result));
}
public void testCondition4 () {
CodeforcesWorldFinals cwf1 = new CodeforcesWorldFinals (19, 11, 54, 29, 11, 53);
String expected = "NO";
String result = cwf1. isPossible ();
Assert. assertTrue (expected. equals (result));
}
public void testCondition5 () {
CodeforcesWorldFinals cwf1 = new CodeforcesWorldFinals (30, 6, 43, 14, 9, 27);
String expected = "YES";
String result = cwf1. isPossible ();
Assert. assertTrue (expected. equals (result));
}
public void testCondition6 () {
CodeforcesWorldFinals cwf1 = new CodeforcesWorldFinals (1, 9, 92, 10, 5, 74);
String expected = "YES";
String result = cwf1. isPossible ();
Assert. assertTrue (expected. equals (result));
}
public void testCondition7 () {
CodeforcesWorldFinals cwf1 = new CodeforcesWorldFinals (1, 1, 47, 28, 2, 29);
String expected = "YES";
String result = cwf1. isPossible ();
Assert. assertTrue (expected. equals (result));
}
public static Test suite () {
return new TestSuite (MyTestCase. class);
}
}
Результаты тестов представлены в приложении А (рис.1).
Кроме того были реализованы тесты, проверяющие корректность входящих значений. Набор тестов представлен в листинге 3.
Листинг 2 - Набор тестов, проверяющих корректность обработки информации
public class TermPaperNPOTest {
public TermPaperNPOTest () {
}
/**
* Test of setDay method, of class TermPaperNPO.
*/
@Test
public void testSetDay () {
System. out. println ("setDay");
String day = "10";
int expResult = 10;
int result = TermPaperNPO. setDay (day);
assertEquals (expResult, result);
}
/**
* Test of setMonth method, of class TermPaperNPO.
*/
@Test
public void testSetMonth () {
System. out. println ("setMonth");
String month = "12";
int expResult = 12;
int result = TermPaperNPO. setMonth (month);
assertEquals (expResult, result);
}
/**
* Test of setYear method, of class TermPaperNPO.
*/
@Test
public void testSetYear () {
System. out. println ("setYear");
String year = "09";
int expResult = 9;
int result = TermPaperNPO. setYear (year);
assertEquals (expResult, result);
}
}
Результаты данного набора тестов представлены в приложении А (рис.2).
Но, как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. Поэтому были реализованы и другие подходы к тестированию ПО.
4.3 Функциональное тестирование
Для проведения функционального тестирования программы, был создан отдельный модуль в виде самостоятельного приложения на языке Java. Приложение состоит из следующих классов:
? Compiler - данный класс предназначен для компиляции и построения программы из исходных кодов.
? TestCase - в данном классе непосредственно производится тестирование программы.
? BlackBoxTest - главный класс приложения.
Для проведения функционального тестирования была выбрана стратегия "черного ящика". Был подобран такой набор тестов, который основан на эквивалентном разбиении, анализе причинно-следственных связей и учитывает наиболее вероятные предположения об ошибках.
Алгоритм работы программы следующий:
Сперва тестирующая программа загружает исходный код, тестируемой программы. Данный код компилируется в *class файл, на основе которого создаётся *jar архив. Далее тестируемая программа запускается в отдельном потоке, на вход которой подается один тест из набора тестов. В конце результаты тестирования записываются в html файл, в котором данные представлены в виде таблицы.
Проанализируем данные полученные в результате тестирования. Тест считается пройденным, если значение, полученное в результате работы программы, совпадает с эталонным, а также, если соблюдено ограничение по времени. В тестировании использовался набор, состоящий из 82 тестов. Все тесты были успешно пройдены, что свидетельствует о функциональной пригодности тестируемого программного продукта.
4.4 Тестирование производительности
Для проведения тестирования производительности был использован интерфейс Runtime. Метода Runtime. getRuntime (). freeMemory () даёт сведения о количестве свободной памяти, доступной виртуальной машине, до начала тестирования и после его окончания. Метода System. currentTimeMillis () позволяет получать системное время до и после тестирования.
4.5 Нагрузочное тестирование
Для проведения нагрузочного тестирования был выбран простой подход: проводилось большое количество тестов функциональности с разными входными данными большого размера.
Заключение
В результате проделанной работы были изучены основы тестирования программного обеспечения. Используя полученные знания, был написан программный комплекс, который удовлетворяет требованиям поставленной задачи. Также в работе рассмотрено использование оболочки модульного тестирования JUnit для тестирования программного обеспечения при разработке.
Были проведены следующие виды тестирования:
· Модульное тестирование
· Тестирование производительности
· Функциональное тестирование
· Нагрузочное тестирование
Проведя анализ полученных результатов, можно сделать вывод, что программный продукт соответствует всем выдвинутым требованиям.
Список используемой литературы
1. Майерс, Г. Искусство тестирования программ/ Г. Майерс; Пер. с англ. под ред. Позина. - М.: Финансы и статистика, 1982. - 176 с.
2. Степанченко И.В. Методы тестирования программного обеспечения: Учеб. пособие / Степанченко И.В. - ВолгГТУ, Волгоград, 2006. - 76 с.
3. Калбертсон, Р. Быстрое тестирование. / Р. Калбертсон, К. Браун, Г. Кобб. - М.: Издательский дом "Вильямс", 2003. - 374 с.
4. Синицын, С.В. Верификация программного обеспечения. / С.В. Синицин, Н.Ю. Налютин. - М.: 2006. - 158 с.
5. Савин, Р. Тестирование дот ком или пособие по жесткому обращению с багами в интернет-стартапах / Р. Савин. - М.: Издательство "Дело", 2007. - 316 с.
6. Канер, С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / С. Канер, Дж. Фолк, Е. Кек Нгуен; Пер. с англ. - К.: Издательство "ДиаСофт", 2001. - 544 с.
7. Тамре, Л. Введение в тестирование программного обеспечения / Л. Тамре; Пер. с англ. М.: Издательский дом "Вильямс", 2003.368 с.
Приложения
Приложение А
Рис 1. "Результаты выполнения набора тестов MyTestCase"
Рис.2 "Результаты выполнения набора тестов TermPaperNPOTest"
Размещено на Allbest.ru
Подобные документы
Тестирование и отладка программного обеспечения: понятие, принципы, этапы, цели и задачи. Тестирование методом сандвича как компромисс между восходящим и нисходящим подходами. Сущность метода "белого и черного ящика", отладки программного обеспечения.
курсовая работа [36,9 K], добавлен 21.07.2012Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.
курсовая работа [112,2 K], добавлен 22.03.2015Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем.
курсовая работа [3,0 M], добавлен 19.11.2009Развитие аппаратных компьютерных средств - задача первых трех десятилетий компьютерной эры. Процесс тестирования как составляющая процесса обеспечения качества разработки ПО. Принципы и критерии, предъявляемые к тестированию программного обеспечения.
курсовая работа [319,5 K], добавлен 25.05.2009История возникновения тестирования программного обеспечения, основные цели и особенности его проведения. Виды и типы тестирования, уровни его автоматизации. Использование и исследование необходимых технологий. Полный цикл прогона всей системы мониторинга.
дипломная работа [1,7 M], добавлен 03.05.2018Сущность тестирования и отладки, методика выявления ошибок в программном обеспечении. Практика отладки приложений в среде Delphi, системы управления версиями приложения и отслеживания ошибок. Применение точек остановки и модификация локальных переменных.
курсовая работа [303,4 K], добавлен 19.01.2016Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
отчет по практике [296,1 K], добавлен 19.04.2015Комплексное функциональное и структурное тестирование программного продукта - граф-программа решения квадратного уравнения. Постановка задачи структурного тестирования маршрутов. Заключение о типе и причине ошибки, предложение по ее исправлению.
курсовая работа [2,8 M], добавлен 05.01.2013История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
курсовая работа [309,5 K], добавлен 16.12.2015Проблема надежности программного обеспечения, ее показатели и факторы обеспечения. Методы контроля процесса разработки программ и документации, предупреждение ошибок. Этапы процесса отладки ПО, приемы структурного программирования и принцип модульности.
презентация [379,5 K], добавлен 30.04.2014
