Сайт с багами – горе для бизнеса. Всего одна 404-я или 500-я ошибка может лишить вашу компанию солидной суммы денег и хорошей репутации. Но есть способ избежать этого: тестировать сайт. О том, как это сделать, расскажет данная статья. Прочитав её, вы узнаете, как тестировать код на Django, создать своего пользователя-тестировщика и много чего ещё. Добро пожаловать под кат.
UPD: Часть 2. JavaScript и русский текст на английских страницахЧасть 3. Отправка результата на почту, TestExplorer и декоратор tag
Время на прочтение
Спасибо пользователям Exosphere и Yuriy_krd за помощь и конструктивную критику
Иногда кажется, что создать что-то по конструктору весьма быстро и просто: хоть сайт, хоть опрос, хоть таблицы. Однако часто упускаешь из внимания какие-то обидные мелочи, из-за которых время уходит впустую и приходится переделывать работу из-за обидного пустяка. Согласитесь, неприятно. Я решил пройти все процессы за вас и предупредить о возможных неприятных мелочах, а также помочь новичкам.
В этой статье мы с вами сделаем гугл-форму, с помощью которой можно собирать данные, опрашивать сотрудников, клиентов, проводить тестирования гипотез и проч. Кстати, крайне актуальная информация в условиях удалённой работы.
Для создания тестов у вас должен быть активный гугл-аккаунт. Если у вас его нет — обратитесь к инструкции “Создание гугл-аккаунта и работа с Гугл-диском”.
Итак, создаем Форму (тестирование).
Обучаясь в институте я, конечно, сдавал множество контрольных, проверочных, курсовых работ, экзаменов и зачётов. Но, одна форма проверки знаний была мной сильно нелюбима – это электронные тесты. Не буду здесь описывать плюсы и минусы этого типа проверки знаний, скажу лишь, что против этой формы я был очень сильно.
Таким образом, в один прекрасный день созрела идея как-то облегчить себе сдачу тестов – взломать, обойти или что-то подобное. В интернете по этому поводу информации не то, чтобы не было, её не было совсем, то есть вообще. Сфера электронных тестов не пользуется популярностью у хакеров и прочих взломщиков.
Не сложно догадаться, что к первому вопросу (Вопрос 1), правильным ответом был «Ответ 4», а ко второму (Вопрос 2), правильным ответом были: «Ответ 2» и «Ответ 3». Программа позволяла делать тесты с несколькими вариантами ответов. Многим одногруппникам этот файл показался счастьем и они начали его заучивать, кто вопросы/ответы, а кто и просто одни ответы. К слову сказать, файл этот мог достигать довольно больших размеров, там могло быть от 300 и до 1500 вопросов. Мне такая перспектива была не по душе, а сознание программиста подсказывало, что если есть такой файл, то что-то можно придумать, дабы облегчить свою жизнь в плане тестов.
В программе в случайном порядке отображаются вопросы из этого списка и варианты ответов из этого же списка, надо всего лишь найти возможность «прочитать», какой вопрос сейчас отображает программа, далее найти его в этом текстовом файле и отобразить каким-то образом правильный ответ.
Задача нетривиальная, учитывая то, что создавать программы я умел, но вот каким-то образом вмешиваться в другие программы знаний не было. После изучения литературы стало понятно, что без API программирования тут не обойтись.
Попробую пояснить в картинках, каждая программа состоит из окон, есть главное окно программы, и куча дочерних окон, у которых, в свою очередь, тоже могут быть дочерние окна:
Вот так вот выглядит окно программы:
А вот так, упрощённо, выглядят окна в программе (помечены красным):
Есть так же, хорошая программа, называется Microsoft Spy++, входит в комплект среды разработки программного обеспечения Visual studio. Ей можно посмотреть в какой иерархии находятся эти окна, что они из себя представляют и прочее. Итак:
API программирование позволяет нам найти нужное окно, от него найти окно с вопросом и прочитать текст вопроса. Далее мы зачитываем наш текстовый файл с данными, находим в нём этот вопрос и зачитываем правильный вариант ответа. Далее, применяя опять же API функции, перебираем окна с ответами и сравниваем с тем, что мы зачитали в файле и, при совпадении, посылаем в окно с названием «&1(2,3,4)» событие «клик мышки».
Всё! Программа для сдачи тестов готова! Осталось только незаметно её запустить перед тестом, либо прописать её в автозагрузку. И ещё одно дополнение, прибегать к помощи программы очень удобно по клику на правую кнопку мышки.
Это всё замечательно работает, но что делать, когда файла с вопросами и ответами нет? Можно прибегнуть к небольшой хитрости. По завершению теста нам показывается информационное окно, сколько ошибок было допущено и оценка.
Вот такое окно:
Делаем программу, которая несколько раз в секунду при помощи API функций проверяет простую вещь: не появилось ли у нас в системе окна с названием «Результаты»? И при появлении такового, посылаем этому окну команду «Hide» — скрыть, а заодно показываем своё, заранее подготовленное, окно с нужным нам текстом. При клике на кнопку «ОК» нашего, заранее подготовленного окна, посылаем клик на кнопку «ОК» скрытого окна и закрываем своё. Всё!
Тестирование бэкенда
Наш сайт написан на Django, поэтому примеры кода указаны для этого фреймворка.
Перед началом советую ознакомиться со списком рекомендаций, которые структурируют и делают более комфортным процесс написания тестов. Я сформировал их за счёт советов других программистов и личного опыта.
Тестирование моделей
Создадим приложение my_app и заполним файл models.py следующим кодом:
from django.db import models
class Trial(models. Model):
“””Простая модель пользовательского триала”””
email = models. EmailField(
verbose_name=’Электронная почта’,
max_length=256,
unique=False,
)
def __str__(self):
return str(self.email)
class Meta:
verbose_name = ‘Триал’
verbose_name_plural = ‘Триалы’
Эта модель – упрощённая версия нашей модели Trial. Вот, что мы можем у неё проверить:
Перейдём к тестам и сначала решим, где они будут находиться. Вы можете писать все тесты в одном файле tests.py (Django добавляет его при создании приложения) либо последовать рекомендациям выше и разделить их.
Если второй вариант вам импонирует больше, то удалите tests.py. Затем создайте папку tests с пустым файлом __init__.py. При запуске тестов он скажет Python, где их искать. Сюда же добавляем еще 3 файла: test_forms.py, test_models.py и test_views.py. Содержимое директории приложения будет примерно таким:
Открываем файл test_models.py и добавляем в него следующий код:
from django.test import TestCase
from my_app.models import Trial
class TrialTests(TestCase):
“””Тесты для модели Trial”””
def test_verbose_name(self):
pass
def test_max_length(self):
pass
def test_unique(self):
pass
def test_str_method(self):
pass
def test_model_verbose_name(self):
pass
def test_model_verbose_name_plural(self):
pass
У Django для тестирования есть специальный модуль django.test. Один из самых важных его классов — TestCase. Именно он и позволяет писать тесты. Чтобы это сделать, нам нужно просто наследовать наш класс от TestCase.
Все наши тесты – это методы класса TrialTests. Пока они ничего не делают, но это ненадолго. Каждый из них будет тестировать по одному условию из списка выше.
Разберёмся с запуском тестов. Чтобы разом выполнить все тесты вашего сайта, введите эту команду в консоли:
python manage.py test
Для запуска тестов конкретного класса, например TrialTests, пишем:
python manage.py test my_app.tests.test_models. TrialTests
Любая из этих команд запустит наши 6 тестов. Выбираем одну из них, вводим в консоль, жмём Enter и получаем примерно такой вывод:
Из него видно, что за 0.001 секунду проверено 6 тестов. ” OK” в конце вывода говорит об их успешном выполнении.
Теперь напишем настоящие тесты. Чтобы это сделать, нам придётся обращаться к параметрам объекта модели Trial. Значит, нужно создать этот объект. И тут важно знать, что для тестов Django использует отдельную чистую базу. Перед прогоном тестов она создаётся, после — удаляется. На скриншоте выше об этом говорят первая и последняя строчки. Если вдруг по какой-то причине база не смогла удалиться, Django скажет об этом и придётся снести её вручную.
Чтобы работать с этой базой, можно использовать 3 метода:
Воспользуемся последним. Поскольку он является методом класса, то добавляем соответствующий декоратор. Внутри создаём объект класса Trial и получаем от него поле email, которое мы будем использовать в самих тестах.
Теперь при запуске тестов класса TrialTests в новой базе будет создаваться объект trial. После прогона он будет удаляться.
Напишем тест параметра verbose_name.
def test_verbose_name(self):
“””Тест параметра verbose_name”””
real_verbose_name = getattr(self.email_field, ‘verbose_name’)
expected_verbose_name = ‘Электронная почта’
self.assertEqual(real_verbose_name, expected_verbose_name)
Из поля email_field мы извлекаем значение параметра verbose_name. Затем применяем метод assertEqual из класса TestCase. Он сравнивает два параметра – реальное и ожидаемое значения verbose_name. Если они равны, тест отработает удачно. В противном случае – упадёт.
Напишем такие же тесты для параметров max_length и unique.
def test_max_length(self):
“””Тест параметра max_length”””
real_max_length = getattr(self.email_field, ‘max_length’)
self.assertEqual(real_max_length, 256)
def test_unique(self):
“””Тест параметра unique”””
real_unique = getattr(self.email_field, ‘unique’)
self.assertEqual(real_unique, False)
Тут всё так же, как и с verbose_name.
Кстати, в тесте параметра unique мы проверяем, что значение равно False. Можно сделать это проще с помощью команды assertFalse. Перепишем код этого теста.
def test_unique(self):
“””Тест параметра unique”””
real_unique = getattr(self.email_field, ‘unique’)
self.assertFalse(real_unique)
Код немного уменьшился и стал более читабельным. Кстати, у Django много таких полезных assert-ов.
Теперь проверим строковое отображение объекта.
def test_string_representation(self):
“””Тест строкового отображения”””
self.assertEqual(str(self.trial), str(self.trial.email))
Тут всё просто. Проверяем, что строковое отображение объекта равно его электронной почте.
И последнее – это тесты полей модели:
def test_model_verbose_name(self):
“””Тест поля verbose_name модели Trial”””
self.assertEqual(Trial._meta.verbose_name, ‘Триал’)
def test_model_verbose_name_plural(self):
“””Тест поля verbose_name_plural модели Trial”””
self.assertEqual(Trial._meta.verbose_name_plural, ‘Триалы’)
Через _meta обращаемся к полям модели Trial и сравниваем их значение с ожидаемым.
Если сейчас запустить тесты, то они успешно отработают, как и раньше. Но ведь так неинтересно! Давайте что-нибудь сломаем. Пусть нашей жертвой станет параметр verbose_name модели Trial. Откроем её код и поменяем значение этого поля с “Триал” на “Что-то другое”. Прогоним тесты.
Как видим, один из тестов упал. Django говорит об этом и о том, что реальное значение поля (“Что-то другое”) не равно ожидаемому (“Триал”).
Миксины – полезные ребята
Тесты моделей – однотипны. Поэтому, когда у вас много сущностей, тестировать их не самая приятная рутина. Я попробовал несколько упростить данный процесс с помощью миксинов. Мой способ неидеален, и я не настаиваю на его использовании, но, возможно, он вам будет полезен.
Думаю, вы заметили, что при тестировании полей verbose_name, max_length и unique прослеживается некоторое дублирование кода. Мы получаем значение поля объекта и сравниваем его с ожидаемым. И так во всех трёх тестах. А значит, можно написать общую функцию, выполняющую эту работу.
Разберёмся с параметрами. С model, думаю, всё понятно. self_ нужен только для вызова метода assertEqual. Поскольку self — это ключевое слово в Python, то мы добавляем к нему _, чтобы не произошло недопонимания. field_and_parameter_value — это словарь с полем и значением его параметра. Например, если мы проверяем параметр max_length, то можно в эту переменную передать email и 256. Если проверяем verbose_name, то передаём email и “Электронная почта”. parameter_name — это тестируемый параметр: max_length, verbose_name и т.д.
Теперь обратимся к коду. Вначале мы получаем все объекты модели и проходимся по ним. Дальше обходим словарь с полями и ожидаемыми значениями параметров. После получаем реальные значения параметров, обращаясь к объекту. А затем сравниваем их с ожидаемыми. Код очень похож на ранее написанный в тестах. Только теперь это всё в одной функции. Кстати, если бы её имя начиналось с префикса test, Django принял бы её за реальный тест и пытался бы выполнить вместе с остальными.
Напишем миксины. Для каждого поля должен быть свой миксин. Для примера возьмём поля verbose_name и max_length.
class TestVerboseNameMixin:
“””Миксин для проверки verbose_name”””
def run_verbose_name_test(self, model):
“””Метод, тестирующий verbose_name”””
run_field_parameter_test(
model, self, self.field_and_verbose_name, ‘verbose_name’
)
class TestMaxLengthMixin:
“””Миксин для проверки max_length”””
def run_max_length_test(self, model):
“””Метод, тестирующий max_length”””
run_field_parameter_test(
model, self, self.field_and_max_length, ‘max_length’
)
Мы создаём нужный метод и в нём вызываем нашу общую функцию с соответствующими параметрами. self.field_and_verbose_name и self.field_and_max_length берутся из класса, который наследуется от миксина. А именно – из метода setUpTestData класса TrialTests.
Наследуем класс TrialTests от наших миксинов.
Если у вас будет много миксинов – их можно объединить, например, в кортеж и при наследовании распаковывать его.
Теперь можно переписать наши тесты:
def test_verbose_name(self):
“””Тест параметра verbose_name”””
super().run_verbose_name_test(Trial)
def test_max_length(self):
“””Тест параметра max_length”””
super().run_max_length_test(Trial)
Когда у вас много тестов для разных моделей, этот способ оказывается весьма полезным.
Тестирование логики
Перейдём к тестам кода из views.py. Возьмём для примера функцию получения домена из имейла.
Таким может быть её тест:
В константе хранятся имейлы и их реальные домены. В тесте мы по ним проходимся, получаем домен с помощью тестируемой функции и сравниваем с ожидаемым.
Они ожидаемо упали. Но почему мы видим, что некорректен только один имейл, хотя мы меняли два? Дело в том, что по умолчанию Django не будет продолжать тестирование, если произошёл фейл. Он просто прекратит прогон тестов, будто команда break, вызванная внутри цикла. Этот факт вряд ли может порадовать, особенно если у вас тесты такие же долгие, как вечерняя поездка по МКАД. Но, к счастью, есть решение. Нам поможет конструкция with self.subTest(). Она указывается после объявления цикла.
В скобках метода subTest мы указываем строку, которую хотим вывести, когда тест упадёт. В данной ситуации это проверяемый имейл.
Теперь при любом фейле Django сохранит отчёт о нём и пойдёт дальше. А после завершения прогона выведет информацию по всему, что упало.
Разберём тест ещё одной функции. При получении от пользователя промокода мы преобразовываем его в более удобный вид – убираем символы “#” и пробелы. Для этого у нас есть функция get_correct_promo:
Так может выглядеть тест для неё:
В константе хранятся некорректные и корректные промокоды. В тесте мы по ним проходимся, и сравниваем промокод, полученный с помощью функции get_correct_promo и действительно корректный промокод.
Пожалуй, тестирование views — самое простое из этой триады тестов. В нём мы просто вызываем нужную функцию и проверяем, что значение, которое она возвращает, совпадает с ожидаемым. Кстати, создавая константы с данными для проверки, желательно придумывать как можно больше разных значений. Так вы повысите шансы на то, что ваш тест станет более эффективным.
Тесты форм
Тесты форм похожи на тесты моделей. В них мы также можем проверять поля и методы.
Создадим форму модели Trial:
from django import forms
from my_app.models import Trial
class TrialForm(forms. ModelForm):
“””Форма модели Trial”””
class Meta:
model = Trial
exclude = ()
Одним из примеров тестов для неё может быть этот код:
В нём мы создаём объект нашей формы и сравниваем label поля с ожидаемым. Примерно так можно писать тесты для форм. Но мы их почти не используем. Для этого есть более эффективный способ, о котором я расскажу в следующей части.
Входящая задача
Нам нужно создать тестирование, которое будет собирать набор информации.
Шаг 4. Отправка теста (формы)
Отправка теста (формы) осуществляется путем нажатии кнопки “Отправить”. В открывшемся окне можно выбрать разные варианты отправки.
Отправка по электронной почте:
В поле “Кому” введите адреса получателей. В этом случае в закладке ответы, Вы будете видеть кто проголосовал, а кто еще не ответил на вопросы формы.
Так же форму можно сразу включить в тело письма.
Следующая закладка — отправить ссылку. В этом случае вы можете отправлять ее не только почтой, но и любым иным способом, в том числе через Мессенджер. Однако в этом случае вы будете вынуждены отслеживать ответивших самостоятельно.
Третий вариант — вставка на сайт. Это для более продвинутых пользователей. Позволяет встроить код с формой сразу в шаблон сайта.
Вы закончили создание формы.
Ссылка на тестовую форму, созданную при написании инструкции.
Что вы делаете, когда пишете тесты?
Как бы вы ответили на этот вопрос? Я бы сказал – кайфую. У каждого разработчика есть своё мнение на счёт тестов. Лично мне этот процесс безумно нравится. Благодаря ему я могу не только писать более надёжный код, но и начинаю лучше разбираться в своих и чужих программах. А вишенкой на торте является чувство, испытываемое, когда все тесты становятся зелёными. В этот момент моя шкала перфекционизма достигает своего апогея.
Иногда при тестировании меня затягивает так, будто я прохожу Half-Life. Я начинаю проводить за этим процессом всё рабочее и свободное время. Конечно, со временем тесты надоедают, и тогда приходится делать перерыв. После чего опять можно стать ноулайфером на несколько недель, будто Valve выпустила новую часть. Если у вас также, то вы понимаете, о чём я. Но хватит разговоров, перейдём к делу!
Свой пользователь-тестировщик
Итак, backend-часть вашего сайта протестирована. Но вдруг на одной из его страниц вы заметили 404-ю ошибку. Написанные тесты не нашли её. Они также не помогут, например, при поиске битых ссылок на страницах. Эти тесты просто не рассчитаны на баги такого рода. Но как тогда их отлавливать? Для этого нужны тесты, имитирующие действия пользователя. Можно использовать django.test. Client, но он позволяет запускать тесты только на самом сервере сайта, а это не всегда удобно. Поэтому обратимся к Python библиотеке requests.
Данные тесты обычно получаются объёмными, поэтому их лучше вынести в отдельный файл (или файлы), например test_requests.py.
Проверка статус-кодов
Для проверки статус-кода страницы нужно:
У библиотеки requests много полезных методов. В выполнении 1-го и 2-го пунктов нам поможет head. С его помощью мы будем отправлять HEAD-запрос на страницы сайта.
from requests import head
Нам достаточно передать в него лишь URL-адрес, чтобы получить ответ со всей нужной информацией о странице. А из этой информации можно извлечь статус-код:
Теперь перейдём к написанию теста. Создадим константу с тестируемыми страницами. Для простоты возьмём домен только русской версии.
Конечно, в идеале относительные пути страниц лучше брать из базы. Но если такой возможности нет – можно обойтись обычным кортежем.
Добавим класс PagesTests вместе с тестом test_status_code:
В тесте на каждую страницу мы отправляем HEAD-запрос и сохраняем ответ в переменной response. После этого проверяем, равен ли статус-код страницы 200.
Проверка ссылок на страницах
Проверить ссылки можно так:
Для поиска ссылок будем использовать метод findall батарейки re. Для отправки GET-запроса – метод get всё той же библиотеки requests. И не забудем о методе head.
from re import findall
from requests import get, head
Далее переменные. Для этого теста нам понадобится константа PAGES, объявленная ранее, и переменная с регулярным выражением для ссылки.
И, наконец, напишем сам тест.
На каждую страницу отправляем GET-запрос и из полученного ответа извлекаем контент. Далее с помощью регулярного выражения и метода findall получаем все ссылки, находящиеся на странице. Их заносим в set, чтобы убрать дубли. Последний этап – уже знакомая нам ситуация: обходим все ссылки, отправляем на них HEAD-запрос и проверяем статус-код. Если переменная link – редирект, то параметр allow_redirects укажет, что мы можем его выполнить. По умолчанию его значение – False. Также добавляем валидные ссылки в set, чтобы в дальнейшем не отправлять на них запрос.
Кстати, иногда на странице можно встретить относительные ссылки. Например, “/ru/pvs-studio/faq/”. Сайт к ним подставляет URL-адрес, но тест этого не делает и, как следствие, не может выполнить запрос.
Чтобы этого избежать, создадим такую функцию:
Если полученная ссылка – относительная, функция добавляет к ней URL-адрес сайта. Теперь в тесте при получении ссылки мы будем использовать эту функцию:
Тесты редиректов
Ещё один вариант тестов с помощью requests – тесты редиректов. Чтобы их проверить, нам нужно:
Следовательно, нам пригодятся два URL-адреса. Первый – ссылка-редирект, на которую жмёт пользователь. Второй – URL-адрес страницы, на которую посетитель в итоге перешёл. Как и в примере со статус-кодами, лучше получать эти URL-ы из базы. Если такой возможности нет, то рекомендую использовать словарь.
Не забудем про переменную SITE_URL, созданную ранее.
SITE_URL = ‘https://pvs-studio.com’
И напишем сам тест.
Первым делом по ссылке мы отправляем HEAD-запрос. При этом разрешаем использовать редиректы. Из полученного ответа берём URL-адрес страницы и сравниваем его с ожидаемым.
Библиотека requests позволяет выполнять много разных проверок сайта. Основные методы для тестов, как вы могли заметить – head и get. Но есть и другие. Они тоже могут пригодиться. Всё зависит от ваших задач.
Элемент управления “Настройки”
Закладка Общие и Презентация не должны вызвать каких-то вопросов. Важная вкладка “Тесты” — в ней вы можете настроить балльную оценку для каждого вопроса в форме. Для этого активируйте сдвижной переключатель “Тест” и Ваша форма перейдет в разряд теста. После активации этой кнопки вы можете назначать в списке вопросов правильные ответы и количество баллов за правильный ответ.
После активации переключателя, нажмите кнопку “Сохранить” и перейдите к вопросам. Внизу блока вопроса появиться кнопка “Ответы”:
Нажав на нее, вы перейдете в режим установки верных ответов и начисления баллов за правильный ответ.
Итак, давайте начнем выполнение поставленной в начале задачи.
Шаг 4. Создаем тест
Активируем переключатель “Обязательный вопрос”. Теперь пользователь обязан ввести Фамилию и Имя, чтобы продолжить прохождение теста.
Добавляем второй вопрос нажав на верхнюю кнопку в правой вертикальной панеле элементов управления.
Сделаем этот вопрос необязательным не активируя переключатель внизу справа блока. Даже не ответив на этот вопрос, пользователь продолжит и сможет закончить тестирование.
Создаем еще один блок с единственным вариантом ответа
Добавляем блок с несколькими вариантами ответов
Тут мы также добавили вариант ответа “Другое”.
Теперь настраиваем баллы для правильных ответов. Переходим в пункт настройки в верхней правой части элементов управления (значок шестеренки). Переходим на закладку “Тест” и активируем переключатель. Нажимаем кнопку Сохранить и возвращаемся к списку наших вопросов.
Нажав на любое пустое место блока вопроса, активируем его. Слева внизу активируем блок ответов. Выбираем нужный нам ответ верным и назначаем количество баллов.
Нажимаем кнопку готово. Баллы назначены.
Теперь нам нужно настроить регулярность вопросов и сбор адресов электронной почты.
Опять переходим в пункт “Настройки” в верхней части элементов управления. Активируем нужные нам элементы настроек.
Переходим сразу в закладку “Презентации” и проверяем, что активирован пункт “Показывать ссылку для повторного заполнения формы”. Нажимаем кнопку “Сохранить”
Тест (форма) готов.
Шаг 3. Элементы управления
Первое, что нужно сделать — создать имя файла для формы. Это имя внутреннее, под ним форма будет храниться на Диске.
Имя создается, если щелкнуть по словосочетанию “Новая форма” в верхней левой части экрана.
В центре экрана находится поле с названием теста (формы). Его будут видеть тестируемые при выполнении. Изменим его на нужное.
Там же заполним описание к тесту (форме).
Далее автоматически создается первый блок вопроса.
В поле “Вопрос без заголовка” вам нужно вписать свой вопрос. Ниже переименовать Вариант 1 ответа на нужный. Если нужно добавить еще один вопрос — нужно нажать ниже “Добавить вопрос”. Также можно добавить вариант “Другое”, тогда в тесте появится текстовое поле, куда пользователь может внести любой иной ответ в произвольной форме.
Выпадающий список позволяет выбрать вид вопроса. В нашем случае автоматически создан вопрос с одним вариантом ответа. Если выпадающий список раскрыть, то можно выбрать иную форму вопроса.
Внизу блока есть кнопки:
Справа от формы находится вертикальный блок кнопок, который позволяет (сверху вниз по кнопкам):
И заключительный блок элементов управления вверху страницы:
Шаг 2. Создание Теста (формы)
Как и в любом документе в Гугл-диске, начало работы начинается с кнопки “Создать+” в верхней левой части экрана. Этой кнопкой создаются папки на Диске, создаются все документы.
Нажав кнопку Создать, вы увидите меню. В нем нужно выбрать пункт “Еще”.
Создать форму можно несколькими способами:
1. Создание пустой формы:
2. Создание формы по шаблону — Повторите действия, указанные выше, до отметки 3, и вместо нее выполните отметку 3+. Вам откроется библиотека шаблонов, где вы можете выбрать наиболее подходящий шаблон. В дальнейшем его можно отредактировать под ваши нужды.
Мы создали пустую форму (тестирование).
Шаг 1 — создание теста (формы)
Переходим в гугл-диск. Для этого нажмите кнопку с точками на панели сверху справа, перейдя по ссылке https://www.google.com/ или https://www.google.ru/ Далее выберите Гугл-диск (далее по тексту Диск).
Заключение
Если хотите поделиться этой статьёй с англоязычной аудиторией, то прошу использовать ссылку на перевод: https://habr.com/en/company/pvs-studio/blog/649189/