ฝัง
- เผยแพร่เมื่อ 25 เม.ย. 2018
- Разделы:
1. По знанию системы
2. По позитивности
3. По целям (объекту)
4. По исполнителям (субъекту)
5. По времени проведения
6. По степени автоматизации
7. По состоянию системы
8. По формальности
Это видеолекция для студентов моей школы тестирования - software-testing.ru/edu/1-sche...
Привет из 2021! Лучшее видео, что я нашел на данную тематику, просто, доступно, понятно!
Спасибо)
Май 2022, ничего не изменилось.
Всё ещё лучшее видео на эту тему.
Тысяча поцелуев автору и огромная благодарность
Классификация тестирования Варианты
1. По знанию системы
- Черный ящик
- Серый ящик
- Белый ящик
2. По позитивности
- Позитивный сценарий
- Негативный (пытаемся сломать)
3. По целям (объекту)
- Функциональное тестирование
- Нефункциональное тестирование:
- производительность (не падает ли при нагрузке, скорость сайта)
- безопасность (уязвимость)
- usability
- GUI (понятность/красота)
- локализация (языки)
- совместимость (версии ОС и устройств)
4. По исполнителям (субъекту)
- Альфа-тестирование, своя команда
- Бета-тестирование, пользователи (стоит их обучить нормально сообщать об ошибках, но у них разные устройства и это большее покрытие)"
5. По времени проведения
- Smoke / Sanity - основной функционал после сборки, что приложение готово для более основательного функционального тестирования
- Регрессионное тестирование - проверка всей системы, что ничего не сломалось, о чём не думали что взаимосвязано"
6. По степени автоматизации
- Ручное
- Автотест: пирамида UI, API, Unit
7. По состоянию системы
- Static - система не запущена: тестирование документации, ревью кода
- Dinamic - система запущена
8. По формальности
- По тестам, чётко по тест-кейсам и чек-листам
- Исследовательское, без тест-кейсам и чек-листам"
Спасибо, за видео. Самый лучший канал. Очень доходчиво объясняете без лишней воды.
Спасибо)
Уже в Вашем курсе нашёл bug 😊 , навязываете своё мнение, а не отстраняетесь от своего опыта, много инфы, смотрят простые пользователи.
Это не баг, это фича)
Время над Годным Контентом не властно !
окончив курсы по тестированию и изучив много контента по Классификации тестирования в недоумении: почему не нашёл Ваше видео раньше - сэкономил бы столько Времени!
Спасибо)
Как же все доступно 😊спасибо автор 💪
Не за что))
За вовку лайк однозначно 😁
Классная лекция, спасибо большое, Оля! Всё законспектировал и соотнёс с другими источниками)
Единственное что, совсем неясно, зачем нужен такой вид тестирования, как статическое/динамическое?
Ведь по сути он ничего не описывает уникального из тест-кейсов или тест-дизайна, а лишь характеризует состояние рабочей среды (или вид занятости тестировщика) на конкретный момент времени. То есть всё, что он описывает, уже было описано в других видах тестирования.
И с точки зрения продуктивности нам эта информация ни о чём дополнительно, сверх уже известного, не скажет.
Цель подобной градации у того, кто придумал этот пункт классификации, не ясна)
Ещё раз спасибо!
Спасибо за фидбек, очень приятно) Ну, классификацию не я придумывала, так что вопрос не ко мне. Но в целом это просто способ "рассортировать" свои знания и подумать, что можно посмотреть в статике, пока разработчик не сделал первый прототип, например
Ещё видео пожалуйста!!
Про (Agile,Scrum )
Таких пока не планирую)
Sanity & Smoke - это разные виды тестирования ;)
Да, есть небольшая разница. В этом видео она не озвучена, сделаю в статье))
В ISTQB это одно и то же
@@Covac_ не могу подтвердить или опровергнуть, не сдавала :)
В глоссарии ISTQB возле определения Sanity написано (смотри Smoke). На форумах только пишут что разные виды, не думаю что здесь стоит утверждать однозначно. Можно вообще обобщить и ляпнуть что это все мини или регрессионное тестирование))
@@kostiantynzozulia4705 вот такое есть определение разницы:
В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование - это одно и тоже. Мы же полагаем, что эти виды тестирования имеют "вектора движения", направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.
От себя - то есть "дым" покрывает бОльшую площадь за минимальное количество времени, т.к. важна эффективность и скорость работы перед запуском масштабного регресса. А санитарное тестирует глубину функционала конкретной функции (старой, новой или их взаимодействия) в отрыве от остальных факторов. И тоже перед регрессом.
На сколько я помню серый ящик предусматривает собой работу с базой данных, но не с кодом 6:46 (если это не так поправьте меня)
Это смотря чью классификацию читать)
А блэк-бокс не метод. И не техника. :)
И не важно, видим ли мы то, что под капотом, или нет.
Серый ящик логичен, если утверждать, что боксы - стратегии. Но это и не стратегии.
Что будем делать с этими утверждениями? Как оценить их верность или ошибочность?
Ну, вы предлагаете свою версию "это не метод и не техника", вам и обосновывать верность или ошибочность :)
Ок, предлагается вообразить ПО в виде ящика с чёрными (непрозрачными) стенками -- примером будет любая кофемашина. Мы знаем, что внутри этого ящика что-то есть и оно там как-то работает, а мы лишь взаимодействуем с этим СНАРУЖИ, подавая ему команды (нажимая кнопки) и получая ожидаемый результат (кофе). Это всё, говорим мы, называется "тестирование методом чёрного ящика". А вот если мы ещё и будем знать, что именно происходит внутри, тогда наше занятие надо называть "тестирование методом белого ящика", по аналогии с тем, что через прозрачные (стеклянные) стенки ящика хорошо видно и понятно, что происходит внутри.
Продолжим этот прекрасный пример и возьмём обыкновенные ручные часы, откроем их крышку и посмотрим на мешанину их внутренних шестерёнок. Сильно оно вам поможет правильно выставлять время на этих часах?
Дальше полагается уточнить, что только обычно внутренности ящика (код программы) могут видеть только программисты, а поскольку мы, тестировщики, код не видим, следовательно -- мы же не программисты.
Но эти "Ящики" были придуманы древними программистами, которые и тестировали, и в код смотрели, и всё там понимали. Люди, которые всё-таки смотрят в код, и даже понимают его, знают, что есть множество ситуаций, в которых понятно/неизвестно, как поведёт себя программа. Не всё зависит от кода, есть и нюансы окружения, в котором работает программа, и внешние воздействия, и даже если всё внутри -- могут состыковаться какие-то несогласованные операции из разных мест кода. И даже если они будут продуманные и согласованные, не факт, что всё будет хорошо.
Glenford J. Myers заявил в своей книге (1979, John Wiley & Sons, Inc., два раза на русский язык переводилась в СССР) о том, что 'White/Black Box Testing' is a strategy.
Что такое стратегия?
Страте́гия (др.-греч. στρατηγία - искусство полководца) - наука о войне, в частности наука полководца, общий, недетализированный план военной деятельности, охватывающий длительный период времени, способ достижения сложной цели, позднее вообще какой-либо деятельности человека.
Задачей стратегии является эффективное использование наличных ресурсов для достижения основной цели (стратегия как способ действий становится особо необходимой в ситуации, когда для прямого достижения основной цели недостаточно наличных ресурсов).
Точно "черный ящик" - стратегия? Не смотреть в код - это общий, недетализированный план [не военной] деятельности как способ достижения цели?
Другие говорят, что это метод (+ далее методика). Ок. Что такое метод?
Ме́тод (от др.-греч. μέθοδος - путь исследования или познания, от μετά- + ὁδός «путь») - осознание формы внутреннего саморазвития содержания изучаемого предмета. Оно же -- Единый обобщённый способ решения задач определённого класса.
Это больше похоже на правду, продолжим копать в эту сторону и переведём это на внятный [русский] логичный язык: Тестирование единым обобщённым способом решения задач определённого класса, и имя этому единому способу -- "черный ящик". Смотрится логично, можно принять за правду (то есть, условно метод, и однозначно не стратегия). Можно настаивать на том, что "черный ящик" -- способ решения задач без ныряния в код.
Но (еще раз) эти "Ящики" были придуманы программистами, которые в код смотрели, и всё равно назвали это "черным ящиком". Программисты древние работали так, как об этом всём рассказывал Майерс (но для этого надо все его листинги псевдокода читать) и Бейзер (тоже очень сложно одолеваем без предварительной подготовки в Computer science) - сперва продумывали алгоритм карандашом на бумаге, затем его тестировали - тоже карандашом на бумаге, затем уже писали итоговый, продуманный и протестированный код. Тестировать в таком контексте можно много чего, но в воображении. И первое, с чего всё начнётся - входные данные. Можно учесть всё, от их типов до результатов их обработки в каждом отдельном случае. И очень часто будет неизвестно, как оно будет работать.
В этом контексте "черный ящик" - не метод, бо он не тянет за собой определённые шаги/действия, которые надо выполнить для получения результата. Это метафора, которая описывает состояние "можно что-то сделать, но хз, что получится".
Я неоднократно проверял эту теорию на живых людях. Когда человеку предлагается тестировать что-то, что ему уже знакомо, он начинает это "покрывать тестами", даже не вникая, как устроен предлагаемый объект. Если предлагается тестировать что-то, что уже вроде бы знакомо, но непонятно, как и почему работает -- весь "чёрный ящик" резко заканчивается, информации нет, предположений нет, результата нет - пример th-cam.com/video/z573ocyltSk/w-d-xo.htmlm41s
Да, тут согласна, чтение кода не всегда помогает понять, "как правильно выставить время" :)
санити это не смоук
Да, разница есть, хотя их иногда и подразумевают друг под другом