Файл: Отчет по практике студента Круглова Анастасия Александровна Курс 4.docx
Добавлен: 11.12.2023
Просмотров: 749
Скачиваний: 25
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Общая стратегия безопасности основывается на трех основных принципах:
-
Конфиденциальность. -
Целостность. -
Доступность.
Конфиденциальность - это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей или, другими словами, при каких условиях пользователь авторизован получить доступ к данному ресурсу.
Существует два основных критерия при определении понятия целостности:
-
Доверие. Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей. -
Повреждение и восстановление. В случае, когда данные повреждаются или неправильно меняются авторизованным или не авторизованным пользователем, Вы должны определить, на сколько важной является процедура восстановления данных. -
Доступность. Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть.
3. Тестирование взаимодействия или Interoperability Testing
Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).
Программное обеспечение с хорошими характеристиками взаимодействия может быть легко интегрировано с другими системами, не требуя каких-либо серьезных модификаций. В этом случае, количество изменений и время, требуемое на их выполнение, могут быть использованы для измерения возможности взаимодействия.
Нефункциональные виды тестирования[1]
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, как система работает.
1.Все виды тестирования производительности
Тестирование производительности (Performance testing).
Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:
Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.
Определение количества пользователей, одновременно работающих с приложением.
Определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций).
Исследование производительности на высоких, предельных, стрессовых нагрузках.
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить, насколько приложение и система в целом работоспособны в условиях стресса, а также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию, после прекращения воздействия стресса. Стрессом, в данном контексте, может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также, одной из задач при стрессовом тестировании может быть оценка деградации производительности. Таким образом, цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Объемное тестирование (Volume Testing)
Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:
Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.
Может производиться определение количества пользователей, одновременно работающих с приложением.
Тестирование стабильности или надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно, поэтому мы и не стали разделять их. В то же время кто-то может разделить. Главное все-таки понимать цели того или иного вида тестирования и постараться их достигнуть.
2. Тестирование установки (Installation Testing)
Тестирование установки направленно на проверку успешной инсталляции и настройки, а также на обновление или удаление программного обеспечения.
В настоящий момент, наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые сами по себе так же требуют надлежащего тестирования, описание которого рассмотрено в разделе "Особенности тестирования инсталляторов").
В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или "read me" файлов, шаг за шагом описывающих все необходимые действия и проверки.
В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого часто пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии (в случае неудачи). Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя - это потеря репутации и большого количества средств. Например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.
3. Тестирование удобства пользования (Usability Testing)
Иногда мы сталкиваемся с непонятными или нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того, чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. Значит, они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее, является неотъемлемой частью тестирования любых массовых продуктов.
Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
Производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д. (меньше - лучше).
Правильность (accuracy) - сколько ошибок сделал пользователь во время работы с приложением (меньше - лучше).
Активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).
Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше).
Виды тестирования связанные с изменениями.
После проведения необходимых изменений, таких как исправление дефектов, программное обеспечение должно быть протестировано заново, для подтверждения того факта, что проблема была решена.
Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:
-
Дымовое тестирование (Smoke Testing) -
Регрессионное тестирование (Regression Testing) -
Тестирование сборки (Build Verification Test) -
Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)
Дымовой тест (англ. Smoke testing или smoke test, дымовое тестирование) — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование.
Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода.
Тестирование сборки (Build Verification Test), как и дымное тестирование, направленно для предварительной проверки разрабатываемого программного продукта перед запуском полномасштабного тестирования по всем параметрам, проводимого командой тестировщиков. Проводится оно для того, чтобы знать – готов ли релиз для такого этапа разработки ПО, как Тестирование или же он еще нуждается в доработке.
Тестирование сборки состоит из набора коротких тестов, которые и определяют готовность сборки.
Основной задачей данного вида тестирования является экономия времени команды тестировщиков, в случае, если релиз имеет серьезные проблемы со своей готовностью к полному циклу тестирования.
Санитарное тестирование - это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.
Цель санитарного тестирования - проверить «рациональность» системы после изменений, чтобы продолжить более тщательное тестирование.
1.2.2 ВИДЫ ТЕСТИРОВАНИЯ ПО СТЕПЕНИ АВТОМАТИЗАЦИИ
При ручном тестировании (manualtesting) тестировщики вручную выполняют тесты, не используя никаких средств автоматизации. Ручное тестирование – самый низкоуровневый и простой тип тестирования, не требующих большого количества дополнительных знаний.
Тем не менее, перед тем как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость.
Мифы о ручном тестировании[2]:
– кто угодно может провести ручное тестирование.
Нет, выполнение любого вида тестирования требует специальных знаний и профессиональной подготовки.
– автоматизированное тестирование мощнее ручного.
Полная автоматизация невозможна. Необходимо использовать также и ручное тестирование.
– ручное тестирование – это просто.
Тестирование может быть очень непростым занятием. Проведение тестирования для проверки максимально возможного количества путей выполнения с использованием минимального числа тест-кейсов требует серьезных аналитических навыков.
Автоматизированное тестирование предполагает использование специального программного обеспечения (помимо тестируемого) для контроля выполнения тестов и сравнения ожидаемого фактического результата работы программы. Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия задачи.