Основы тестирования программного обеспечения - вопросы и ответы

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



Что такое тестирование программного обеспечения?

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

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

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


Проверка : Мы делаем правильную работу? Проверка : Правильно ли мы делаем работу?

Верификация - это проверка или тестирование элементов, включая программное обеспечение, на соответствие и согласованность со связанной спецификацией.


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

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



Что такое исследовательское тестирование и когда его следует проводить?

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

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


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

Исследовательское тестирование обычно проводится по мере развития продукта (гибкости) или в качестве окончательной проверки перед выпуском программного обеспечения. Это дополнительная деятельность к автоматическому регрессионному тестированию.



Какие существуют методы тестирования и какова их цель?

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

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


Зачем нужно тестирование?

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


Примеры могут быть:

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


В чем разница между ошибкой, дефектом, ошибкой, отказом, отказом и ошибкой?

Ошибка и ошибка - это одно и то же. Ошибка, Дефект и Неисправность - это одно и то же.

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

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




Насколько хватит тестирования?

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

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



Что такое фундаментальный процесс тестирования

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

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


Фундаментальный процесс тестирования включает пять действий:

  • Планирование
  • Технические характеристики
  • Исполнение
  • Запись
  • Проверка завершения теста

Процесс тестирования всегда начинается с планирования тестирования и заканчивается проверкой завершения теста.

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



Семь принципов тестирования программного обеспечения

Ниже приведены семь принципов тестирования программного обеспечения:

1. Тестирование показывает наличие ошибок

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

2. Исчерпывающее тестирование невозможно.

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

3. Раннее тестирование

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

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

4. Кластеризация дефектов

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

5. Парадокс пестицидов

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

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

6. Тестирование зависит от контекста.

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

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

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

7. Отсутствие ошибок заблуждение

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



Что такое тестирование белого ящика

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

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

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

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

Статический и динамический анализ

Статический анализ включает в себя просмотр кода для выявления возможных дефектов в коде. Динамический анализ включает выполнение кода и анализ вывода.

Покрытие заявления

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

Покрытие филиала

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

Тестирование безопасности

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

Мутационное тестирование

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

Преимущества тестирования белого ящика

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

Недостатки тестирования белого ящика

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



Что такое тестирование черного ящика

В Black Box Testing тестировщик тестирует приложение, не зная о внутренней работе тестируемого приложения.

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

Методика испытаний для анализа граничных значений

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

Техника перехода состояний

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

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

Методика проверки разделения на эквивалентность

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

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

Преимущества тестирования черного ящика

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

Недостатки тестирования черного ящика

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