Transcription
Привет. Меня зовут Артём, и сегодня мы с вами поговорим о таком немаловажном аспекте в тестировании, как техники тест-дизайна. Рассмотрим, что это такое, для чего они нужны, какие есть виды, а также разберём на практике некоторые из них.
Давайте не будем долго затягивать и перейдём сразу на доску. Как видим, перед нами есть некая диаграмма, на которой я расписал наиболее популярные и наиболее часто встречающиеся в работе техники тест-дизайна. Сначала определимся, что это вообще такое. Ну, как следует из названия, это техники, которые позволяют нам покрыть максимальным количеством тестов нашу функциональность, при этом потратив на это минимальное количество времени и сил.
Начнём, я думаю, с вот этого. А это исчерпывающее тестирование. Оно обозначено красным и не просто так. Вообще исчерпывающее тестирование - это скорее набор методов и техник тестдизайна, который гласит нам о том, что нам нужно протестировать наше приложение от и до полностью, да? То есть пройдя все сценарии, все возможные виды страниц и так далее. Но, как мы знаем, из одного из принципов тестирования у нас следует следующее, что исчерпающее тестирование в принципе невозможно. То есть эта техника, она скорее такая абстрактная, и о ней нужно просто помнить и всё. На практике вы никогда её не примените нигде и никак.
Перейдём к чему-нибудь более реальному. Это эквивалентное разбиение. Вообще эквивалентное разбиение такая техника, которая позволяет нам, к примеру, когда у нас есть какой-то набор значений, разбить этот набор значений на некие классы и тестировать не все значения из этого диапазона, а только какие-то выборочные единичные случаи из наших классов.
Давайте нагляднее посмотрим это на примере. У нас есть некоторая вот такая задачка, в которой написано, что есть числовое поле возраст. И есть критерии, что если возраст меньше 18, то регистрация не проходит. Если возраст 18 тире 60 лет, то регистрация проходит. И если возраст больше 60 лет, то регистрация также не проходит. Начнём. Что нам нужно сделать? Нам нужно определить наши классы. Ну, здесь они наглядно видны. За нас это уже сделали. У нас есть, э, первый класс. это до 18 лет. Второй класс - это от 18 до 60 и третий 60 и больше. Нам нужно взять значение из каждого из этих диапазонов. Что мы сделаем? Возьмём из первого, ну, к примеру, 14. Далее возьмём, к примеру, 42. И далее возьмём, к примеру, ну, 87, да? Итак, мы определили три значения, которые мы будем тестировать. Как нам это помогло? Если бы мы делали полное тестирование, мы бы проходились по каждому значению отдельно. То есть вводили бы сначала ноль, потом один, потом 2, потом 3, потом четыре и так далее. А так мы сократили наше количество проверок до трёх. То есть мы просто проверяем 14 и предполагаем, что у нас в первом классе остальные значения ведут себя точно так же. Ну и, соответственно, точно так же во втором и в третьих классах. В принципе, в этом вся суть этой технике.
Дальше у нас идёт анализ граничных значений. Стоит заметить, что он зачастую используется в совокупности с эквивалентным разбиением. Давайте посмотрим, что это такое. Ну, в целом вернёмся к нашей предыдущей задачке. Мы помним, что у нас есть некоторые классы, а есть ещё и границы этих классов. Граница первого и второго класса находится на числе 18. Граница между вторым и третьим на числе 60. Что мы делаем? Мы берём значение чётко на этих границах. Первое - это 18. Но нам нужно проверить помимо этого ещё и ближайшие к нему значения. Давайте возьмём, то есть, соответственно, 17 и справа возьмём 19. В этом случае мы проверяем, когда сначала число 18, мы предполагаем, что это число будет относиться уже ко второму классу, и у нас регистрация пройдёт. А вот 17 не должно, а 19 уже должно. И таким образом мы расписываем и для второй границы между вторым и третьим классом. То есть берём значение 59, далее берём значение 60 и берём значение 61. Таким образом, мы определили девять тестовых значений, которые мы будем проверять. И это нам позволит максимально эффективно проверить всю нашу функциональность, а не перебирать каждое значение отдельно и смотреть на результат.
В принципе, это всё. Давайте перейдём к следующей технике. Это исследовательское тестирование. Что оно вообще означает? Это когда вы без какого-то чёткого плана, без заранее подготовленных каких-то тестовых данных просто заходите в приложение, ставите себя на место пользователя и начинаете лазить по всем его разделам. При этом помню, что вы как бы тестировщик и обращаете внимание на какие-то технические моменты. Вот в целом это как бы вся суть.
Далее, предугадывание ошибок. Эта техника используется тогда, когда вы уже, ну, довольно давно работаете на проекте, да, знакомы с ним уже, и вы можете предположить, что в каком-то месте может произойти какая-то ошибка, которую, допустим, вы уже встречали. Ну, как пример, допустим, у вас есть, э, какая-то ручка, да, а, которая вызывается в одной части приложения. И вот написали вторую часть приложения, мм, и там тоже будет использоваться эта ручка. А, предположим, что когда вы тестировали то первое место, где использовалась эта ручка, там вы находили ошибку. Допустим, сервер возвращал какие-то неправильные данные, и вы уже в этой второй задаче можете предположить, что эта ручка будет возвращать какие-то некорректные значения. Вот в целом вот так и работает техника.
Далее, попарное тестирование. Здесь уже более интересно. Давайте перейдём также к примеру. Эта техника необходима тогда, когда у нас есть большое количество параметров. Эти параметры принимают, ну, какое-то большое количество значений. То есть, если мы будем проверять абсолютно все тестовые случаи, да, уникальные, мы просто сойдём с ума. А, но чтобы это сделать эффективно, мы можем применить технику попарного тестирования и сформировать какой-то свой, а, соответственно, свою таблицу проверок.
Давайте начнём с первой задачки. А, у нас есть форма обо мне, и в ней три параметра: пол, возраст и статус. Для них есть значение. Это пол мужчина-женщина, возраст меньше 18, 18 и больше сока. Ну, и статус в браке и холост. Что мы будем делать? Можно, конечно, вручную вставить все эти уникальные случаи, но это не целесообразно, просто трата времени. Есть уже готовые сервисы. Вот один из них - это Pirvise. Перейдём на него и давайте покажу, как вообще с ним работать. У нас есть вот такая табличка, которую нам необходимо заполнить. Сверху у нас будут параметры. слева вот здесь вот у нас будет количество наших значений, а вот здесь вот у нас будут все наши значения. Давайте введём первый параметр. Какой у нас там было? Это пол. Мы так вводим пол. Далее у нас идёт возраст и статус. Вот. А всего у нас максимально три значения может быть. Это у нас вот в поле возрасте. То есть у нас может быть, а, соответственно, меньше 18 тире 40 створок и больше сорока. Пол у нас может быть либо, а, либо мужской, либо женский статус, либо краки, либо холост. Вот мы заполнили нашу табличку. И чтобы сформировать все уникальные случаи, мы нажимаем на кнопочку generate all combinations. У нас формируется таблица в Экселе. Давайте её сейчас откроем. И здесь можно увидеть, что у нас существует 12 уникальных случаев. Так, извиняюсь, 12 уникальных случаев. А, то есть у нас для каждого из этих параметров формируется уникальная последовательность сочетания этих параметров. Но хорошо, здесь в данном примере у нас всего 12 тестовых случаев, да, получилось, но когда у нас больше параметров и больше для них значений, это число будет расти просто в геометрической прогрессии. А как нам оптимизировать в целом а эту таблицу? В принципе, вместо того, чтобы формировать уникальные, а случаи для каждого из этих трёх значений, мы будем формировать для их пар. То есть вот пол а возраст и возраст тире статус. А давайте попробуем это сделать. Что мы делаем? У нас есть пол мужской и женский. И как видим, здесь вот у нас записи повторяются. мужской меньше восемнадцати, мужской меньше восемнадцати и так далее. Мы возьмём уникальные значения. То есть мужской меньше восемнадцати, а мужской а давайте женский меньше восемнадцати, мужской 18 тире40, женский 18 тире 40. И также для больше сорока мужской пол и женский. Вот. А далее мы будем уже сравнивать следующие два параметра - это возраст и статус. То есть у нас есть здесь 18 тире40 и больше 40. А в статусе у нас есть всего два положения. Это либо в браке, либо холс. И мы просто берём и для каждого из этих значений, да, 18 и 18 вставляем уникальные. То есть 18 меньше 18 в браке, меньше 18 холост. Дальше 18 тире40, то же самое, 18 тире40 в браке, 18 тире40 холост. Ну и для последнего. Таким образом мы получаем уже шесть проверок. То есть мы сократили в два раза нашу таблицу и будем проверять эти значения.
Вообще, а сокращение проверок, безусловно, приводит к снижению количества покрытия нашей функциональности тестами. Но, в принципе, есть исследования, которые доказывают, что, а, если, допустим, мы составим все тестовые случаи, у нас, ну, как бы вероятность нахождения багат в районе там 100%, да, ну, если он действительно есть здесь. А если мы сокращаем, применяя технику попарного тестирования, то у нас этот процент падает всего лишь где-то до 9597. То есть с такой вероятностью мы найдём баг, который там на самом деле, допустим, есть. А, но при этом мы экономим кучу времени, да? Возможно, на этом примере не особо наглядно видно, потому что у нас здесь всего 12 проверок, и мы сократили как бы в два раза.
Давайте перейдём к другому, э, примеру, и я покажу вам более наглядно. Допустим, у нас есть какое-то вот условие. Пользователь может выбрать товар, яблоко, телефон или ложка, указать количество товара от одного до восьми и способ оплаты, э, банковская карта, оплата при получении или наличная. А, вернёмся к нашему уже знакомому инструменту и заполним также таблицу. Товар, количество и оплата. Товар первое - это яблоко. Второй это телефон, да, по-моему. Третий - это у нас ложка. И добавим количество м наших записей, потому что у нас параметри количества от одного до восьми могут быть значения. Далее третий, четвёртый, пятый, шестой, седьмой и восьмой. Оплата у нас может быть либо карта, либо картой при получении, либо наличными. В таком случае мы можем посчитать, какое количество у нас будет всего уникальных случаев. То есть 3х на 3 на 8 будет 72 уникальных тестовых случая. Ну, можем тут проверить, нажать generate all combinations. А, ну вот, в общем, здесь было написано, что 72, но давайте сформируем с помощью этого инструмента уже готовую таблицу, оптимизированную. Как это сделать? Нажимаем просто generate payerwise, и у нас создаётся новая табличка. Так, у меня здесь что-то подвисло. Так, это немножко не то. Секундочку. Так, вот, да, наша табличка. И мы сократили количество проверок, да, уже до 30 штук. Больше чем два раза, но всё-таки, да, ещё не такая наглядная разница. Вот. Но уже готовая за то табличка, по которой можно проходиться и проверять.
А давайте покажу, что будет, если у нас будет больше параметров и больше значений. Допустим, у нас будет количество уже до 10ти расписано. Даже давайте до 12ти. [музыка] А товаров будет больше. Будет ещё, например, лимонт лук, будет, не знаю, лайм, к примеру, да, оплата будет наличными ещё. Так, это и, допустим, будет ещё оплата, ну, скажем, а, и добавим какое-нибудь ещё одно поле, например, город. Вот так будет А, Б, Б, Г. Также, допустим, время года, когда у нас происходит заказ, да, время года, весна, века, осень и зима. Какое же количество у нас здесь получится уникальных записей? Давайте посмотрим. Как видим, у нас получилось 4.608 уникальных тестовых случаев. Такое количество случаев проверить, ну, особенно одному, да, ну, просто невозможно, да и нецелесообразно. Для этого мы сформируем уже готовую таблицу и увидим, что у нас количество вариантов сократилось до 108. То есть вот как раз-таки на уже таких сложных случаях у нас наглядно а видна полезность этого метода.
А, ну, с попарным тестированием в принципе всё. Давайте пойдём дальше. Это причина следствия. Ну, это такой довольно простой способ. То есть когда мы что-то делаем, да, например, а мы нажимаем на вот здесь вот, я не знаю, у меня видно, нет. В общем, здесь вот есть иконочка таймер. А, то есть причина, мы нажимаем на м какой-то параметр, да, на какую-то, соответственно, кнопку и как следствие ожидаем увидеть, например, вот такой вот, э, вот такое вот окно. Либо же какой-то более сложный случай, например, совокупность параметров, да, там, то есть, например, кликнуть на блок, дальше при этом выбрать конкретно, например, вот эту вот иконочку, нажать на неё и как ожидаем, что мы ожидаем? Мы ожидаем, что у нас появится вот такое вот окно с выбором цвета. Вот, в принципе, это всё.
Дальше диаграмма состояний. Более интересный способ, а также разберём на примере. У нас есть какой-то функционал решения капчи, и он сейчас тестируется. На решение даётся три попытки. Если третья попытка неудачная, то капча меняется. Как мы это распишем? Составим вот такую диаграммку. Здесь видно, что у нас есть точка входа. И дальше идёт первая попытка. От неё два ответления. То есть либо решение верное, либо решение неверное. Если верное, то успешное решение капчи и точка выхода. И так далее. Если на третьей попытке у нас неверное решение, то у нас происходит смена капчи и тоже точка выхода. Здесь наглядно видно, что у нас есть четыре способа, а прохождения по всему этому пути. То есть раз здесь 2 3 и 4. А это довольно простой пример. Но когда у вас большое количество каких-то компонентов, которые взаимодействуют, да, параметрах, которые друг на друга влияют, а, например, на той же форме авторизации какой-нибудь, а очень удобно составить такую диаграмму. и наглядно увидеть, чтобы не запутаться, какие у нас варианты решения есть, и уже на основе этого проходиться и тестировать по каждому случаю. В принципе, это вся техника.
Последняя техника - это таблица принятия решений. Что это такое? Давайте тоже разберём на примере. Есть форма регистрации, на ней три поля: mail, пароль и возраст. У нас есть условия, которые гласят, а, что регистрация у нас пройдёт только в тех случаях, когда у нас верный. Пароль тоже верный. Возраст больше 18 и возраст меньше 50. А количество случаев здесь будет равно 2 в четвёртой степени. Почему? Потому что у нас каждый этот критерий может принимать значение либо да, либо нет. То есть регистрация успешна, да, либо же нет, неуспешно. А в таком случае, если 2 в четвёртой степени, это у нас будет 16 проверок. Мно как же нам оптимизировать, в принципе, эти проверки? А, допустим, мы знаем в этом случае, что у нас есть два поля возраста. Они оба про возраст. Вот. И мы можем, а, объединить их в одно условие, что если возраст от 18 до 50, тогда регистрация успешна, а не использовать два критерия. Давайте можем воспользоваться также вот этим же инструментом. Составим, получается, несколько параметров. IL корректныйроль корректный тоже и возраст от 18 до с до 50 лет. Да. Да. И значение либо да, либо нет. Вот. А в таком случае у нас уже будет 2 третьей степени. Это восемь проверок. Ну, можем проверить. Как видим, вот здесь получилось восемь восемь случаев. Так, у меня почему-то зависает. Сейчас завершим. Сохранять и перейдём обратно. Сгенерируем. Как видим, у нас появилось восемь вариантов в таком случае уникальных. А давайте откроем. Вот получается наша табличка. И что мы будем здесь делать? Нам необходимо теперь написать результат, который у нас возможен. В данном случае это два результата, то есть регистрация успешно и регистрация не успешна. Успешно она в каких случаях? Когда все три параметра, да, то здесь тоже ставим, да, а в остальных случаях нет. Здесь наоборот, а здесь, [музыка] да, вот получается вот такую табличку мы составили, и уже по ней можно тестировать, проходиться по каждому уникальному случаю. Вот в целом а по этой технике всё.
Давайте вернёмся. Ну и как итог, все эти техники необходимы для того, чтобы максимально эффективно тестировать наше ПВО. Ну а если ты тоже хочешь полностью выучить тестирование и найти работу инженеров хорошей компании с хорошей зарплатой, то переходи в мой Telegram-канал. Там есть вся информация по моему курсу. С ней ты можешь ознакомиться и, если останутся какие-то вопросы, написать мне в лс. И, возможно, это будет твой первый шаг в лучшую жизнь.