Укажите ваше окружение яндекс тест что это

Да, это boot2docker, но интересно не это. Посмотрим на смонтированные разделы:

docker@testenv:~$ mount tmpfs on / type tmpfs (rw,relatime,size=918088k) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) /dev/sda1 on /mnt/sda1 type ext4 (rw,relatime,data=ordered) [. cgroup skipped . ] none on /Users type vboxsf (rw,nodev,relatime) /dev/sda1 on /mnt/sda1/var/lib/docker/aufs type ext4 (rw,relatime,data=ordered) docker@testenv:~$ ls /Users/ Shared/ logpacker/ docker@testenv:~$ 

В данном случае мы используем MacOS и, соответственно, внутрь машины смонтирована директория /Users (аналог /home в linux). Это позволяет нам прозрачно работать с файлами на host-системе в рамках docker, то есть спокойно подключать и отключать volumes, не заботясь о прослойке в виде VM. Это действительно очень удобно. По идее, нам можно забыть про эту VM, она нужна только для того, чтобы docker работал в “родной” среде. При этом использование docker-клиента будет абсолютно прозрачным.
Итак, базовое окружение построено, далее будем запускать Docker контейнеры.

Настройка и запуск контейнеров

• Три контейнера с серверной частью приложения.
• Три контейнера с клиентской частью приложения.
• Генератор нагрузки для каждого агента. Например, Ngnix, который будет генерировать логи, а мы его будем стимулировать Яндекс.Танком или Apache Benchmark.
• И в еще одном контейнере мы отойдем от идеологии. Наш сервис умеет работать в так называемом “dual mode”, т.е. клиент и сервер находятся на одном и том же хосте, более того, это всего один экземпляр приложения, работающий сразу и как клиент, и как сервер. Его мы запустим в контейнере под контролем supervisord, и в этом же контейнере будет запущен наш собственный небольшой генератор нагрузки в качестве основного процесса.

docker-compose.yml

# external services elastic: image: elasticsearch ngx_1: image: nginx volumes: - /var/log/nginx ngx_2: image: nginx volumes: - /var/log/nginx ngx_3: image: nginx volumes: - /var/log/nginx # lp servers lp_server_1: image: logpacker_service command: bash -c "cd /opt/logpacker && ./logpacker -s -v -devmode -p=0.0.0.0:9995" links: - elastic expose: - "9995" - "9998" - "9999" lp_server_2: image: logpacker_service command: bash -c "cd /opt/logpacker && ./logpacker -s -v -devmode -p=0.0.0.0:9995" links: - elastic - lp_server_1 expose: - "9995" - "9998" - "9999" lp_server_3: image: logpacker_service command: bash -c "cd /opt/logpacker && ./logpacker -s -v -devmode -p=0.0.0.0:9995" links: - elastic - lp_server_1 - lp_server_2 expose: - "9995" - "9998" - "9999" # lp agents lp_agent_1: image: logpacker_service command: bash -c "cd /opt/logpacker && ./logpacker -a -v -devmode -p=0.0.0.0:9995" volumes_from: - ngx_1 links: - lp_server_1 lp_agent_2: image: logpacker_service command: bash -c "cd /opt/logpacker && ./logpacker -a -v -devmode -p=0.0.0.0:9995" volumes_from: - ngx_2 links: - lp_server_1 lp_agent_3: image: logpacker_service command: bash -c "cd /opt/logpacker && ./logpacker -a -v -devmode -p=0.0.0.0:9995" volumes_from: - ngx_3 links: - lp_server_1 

В этом файле все стандартно. Первым запускаем elasticsearch, как основное хранилище, затем три экземпляра с nginx, которые будут выступать поставщиками нагрузки. Далее запускаем наши сервер-приложения. Обратите внимание, все последующие контейнеры линкуются с предыдущими. В рамках нашей docker-сети, это позволит обращаться к контейнерам по имени. Чуть ниже, когда мы будем разбирать запуск нашего сервиса в “dual mode”, мы еще вернемся к этому моменту и рассмотрим его чуть подробнее. Также с первым контейнером, в котором находится экземпляр сервер-приложения, залинкованы агенты. Это означает, что все три агента будут пересылать логи именно этому серверу.

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

И еще один момент: обратите внимание на логику монтирования volumes. На контейнерах с nginx мы указываем именованный volume, который будет доступен в docker-сети, а на контейнерах с агентами мы просто подключаем его, указав имя сервиса. Таким образом, у нас получится shared volume между потребителями и поставщиками нагрузки.

Итак, запускаем наше окружение:

$ docker-compose up -d 

Проверяем, что все запустилось нормально:

$ docker-compose ps Name Command State Ports -------------------------------------------------------------------------------------------- assets_lp_agent_1_1 bash -c cd /opt/logpacker . Up assets_lp_agent_2_1 bash -c cd /opt/logpacker . Up assets_lp_agent_3_1 bash -c cd /opt/logpacker . Up assets_lp_server_1_1 bash -c cd /opt/logpacker . Up 9995/tcp, 9998/tcp, 9999/tcp assets_lp_server_2_1 bash -c cd /opt/logpacker . Up 9995/tcp, 9998/tcp, 9999/tcp assets_lp_server_3_1 bash -c cd /opt/logpacker . Up 9995/tcp, 9998/tcp, 9999/tcp assets_ngx_1_1 nginx -g daemon off; Up 443/tcp, 80/tcp assets_ngx_2_1 nginx -g daemon off; Up 443/tcp, 80/tcp assets_ngx_3_1 nginx -g daemon off; Up 443/tcp, 80/tcp elastic /docker-entrypoint.sh elas . Up 9200/tcp, 9300/tcp 

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

Присвоение имен контейнерам

Вернемся к контейнеру, в котором мы хотели запустить наше приложение в “dual mode”. Основным процессом в этом контейнере будет выступать генератор нагрузки (простейший shell-сценарий). Он генерирует текстовые строки и складывает их в текстовые “лог”-файлы, которые, в свою очередь, будут являться нагрузкой для нашего приложения. Сначала нужно собрать контейнер с нашим приложением, запускаемым под supervisord . Возьмем последнюю версию supervisord , так как нам нужна возможность передачи переменных окружения в конфигурационный файл. Нам подойдет supervisord версии 3.2.0, однако в Ubuntu 14.04 LTS, которую мы взяли за базовый образ, версия supervisord достаточно старая (3.0b2). Установим свежую версию supervisord через pip . Итоговый Dockerfile получился таким:

Dockerfile

FROM ubuntu:14.04 # Setup locale environment variables RUN locale-gen en_US.UTF-8 ENV LANG en_US.UTF-8 ENV LANGUAGE en_US:en ENV LC_ALL en_US.UTF-8 # Ignore interactive ENV DEBIAN_FRONTEND=noninteractive RUN apt-get update && \ apt-get install -y wget unzip curl python-pip # Install supervisor via pip for latest version RUN pip install supervisor RUN mkdir -p /opt/logpacker ADD final/logpacker /opt/logpacker/logpacker ADD supervisord-logpacker-server.ini /etc/supervisor/conf.d/logpacker.conf ADD supervisor.conf /etc/supervisor/supervisor.conf # Load generator ADD random.sh /opt/random.sh # Start script ADD lp_service_start.sh /opt/lp_service_start.sh 

Генератор нагрузки крайне прост:

#!/bin/bash # generate random lines OUTPUT_FILE="test.log" while true do _RND_LENGTH=`awk -v min=1 -v max=100 'BEGIN'` _RND=$(( ( RANDOM % 100 ) + 1 )) _A ; echo $_A; echo $_A >> /tmp/logpacker/lptest.$_RND.$OUTPUT_FILE; done 

Стартовый скрипт тоже не сложный:

#!/bin/bash # run daemon supervisord -c /etc/supervisor/supervisor.conf # launch randomizer /opt/random.sh 

Вся хитрость будет заключаться в конфигурационном файле supervisord и запуске Docker-контейнера.
Рассмотрим конфигурационный файл:

[program:logpacker_daemon] command=/opt/logpacker/logpacker %(ENV_LOGPACKER_OPTS)s directory=/opt/logpacker/ autostart=true autorestart=true startretries=10 stderr_logfile=/var/log/logpacker.stderr.log stdout_logfile=/var/log/logpacker.stdout.log 

Обратите внимание на %(ENV_LOGPACKER_OPTS)s . Supervisord может выполнять подстановки в конфигурационный файл из переменных окружения. Переменная записывается как %(ENV_VAR_NAME)s и ее значение подставляется в конфигурационный файл при старте демона.
Запускаем контейнер, выполнив следующую команду:

$ docker run -it -d --name=dualmode --link=elastic -e 'LOGPACKER_OPTS=-s -a -v -devmode' logpacker_dualmode /opt/random.sh 

При помощи ключа -e есть возможность установить необходимую переменную окружения, при этом она будет установлена глобально внутри контейнера. И именно ее мы подставляем в конфигурационный файл supervisord . Таким образом, мы можем управлять ключами запуска для нашего демона и запускать его в нужном нам режиме.
Мы получили универсальный образ, хотя немного не соответствующий идеологии. Заглянем внутрь:

Environment

$ docker exec -it dualmode bash $ env HOSTNAME=6b2a2ae3ed83 ELASTIC_NAME=/suspicious_dubinsky/elastic TERM=xterm ELASTIC_ENV_CA_CERTIFICATES_JAVA_VERSION=20140324 LOGPACKER_OPTS=-s -a -v -devmode ELASTIC_ENV_JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre ELASTIC_ENV_JAVA_VERSION=8u66 ELASTIC_ENV_ELASTICSEARCH_REPO_BASE=http://packages.elasticsearch.org/elasticsearch/1.7/debian ELASTIC_PORT_9200_TCP=tcp://172.17.0.2:9200 ELASTIC_ENV_ELASTICSEARCH_VERSION=1.7.4 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ELASTIC_PORT_9300_TCP_ADDR=172.17.0.2 ELASTIC_ENV_ELASTICSEARCH_MAJOR=1.7 ELASTIC_PORT_9300_TCP=tcp://172.17.0.2:9300 PWD=/ ELASTIC_PORT_9200_TCP_ADDR=172.17.0.2 ELASTIC_PORT_9200_TCP_PROTO=tcp ELASTIC_PORT_9300_TCP_PORT=9300 SHLVL=1 HOME=/root ELASTIC_ENV_JAVA_DEBIAN_VERSION=8u66-b17-1~bpo8+1 ELASTIC_PORT_9300_TCP_PROTO=tcp ELASTIC_PORT=tcp://172.17.0.2:9200 LESSOPEN=| /usr/bin/lesspipe %s ELASTIC_ENV_LANG=C.UTF-8 LESSCLOSE=/usr/bin/lesspipe %s %s ELASTIC_PORT_9200_TCP_PORT=9200 _=/usr/bin/env 

Помимо нашей переменной, которую мы явно указали при старте контейнера, мы видим еще и все переменные, относящиеся к залинкованному контейнеру, а именно: IP-адрес, все открытые порты и все переменные, которые были явно установлены при сборке образа elasticsearch при помощи директивы ENV. Все переменные имеют префикс с именем экспортирующего контейнера и название, указывающее на их суть. Например, ELASTIC_PORT_9300_TCP_ADDR обозначает, что в переменной хранится значение, указывающее на контейнер с именем elastic и его ip-адрес, на котором открыт порт 9300. Если поднимать отдельный discovery-сервис для поставленных задач не резонно, то это отличный способ получить IP-адрес и данные залинкованных контейнеров. При этом остается возможность использовать их в своих приложениях, которые запущены в Docker контейнерах.

Управление контейнерами и система мониторинга

Итак, мы построили окружение для тестирования отвечающее всем нашим изначальным запросам. Осталась пара нюансов. Во-первых, установим Weave Scope (скриншоты которого были в начале статьи). При помощи Weave Scope можно визуализировать среду, в которой мы работаем. Помимо отображения связей и информации о контейнерах, мы можем выполнить attach к любому контейнеру или запустить полноценный терминал с sh прямо в браузере. Это незаменимые функции при отладке и тестировании. Итак, с хост-машины выполняем следующие действия, в рамках нашей активной сессии:

 $ wget -O scope https://github.com/weaveworks/scope/releases/download/latest_release/scope $ chmod +x scope $ scope launch 

После выполнения этих команд, перейдя по адресу VM_IP:4040 мы попадаем в интерфейс управления контейнерами, представленный на картинке ниже:

Отлично, почти все готово. Для полного счастья нам не хватает системы мониторинга. Воспользуемся cAdvisor от Google:

$ docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8080:8080 --detach=true --name=cadvisor google/cadvisor:latest 

Теперь по адресу VM_IP:8080 у нас есть система мониторинга ресурсов в реальном времени. Мы можем отслеживать и анализировать основные метрики нашего окружения, такие как:

• использование системных ресурсов;
• загрузка сети;
• список процессов;
• прочая полезная информация.

Заключение

• Полноценная эмуляция сети для тестирования сетевого взаимодействия.
• Добавление и удаление узлов с приложением осуществляется за счет изменений в docker-compose.yml и применяется одной командой.
• Все узлы могут полноценно получать информацию о сетевом окружении.
• Добавление и удаление хранилищ данных выполняется одной командой.
• Управление и мониторинг системы доступны через браузер. Это реализовано при помощи инструментов, отдельно запущенных в контейнерах рядом с нашим приложением, что позволяет изолировать их от host-системы.

Ссылки на все инструменты, упомянутые в статье:

• Docker
• docker-compose
• docker-machine
• Docker Toolbox
• Weave Scope
• cAdvisor
• Все конфигурационные файлы и скрипты, используемые для построения тестового окружения

Каких ответов я жду на собеседовании по тестированию

Долго собирался написать статью… И вот, наконец, выполнил свое намерение. Вопросы, поднимаемые в статье, обсуждались уже не раз и не два, но усердные поиски компиляции ответов на эти вопросы так и не увенчались успехом. Но, как подсказывает мой опыт, такая компиляция очень нужна. Прежде всего она требуется юниорам, ибо в сети по запросу «тестирование» на них (соискателей) обрушивается огромный объем информационного мусора, который плохо структурирован и часто противоречит сам себе.

Вступление

Сначала несколько слов о себе. На данный момент являюсь начальником отдела тестирования и сопровождения компании, занимающейся корпоративными ГИС. До этого работал руководителем группы тестирования в компании, разрабатывающей коммерческие СДО (Системы дистанционного обучения). А еще раньше ведущим инженером по тестированию в компании, которая обеспечивала электронные торги по ФЗ №94. А начинал я свою карьеру более 11 лет назад в роли системного администратора (в трех различных организациях). Стажером-программистом был чуть меньше двух лет (вначале нулевых – VB). Фрилансил инженером-программистом: писал собственный баг-трекер для госкомпании… Исходя из сказанного, можно утверждать, что определенный опыт (тестирования — суммарно более 5 лет) наработан…

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

1. Почему вы решили стать тестировщиком?
2. Что такое тестирование? В чем его суть как процесса?
3. Что такое ошибка?
4. В чем цель тестирования?
5. Что вы знаете о жизненном цикле ПО?
6. Какие бывают требования?
7. Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?
8. Расскажите о тестовой документации: виды, цели.
9. Из каких этапов состоит процесс тестирования?
10. Автоматизированное тестирование – отдельный вид тестирования?
11. Какой тип/вид класс тестирования имеет смысл автоматизировать?

Может, я слишком требователен к ответам? Нет, я просто жду от соискателя понимания того, чем ему придется заниматься. Вот как проходит собеседование: я начинаю разговаривать с соискателем предпочтительно в форме диалога, задавая ему указанные вопросы. Если получаю ответ, правильный или близкий к правильному, то перехожу к следующему вопросу. Если соискатель «блуждает», приводит заученную формулировку или просто не может ее обосновать, я пытаюсь подвести его к правильному ответу и почему этот ответ правильный. Пытаюсь заставить рассуждать. Последний год вместо собеседований у меня получаются импровизированные лекции. И дело не только в том, что соискатели менее осведомлены или у них мало опыта. Имели место и собеседования на должность ведущего инженера по тестированию с претендентами с 10 летним опытом… результат почти всегда удручает. По-моему, дело в том, что очень много противоречивой информации и «неполезного» опыта, ведь очень многие российские компании строят процесс тестирования по модели С. Канера – когда два – три высококвалифицированных тестировщика полностью генерируют, отбирают и описывают кейсы, а проверки проводят 10 -15,100, 500+ «тестеров» не особо вникая в саму суть процесса.

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

Почему вы решили стать тестировщиком?

Наиболее частый ответ: «потому что это просто и интересно (!)». Т. е. кандидат считает, что ему будут платить деньги за щелканье мышкой в вк… Или дадут софт и скажут – сломай его… Или он просто не готовился к этому вопросу и имеет весьма слабое представление о профессии.

Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).

Бывали и ответы: «меня мама/муж/жена заставила идти на собеседование».

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

Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».

Что такое тестирование? В чем его суть как процесса?

Наиболее частый ответ (напрямую прописан у С. Канера и Р.Савина) – «поиск ошибок». И во всей литературе по тестированию почему-то никто не указывает, что это упрощение и весьма грубое, и вообще, этот ответ просто неверен!

Тестирование – комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).

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

Что такое ошибка?

Ну, здесь, слава Богу, почти все отвечают: «некорректная работа программы…». А вот дальше начинается хаос, когда спрашиваешь: «а как мы узнаем корректная работа или нет?»

Правильный ответ есть почти на всех известных мне ресурсах о тестировании:
Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным.
Чтобы не блуждать в противоречиях/предположениях и т. п., – это единственно правильный ответ.

В чем цель тестирования?

Здесь люди начинают повторять ответ на второй вопрос с разными вариациями. Наиболее внимательные соискатели пытаются пересказать то, что я им подсказывал при ответе на второй вопрос. А ответ крайне простой:

Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям.

Всё. Не больше и не меньше. Ну, конечно же, можно еще сказать, что цель тестирования – предоставление информации о количестве ошибок в продукте. А именно это и неправильно. Почему? Вот просто-таки каждодневный кейс многих тестировщиков/ПМ/аналитиков: звонок заказчика – «как там мой продукт?». «Вы знаете, в нем еще 60 багов!» – ответ тестировщика/ПМ… И что дальше? Это много? Мало? Нормально? Можно, конечно, рассказать подробно о критичности этих багов, их приоритетах, но это не ответ на вопрос заказчика, это выдача сырой необработанной информации ДВП. Теперь тот же кейс. «Как там мой продукт?», – спрашивает заказчик. «35% процентов требований реализовано полностью, еще 5% – с замечаниями и еще 2% – сейчас в реализации», – отвечает ПМ/тестировщик. Как Вам кажется, такой ответ понятнее? И пусть в эти 5% входят, уже упомянутые 60 багов-замечаний… Ответ на вопрос дан настолько точный, насколько это вообще возможно в данном формате. Вот именно это и является целью тестирования. А, соответственно, и сам процесс по своей сути должен сводиться к достижению этой цели.

Что вы знаете о жизненном цикле ПО?

Про ЖЦ ПО сказано много, да и он сильно зависит от организации процесса реализации в целом. Все же есть некоторая «золотая середина», но и здесь умудряются фантазировать дикие вещи, то сводя все к трем пунктам, то разрисовывая схему на три страницы… Всем, кто проводил/проходил собеседование, и так ясно, какие ошибки совершаются и сколько вариантов у правильных ответов. Останавливаться подробнее не буду, скажу только, что есть целый пул кандидатов, которые намертво стопорились на этом вопросе (примерно 7%).

Какие бывают требования?

До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».

Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.

Но есть одна категория, про которую забывают. Я в этой статье уже несколько раз упоминал о «…требованиях прямых и косвенных…». На собеседовании я эту фразу произношу раз пять-шесть. Очень малый процент соискателей переспрашивает и тем самым исключает этот вопрос из собеседования. А полный ответ таков: «Требования бывают прямыми (т. е. формализованными в технической документации, спеках, юзер-стори и прочих формальных артефактах) и косвенными (т. е. проистекающими из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного продукта или продуктах, подобных ему). Все требования также подразделяются на функциональные (описывающие какие функции должен выполнять продукт) и нефункциональные (требования к окружению, поддерживаемости, надежности и прочим характеристикам продукта). Прямые требования всегда приоритетнее косвенных.»

Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» – прямое требование, из него проистекают косвенные – она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное – такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.

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

Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?

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

Расскажите о тестовой документации: виды, цели.

Тестовая документация – пожалуй, самая большая проблема. По ней идут такие битвы в сообществах, фирмах и т. д.! Про нее столько противоречивой информации. О ней изданы многотомники на разных языках. О ней такая каша в головах… Каких только ответов не приходилось слышать (да-да, включая ТЗ и проектное решение – это тоже тестовая документация)… Поэтому выскажу свои мысли по этому поводу.

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

• Замечание – короткая записка, комментарий о небольшой неточности в реализации продукта.
• Баг-репорт – описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым – ошибки или ее проявления. Он обязательно должен содержать следующие элементы:
  • Идею тестового случая, вызвавшего ошибку.
  • Описание исходного состояния системы для выполнения кейса.
  • Шаги, необходимые для того, чтобы выявить ошибку или ее проявление.
  • Ожидаемый результат, т. е. то, что должно было произойти в соответствии с требованиями.
  • Фактический результат, т. е. то, что произошло на самом деле.
  • Входные данные, которые использовались во время воспроизведения кейса.
  • Прочую информацию, без которой повторить кейс не получится.
  • Критичность и/или приоритет.
  • Экранный снимок (скрин).
  • Версию, сборку, ресурс и другие данные об окружении.
  • Тест-план (план тестирования) – формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок. Т.е. перечень направлений проверок, которые должны быть проведены в рамках сессии тестирования (и, сообразных этим направлениям, требований). Также может содержать в себе необходимую информацию об окружении, методике, прочих условиях важных для показательности данной сессии тестирования. Под направлением проверок также может пониматься более детализированная тестовая документация (в виде ссылки на нее): чек листы, тестовые комплекты, тестовые сценарии, на которую необходимо опираться при проведении сессии тестирования. Основная цель документа – описать границы сессии тестирования, стабилизировать показательность данной сессии.
  • Тестовый сценарий – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им проверок корректности поведения продукта в ходе этих действий. Может содержать информацию об исходном состоянии продукта для запуска сценария, входных данных и прочие сведения, имеющие определяющее значение для успешного и показательного проведения проверок по сценарию. Особенностью является линейность действий и проверок, т.е. зависимость последующих действий и проверок от успешности предыдущих. Цель документа – стабилизация покрытия аспектов продукта, необходимых для выполнения функциональной задачи, показательными необходимыми и достаточными проверками. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.
  • Тестовый комплект – некоторый набор формализованных тестовых случаев объединенных между собой по общему логическому признаку.
  • Чек-лист (лист проверок) – перечень формализованных тестовых случаев в виде удобном для проведения проверок. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Обязательно должен содержать в себе информацию о: идеях проверок, наборах входных данных, ожидаемых результатах, булевую отметку о прохождении/непрохождении тестового случая, булевую отметку о совпадении/несовпадении фактического и ожидаемого результата по каждой проверке. Может так же содержать шаги для проведения проверки, данные об особенностях окружения и прочую информацию необходимую для проведения проверок. Цель – обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования.
  • Тестовый случай (тест-кейс) – формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным. Обязательно должен содержать следующую информацию:
    • Идея проверки.
    • Описание проверяемого требования или проверяемой части требования.
    • Используемое для проверки тестовое окружение.
    • Исходное состояние продукта перед началом проверки.
    • Шаги для приведения продукта в состояние, подлежащее проверке.
    • Входные данные для использования при воспроизведении шагов.
    • Ожидаемый результат.
    • Прочую информацию, необходимую для проведения проверки.
    • Обеспечить стабильность покрытия требований проверками.
    • Обеспечить показательность всех проводимых проверок.
    • Обеспечить необходимость и достаточность проводимых проверок.
    • Сэкономить время на этапах тестирования, сводя их к проведению проверок и анализу и передаче результатов.
    • Снизить входной уровень квалификации тестировщика для проведения проверок.
    • Повысить прогнозируемость сессий тестирования в части затрат времени и ресурсов.
    • Повысить прозрачность процесса тестирования для других участников процесса производства продукта.
    • Обеспечить базу знаний о продукте и истории его развития.
    • Стабильность покрытия. Со стремящейся к бесконечности долей вероятности, если проводится тестирование по документации, то будут проведены только те проверки, которые есть в данной документации. Вероятность пропуска ошибки (чаще всего несоответствие косвенному требованию, непокрытому документацией) возрастает.
    • Плохая локализация ошибки тестировщиком. Либо полное отсутствие локализации. Фактический результат не совпал с ожидаемым – ошибка. А что это на самом деле: ошибка; проявление ошибки; инцидент, уже описанной ошибки, тестировщик не проверит (в подавляющем количестве случаев).
    • Высокий требуемый уровень квалификации специалиста для создания и поддержания тестовой документации.
    • Большие временные затраты на создание и поддержание тестовой документации.
    • Слабо прогнозируемое время актуальности тестовой документации.

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

    Из каких этапов состоит процесс тестирования?

    1. инициация,
    2. выявление требований прямых и косвенных,
    3. генерация тестовых случаев,
    4. отбор показательных тестовых случаев,
    5. проведение проверок,
    6. фиксация результатов,
    7. анализ результатов,
    8. передача информации о соответствии проверенного продукта требованиям.

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

    • доступно необходимое тестовое окружение,
    • доступен билд/ресурс/предмет тестирования,
    • код, БД, прочие компоненты объекта тестирования «заморожены», т. е. не изменяются в период всей сессии тестирования,
    • модификация требований (хотя бы прямых) «заморожена»,
    • известно направление тестирования,
    • известны сроки на сессию тестирования.

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

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

    Отбор тестовых случаев – отбор наиболее показательных, значимых и воспроизводимых тестовых случаев. От этого этапа зависит, насколько тестирование будет полезным, эффективным и анализируемым. Например, в «простом» примере с красной кнопкой понятно, что количество косвенных требований стремится к бесконечности, и проверять их все подряд – полный абсурд, но подобные кейсы должны быть сгенерированы хотя бы в голове проверяющего. А для того чтобы они не вошли в проверки, необходимо выполнить соответствующий отбор и проверить только, действительно ли кнопка красная.

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

    Проведение проверок – тут все понятно. Либо согласно документации, либо ad hoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок. Почему-то большинство именно этот пункт называет тестированием. И в голове обывателя, незнакомого с профессией, только один этот пункт и содержится J.

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

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

    Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п. Но это – уже QA J!

    Вместо послесловия

    Внимательный читатель заметил, что вопросы набирают сложность от начала к концу беседы. Вместе с тем, стоит отметить, что все эти вопросы не должны затруднить специалистов по тестированию, то есть тех, кто не «просто кликал мышью – тестировал», а пытался разобраться в сути того, чем он занимается, тех, кто не остановился на одной книжке или одном ресурсе, а продумал и обосновал свои действия… хотя бы для самого себя.

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

    • Тестирование IT-систем
    • Тестирование веб-сервисов
    • Тестирование мобильных приложений

    Что такое тестовое окружение в тестировании

    Многие начинающие тестировщики задают вопрос, что такое тестовое окружение в тестировании.

    Давайте ответим на этот вопрос.

    Окружение (environment) — это среда, место, машина, на которой находится приложение, сайт. Например, хостинг — это место, где хранится сайт, хостинг — это окружение, где может располагаться сайт.

    Тестовое окружение (test environment) — это то место, где тестировщик тестирует сайт, приложение, программу.

    В процессе разработки, как правило, существует несколько тестовых окружений.

    Зачем нужно иметь несколько тестовых окружений? Дело в том, что большие системы могут быть развернуты не на одной машине, не на одном окружении, а на нескольких, это уже называют кластером. А разработчик пишет код не на нескольких машинах, а на одной, поэтому выделяют ещё другой тип тестового окружения — локальное окружение.

    Локальное окружение — это всего одна машина, на которой разрабатывают, тестируют приложение.

    Боевое окружение — это уже реальная сеть машин, совокупность нескольких окружение, это уже нетестовое окружение, а самое настоящее окружение, где работают пользователи приложения.

    Чтобы не тестировать на боевом окружении, но при этом нужно проверить работу сразу на нескольких машинах, создают тестовое окружение из нескольких машин.

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

    Теперь Вы знаете, что тестовое окружение в тестировании.

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

    Похожие публикации:

    1. Pgadmin что это
    2. Php как создать переменную
    3. Как поймать бандита
    4. Как сделать переключение картинок в html