Please enable JavaScript.

Coggle requires JavaScript to display documents.

Тестирование, :red_flag:Как regression, так и confirmation testing…

- - - - Спецификация и бизнес требования - являются входными данными.
        
        completeness (полнота) - насколько набор функций охватывает все задачи и цели пользователя
        
        correctness (корректность) - насколько система обеспечивает правильные результаты с необходимой степенью точности
        
        appropriateness (целесообразность) - насколько функция способствует выполнению нужд, задач и целей пользователя.
      - Цели тестирования
        
        тестирование основных функций приложения
        
        проверка доступности системы для пользователя
        
        тестирования для проверки ошибок (например, отображаются ли подходящие сообщения об ошибках)
        
        базовое тестирование системы на удобство использования
      - :red_flag: Функциональное тестирование проводится на всех уровнях тестирования, проверяет UI, API, базу данных, безопасность, связь клиент / сервер и другие функциональные возможности тестируемого приложения. Оно всегда выполняется первым (только после него идет нефункциональное), может проводиться вручную, или с использованием автоматизации. Функциональное тестирование основано на методе тестирования черным ящиком (данный метод описан в уроке "Методы тестирования") и не касается исходного кода приложения.
    - - Конфигурация - (Configuration testing) направлено на проверку работы ПО при различных конфигурациях системы (поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.). Частью Configuration testing является тестирование совместимости - Compatibility testing (некоторые авторы выделяют его в отдельный вид), которое проверяет насколько система умеет делиться своими ресурсами. Когда у нас в одной и той же программной среде живет наша система и еще какая-то и мы тестируем, насколько наша система может сосуществовать с другой системой. В Configuration testing также относим:
        
        тестирование кроссбраузерности (Cross browser testing) - проверку работы приложения в разных браузерах либо разных версиях одного браузера - может выделяться и как отдельный вид.
        
        тестирование кроссплатформенности (Cross platform testing) - проверку работы одного и того же приложения на разных операционных системах - также может выделяться и как самостоятельный вид.
      - Надежность - (Reliability testing) проверяет работоспособность ПО при длительном тестировании с ожидаемым уровнем нагрузки. Причем длительность его проведения не имеет первостепенного значения, основная задача – наблюдая за потреблением ресурсов, выявить утечки памяти и проследить чтобы скорость обработки данных и/или время отклика приложения в начале теста и с течением времени не уменьшалась. В противном случае вероятны сбои в работе продукта и перезагрузки системы.
      - Инсталляция - (Installation, Deployment testing) проверяет инсталляцию и настройку, а также установку, обновление, удаление ПО на всех заявленных платформах.
      - Безопасность - (Security testing) выявляет недостатки в механизмах безопасности продукта, которые защищают его данные и поддерживают его функциональность, показывает, насколько ПО уязвимо к различным атакам. Что обычно проверяют на безопасность: отображение важной информации в зашифрованном виде (пароли, cvv карты и т.д), наличие правил создания паролей при регистрации, невозможность зайти под старым паролем после смены пароля, сообщения об ошибках не содержат никакой секретной информации и др.
      - Отказоустойчивость - (Robustness testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью является проверка систем восстановления, которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта. Данный вид тестирования очень важен для систем, работающих по принципу “24x7”, например, банковское приложение, финансовые заявки, торговые платформы и т.д.
      - Тестирование производительности/нагрузочное (Performance/Load testing) заключается в тестировании различных показателей производительности системы путем моделирования различных нормальных условий нагрузки с помощью инструментов автоматического тестирования.
        
        время - насколько время отклика, обработки, производительности ситемы отвечает заявленным требованиям
        
        ресурсы - количестко и типы ресурсов, которые система реально использует для выполнения своих функций по сравнению с тем, что указано в требованиях (например, емкость диска, использование памяти и т.д.)
        
        емкость - насколько максимальные пределы какого-то определеннего параметра соответствуют заявленным требованиям. Этим параметром может быть, например, максимальное количество пользователей, максимальный объем данных обработки за секунду, максимальное количество транзакций в день и т.д.
        
        Load testing - нагрузочное тестирование - некоторыми авторами (Рекс Блэк "Ключевые процессы тестирования") выделяется в отдельный вид тестирования и фокусируется на способности системы справляться с возрастающим уровнем ожидаемой нагрузки.
      - Стресс тест - (Stress testing) основано на тех же характеристиках, что и Performance (время, ресурсы и емкость) и направлено на превышение ожидаемых нагрузок, поиск слабых мест системы. Оно используется для того, чтобы эту систему сломать и посмотреть, как она будет вести себя при пиковых и аномальных нагрузках, а также в процессе отказа тех или иных ее частей. Например, загрузить файл, размер которого сильно превышает указанный в требованиях, или проверить работу приложения, когда в нем запущено множество процессов. Так как данный вид тестирования оценивает надежность и устойчивость системы в условиях серьезного превышения пределов нормального функционирования, его особенно необходимо проводить для критически важного ПО.
      - Удобство пользования - (Usability testing) проверяет, удобно ли будет пользоваться тем функционалом, который есть в программе.
      - Соответствие требованиям законодательств (Compliance testing)
  - - - Ревью - проверка документации (любого рабочего продукта, который участники команды могут читать и понимать)
      - Статический анализ - оценка кода с помощью специальных инструментов (применяется к любому продукту с формальной структурой - код, какие-то модели).
- - - - Разбиение на эквивалентные классы – метод сокращения числа тестов путем выбора одного теста из эквивалентного набора. Весь объем тестовых данных разбивается на эквивалентные классы и для каждого эквивалентного класса пишется по одному–двум тест кейсам.
      - Анализ граничных значений – дополняет технику классов эквивалентности, проверяет значения на границах классов эквивалентности.
      - Доменный анализ – это тестирование множества параметров (доменов) одновременно.
      - Таблица принятия решений – представляет собой таблицу с набором условий, одновременное выполнение которых должно привести к определенному действию или решению.
      - Диаграмма состояний и переходов – тестирование всех возможных комбинации начальных и конечных состояний.
      - Попарное тестирование – тестирование всех возможных отдельных комбинаций каждой пары входных параметров.
      - Тестирование вариантов использования – проверка продукта по наиболее частым и важным сценариям использования – юз кейсам (use cases)
  - - - Тестирование потока управления (Control Flow Testing, CFT) – одна из техник тестирования белого ящика, основанная на определении путей (последовательностей) выполнения кода программного модуля, их анализа и создания тест кейсов для покрытия этих путей. Анализ потока управления означает алгоритм, который формирует граф потока управления – Control Flow Graph. Это графическое представление вычислений во время выполнения кода, состоящее из ребер (пути потока управления) и узлов (блоки входа и выхода). Через блок входа поток управления входит в граф, через блок выхода – уходит. уровни тестового покрытия:
        
        1) покрытие операторов, подразумевающее выполнение всех исполняемых операторов в исходном коде хотя бы один раз. В терминологии ISTQB оператор (statement) – это сущность языка программирования, минимальный неделимый исполняемый блок: if, for и switch. Процентное отношение операторов, исполняемых набором тестов, к их общему количеству является метрикой покрытия операторов. Покрытие операторов позволяет найти мертвый код, неиспользованные выражения и ветви, а также недостающие операторы;
        
        2) покрытие альтернатив – каждого узла с решениями (TRUE или FALSE на выходе), подразумевающее прохождение ветви хотя бы один раз. Под решением понимается программная точка, в которой control flow имеет два или более альтернативных маршрута (ветви). На этом уровне для покрытия по веткам достаточно два тестовых примера (на TRUE и на FALSE). Покрытие альтернатив не гарантирует покрытие всех путей, но при этом гарантирует покрытие всех операторов;
        
        3) покрытие условий, при котором каждое логическое выражение с операндами AND, OR, XOR должно выполняться хотя бы один раз. Для обеспечения полного покрытия каждая компонента логического условия в результате выполнения тестовых примеров должна принимать все возможные значения, но при этом не требуется, чтобы само логическое условие принимало все возможные значения;
        
        4) покрытие условий + альтернатив, при котором тест-кейсы создаются для каждого условия и для каждой альтернативы так чтобы и логическое условие и каждая его компонента приняли все возможные значения;
        
        5) комбинаторное (множественное) покрытие условий, при котором все возможные комбинации результатов условия в каждом решении должны выполнятся хотя бы один раз. Метод сложен и порой избыточен, поэтому редко применяется на практике;
        
        6) покрытие путей, подразумевающее прохождение каждого пути хотя бы один раз. Проверяется каждый линейно независимый путь в коде, т.е. количество тестов будет эквивалентно цикломатической сложности программы. Цикломатическая сложность программы — это количество линейно независимых маршрутов через программный код. Например, если код не содержит никаких точек ветвления или циклов, то сложность равна единице, т.к. есть только один-единственный маршрут через код. Если код имеет оператор if, содержащий простое условие, то существует два пути через код: один если условие верно (TRUE) и второй, если нет (FALSE).
        
        7) покрытие бесконечного числа путей, которое решается с помощью их сокращения и уменьшения количества тест кейсов разными способами:
        
        не выполнять цикл совсем;
        
        выполнить цикл один раз;
        
        выполнить цикл n раз, где n - это небольшое значение, представляющее символическое количество повторений цикла;
        
        выполнить цикл m раз, где m - максимальное количество повторений цикла. Кроме того, можно выполнить цикл m-1 и m+1 раз.
      - Тестирование потока данных (Data Flow Testing, DFT) – еще одна техника тестирования белого ящика, направленная на обнаружение неправильного использования значений данных, возникшего из-за ошибок в коде. Поток управления здесь анализируется с точки зрения жизненного цикла переменной и используется для поиска аномалий, которые могут случится с переменными.