Тестирование программного обеспечения

- Какой формат ввода поля «Пол» (м и ж или муж и жен или мужской и женский)?;

- Может ли поле «Автор» содержать числовые значения?;

- Какой формат ввода даты возврата?

При последующей доработке проекта следует в требования добавить уточнения по этим вопросам. тестирование программное обеспечение junit

4. Категория тестов «Неверные данные»

Возможные вопросы:

- Что означает «выход за границы»?

- Каковы будут последствия?

- Что порождает неправильные данные в тестируемом приложении?

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

Примеры неверных данных для числовых полей могут быть следующие

- значения вне допустимого диапазона;

- отрицательные числа;

- десятичные дроби;

- на первой позиции - ноль или пробел;

- буквенно-цифровые сочетания знаков.

Примеры неверных данных для буквенно-числовых полей:

- на первой позиции - пробел;

- отличные от буквенно-цифровых знаки;

- нажатие специфических клавиш.

При неверных условиях система может вести себя следующим образом:

- отправить сообщение об ошибке;

- напомнить пользователь о корректных данных;

- повторно использовать предыдущее верное значение или состояние;

- отменить транзакцию;

- проигнорировать случившееся и попытаться обработать запрос как есть.[8]

В требованиях для рассматриваемого примера о неверных данных ничего не указано. Поэтому остаются без ответов следующие вопросы:

- Что случится, если пользователь введет не буквенные значения в поля «Фамилия», «Имя», «Отчество», «Жанр»?

- Что случится, если поле «Адрес» будет состоять только из числовых значений?

- Что случится, если в поля «Телефон», «Дата возврата», «Идентификатор» пользователь введет не числовые данные, отрицательные или дробные числа?

- Что случится, если пользователь введет в поле «Дата возврата» дату, которая была раньше «Даты выдачи»?

- Что случится, если при вводе значений в любое поле пользователь введет на первую позицию пробел, а для числовых - ноль?

- Что случится, если в поле «Пол», в которое предполагается вводить значения определенного формата, ввести что-либо отличное от данного формата?

- Что случится, если любое из полей будет пустым?

- Сколько читателей и книг можно добавить?

- Есть ли возможность удаления из файлов книг и читателе?

Для достижения должного уровня проекта в требования к данному приложению следует внести ответы на данные вопросы.

5. Категория тестов « Сброс»

Возможные вопросы:

- Что случится, если пользователь нажмет клавишу <ESCAPE> или другой тип клавиши с функцией «стоп»?

- Что случится, если пользователь активизирует последовательность сброса?

- Что случится, если обработка данных остановиться прежде, чем будет выполнена задача?

- Что случится, если будет выдернут кабель?

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

- Какие этапы необходимы для восстановления системы после её аварийного отключения?

- Останутся ли какие-либо файлы в открытом состоянии?

Восстановление системы может принимать различные формы, например:

- перезагрузка системы;

- повторная инициализация приложения;

- переустановка приложения.[8]

6. Категория тестов «»Потери мощности»

Возможные вопросы:

- Что случится, если в ходе обработки данных будет отключено питание или произойдет падение напряжения?

Что случиться, если при запуске или восстановлении последовательности произойдет падение напряжения?

- Какие возможные сбои в аппаратном обеспечении?

Колебания напряжения и аварийные отключения - это реальность. Одни системы требовательны к качеству подаваемого напряжения, в то время как другие могут допускать его слабые колебания. В некоторые критичные системы встроены блоки резервного питания. Потери мощности могут быть также результатом сбоев в аппаратной части или е1 повреждений. Цель тестирования - определить, насколько хорошо система справляется с деструктивными действиями.[8]

7. Категория тестов «Создание напряжений в системе»

Возможные вопросы:

- Что означает для тестируемой системы «слишком много»?

- Как можно перегрузить систему?

- Что случится, когда другие процессы потребуют совместного использования одного и того же ресурса?

- Какие существуют ограничения на обработку данных и на ресурсы?

- Можно ли в фоновом режиме запускать одновременно и другие процессы?

Создать напряжение в системе можно при помощи следующих методов:

- уменьшить доступную область памяти или дискового пространства;

- запустить параллельно несколько экземпляров приложения;

- очень быстро нажимать клавиши;

- выполнить огромное число повторений определенных действий или вводов;

- сгенерировать максимально возможное количество данных.

Реакция системы, в которой возникло экстремальное напряжение, может быть следующей:

- отличия не наблюдаемы;

- медленный ответ;

- выход системы из строя.[8]

8. Категория тестов «Тестирование характеристик»

Возможные вопросы:

- Как пользователь обычно взаимодействует с системой?

- Как долго может выполняться задача?

- С какой нагрузкой может справиться система?[8]

9. Категория тестов «Ошибки, описки и нарушение логики в сообщениях, выдаваемых программой»

Возможные вопросы:

- Содержат ли сообщения, которые выводит программа на действия пользователя, орфографические ошибки?

- Содержат ли эти сообщения описки?

- Правильно ли построено сообщение по смыслу?

В проекте «Библиотека» обнаружены следующие ошибки и описки:

- при успешной регистрации выдачи книги, приложение выводит сообщение: «Выдача успешно зарегестирована», где в слове «зарегистрирована» содержится две ошибки;

- при возникновении ошибки во время возврата книги программа выводит сообщение «Ошибка регустрации возвращенной книги. Возможно нет данных по этой книге». Здесь в слове регистрация содержится описка;

- сообщение «Данного читателя не существует или ему не разрешена выдача книг» использовать не логично, так как не понятно по какой причине невозможно выдать книгу;

- если при возврате книги введен номер книги, о которой нет информации в файле «readers.txt», то выводится сообщение «Ошибка регистрации возвращенной книги. Возможно нет данных по этой книге». Во втором предложении данного сообщения содержится пунктуационная ошибка. Однако это предложение вообще использовать не следует, так как данные по книге либо есть в файле «readers.txt», если книга зарегистрирована, либо нет, если книга не была добавлена. Поэтому предположение о существовании книги не уместны.

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

Создание тестовых примеров

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

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

Информацию о тестовых примерах занесем в таблицу, которую мы уже использовали в подразделе 2.2. В данную таблицу добавим только графу «Предыдущее состояние», в которой указывается предварительные условия для выполнения тестового примера. Такими условиями могут быть:

- запуск приложения;

- успешное прохождение другого теста.

Тестовые примеры для рассматриваемого проекта «Библиотека» представлены в таблице 2.3.

Таблица 2.3. Тестовые примеры для приложения «Библиотека».

ID тестового примера	Предыдущее состояние	Входные данные	Ожидаемые результаты	Реальные результаты
Т1	запущено приложение, текстовые файлы не созданы	Выход	выход из приложения	выход из приложения
Т2	запущено приложение, текстовые файлы не созданы	привет	сообщение 16	сообщение 16
Т3	запущено приложение, текстовые файлы не созданы	Добавить читателя	сообщение 16	сообщение 16
Т4	запущено приложение, текстовые файлы не созданы	добавить читателя	сообщение 1, создание текстового файла «readers.txt»	сообщение 1, создание текстового файла «readers.txt»
Т5	Т4	добавить читателя;Бомко;Анастасия;Михайловна;ж;Витебск;6791816	сообщение 2	сообщение 2
Т6	Т4	добавить читателя;Бомко;Анастасия;Михайловна;ж;Витебск;6791816	сообщение о попытке добавить уже зарегистрированного читателя	сообщение 2
Т7	Т4	добавить читателя; Бомко; Елена; Аркадьевна; ж; Витебск; 6791816	сообщение о некорректно введенных данных	сообщение 2
Т8	Т4	добавить читателя;4;6; 7;ж;Витебск;6791816	сообщение о некорректно введенных данных	сообщение 2
Т9	Т4	добавить читателя;Петров;Петр;Петрович;привет;Витебск;5555555	сообщение о некорректно введенных данных	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т10	Т4	добавить читателя;Бомко;Анастасия; Михайловна;жен;Витебск;6791816	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т11	Т4	добавить читателя;Красько;Юлия;Васильевна;женский;Витебск;6791816	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т12	Т4	добавить читателя;Петров;Петр;Петрович;м;Витебск;555555	сообщение 2 (при сохранении полю «пол» присвоено значение «м»)	сообщение 2 (при сохранении полю «пол» присвоено значение «м»)
Т13	Т4	добавить читателя;Петров;Максим;Петрович;муж;Витебск;555555	сообщение 2 (при сохранении полю «пол» присвоено значение «м»)	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т14	Т4	добавить читателя;Карпов;Петр;Петрович;мужской;Витебск;555555	сообщение 2 (при сохранении полю «пол» присвоено значение «м»)	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т15	Т4	добавить читателя;Петров;Иван;Иванович;м;666;776534	сообщение о некорректно введенных данных	сообщение 2
Т16	Т4	добавить читателя;Иванов;Иван;Иванович;м;Минск;привет	сообщение о некорректно введенных данных	сообщение 2
Т17	Т4	добавить читателя;Сидоров;Иван;Иванович;м;Минск;0776534	сообщение о некорректно введенных данных	сообщение 2
Т18	Т4	добавить читателя; ; ; ; ; ;	сообщение о некорректно введенных данных	сообщение 2
Т19	запущено приложение, текстовые файлы не созданы	Добавить книгу	сообщение 16	сообщение 16
Т20	запущено приложение, текстовые файлы не созданы	добавить книгу	сообщение 4	Сообщение 4
Т21	Т20	добавить книгу;Пушкин А.С.;Золотая рыбка;Сказка	сообщение 5, создание текстового файла «books.txt»,	сообщение 5, создание текстового файла «books.txt»,
Т22	запущено приложение, создан текстовый файл «readers.txt»	добавить книгу;Пушкин А.С.;Золотая рыбка;Сказка	сообщение 5	сообщение 5
Т23	Т22	добавить книгу;Лермонтов М.Ю.;Стихи;Стихи	сообщение 5	сообщение 5
Т24	Т22	добавить книгу; Булгаков М.А; Мастер и Маргарита; Фантастика	сообщение о некорректно введенных данных	сообщение 5
Т25	Т22	добавить книгу;Пушкин А.С.;Капитанская дочка;12345	сообщение о некорректно введенных данных	сообщение 5
Т26	Т22	добавить книгу; ; ;	сообщение о некорректно введенных данных	сообщение 5
Т27	запущено приложение, текстовые файлы не созданы	Выдать книгу	сообщение 16	сообщение 16
Т28	запущено приложение, текстовые файлы не созданы	выдать книгу	сообщение 7	сообщение 7
Т29	Т28	выдать книгу;1;1;31.12.2010	сообщение о том, что в базе нет информации о читателях	сообщение 11
Т30	запущено приложение, создан текстовый файл «readers.txt»	выдать книгу;1;1;31.12.2010	сообщение о том, что в базе нет информации о книгах	сообщение 10
Т31	запущено приложение, созданы текстовые файлы «readers.txt» и «books.txt»	выдать книгу;1;1;31.12.2010	сообщение 8, создание текстового файла «abonement.txt»	сообщение 8, создание текстового файла «abonement.txt»
Т32	Т31	выдать книгу;1;2;31.12.2010	сообщение 11	сообщение 8
Т33	Т31	выдать книгу;88;3;30.12.2010	сообщение 11	сообщение 11
Т34	Т31	выдать книгу;привет;6;30.12.2010	сообщение о некорректно введенных данных	сообщение 11
Т35	Т31	выдать книгу;2;привет;30.12.2010	сообщение о некорректно введенных данных	сообщение 11
Т36	Т31	выдать книгу;2;1;30.12.2010	сообщение 10	сообщение 10
Т37	Т31	выдать книгу;2;88;30.12.2010	сообщение о том, что данная книга не зарегистрирована	сообщение 10
Т38	Т31	выдать книгу;2;3;30.12.1901	сообщение 9	выход из приложения
Т39	Т31	выдать книгу;2;3;10.10.2001	сообщение 9	сообщение 8
Т40	Т31	выдать книгу;3;4;10\01\2011	сообщение 9	сообщение 9
Т41	Т31	выдать книгу;3;4;010.010.02011	сообщение 9	сообщение 8 (при сохранении формат даты стал стандартным)
Т41	Т31	выдать книгу;4;5;43.56.2010	сообщение 9	сообщение 8 (при сохранении полю «Дата возврата» присвоено значение 12.09.2014
Т42	Т28	выдать книгу;5;6;привет	сообщение 9	сообщение 9
Т44	запущено приложение, текстовые файлы не созданы	Вернуть книгу	сообщение 16	сообщение 16
Т45	запущено приложение, текстовые файлы не созданы	вернуть книгу	сообщение 13	сообщение 13
Т46	Т45	вернуть книгу;1	сообщение 15	сообщение 15
Т47	запущено приложение, создан текстовый файл «readers.txt»	вернуть книгу;1	сообщение 15	сообщение 15
Т47	запущено приложение, создан текстовый файл «books.txt»	вернуть книгу;1	сообщение 15	сообщение 15
Т48	запущено приложение, созданы текстовые файлы «readers.txt» и «books.txt»	вернуть книгу;1	сообщение 15	сообщение 15
Т49	запущено приложение, создан текстовый файл «abonement.txt».	вернуть книгу;1	сообщение 15	выход из приложения
Т50	запущено приложение, созданы текстовые файлы «readers.txt», «books.txt», «abonement.txt»	вернуть книгу;1	сообщение 14	сообщение 14
Т51	запущено приложение, созданы текстовые файлы «readers.txt», «books.txt», «abonement.txt»	вернуть книгу;6	сообщение 15	сообщение 15
Т52	запущено приложение, созданы текстовые файлы «readers.txt», «books.txt», «abonement.txt»	вернуть книгу;88	сообщение 15	сообщение 15
Т53	запущено приложение, созданы текстовые файлы «readers.txt», «books.txt», «abonement.txt»	вернуть книгу;привет	сообщение 15	сообщение 15

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

• 3. Тестирование при разработке программного обеспечения

3.1 Модульное тестирование

Модульное тестирование (англ. unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы путём запуска тестов в искусственной среде.

Модуль - наименьший компонент, который можно скомпилировать, либо наименьший компонент, функциональность которого можно проверить.

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

С помощью модульного тестирования обычно тестируют низкоуровневые элементы кода, такие как методы и интерфейсы.

3.2 Цели создания тестов

Тесты предотвращают появление ошибок в новом коде

Тесты являются ранними клиентами кода и позволяют выявлять многие ошибки сразу.

Тесты заставляют разработчика идти мелкими шагами и более пристально уделять внимание коду, который он пишет. Если разработчик чрезмерно ускоряется - вероятность того, что тест провалится, резко увеличивается.

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

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

Поощрение изменений

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

Хорошо протестированный код легко переносит рефакторинг. Уверенность в том, что изменения не сломают существующую функциональность, придает уверенность разработчикам и увеличивает эффективность их работы. Если существующий код хорошо покрыт тестами, разработчики будут чувствовать себя намного свободнее при внесении архитектурных решений, которые призваны улучшить дизайн кода.

Улучшение дизайна кода

Тесты заставляет программиста делать код более приспособленным для тестирования. Например, делать классы менее связанными и легкими для использования. Сильно связанный код или код, который требует сложной инициализации, будет значительно труднее протестировать.

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

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

Цель модульного тестирования - получение работоспособного кода с наименьшими затратами.

3.3 JUNIT

Оболочки модульного тестирования - это программные средства для разработки модульных тестов, включая: построение, выполнение тестов и вывод результатов их прохождения. Первая оболочка модульного тестирования SUnit была создана Кентом Беком в 1999 году для языка Smalltalk. Позднее Эрик Гамма создал JUnit. Сейчас существует множество оболочек для модульного тестирования, которые известны как программные средства семейства XUnit. JUnit - эталонная реализация xUnit, JUnit - наиболее широко используемая и расширенная реализация оболочек модульного тестирования. JUnit реализован на языке Java и используется для тестирования Java кода.

JUnit позволяет вне класса создавать тесты, при выполнении которых произойдет корректное завершение программы в результате неправильной ее работы. Кроме того, будет создано сообщение о возникшей ошибке. Если же результат работы теста не выявит ошибок, то программа продолжит её выполнение.[9]

Разработка тестов с помощью JUnit

Разработаем тест с помощью JUnit для приложения «Определение типа треугольника».

Пример теста приведен в листинге 3.1.

Листинг 3.1 - Тест для равностороннего треугольника

@Test

public void sumTest(){

double a=3;

double b=3;

double c=3;

String expected = "Треугольник, со сторонами равными введенным числам, является РАВНОСТОРОННИМ";

String actual = S2;

org.junit.Assert.assertEquals(expected, actual);

Метод, предназначенный для функционирования в качестве теста, достаточно промаркировать новой аннотацией: @Test.

@Test - указывает JUnit, что public void метод, который промаркирован данной аннотацией, может быть запущен как тест. Перед выполнением теста JUnit создает новый объект класса, который содержит тест.

Проверки JUnit выглядят следующим образом:

- assertTrue(String message, Boolean test) - метод проверяет, является ли выражение test истинным;

- assertFalse(String message, Boolean test) - метод проверяет, является ли выражение test ложным. В качестве test может быть выражение типа actual | | expected;

- assertNull(String message, Object object) - метод проверяет является ли object null;

- assertNotNull(String message, Object object);

- assertEquals(String message, Object expected, Object actual) - метод сравнивает expected и actual, используя метод equals;

- assertSame(String message, Object expected, Object actual) - метод сравнивает expected и actual, используя оператор ==;

- assertNotSame(String message, Object expected, Object actual).[9]

Заключение

В результате проделанной работы были изучены основы тестирования программного обеспечения. При использовании литературы по данной теме были составлены методические материалы «Тестирование программного обеспечения» (Приложение Б, Приложение В). Используя полученные знания, были протестированы два приложения: «Определение типа треугольника» и «Библиотека». Однако в работе тестируются только настольных приложений ручным методом. В дальнейшем планируется изучить тестирование Web-приложений и освоить автоматический метод тестирование программного обеспечения.

Также в работе рассмотрено использование оболочки модульного тестирования JUnit для тестирования программного обеспечения при разработке.

Список использованных источников

1. Майерс, Г. Искусство тестирования программ/ Г. Майерс; Пер. с англ. под ред. Позина. - М.: Финансы и статистика, 1982. - 176 с.

2. Степанченко И.В. Методы тестирования программного обеспечения: Учеб. пособие / Степанченко И.В. - ВолгГТУ, Волгоград,2006. - 76 с.

3. Калбертсон, Р. Быстрое тестирование. / Р. Калбертсон, К. Браун, Г. Кобб. - М.: Издательский дом «Вильямс», 2003. - 374 с.

4. Синицын, С. В. Верификация программного обеспечения. / С.В. Синицин, Н.Ю. Налютин. - М.:2006. - 158 с.

5. Савин, Р. Тестирование дот ком или пособие по жесткому обращению с багами в интернет-стартапах / Р. Савин. - М.: Издательство «Дело», 2007. - 316 с.

6. Канер, С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / С. Канер, Дж. Фолк, Е. Кек Нгуен; Пер. с англ. - К.: Издательство «ДиаСофт», 2001. - 544 с.

7. Тамре, Л. Введение в тестирование программного обеспечения / Л. Тамре; Пер. с англ. М.: Издательский дом «Вильямс», 2003. 368 с.

Приложение

Процесс тестирования программного обеспечения можно отчасти назвать интуитивным, но в то же время в основе его лежит вполне систематизированный подход. Хорошо протестировать программу означает нечто гораздо более серьезное, чем просто "погонять" ее несколько минут, чтобы убедиться, что она работает. Эффективное тестирование требует тщательного анализа и строгого системного подхода.[1]

Тестирование программного обеспечения (software testing) - это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов. Несмотря на всю простоту этого определения, в нем содержатся пункты, которые требуют дальнейших пояснений. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование суть плановая, упорядоченная деятельность.[2]

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

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

- совокупность выполняемых вами действий,

- последовательность событий, которые должны произойти в результате этих действий.

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

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

Тесты могут объединяться в группы по функциональным признакам. Группа родственных тестов называется тестовым набором.

Для удобства выполнения тесты можно разбивать на тестовые случаи. Тестовый случай представляет собой совокупность входных данных теста, условий выполнения и ожидаемых результатов, которые разработаны для конкретной цели. Тестовый случай представляет наименьшую единицу тестирования, которую можно самостоятельно выполнить от начала до конца. Если некоторый тест требует выполнения пространной методики тестирования с множеством ожидаемых результатов, имеет смысл разбить такой тест на тестовые случаи. Однако при этом следует иметь в виду, что тестовый случай есть наименьший модуль тестирования, и что с каждым тестовым случаем должен быть связан, по меньшей мере, один ожидаемый результат.[3] Отношения, связывающие тестовые наборы, тесты и тестовые случаи, показаны на рисунке 1.



Рисунок 1. Архитектура тестов.

Хороший тест должен удовлетворять следующим критериям:

1. Существует обоснованная вероятность выявления тестом ошибки.

Целью тестирования является поиск ошибок. Поэтому, придумывая тестовые примеры, проанализируйте все возможные варианты сбоя программы или ее неправильного поведения. Если в программе может произойти определенная ошибка, подумайте, как ее поймать.

2. Набор тестов не должен быть избыточным.

Если два теста предназначены для выявления одной и той же ошибки, зачем выполнять их оба?

3. Тест должен быть наилучшим в своей категории.

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

4. Он не должен быть слишком простым или слишком сложным.

Объединив два теста в один, можно сэкономить время на их выполнении. Но не переусердствуйте - огромный и сложный тест трудно понять, трудно выполнить и долго создавать. Поэтому лучше всего придерживаться золотой середины, разрабатывая простые, но все же не совсем элементарные тестовые примеры. Кроме трудоемкости, у сложных тестов есть и более серьезный недостаток. Скомбинировав несколько неверных входных значений, нельзя сказать наверняка, как программа интерпретирует каждое из них. После первого же недопустимого значения поведение программы может выйти из-под контроля, например, она может просто отказаться принимать все остальные данные.[1]

Задание: На примере приложения «Определение типа треугольника» ознакомиться с процессом описания требований к приложению. Составить набор тестов для данного приложения.

Ход выполнения работы:

Предположим, что дана задача: определить тип треугольника, если три данных целых числа интерпретируются как длины сторон треугольника.

1. Определим входные и выходные данные.

Входные данные: три целых числа, которые интерпретируются как длины сторон треугольника.

Выходные данные - информация о том, является ли треугольник равнобедренным, равносторонним или неравносторонним; треугольник с введенными сторонами не может быть построен.

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

2. Проанализировав возможные ошибки, составим следующие тесты:

1. Тест, который представляет правильный неравносторонний треугольник. (Например, тесты, со значениями 1, 2, 3 и 2, 5, 10 неудачны, так как не существует треугольников, имеющих такие стороны.).

2. Тест, который представляет правильный равносторонний треугольник.

3. Тест, который представляет правильный равнобедренный треугольник. (Например, тесты со значениями 2, 2, 4 принимать в расчет не следует.)

4. Три теста, которые представляют правильные равнобедренные треугольники, полученные перестановкой двух равных сторон треугольника (например, 3, 3, 4; 3, 4, 3 и 4, 3, 3).

5. Тест, в котором длина одной из сторон треугольника принимает нулевое значение.

6. Тест, в котором длина одной из сторон треугольника принимает отрицательное значение.

7. Тест, включающий три положительных целых числа, сумма двух из которых равна третьему. Другими словами, если программа выдала сообщение о том, что числа 1, 2, 3 представляют собой стороны неравностороннего треугольника, то такая программа содержит ошибку.

8. Три теста с заданными значениями всех трех перестановок, в которых длина одной стороны равна сумме длин двух других сторон (например, 1, 2, 3; 1, 3, 2 и 3, 1, 2).

9. Тест из трех целых положительных чисел, таких, что сумма двух из них меньше третьего числа (т. е. 1, 2, 4 или 12, 15, 30).

10. Три теста из категории 9, в которых испытываются все три перестановки (например, 1, 2, 4; 1, 4, 2 и 4, 1, 2).

11. Тест, в котором все стороны треугольника имеют длину, равную нулю (т. е. 0, 0, 0).

12.Тест, содержащий нецелые значения.

Замечание: Для каждого теста необходимо заранее описать не только входные значения, но и выходные данные метода.

3. Для простоты просмотра результатов тестов будем использовать таблицу.

В таблице содержится следующая информация.

- ID тестового примера. Уникальный идентификационный номер тестового примера.

- Входные данные. Последовательность входных данных, которая вводится тестером.

- Ожидаемые результаты. Поведение системы, которое тестер ожидает увидеть.

- Реальные результаты. Место, куда тестер будет записывать неожиданные результаты, или где он будет делать отметку о том, что тест был пройден.

Результаты тестирования показаны в таблице 1.

Таблица 1. Набор тестов для приложения «Определение типа треугольника».

ID тестового примера	Входные данные	Ожидаемые результаты	Реальные результаты
	1 сторона	2 сторона	3 сторона
Т1	3	7	6	Сообщение, о том, что треугольник с введенными сторонами является неравносторонним
Т2	3	3	3	Сообщение, о том, что треугольник с введенными сторонами является равносторонним
Т3	6	6	3	Сообщение, о том, что треугольник с введенными сторонами является равнобедренным
Т4.1	3	3	4	Сообщение, о том, что треугольник с введенными сторонами является равнобедренным
Т4.2	3	4	3	Сообщение, о том, что треугольник с введенными сторонами является равнобедренным
Т4.3	4	3	3	Сообщение, о том, что треугольник с введенными сторонами является равнобедренным
Т5	0	3	4	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т6	-1	3	5	Сообщение, о том, что треугольник с отрицательными сторонами не может быть построен
Т7	1	2	3	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т8.1	1	3	2	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т8.2	2	1	3	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т8.3	3	2	1	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т9	1	2	4	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т10.1	4	2	1	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т10.2	1	4	2	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т10.3	4	1	2	Сообщение, о том, что треугольник с введенными сторонами не может быть построен
Т11	0	0	0	Сообщение, о том, что треугольник с отрицательными сторонами не может быть построен
Т12	4.6	2	3	Сообщение о том, что введено нецелое число

4.Разработать приложение «Определение типа треугольника».

5. Протестировать приложение «Определение типа треугольника». Результаты тестирования занести в таблицу 1. Если результаты, полученные в процессе тестирования приложения не соответствуют ожидаемым, то приложение не прошло тестирование и необходима его доработка.

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

Цель работы: Усовершенствовать навыки составления тестов.

Задание: 1. На основе требований к программному продукту составить наборы тестов для тестирования приложения, предложенного преподавателем.

2. В случае необходимости доработать требования к программному продукту.

Требования к приложению «Библиотека».

Приложение «Библиотека» может выполнять 9 команд. Все команды вводятся пользователем с клавиатуры.

1. При вводе команды «помощь» должен выдаваться полный список команд, используемых данной программой. Данная функция пока не разработана.

2. С помощью команды «выход» производиться выход из приложения.

3. В результате ввода команды «добавить читателя» должно выдаваться сообщение «Ошибка! Вводите данные по следующему образцу: добавить читателя; фамилия; имя; отчество; пол; адрес; телефон» (Сообщение 1). То есть чтобы добавить читателя пользователь должен ввести данные следующего формата: «добавить читателя; фамилия; имя; отчество; пол; адрес; телефон». При вводе данной команды читатель сохраняется в текстовом файле «readers.txt», ему присваивается уникальный идентификационный номер, а на экран выдается сообщение «Читатель сохранен под номером …» (Сообщение 2), где вместо точек ставится идентификатор читателя. Если введенную информацию не удается сохранить, то выводиться сообщение «Не удалось сохранить читателя» (Сообщение 3).

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

5. Команда «выдать книгу». Вывод сообщения «Ошибка! Вводите данные по следующему образцу: выдать книгу;номер читателя;номер книги;дата возврата» (Сообщение 7). Таким образом, для того чтобы зарегистрировать выдачу книги пользователю надо ввести команду формата: «выдать книгу;номер читателя;номер книги;дата возврата». Если выдача осуществилась, то выдается сообщение «Выдача успешно зарегистрирована» (Сообщение 8) и информация сохраняется в файле «abonement.txt». В данную информацию входят: идентификатор выдачи, идентификатор читателя, идентификатор книги и период, на который выдана книга, где дата выдачи определяется по системным часам, а дата возврата вводится пользователем. При неверно введенной дате выводится сообщение «Неверно введена дата возврата» (Сообщение 9), если книга уже выдана - «Данная книга находится на руках» (Сообщение 10). Если читателя, которому хотят выдать книгу, нет в файле «readers.txt» или существующий читатель уже взял книгу, то при попытке выдать ему книгу выводится сообщение «Данного читателя не существует или ему не разрешена выдача книг» (Сообщение 11). Если регистрация выдачи книги не может осуществиться, то мы видим сообщение «Ошибка регистрации выдачи книги» (Сообщение 12).

6. Команда «вернуть книгу». При вводе видим сообщение «Ошибка! Вводите данные по следующему образцу вернуть книгу;номер книги» (Сообщение 13). Если данные введены согласно данному формату, то выводится «Возврат книги зарегистрирован» (Сообщение 14). Если же введен номер книги, о которой нет информации в файле «readers.txt», то выводится «Ошибка регистрации возвращенной книги. Возможно нет данных по этой книге» (Сообщение 15).

7. Команда «поиск читателя». Введя данную команду, пользователь увидит полный список зарегистрированных читателей. Если ввести команду вида «поиск читателя;фамилия читателя», то программа выдаст всю информацию о читателе с введенной фамилией. Еще один вариант поиска - «поиск читателя;идентификатор читателя». Выводит информацию о читателе, который имеет данный идентификатор.

8. Команда «поиск книги». При вводе данной команды выводится список не выданных книг библиотеки. Поиск может осуществлять по фамилии автора: «поиск книги;фамилия автора», и по идентификатору: «поиск книги;идентификатор». На экран выводится информация о книге, фамилию автора которой ввел пользователь, и о книге, имеющей введенный идентификатор соответственно.

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

10. Если пользователь ввел неподдерживаемую программой команду, то выдается сообщение «Неподдерживаемая команда» (Сообщение 16).

Ход выполнения работы:

1. Выделение требований.

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

Таблица 1. Описание приложения с разбиением на пункты.

Номер	Описание
Т1	Пользователь может посмотреть весь список команд
Т2	Выход из приложения осуществляется при вводе пользователем команды выхода
Т3	Пользователь может добавить читателя
Т4	Пользователь может добавить книгу
Т5	Пользователь может выдать книгу читателю
Т6	Пользователь может зарегистрировать возврат книги
Т7	Пользователь может посмотреть список зарегистрированных читателей
Т8	Пользователь может организовать поиск читателя по введенной фамилии
Т9	Пользователь может организовать поиск читателя по введенному идентификатору
Т10	Пользователь может посмотреть список зарегистрированных не выданных книг
Т11	Пользователь может организовать поиск книги по введенной фамилии автора
Т12	Пользователь может организовать поиск книги по введенному идентификатору

2. Категории тестов

Опытные тестеры в состоянии сразу же создать оригинальные тесты, так как они думают обо всех вариантах состояний ввода. Вытекающих из категорий тестов. Применение категорий тестов ко всем возможным входным условиям помогает определить тесты. Для каждой категории тестов тестер должен подумать над вопросом: «Каких результатов следует ожидать при данных условиях?» Конечно, не всякая категория применима в любых обстоятельствах.

Категории тестов, рассматриваемые при разработке тестовых примеров, включают следующие ситуации:

- нет данных;

- повторное выполнение;

- верные данные;

- неверные данные;

- сброс;

- потеря мощности;

- создание напряжений в системе;

- тестирование характеристик;[1]

- ошибки, описки и нарушения логики в сообщениях, выдаваемых программой.

1. Категория тестов «Нет данных».

Возможные вопросы:

- Как можно «подвесить» систему?

- Что случится, если не ввести данные?

- Что означает утаивание данных?

- Каково значение или состояние по умолчанию?

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

Хорошо, что требования определяют ожидаемые результирующие данные. Когда данные отсутствуют, система может повести себя следующим образом:

- отправить сообщение об ошибке;

- установить значение, заданное по умолчанию;

- повторно использовать предыдущие данные или состояние;

- напомнить пользователю об отсутствии данных;

- аннулировать транзакцию;

- прервать выполнение.[1]

В проекте «Библиотека», если пользователь нажал клавишу <ENTER> без введенных данных, приложение расценивает это как неподдерживаемую команду и выводит сообщение «Неподдерживаемая команда».

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

2. Категория тестов «Повторное выполнение»

Возможные вопросы:

- Что случится, если два раза подряд будут представлены одни и те же данные или же ввод будет сделан дважды?

- Что случится, если повторить предыдущее состояние?

В зависимости от типа приложения дублирование данных может означать повторное введение одних и тех же значений, двойное нажатие клавиши <ENTER> в одной строке, повторную отправку одного и того же пакета данных, запуск одной и той же команды (то есть любого действия, которое выполняется дважды).

Ожидается, что система может повести себя следующим образом:

- отправить сообщение об ошибке;

- перезаписать предыдущее значение или состояние;

- предложить пользователю подтвердить перезапись предыдущего значения или состояния;

- обработать второй запрос как отдельное независимое событие.[1]

В проекте «Библиотека» пользователь может добавлять читателя и книгу; однако в требованиях не указано, что случится, если информация о книге или читателе будет введена дважды.

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

3. Категория тестов «Верные данные»

Возможные вопросы:

- Что такое верные экземпляры этих данных?

- Каков диапазон верных значений входных данных?

- Каковы граничные значения данных?

- Каков формат верного пакета?

- Какая информация передается при верной транзакции?

Тестовый пример, построенный на основе верных данных, подтверждает, что приложение корректно обрабатывает информацию. Значения неверных данных попадают в категорию «Неверные данные».[1]

В проекте «Библиотека», если пользователь ввел верные данные при добавлении читателя, книги, при выдаче книги, то создаются текстовые документы «readers.txt», «books.txt», «abonement.txt» соответственно. Также из требований известен образец ввода данных, однако какие данные являются верными не указано. Таким образом, требования неполны. Возникают вопросы:

- Какой формат ввода поля «Пол» (м и ж или муж и жен или мужской и женский)?;

- Может ли поле «Автор» содержать числовые значения?;

- Какой формат ввода даты возврата?

При последующей доработке проекта следует в требования добавить уточнения по этим вопросам.

4. Категория тестов «Неверные данные»

Возможные вопросы:

- Что означает «выход за границы»?

- Каковы будут последствия?

- Что порождает неправильные данные в тестируемом приложении?

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

Примеры неверных данных для числовых полей могут быть следующие

- значения вне допустимого диапазона;

- отрицательные числа;

- десятичные дроби;

- на первой позиции - ноль или пробел;

- буквенно-цифровые сочетания знаков.

Примеры неверных данных для буквенно-числовых полей:

- на первой позиции - пробел;

- отличные от буквенно-цифровых знаки;

- нажатие специфических клавиш.

При неверных условиях система может вести себя следующим образом:

- отправить сообщение об ошибке;

- напомнить пользователь о корректных данных;

- повторно использовать предыдущее верное значение или состояние;

- отменить транзакцию;

- проигнорировать случившееся и попытаться обработать запрос как есть.[1]

В требованиях для рассматриваемого примера о неверных данных ничего не указано. Поэтому остаются без ответов следующие вопросы:

- Что случится, если пользователь введет не буквенные значения в поля «Фамилия», «Имя», «Отчество», «Жанр»?

- Что случится, если поле «Адрес» будет состоять только из числовых значений?

- Что случится, если в поля «Телефон», «Дата возврата», «Идентификатор» пользователь введет не числовые данные, отрицательные или дробные числа?

- Что случится, если пользователь введет в поле «Дата возврата» дату, которая была раньше «Даты выдачи»?

- Что случится, если при вводе значений в любое поле пользователь введет на первую позицию пробел, а для числовых - ноль?

- Что случится, если в поле «Пол», в которое предполагается вводить значения определенного формата, ввести что-либо отличное от данного формата?

- Что случится, если любое из полей будет пустым?

- Сколько читателей и книг можно добавить?

- Есть ли возможность удаления из файлов книг и читателе?

Для достижения должного уровня проекта в требования к данному приложению следует внести ответы на данные вопросы.

5. Категория тестов « Сброс»

Возможные вопросы:

- Что случится, если пользователь нажмет клавишу <ESCAPE> или другой тип клавиши с функцией «стоп»?

- Что случится, если пользователь активизирует последовательность сброса?

- Что случится, если обработка данных остановиться прежде, чем будет выполнена задача?

- Что случится, если будет выдернут кабель?

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

- Какие этапы необходимы для восстановления системы после её аварийного отключения?

- Останутся ли какие-либо файлы в открытом состоянии?

Восстановление системы может принимать различные формы, например:

- перезагрузка системы;

- повторная инициализация приложения;

- переустановка приложения.[1]

6. Категория тестов «»Потери мощности»

Возможные вопросы:

- Что случится, если в ходе обработки данных будет отключено питание или произойдет падение напряжения?

- Что случиться, если при запуске или восстановлении последовательности произойдет падение напряжения?

- Какие возможные сбои в аппаратном обеспечении?

Колебания напряжения и аварийные отключения - это реальность. Одни системы требовательны к качеству подаваемого напряжения, в то время как другие могут допускать его слабые колебания. В некоторые критичные системы встроены блоки резервного питания. Потери мощности могут быть также результатом сбоев в аппаратной части или е1 повреждений. Цель тестирования - определить, насколько хорошо система справляется с деструктивными действиями.[1]

7. Категория тестов «Создание напряжений в системе»

Возможные вопросы:

- Что означает для тестируемой системы «слишком много»?

- Как можно перегрузить систему?

- Что случится, когда другие процессы потребуют совместного использования одного и того же ресурса?

- Какие существуют ограничения на обработку данных и на ресурсы?

- Можно ли в фоновом режиме запускать одновременно и другие процессы?

Создать напряжение в системе можно при помощи следующих методов:

- уменьшить доступную область памяти или дискового пространства;

- запустить параллельно несколько экземпляров приложения;

- очень быстро нажимать клавиши;

- выполнить огромное число повторений определенных действий или вводов;

- сгенерировать максимально возможное количество данных.

Реакция системы, в которой возникло экстремальное напряжение, может быть следующей:

- отличия не наблюдаемы;

- медленный ответ;

- выход системы из строя.[1]

8. Категория тестов «Тестирование характеристик»

Возможные вопросы:

- Как пользователь обычно взаимодействует с системой?

- Как долго может выполняться задача?

- С какой нагрузкой может справиться система?[1]

9. Категория тестов «Ошибки, описки и нарушение логики в сообщениях, выдаваемых программой»

Возможные вопросы:

- Содержат ли сообщения, которые выводит программа на действия пользователя, орфографические ошибки?

- Содержат ли эти сообщения описки?

- Правильно ли построено сообщение по смыслу?

В проекте «Библиотека» обнаружены следующие ошибки и описки:

- при успешной регистрации выдачи книги, приложение выводит сообщение: «Выдача успешно зарегестирована», где в слове «зарегистрирована» содержится две ошибки;

- при возникновении ошибки во время возврата книги программа выводит сообщение «Ошибка регустрации возвращенной книги. Возможно нет данных по этой книге». Здесь в слове регистрация содержится описка;

- сообщение «Данного читателя не существует или ему не разрешена выдача книг» использовать не логично, так как не понятно по какой причине невозможно выдать книгу;

- если при возврате книги введен номер книги, о которой нет информации в файле «readers.txt», то выводится сообщение «Ошибка регистрации возвращенной книги. Возможно нет данных по этой книге». Во втором предложении данного сообщения содержится пунктуационная ошибка. Однако это предложение вообще использовать не следует, так как данные по книге либо есть в файле «readers.txt», если книга зарегистрирована, либо нет, если книга не была добавлена. Поэтому предположение о существовании книги не уместны.

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

3. Создание тестовых примеров

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

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

Информацию о тестовых примерах занесем в таблицу, которая уже использовалась в лабораторной работе №1. В данную таблицу добавим только графу «Предыдущее состояние», в которой указывается предварительные условия для выполнения тестового примера. Такими условиями могут быть:

- запуск приложения;

- успешное прохождение другого теста.

Тестовые примеры для команды «Добавить читателя» рассматриваемого проекта «Библиотека» представлены в таблице 2.

Таблица 2. Тестовые примеры для приложения «Библиотека»

ID тестового примера	Предыдущее состояние	Входные данные	Ожидаемые результаты	Реальные результаты
Т1	запущено приложение, текстовые файлы не созданы	Добавить читателя	сообщение 16	сообщение 16
Т2	запущено приложение, текстовые файлы не созданы	добавить читателя	сообщение 1, создание текстового файла «readers.txt»	сообщение 1, создание текстового файла «readers.txt»
Т3	Т2	добавить читателя;Бомко;Анастасия;Михайловна;ж;Витебск;6791816	сообщение 2	сообщение 2
Т4	Т2	добавить читателя;Бомко;Анастасия;Михайловна;ж;Витебск;6791816	сообщение о попытке добавить уже зарегистрированного читателя	сообщение 2
Т5	Т2	добавить читателя; Бомко; Елена; Аркадьевна; ж; Витебск; 6791816	сообщение о некорректно введенных данных	сообщение 2
Т6	Т2	добавить читателя;4;6; 7;ж;Витебск;6791816	сообщение о некорректно введенных данных	сообщение 2
Т7	Т2	добавить читателя;Петров;Петр;Петрович;привет;Витебск;5555555	сообщение о некорректно введенных данных	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т8	Т2	добавить читателя;Бомко;Анастасия; Михайловна;жен;Витебск;6791816	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т9	Т2	добавить читателя;Красько;Юлия;Васильевна;женский;Витебск;6791816	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)	сообщение 2 (при сохранении полю «пол» присвоено значение «ж»)
Т10	Т2	добавить читателя;Петров;Петр;Петрович;м;Витебск;555555	сообщение 2 (при сохранении полю «пол» присвоено значение «м»)

Подобные документы

• Автоматизация тестирования программных систем средствами Java технологий

  История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
  
  курсовая работа [309,5 K], добавлен 16.12.2015
  

• Тестирование программного обеспечения

  Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.
  
  курсовая работа [112,2 K], добавлен 22.03.2015
  

• Проектирование процесса тестирования программного обеспечения

  Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем.
  
  курсовая работа [3,0 M], добавлен 19.11.2009
  

• Тестирование программного обеспечения

  Тестирование как составляющая часть процесса отладки программного обеспечения, его роль для обеспечения качества продукта. Обнаружение ошибок в программах, выявление причин их возникновения. Подходы к формулированию критериев полноты тестирования.
  
  курсовая работа [1,6 M], добавлен 20.12.2012
  

• Тестирование программного обеспечения

  История возникновения тестирования программного обеспечения, основные цели и особенности его проведения. Виды и типы тестирования, уровни его автоматизации. Использование и исследование необходимых технологий. Полный цикл прогона всей системы мониторинга.
  
  дипломная работа [1,7 M], добавлен 03.05.2018
  

• Тестирование и отладка программного обеспечения

  Сущность тестирования и отладки, методика выявления ошибок в программном обеспечении. Практика отладки приложений в среде Delphi, системы управления версиями приложения и отслеживания ошибок. Применение точек остановки и модификация локальных переменных.
  
  курсовая работа [303,4 K], добавлен 19.01.2016
  

• Автоматизированая система тестирования знаний по программированию

  Выбор инструментальной среды разработки программного обеспечения системы. Алгоритм создания теста и ввода его исходных данных. Анализ экономической эффективности применения программного обеспечения "Тестирования знаний обучающихся программированию".
  
  дипломная работа [3,2 M], добавлен 11.09.2014
  

• Автоматизация тестирования программного обеспечения

  Комплексное функциональное и структурное тестирование программного продукта - граф-программа решения квадратного уравнения. Постановка задачи структурного тестирования маршрутов. Заключение о типе и причине ошибки, предложение по ее исправлению.
  
  курсовая работа [2,8 M], добавлен 05.01.2013
  

• Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО "КИЭП "Энергомера"

  Проектирование базы данных, информационной подсистемы PLC-Tester, модуля тестирования и web-приложения. Разработка логической структуры программного продукта и общие требования к техническому обеспечению. Запуск программы и описание тестовых прогонов.
  
  дипломная работа [3,2 M], добавлен 30.06.2011
  

• Тест: Правила дорожного движения

  Описание исходных текстов программного продукта. Системные требования и установка программного продукта. Тестирование пользователя по двадцати вопросам указанной темы и сохранение результатов тестирования. Форма отображения результатов тестирования.
  
  курсовая работа [2,8 M], добавлен 09.07.2013
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам