Файл: Основы алгоритмизации и программирования.pdf

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

Тестирование перегрузок. Во время тестирования перегрузок системы определяются технические ограничения системы без учёта архитектуры. Эти испытания проводятся на пике обработки транзакций и при непрерывной загрузке больших объемов данных. Тестирование перегрузок просчитывает пропускную способность системы и ее эластичность на всех аппаратных платформах^[48]. Этот метод предполагает одновременное обращение со стороны многих пользователей к определенным функциям системы, а некоторые вводят значения вне нормального диапазона. Из системы требуется обработка огромных объемов данных или при выполнении большого количества функциональных запросов в течение короткого периода времени.

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

Тестирование удобства пользования. Тесты удобства^[50] направлены на подтверждение простоты применения системы и то, что пользовательский интерфейс выглядит очень привлекательно. Эти испытания учитывают человеческий фактор в системе. Тестировщик должен оценить приложение с точки зрения конечного пользователя.

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

Отладка программы в любом случае принимает во внимание и логическое решение доступной информации об ошибках. Большинство ошибок могут быть признаны по косвенным признакам путем тщательного анализа кода, результатов тестирования, без получения дополнительной информации. Поэтому используют различные методы (рис. 6)^[51]:

Рис. 6. Методы отладки программного обеспечения

Ручное тестирование;

Пролога;

Снижение;

Обратная трассировка.

Способ ручного тестирования.

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

Метод пролога.

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

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

Метод снижения^[53].

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

Метод обратной трассировки^[54].

Для небольших программ эффективный метод применения обратной трассировки. Нужно начинать с точки вывода неправильных результатов. Для этой точки является рабочей гипотеза, о значениях ключевых переменных, которые могли привести к имеющимся результатам. Кроме того, в происхождение этой гипотезы, вносятся предложения о значениях переменных в предыдущем пункте. Процесс^[55] продолжается до тех пор пока не находиться причина ошибки.

Вывод:

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

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

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

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

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

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

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

Методы тестирования на основе стратегии чёрного ящика: а) эквивалентное разбиение, б) анализ граничных значений, в) диаграммы причинно-следственных связей, г) система тестирования, д) функциональное тестирование, е) регрессионное тестирование, ж) тестирование безопасности, з) тестирование перегрузок, и) тестирование производительности, к) тестирование удобства пользования.

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

Заключение

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

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

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

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

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

Библиография

Тестирование и отладка программ для профессионалов будущих и настоящих [Электронный ресурс] / М. А. Плаксин. — 2-е изд. (эл.). — М. : БИНОМ. Лаборатория знаний, 2013. — 167 с.

Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем -СПб.:Питер, 2004.- 318 с.

Винниченко И. В. Автоматизация процессов тестирования. — СПб.: Питер, 2005. — 203 с.

Приложение