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

Размещено на http://www.allbest.ru/

Курсовая работа

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

Содержание

Введение

1. История развития и виды тестирования программного обеспечения

1.1 История развития тестирования программного обеспечения

1.2 Виды тестирования

1.2.1 Инсталляционное тестирование (installation testing)

1.2.2 Регрессионное тестирование (regression testing)

1.2.3 Тестирование новой функциональности (new feature testing)

1.2.4 Конфигурационное тестирование (configuration testing)

1.2.5 Тестирование совместимости (compatibility testing)

1.2.6 Тестирование удобства эксплуатации (usability testing)

1.2.7 Интеграционное тестирование (integration testing)

1.2.8 Тестирование безопасности (security testing)

1.2.9 Тестирование интернационализации (internationalisation testing)

1.2.10 Локализационное тестирование (localisation testing)

1.2.11 Тестирование прототипа (prototype testing)

1.2.12 Тестирование производительности (performance testing), Нагрузочное тестирование (load testing), Стрессовое тестирование (stress testing)

1.2.13 Модульное (компонентное) тестирование (Unit testing)

2. JUnit (Модульное тестирование)

2.1 Описание

2.2 Аннотация @Test

2.3 Наиболее часто используемые методы

2.4 Фикстуры

2.5 Тестирование исключительных ситуаций

2.6 Ограничение по времени

2.7 Игнорирование тестов

3. Примеры

Заключение

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

Введение

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

Традиционные методы разработки тестов вручную уже не могут обеспечить качественное тестирование современных программных систем. Появляется все большее число методик автоматизации и инструментальных средств, направленных на повышение качества и сокращение затрат ресурсов на тестирование ПО. Недостаточно хорошо проведенное тестирование может нанести серьезный урон проекту в целом. Устранение ошибки на стадии сопровождения готового ПО обходится в среднем в 200 раз дороже, чем на стадии определения требований, а в результате позднего выявления ошибок общий бюджет проекта возрастает на 30-40%.

На данный момент существует довольно много видов тестирования. Основные из них будут рассмотрены в данной работе.

Объект исследования. Объектом исследования является модульное (Unit) тестирование на языке программирования Java с использованием библиотеки JUnit.

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

Задачей работы является описание создания тестовых классов на языке программирования Java.

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

1. История развития и виды тестирования программного обеспечения

1.1 История развития тестирования программного обеспечения

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

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

В начале 1970-х тестирование ПО обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы ПО». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности -- неэффективный метод тестирования ПО. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приемо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест -- это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой -- выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.

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

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

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

1.2 Виды тестирования

1.2.1 Инсталляционное тестирование (installation testing)

В процессе инсталляционного тестирования проверяется корректность установки и удаления программного продукта в среде, максимально приближенной к эксплутационной. Об этом аспекте корректной работы программного обеспечения очень часто просто забывают (и напрасно). Правильно выполненная установка программы -- необходимое условие её корректной дальнейшей работы. Проверка правильности установки должна быть обязательным элементом проекта по тестированию любого продукта. Если программу невозможно корректно установить, и при этом что-то не будет работать или будет работать неправильно, работа по тестированию самого программного тестирования бессмысленна. Почему? Потому что заказчику не нужен продукт, который даже невозможно установить. Если пользователь уже на этапе установки сталкивается с проблемами в разработанном программном продукте, что он подумает о самом программном продукте? Будет ли он связываться с такой фирмой-разработчиком?

1.2.2 Регрессионное тестирование (regression testing)

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

1.2.3 Тестирование новой функциональности (new feature testing)

В данном виде тестирования акцент делается на тестировании новой функциональности, появившейся в конкретном выпуске (build) программного продукта.

1.2.4 Конфигурационное тестирование (configuration testing)

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

1.2.5 Тестирование совместимости (compatibility testing)

Тестирование совместимости помогает убедиться в функциональных возможностях и надёжности работы продукта в поддерживаемых браузерах (если речь идет о Web-приложениях) и операционных системах. Также может проверяться работоспособность продукта при использовании различных аппаратных платформ.

1.2.6 Тестирование удобства эксплуатации (usability testing)

Тестирование интерфейса человек/машина производится в отношении таких моментов как внешний вид пользовательского интерфейса, удобство навигации (преимущественно для Web-сайтов). Практичность и удобство использования - очень важные характеристики программного продукта. Например, программа может вполне соответствовать всем предъявляемым к ней требованиям с точки зрения функциональности. Но функции реализованы неудобно: некоторые шаги приходится повторять много раз, тогда как по логике достаточно выполнить однажды; расположение элементов интерфейса нелогично, программа быстро вызывает утомление и т.д. Для выявления такого рода недочётов и применяют тесты на удобство использования. Часто эта группа тестов относится к категории некритичных, но когда речь идёт, например, о рыночном готовом продукте, пренебрегать удобством эксплуатации весьма опасно.

1.2.7 Интеграционное тестирование (integration testing)

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

1.2.8 Тестирование безопасности (security testing)

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

- первичное тестирование безопасности;

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

- полное тестирование приложения и сервера.

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

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

1.2.9 Тестирование интернационализации (internationalisation testing)

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

1.2.10 Локализационное тестирование (localisation testing)

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

Пункт меню: «Сделать под себя» («Customise»)

Огромная красная кнопка «ВСЁ!» («Finish»)

Пункт меню «Ясные печенья» («Clear cookies»)

1.2.11 Тестирование прототипа (prototype testing)

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

Тестирование прототипа охватывает следующие аспекты:

Структура приложения;

Формы;

Прототип бизнес-логики;

Логические связи между модулями;

Навигация;

Графический интерфейс пользователя.

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

1.2.12 Тестирование производительности (performance testing), Нагрузочное тестирование (load testing), Стрессовое тестирование (stress testing)

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

1.2.13 Модульное (компонентное) тестирование (Unit testing)

С термином Unit testing связана некоторая путаница. Во-первых, на русский его переводят и как «модульное тестирование», и как «компонентное тестирование». Во-вторых, под этим термином кроется два достаточно различных вида деятельности:

1. Если мы говорим и «компонентном тестировании» (здесь уместнее этот перевод) в общем смысле (в контексте «тестирования вообще»), мы имеем в виду тестирование отдельных частей приложения. Причём эти части могут быть достаточно крупными.

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

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

2. JUnit (Модульное тестирование)

2.1 Описание

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

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

Модульное тестирование или unit testing -- процесс проверки на корректность функционирования отдельных частей исходного кода программы путем запуска тестов в искусственной среде. Под частью кода в Java следует понимать исполняемый компонент. С помощью модульного тестирования обычно тестируют низкоуровневые элементы кода -- такие, как методы. JUnit позволяет вне исследуемого класса создавать тесты, при выполнении которых произойдет корректное завершение программы. Кроме основного положительного сценария может выполняться проверка работоспособности системы в альтернативных сценариях, например, при генерации методом исключения как реакция на ошибочные исходные данные.

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

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

JUnit 4 в отличие от JUnit 3 полностью построен на аннотациях.

Для использования технологии необходимо загрузить библиотеку JUnit с сервера junit.org и включить архив junit.jar в список библиотек приложения.

При включении модульного тестирования в проект:

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

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

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

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

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

-- снижается число новых ошибок при добавлении новой функциональности;

-- устаревшие тесты можно игнорировать;

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

-- каждому техническому требованию соответствует тест;

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

2.2 Аннотация @Test

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

Тестовый метод должен всегда объявляться как public void. Аннотация может использовать параметры:

expected -- определяет ожидаемый класс исключения;

timeout -- определяет время, превышение которого делает тест ошибочным.

2.3 Наиболее часто используемые методы

Метод assertEquals() проверяет на равенство значений expected и actual с возможной погрешностью delta. При выполнении заданных условий сообщает об успешном завершении, в противном случае -- об аварийном завершении теста. При аварийном завершении генерируется ошибка java.lang.AssertionError.

Все методы класса Assert в качестве возвращаемого значения имеют тип void.

Среди них можно выделить:

assertTrue(boolean condition)/assertFalse(boolean condition) -- проверяет на истину/ложь значение condition;

assertSame(Object expected, Object actual) -- проверяет, ссылаются ли ссылки на один и тот же объект;

assertNotSame(Object unexpected, Object actual) -- проверяет, ссылаются ли ссылки на различные объекты;

assertNull(Object object)/assertNotNull(Object object) -- проверяет, имеет или не имеет ссылка значение null;

assertThat(T actual, Matcher<T> matcher) -- проверяет выполнение условия;

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

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

В дополнение к классу Assert с его методами жесткой проверки прохождения теста разработан класс org.junit.Assume. Методы этого класса в случае невыполнения предполагаемого условия при работе теста сообщают только о том, что предположение не исполнилось, не генерируя при этом никаких ошибок. Методы класса предполагают, что:

assumeNoException(Throwable t) -- тестируемый метод завершится, не вызвав исключения;

assumeNotNull(Object…objects) -- передаваемый аргумент(ы) не является ссылкой на null;

assumeThat(T actual, Matcher<T> matcher) -- условие выполнится;

assumeTrue(boolean b) -- значение передаваемого аргумента истинно.

2.4 Фикстуры

Фикстура (Fixture) -- состояние среды тестирования, которое требуется для успешного выполнения тестового метода. Может быть представлено набором каких-либо объектов, состоянием базы данных, наличием определенных файлов, соединений и проч.

В версии JUnit 4 аннотации позволяют исполнять одну и ту же фикстуру для каждого теста или всего один раз для всего класса, или не исполнять ее совсем.

Предусмотрено четыре аннотации фикстур -- две для фикстур уровня класса и две для фикстур уровня метода.

-- @BeforeClass -- запускается только один раз при запуске теста.

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

-- @After -- запускается после каждого метода.

-- @AfterClass -- запускается после того, как отработали все тестовые методы.

Использование фикстур позволяет выделить этапы и точно определять моменты, например, создания/удаления объекта, инициализации необходимых ресурсов, очистки памяти и прочего.

2.5 Тестирование исключительных ситуаций

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

Аннотацию @Test при необходимости тестирования генерации конкретного исключения (например, деление на 0) следует использовать с параметром expected. Параметр предназначен для задания типа исключения, которое данный тест должен генерировать в процессе своего выполнения.

2.6 Ограничение по времени

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

2.7 Игнорирование тестов

При контроле корректности функционирования бизнес-логики приложений до появления JUnit 4 игнорирование неудачных, незавершенных или устаревших тестов представляло определенную проблему. Аннотация @Ignore заставляет инфраструктуру тестирования проигнорировать данный тестовый метод.

Аннотация предусматривает наличие комментария о причине игнорирования теста, полезного при следующем к нему обращении.

3. Примеры

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

Код программы:

package Clc;

public class Main {

public void main(String[] args){

this.mult(2, 5);

this.del(6, 3);

}

public int mult(int a, int b){

return a*b;

}

public double del(int a, int b){

return a/b;

}

}

Теперь рассмотрим код тестового класса:

package Clc;

import static org.junit.Assert.*;

import org.junit.Test;

public class MainTest {

@Test

public void testMult() {

Main c = new Main();

int prod = c.mult(3, 5);

assertEquals("Умножение выполнено неверно", prod, 16);

}

@Test

public void testDel() {

Main c = new Main();

assertEquals("Деление неверно",c.del(20, 2),11);

}

@Test

public void testDelEx() {

Main c = new Main();

try{

c.del(2, 0);

fail("Деление на 0");

}

catch(Exception e){

System.out.println("Попытка деления на 0");

}

}

@Test (expected = Exception.class)

public void testDelNol(){

new Main().del(3, 0);

}

}

Во-первых мы импортируем две библиотеки, которые нам понадобятся для выполнения тестов: org.junit.Assert.* и org.junit.Test. Это основные библиотеки для создания тестов в JUnit. В нашем случае работа ведётся на JUnit 4.11.

Методом assertEquals() тестового метода testMult() мы сравниваем действительное значение (то, которое получили в ходе выполнения метода mult() класса Main.java) с тем значением, которое нужно получить на выходе (в нашем случае значение заведомо ложное).

Методом testDel() делаем то же самое только для деления (тестируем метод del() класса Main.java).

Третий метод - testDelNol() как раз показывает тестирование исключений, когда программа каким-то образом может пропустить деление на ноль. После аннотации теста можно увидеть дополнительный параметр (expected = Exception.class. Он говорит о том, что мы заведомо ожидаем ошибку выполнения теста.

Тестировать исключения можно и другим способом, как показано в методе testDelEx(). Здесь уже кому как удобно.

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

Посмотрим на выполнение этого тестового класса:



Последние 2 теста выполнены успешно, так как на выходе мы получили ожидаемую ошибку.

Рассмотри второй пример. Здесь будет простое матричное умножение.

Вспомогательный класс заполнения матриц:

package matrix_m;

public class MMult {

int m,n;

public MMult(int columns, int rows){

m = columns;

n = rows;

matrix = new double [m][n];

}

double [][] matrix;

int rows(){

return n;

}

int column(){

return m;

}

double element (int column, int row){

return matrix[column][row];

}

public void update(int column, int row, double value){

matrix [column][row] = value;

}

double[] row(int index){

return matrix[index];

}

double[] column(int index){

double[] tmp = new double[this.n];

for (int i = 0; i < index; i++)

matrix[i][index] = tmp[i];

return tmp;

}

}

Основной класс:

package matrix_m;

import java.util.Scanner;

public class Main {

public Scanner in = new Scanner(System.in);

public int row1, col2, col, row;

public static void main(String[] args){

Main mmultiply = new Main();

MMult first = mmultiply.read();

MMult second = mmultiply.read();

MMult prod = mmultiply.prod(first, second);

if (prod == null)

System.out.println("Эти матрицы не могут быть перемножены");

else

mmultiply.print(prod);

}

MMult read(){

System.out.println("Введите размерность матрицы");

col = in.nextInt();

row = in.nextInt();

MMult mx = new MMult(col,row);

if(mx.m != 0 || mx.n != 0){

System.out.println("Введите элементы этого массива");

for (int i = 0; i < mx.column(); i++){

for (int j = 0; j < mx.rows(); j++){

double tmp = in.nextDouble();

mx.update(i, j, tmp);

}

}

}

else{

System.out.println("Введена нулевая размерность");

}

return mx;

}

public void print(MMult matrix){

for (int i = 0; i < matrix.column(); ++i, System.out.println())

for (int j = 0; j < matrix.rows(); ++j)

System.out.printf(" %10.4f", matrix.element(i, j));

}

MMult prod(MMult first, MMult second){

int col1 = first.column(), row2 = second.rows();

row1 = first.rows();

col2 = second.column();

MMult res = new MMult(first.column(),second.rows());

if(row1 == col2){

for (int i = 0; i < col1; i++)

for(int k = 0; k < row2; k++)

for (int j = 0; j < col2; j++)

res.update(i, k, res.element(i, k)+ first.element(i, j) * second.element(i, k));

return res;

}

else

return null;

}

}

Тестовый класс:

import static org.junit.Assert.*;

import org.junit.Test;

public class MainTest {

Main pr = new Main();

MMult first = pr.read();

MMult second = pr.read();

@Test

public void testMain() {

assertFalse("Матрицы не перемножены",pr.prod(first, second)== null);

}

@Test

public void testRead() {

assertTrue("Введено не числовое значение", pr.in.hasNextInt() == false);

if(pr.col == 0 || pr.row == 0){

fail("Введена нулевая размерность");

}

}

@Test

public void testProd() {

assertTrue("Колличество строк первой и столбцов второй матриц не совпадают", pr.row1 != pr.col2);

}

}

Здесь при тестировании мы проверяем были ли умножены матрицы, (testMain()), на введении нулевой размерности матрицы или не числового значения(testRead()), и на то, могут ли быть матрицы перемножены(testProd()).

Выполнение теста(для просмотра результата все значения были введены ложные):



Заключение

В результате проделанной работы были изучены основы тестирования программного обеспечения. Используя полученные знания, был написан программный комплекс. Особое внимание было уделено оболочке модульного тестирования JUnit для тестирования программного обеспечения при разработке. В дальнейшем планируется изучить тестирование Web-приложений.

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

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

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

3. Канер, С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / С. Канер, Дж. Фолк, Е. Кек

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

5. Петренко А., Бритвина Е., Грошев С., Монахов А. Тестирование на основе моделей // «Открытые системы», 2003.

6. Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. -М.: Изд-во Лори, 2003. 567 с.

7. Макгрегор Д., Сайке Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. К.: ООО «ТИД «ДС», 2002. - 432с.

Размещено на Allbest.ru