100+ ВИДОВ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ – ПОЛНЫЙ СПИСОК

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

100+ ВИДОВ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ – ПОЛНЫЙ СПИСОК

Окончательный список из 100+ типов тестирования программного обеспечения

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

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

Полный список типов тестирования:

Давайте рассмотрим различные типы тестирования один за другим.

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

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

< сильный>3. Ручное тестирование: ручное тестирование — это процесс тестирования программного обеспечения вручную для поиска дефектов. Тестировщик должен иметь точку зрения конечного пользователя и убедиться, что все функции работают, как указано в документе с требованиями. В этом процессе тестировщики выполняют тестовые случаи и создают отчеты вручную без использования каких-либо инструментов автоматизации.

4. Автоматическое тестирование: Автоматизированное тестирование — это процесс тестирования программного обеспечения с использованием инструмента автоматизации для поиска дефектов. В этом процессе выполнение тестовых сценариев и генерация результатов выполняются автоматически средствами автоматизации. Наиболее популярными инструментами для автоматического тестирования являются HP QTP/UFT, Selenium WebDriver и т. д.

Узнайте, в чем разница между ручным и автоматическим тестированием, здесь…

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

Подробнее о тестировании черного ящика читайте здесь…

6 . Тестирование в стеклянном ящике. Тестирование в стеклянном ящике — это методология тестирования, которая сканирует структуру программы, а затем создает тестовые данные на основе потока и логики программы. Этот тип тестирования в основном выполняется с использованием внутренней логики программирования для выбора правильных тестовых данных и устранения ошибок проектирования.

Тестирование стеклянного ящика называется тестированием открытого ящика, тестированием, управляемым логикой, тестированием, управляемым путем, или тестированием ясного ящика. К методам тестирования стеклянного ящика относятся покрытие путей, покрытие ветвей и покрытие операторов.

7. Тестирование белого ящика: Тестирование «белого ящика» также называют «стеклянным ящиком», «прозрачным ящиком» и структурным тестированием. Он основан на структуре внутреннего кода приложения. При тестировании методом белого ящика для разработки тестовых случаев используется внутренняя перспектива системы, а также навыки программирования. Это тестирование обычно проводилось на уровне подразделения.

Нажмите здесь, чтобы получить дополнительные сведения.

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

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

9. Структурное тестирование:

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

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

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

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

12. Тестирование компонентов: см. модульное тестирование

13. Модульное тестирование: см. Модульное тестирование

14. Интеграционное тестирование. Интеграционное тестирование — это процесс тестирования интерфейса между двумя программными модулями. Интеграционное тестирование выполняется с использованием нескольких подходов, таких как подход “большой взрыв”, подход “сверху вниз”, подход “снизу вверх” и подход гибридной интеграции.

Полное руководство по интеграционному тестированию

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

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

17. Быстрое интеграционное тестирование: однократное объединение всех модулей и проверка функциональности после завершения тестирования отдельных модулей.

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

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

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

20. Гибридное интеграционное тестирование: Гибридное интеграционное тестирование представляет собой комбинацию интеграционного тестирования “сверху вниз” и “снизу вверх”.

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

22. Бета-тестирование. Перед выпуском бета-тестирование проводится ограниченным числом конечных пользователей. Обычно это делается на месте клиента.

23. Гамма-тестирование: Гамма-тестирование проводится, когда программное обеспечение готово к выпуску с заданными требованиями. Делается на месте у клиента. Это делается напрямую, пропуская все внутренние действия по тестированию.

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

Подробнее о методике тестирования разделения на эквивалентность…

25. Тестирование анализа граничных значений: Анализ граничных значений (BVA) основан на проверке граничных значений допустимых и недопустимых разделов. Поведение на границе каждой секции эквивалентности с большей вероятностью будет неправильным, чем поведение внутри секции, поэтому границы — это область, где тестирование может привести к дефектам. Каждый раздел имеет свои максимальные и минимальные значения, и эти максимальные и минимальные значения являются граничными значениями раздела. Граничное значение для допустимого раздела является допустимым граничным значением. Точно так же граничное значение для недопустимого раздела является недопустимым граничным значением.

Подробнее о методике тестирования анализа граничных значений…

26. Тестирование таблиц решений: Таблица решений также известна как Таблица причинно-следственных связей. Этот метод тестирования подходит для функций, которые имеют логические отношения между входами (логика if-else). В методе таблицы решений мы имеем дело с комбинациями входных данных. Чтобы идентифицировать тестовые случаи с таблицей решений, мы рассматриваем условия и действия. Мы принимаем условия в качестве входных данных, а действия — в качестве выходных данных.

Подробнее о методе тестирования таблицы решений…

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

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

Подробнее о методе проектирования тестов перехода между состояниями…

29. Исчерпывающее тестирование: Тестирование всех функций с использованием всех допустимых и недопустимых входных данных и предварительных условий называется исчерпывающим тестированием.

30. Раннее тестирование. Дефекты, обнаруженные на ранних этапах SDLC, менее затратны для исправления. Таким образом, раннее тестирование снижает затраты на исправление дефектов.

31. Тестирование варианта использования: Тестирование варианта использования выполняется с помощью документа варианта использования. Это делается для определения тестовых сценариев для сквозного тестирования

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

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

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

35. Тестирование покрытия решений/тестирование покрытия ветвей. Тестирование покрытия решений или тестирование покрытия ветвей – это метод тестирования белого ящика, который проверяет выполнение каждой возможной ветви хотя бы один раз.

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

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

38. Тестирование циклов. Тестирование циклов — это метод тестирования “белого ящика”, который предназначен для проверки различных видов циклов, таких как простые циклы, вложенные циклы, конкатенированные циклы и неструктурированные циклы.

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

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

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

42. Soak-тестирование. Запуск системы под высокой нагрузкой в ​​течение длительного периода времени для выявления проблем с производительностью называется Soak-тестированием.

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

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

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

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

46. Объемное тестирование: проверка того, что система/приложение может обрабатывать большие объемы данных

47. Тестирование надежности. Тестирование надежности — это тип тестирования, который выполняется для проверки надежности приложения.

48. Тестирование уязвимостей. Тестирование уязвимостей – это процесс выявления уязвимостей или слабых мест в приложении.

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

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

<сильный>51. Повторное тестирование: чтобы убедиться, что дефекты, которые были обнаружены и опубликованы в более ранней сборке, были исправлены или нет в текущей сборке. Скажем, вышел билд 1.0. Группа тестирования обнаружила некоторые дефекты (идентификатор дефекта 1.0.1, 1.0.2) и опубликовала их. Вышел билд 1.1, сейчас проводится повторное тестирование дефектов 1.0.1 и 1.0.2 в этом билде.

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

53. Дымовое тестирование: Дымовое тестирование проводится, чтобы убедиться, что сборка, которую мы получили от команды разработчиков, пригодна для тестирования или нет. Это также называется проверкой «День 0». Это делается на уровне сборки. Это помогает не тратить время на тестирование всего приложения, когда основные функции не работают или ключевые ошибки еще не исправлены.

54. Тестирование работоспособности. Тестирование работоспособности проводится на этапе выпуска, чтобы проверить основные функции приложения, не углубляясь. Его также называют подмножеством регрессионного тестирования. Это делается на «уровне релиза». Иногда из-за ограничений по времени выпуска тщательное регрессионное тестирование не может быть выполнено для сборки, тестирование работоспособности выполняет эту часть, проверяя основные функции.

55. Динамическое тестирование: динамическое тестирование предполагает выполнение кода. Он проверяет вывод с ожидаемым результатом

56. Статическое тестирование. Статическое тестирование включает проверку документов для выявления дефектов на ранних стадиях SDLC.

57. Обезьянье тестирование: преднамеренное выполнение ненормальных действий с приложением, чтобы проверить его стабильность.

58. Горилла-тестирование: Горилла-тестирование проводится тестировщиками, иногда к ним присоединяются и разработчики. Это включает в себя многократное тестирование системы для проверки надежности системы.

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

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

61. Совместимость тестирование: развертывание и проверка того, работает ли приложение должным образом в другой комбинации компонентов среды.

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

63. Тестирование локализации. Локализация – это процесс адаптации программного обеспечения глобализации для определенного региона или языка путем добавления компонентов, специфичных для местных условий.

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

65. Тестирование интернационализации – см. Тестирование глобализации

66. Положительное тестирование: оно должно определить, что система должна делать. Это помогает проверить, соответствует ли приложение требованиям или нет.

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

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

Полное руководство по тестированию безопасности

69. Тестирование на проникновение. Тестирование на проникновение также известно как тестирование на проникновение. Это тип тестирования безопасности. Это выполняется для оценки безопасности системы.

Полное руководство по тестированию на проникновение

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

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

72. A/B-тестирование: обратитесь к сегментарному тестированию…

73. Сплит-тестирование. Обратитесь к групповому тестированию…

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

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

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

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

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

79. Тестирование API: API означает интерфейс прикладного программирования. Тестирование API — это тип тестирования программного обеспечения, который включает тестирование API с помощью некоторых инструментов, таких как SOAPUI, PostMan.

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

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

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

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

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

84. Тестирование установки: проверяется, успешно ли установлено приложение и работает ли оно должным образом после установки.

85. Формальное тестирование. Это процесс, при котором тестировщики проверяют приложение, используя заранее запланированные процедуры и соответствующую документацию.

86. Пилотное тестирование. Пилотное тестирование — это тестирование, которое компания проводит в режиме реального времени, чтобы завоевать доверие клиента

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

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

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

Подробнее о кроссбраузерном тестировании…< р>89. Тестирование совместимости браузера: Тестирование совместимости браузера является важной частью этапа тестирования. Это делается для проверки приложения в нескольких веб-браузерах. Для проведения этого тестирования должно быть выделено достаточно ресурсов.

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

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

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

92. Тестирование обратной совместимости: см. Тестирование обратной совместимости…

93. Тестирование на соответствие: тестирование на соответствие — это нефункциональное тестирование, которое проводится для проверки соответствия программного обеспечения определенному набору стандартов.

94. Тестирование на соответствие: Тестирование на соответствие – это метод тестирования, позволяющий проверить, соответствует ли продукт определенным стандартам перед его выпуском. Эти стандарты определяются такими организациями, как IEEE, для обеспечения соответствия программного обеспечения.

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

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

95. Тестирование пользовательского интерфейса: при тестировании пользовательского интерфейса тестировщики стремятся протестировать как графический интерфейс, так и интерфейсы командной строки (CLI)

Также см. Тестирование графического интерфейса пользователя…

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

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

98. Краудсорсинговое тестирование. Краудсорсинговое тестирование проводится сообществом опытных тестировщиков по обеспечению качества через онлайн-платформу.

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

100. Тестирование хранилища данных: см. Тестирование ETL…

101. Тестирование с внедрением ошибок. Тестирование с внедрением ошибок — это метод тестирования, при котором ошибка намеренно вносится в код для улучшения покрытия тестами.

102. Проверка отказоустойчивости: Отказоустойчивое тестирование — это метод тестирования, который проверяет способность системы выделять дополнительные ресурсы во время сбоя сервера и переноса части обработки на резервные системы

103. Все парное тестирование: Подход к полному парному тестированию заключается в тестировании приложения со всеми возможными комбинациями значений входных параметров.

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

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

Здесь я собираюсь сделать вывод о различных типах типов тестирования программного обеспечения. Если вам понравился этот пост, поделитесь им с друзьями.

Здесь я выбрал несколько постов, которые помогут вам узнать больше о собеседованиях:

  • Учебное пособие по ручному тестированию
  • Учебное пособие по Agile
  • Вопросы для собеседования по ручному тестированию
  • Вопросы для собеседования по Agile
  • Почему вы выбрали тестирование программного обеспечения в качестве карьеры
  • Общие вопросы для собеседования

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

TAG: qa

От QA genius

Adblock
detector