Конференция_ConfetQA

Отчет о конференции ConfetQA
День первый
Первый день конференции был посвящен
автоматизации тестирования и системам логирования.
Первый доклад был посвящен обзору инструмента тестирования
TestComplete. В целом доклад напоминал собой рекламу инструмента. В
целом из доклада полезных знаний для себя получил. Во-первых, как такого
обзора я и не услышал, кроме как он все умеет делать, он лучший и я вам его
советую. Во-вторых непосредсредтвенно работа на нем и не была
продемонстрирована. В-третьих инструмент платный (цена от 1,4 – до 4
тысяч долларов). В четвертых, для тестирования только вебприложений, его
не рекомендуется использовать. Есть гораздо более дешевые и лучшие
инструменты.
Нашел ссылку на библиотеку книг по тестированию http://testbooks.ru/
$intCount полезных советов по логированию в автотестах,
Илья Фомин
Второй доклад был посвящен библиотекам логирования. В основе доклада
был упор сделан упор на создание собственного логгера, которые будет
отвечать всем вашим требованиям. Приведу ниже список оснонвных
требования к логам:
 Ориентация на различных читателей
o Читаем машинами
o Читаем тестировщиками
o Читаем разработчиками
o Читаем менеджерами
 Использовать HTML
o Человекочитаем
o Интерактивен
o Самодостаточен (можно отправить по почте)
o Допускает текстовый поиск
o Можно встроить в web-приложение
 Не забывать про стандартный лог (чаще всего подробный, ибо
пригодится)
 Возможность различных форматов для интеграции
 Стремление к полноте
o Во всех логах – вся необходимая информация
 Скриншоты проваленных шагов и ошибок (не только проблемных
элементов, а всего экрана)
 Возможность включать один лог в другой
 Фильтры отображения
o Несколько уровней
o Debug
o Message
o Screenshot
o Checkpoint
o Warning
o fail
 Иерархичность
 Цветовое кодирование





o Сообщения
o Графика
o Почта
Использование матриц
Введите известные типы ошибок
Централизация хранения
Создание библиотеки верификаторов
И не забывать про unicode
Строим Web Testing Framework за 20 минут, Андрей
Дзыня
В третьем докладе продемонстрировали создание фреймворка для
тестирования приложения, с использованием Java и Selenium 2. К сожалению
для меня, вообще не знакомого с данной темой, доклад в первый день
прошел практически мимо. Однако благодаря ему, я познакомился со
структурой создания автоматических тестов, программой селениум. Которая
оказалось очень полезной и очень необходимым инструментов для
автоматизации тестирования. Так как доклад для был людей знакомых с
инструментом селениум, считаю необходимым вернуться к докладу через
некоторое время и заново прослушать и проанализировать
Второй день конференции
1.Явные и неявные требования
Тестировщик не должен уповать на качество работы аналитика и т.п., а
должен сам очень грамотно понимать и выявлять требования – основная
мысль которая прозвучала в докладе. Зачастую тестер протестировав явные
требование пропускает неявные. Которые не указаны, но они исходят из
здравого смысла или спефики разрабатываемой сферы. В докладе прозвучал
ряд примеров. В частности был дан пример интернет-магазина и адреса
доставки. В том что номер дома может быть не только цифрой, а например
1а, квартиры также могут иметь буквенный индекс.
2. «Я не буду это фиксить – это не баг!», или особенности юзабилитибагопроизводства, Андрей Мясников
К юзабилити доклад имел весьма смутное отношение. Доклад был больше
психологическим – “практические советы по воздействию на
программистов”.
Достаточно подробно рассказывалось о необходимости найти к
программисту свой подход. Если программист не хочет исправлять этот баг,
а считает фичей – постараться привести убедительные доводы примеры.
Не забывать про ранее выявленные багги – они могут повториться.
Также в самом докладе было рекомендовано книга “Искусство мыть слона”.
Скачал книгу в электронном виду, просмотрел поверхностно.
3. Интенсивный тестовый цикл, или Планируем аврал, Алексей Лянгузов
Речь шла об авралах в работе и способе использования посторонних
ресурсов.
Автор изложил варианты решения проблемы исходя из личного опыта:
Зачастуя проблема решается через «Авральный метод», но при этом есть ряд
проблем.





Неудобство руководителям тестирования
Отсутствие качественных тестировщиков
Неудобство тестировщиков
Может пострадать тестирование других проектов
Тяжело тестировать не зная предмета и отрасли (не знакомство с
проектов)
Решения «Аврального метода»
 Ротация
 Общекомандная работа
 Поключение программистов
Автор доклада предлаегт улучшить метод, что позволит избежать ошибок.
Запланированный десант.
В сам процесс тестирование запланировать авральное тестирование. Что
позволит избежать проблем.
Чтобы метод работал нужно не забывать про ряд нюансов.
Не нужно отдавать
 Верификацию багов
 Муторные задачи
 Неоригинальные задачи
 Ответственные задачи
 Ненужные тесты
Плюсы данного метода предварительных авральных работ




Знакомство с другими проектами
Новые люди находят новые баги
Реальная помощь и ускорение работ
Нет стресса для тесторов и руководителей
Третий день конференции.
Powershell — швейцарский нож для тестировщика, Игорь Любин
В докладе было продемонстрировано наглядным методом краткое
знакомство с данным средством. Была дана первичная информация о
 Командлетах
 Алиасах
 Конвейере
Познакомил докладчик с основными командами:
 Get-Command
 Get-Help
 Get-Member
Разобрал решение практических задач, как:






Собирать логи, копировать файлы
Запускать/останавливать программы и службы
Выполнять скрипты на удаленной машине
Проверить почту и вытащить нужную информацию из письма
Управлять виртуальными машинами VmWare
Устанавливать дополнительные пакеты в VS2010
«9,8 м/с уверенности»
Автор данного доклада тестировщик крупных интернет-магазинов. В данном
докладе он продемонстрировал некоторые моменты в тесте фильтра
огромного кол-ва товаров при помощи таких инструментов как Selenium IDE,
eclipse и ряда уже написанных скриптов в собственном фреймворке.
Познакомил с системой хранения тест-кейсов RCH. И непосредственно
полный импорт всех тесткейсов в EXcel и последующей обработкой,
форматированием и сортировкой. К сожаленью, не могу описать тезисно
данные действия. Необходимо более детально изучить данное выступление.
Фазиннг
Доклад посвящен был фаззингу. Фаззинг - это один из подвидов
тестирования безопасности. Это процесс отсылки намеренно некорректных
данных в объект с целью вызвать ситуацию сбоя или ошибку. программе
чаще всего подсовываются заведомо неправильные данные, при этом
отслеживаются такие ситуации, когда система не может их обработать и
вылетает. Аварийное завершение работы считается нахождением дефекта в
программе и может привести к дальнейшему выявлению уязвимости.
Можно выделить такие фазы в тестировании как:
• Определение цели
• Определение вводимых значений
• Порождение некорректных данных
• Исполнение некорректных данных
• Мониторинг исключений
• Определение работоспособности
В тоже время к фазингу не относятся ошибки контроля доступа, ошибки в
логике устройства, повреждения памяти, многоступенчатые уязвимости.
Фазтестинг также бывает трех основных видов:
Метод Черного ящика, Белого и Серого ящиков.
А особо активное использование началось в 2006 году, когда при помощи
фаззинга была найдена масса уязвимостей в Internet Explorer, Microsoft Word
и Microsoft Excel. Сейчас фаззинг является одним из самых эффективных
методов выявления проблем безопасности кода.
Выделяется три подхода к выявлению недостатков системы: тестирование
методом черного, серого и белого ящиков. Различие между ними
определяется теми ресурсами, которые доступны во время тестирования.
Метод черного ящика чаще всего используется при работе с удаленными
веб-сервисами или веб-приложениями. При этом данные на входе могут
подаваться в виде запросов, а на выходе получаются какие-то веб-страницы
или значения, с которыми и продолжается работа.
Проводить такое тестирование вручную, без использования автоматизации,
обычно не очень хорошее решение. Но его можно использовать, например,
при свипинге (sweeping) – процессе поиска похожих уязвимостей в
различных приложениях.
Одним из самых популярных на данный момент фаззеров для тестирования
черного ящика является OWASP JBroFuzz. Он бесплатен, но при этом
позволяет проводить самые различные проверки: на межсайтовый скриптинг
(XSS), на SQL-инъекции, на переполнение буфера, целочисленное
переполнение и пр. Он работает с самыми популярными сетевыми
протоколами: HTTP, SOAP, XML, LDAP и др.
Метод серого ящика представляет собой комбинацию из метода черного
ящика и восстановления кода (RCE – reverse code engineering). Сложно
переоценить наличие исходного кода для тестирования безопасности, но
даже если исходного кода нет – не все потеряно. Сходную картину можно
получить при анализе скомпилированной сборки. Оценка безопасности
сборки по отношению к уровню исходного кода называется бинарной
проверкой.
Двоичный файл нельзя преобразовать в исходный код, но можно
преобразовать последовательность инструкций сборки. Для восстановления
кода используются дизассемблеры, декомпиляторы и дебаггеры.
Дизассемблеры преобразуют машинный код в ассемблерный, после чего его
уже может читать человек.
Декомпиляторы статически анализируют и преобразуют двоичный код в
такой формат, который понятен человеку. Т.е. они переводят код не в
ассемблер, а в языковые конструкции более высокого уровня.
Дебаггеры запускают программу-объект или присоединяются к ней и
отслеживают ее выполнение.
Дизассемблеры доступны как платные, так и бесплатные. К самым
распространенным относятся инструменты компаний LogicLibrary, Veracode,
Halvar Flake и др.
Метод белого ящика может применяться только в том случае, если доступен
сам исходный код. Как и для метода черного ящика, проверка может
выполняться вручную или с помощью инструментов. Но как и в
черноящичном случае – проверка вручную трудоемкая и долгая.
Для проверки исходного кода используются на: средства проверки на этапе
компиляции, браузеры исходного кода и автоматические инструменты
проверки исходного кода.
Средства проверки на этапе компиляции обычно уже встроены в
компиляторы и ищут недостатки после создания кода.
Браузеры исходного кода созданы для того, чтобы облегчать мануальный
анализ кода.
Автоматические инструменты проверки исходного кода просматривают
исходный код и определяют потенциальные уязвимости автоматически. Они
бывают как платные, так и свободно распространяемые, но рассчитаны
только на определенные языки программирования, поэтому если какой-то
продукт написан на нескольких языках программирования – понадобится
несколько инструментов. Или же не понадобится ни одного, если такой язык
не поддерживается ни одним из существующих инструментов.
Одним из достаточно распространенных автоматических инструментов
проверки исходного кода является RATS. Он бесплатен и может
использоваться как для UNIX, так и для Win32. Он поддерживает C, C++, Perl,
PHP и Python.
Не существует какого-то одного единственно верного подхода к нахождению
уязвимостей в тестируемом приложении. Зачастую случается так, что
несколько методов, инструментов дополняют друг друга, а не используются
по отдельности.
Следует также помнить, что опытного тестировщика никогда не заменит ни
один автоматический инструмент. Все подобные инструменты – только
средства для облегчения тяжелого труда и сбережения массы времени. Но
все создаваемые ими отчеты все равно должны проверяться опытными
аналитиками, тестировщиками, разработчиками – или кто еще есть из
опытных на проекте?
Фаззинг – это не панацея от всех бед, и 100% результата он не гарантирует.
Фаззинг в частности, нужен нам для того, чтобы потом, в дальнейшем, после
выпуска продукта на рынок не закрывать судорожно найденные
злоумышленниками уязвимости, и не терять на этом десятки, а то и сотни
тысяч каких-нибудь денег.
Четвертый день конференции.
Наглядные нагрузочные тесты в JMeter, Андрей Похилько
Простой нагрузочный тест с Apache JMeter
По моим наблюдениям, разработчики довольно редко делают нагрузочное
тестирование сайтов и веб-приложений. И бывает так, что выставят проект в
Интернет, а тут вдруг посетители начнут ходить (хабраэффект, к примеру,
случился), и сайт в самый подходящий момент ложится или начинает не подетски тормозить.
Почему бы не избежать этих неприятностей, прогнав нагрузочный тест?
Наверное, кого-то останавливает неверное представление о том, что
нагрузочное тестирование — это очень сложное дело, требующее
специальных знаний. Однако не боги горшки обжигают. Если выбор —
тестировать не слишком профессионально, или не тестировать вовсе, я бы
выбрал первое. Тем более, что организовать примитивный тест
производительности очень даже просто. Можно воспользоваться онлайнсредствами (см., например, Нагрузочное тестирование по-быстренькому), а
можно замутить все своими руками, это ненамного сложнее.
Под катом рассказываю, как с нуля организовать незамысловатый
нагрузочный тест сайта при помощи Apache JMeter.
Сразу хочу предупредить, что описанный подход (Log Replay) хорошо
работает именно для сайтов, и не годится для веб-приложений, активно
использующих POST, а также, по своей простоте, игнорирует существование
cookie-based сессий. Кроме того, нежелательно тестировать проект,
развернутый по адресу 127.0.0.1, результаты довольно сильно искажаюся изза того, что JMeter и сайт тормозят друг друга (с другой стороны, плохо, когда
сервер далеко — мешают задержки).
Нам понадобится:
1. JMeter
2. Установленная Жаба, в наше время она водится почти на любой
машине
3. Access log нашего сайта. Если access log у нас пустой, нам ничто не
мешает его слегка пополнить, взяв в руки браузер и полазив по сайту.
Можно пройти сайт попавшимся под руку краулером, например
HTTrack или Xenu. Если веб-сервер — IIS, то предварительно нужно
переключить формат лога в NCSA, понимаемый парсером JMeter-а.
Брать лог из-под работающего сервера (когда он туда пишет) не стоит,
лучше взять уже закрытый, скажем, вчерашний, или приостановить
веб-сервер на время выемки лога. Лог стоит посмотреть текстовым
редактором на предмет корректности.
Есть еще неплохой способ генерации файла, который для JMeter'а сойдет за
лог, причем без захода в файловую систему сервера. Добываем откуданибудь список URL сайта. Приемлемый список делает Xenu в отчете о
сканировании. Вставляем этот список в текстовый файл. Получится что-то
вроде
http://test.local/index.php
http://test.local/news/event-12.php
...
Делаем глобальный реплейс «http://test.local» на «"GET » (с кавычкой и
пробелом), получаем
"GET /index.php
"GET /news/event-12.php
...
Этот формат парсер хорошо кушает, принимая за чистую монету (закрывать
кавычки в конце строки не надо).
Итак, скачали JMeter
(http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi,
разворачиваем архив, идем в директорию bin и запускаем jmeter.bat (делаю
пример под Виндой). После небольшой паузы стартует GUI традиционного
жабьего вида.
Слева наблюдаем дерево из 2 узлов: TestPlan и Workbench (про второй сразу
забываем, он нам не понадобится). На Test Plan кликаем правым кликом и
говорим Add->Thread Group (в интерфейсе можно увидеть много фишек
разной степени полезности, но мы сейчас не отвлекаемся, а кратчайшим
путем идем к нашему тесту, потом, если захотим — будем изучать обширные
возможности JMeter подробнее).
Группа потоков добавилась:
Менять мы тут пока ничего не будем. Цифры все стоят по 1, что хорошо. Это
один виртуальный пользователь, поторый один раз выполнит сценарий (в
случае используемого нами Access Log Sampler'а — выполнит один запрос,
соответствующий первой строчке лога). А нам для отладки теста больше и не
надо.
Переименовывать Test Plan и Thread Group тоже не будем, эти названия у нас
в рамках теста уникальны.
Правым кликом на Thread Group добавляем Access Log Sampler (Thread
Group->Add->Sampler->Access Log Sampler)
Вбиваем адрес сервера и локальный путь к аксесс-логу (мы его утащили с
сервера и положили к себе на диск):
Теперь добавляем в тест средства отображения:



Thread Group->Add->Listener->View Results in Table
Thread Group->Add->Listener->Graph Results
Thread Group->Add->Listener->Aggregate Report
Во View Results in Table надо заполнить поле Filename (если не указывать
путь, лог-файл образуется рядом с jmeter.bat). Создавать лог необходимо для
отладки, так как JMeter в своем GUI толковой информации об ошибках не
выводит.
Тест-план готов, переходим к его тестированию :) и отладке (ничего-ничего,
он может и с первого раза заработать).
File->Save, и так каждый раз после внесения изменений в тест-план. Это
важно, JMeter другой раз виснет, и тест приходится восстанавливать по
памяти.
Run->Clear All (на первый раз можно не делать, но потом все равно
понадобится).
Run->Start.
И идем смотреть во View Results in Table. Если нам повезло, там будет одна
строчка, с зеленой галочкой в колонке Status.
Если что-то пошло не так, в статусе будет ошибка:
Если такое дело, идем читать наш TestPlan.log. Как правило, по сообщениям
в нем можно догадаться, что именно сломалось. Например, если
тестируемый сервер не отвечает, в логе оказывается такая ругань: rc="Non
HTTP response code: java.net.ConnectException" rm="Non HTTP response
message: Connection refused: connect". Такой текст rc="Non HTTP response
code: java.net.ProtocolException" rm="Non HTTP response message: Invalid HTTP
method: null" скорее всего свидетельствует о том, что строка акцесс-лога
неправильно распарсилась.
Положим, разобрались, или все сразу прошло чисто. Идем в свойства Thread
Group и ставим Loop Count: Forever
Запускаем (File->Save, Run->Clear All, Run->Start). Идем смотреть во View
Results in Table. Должно получиться как-то так:
В последней строчке ошибка, это JMeter испытывает расстройство оттого, что
файл закончился (видно, привык работать с бесконечными файлами). К
сожалению, по окончании файла сценарий останавливается, игнорируя
настройку Action to be taken after a Sampler error = Continue (мне это кажется
багом, а разработчикам наверняка фичей). Чтобы это не исказило результаты
теста, лучше брать достаточно длинные аксесс-логи. Длинный файл
несложно организовать из короткого с помощью copy в командной строке
или Ctrl+C, Ctrl+V в текстовом редакторе. Для наших опытов больше 1000
строк в логе вряд ли понадобится.
Еще, прежде чем начать тест, добавим в начало сценария случайную
задержку (Uniform Random Timer) 0-1000 миллисекунд, она обычно помогает
несколько сгладить графики. Сценарий в результате работает так: ждет
случайное количество миллисекунд, читает строку из лога, делает HTTP
запрос, передает результаты листенерам, снова ждет, читает следующую
строчку, и так далее.
Делаем первый, пристрелочный, тест. В свойствах группы потоков поставим:
Number of Threads (users): 100, Ramp-Up Period (in seconds): 100. Мы
собираемся натравить на сайт 100 виртуальных юзеров, вводя их в бой по
одному в течении 100 секунд, то есть по юзеру в секунду. Цифры 100 и 100 я
взял откуда-то с потолка, но надо же с чего-то начать.
Еще раз напомним себе, что мы имеем хорошие шансы притормозить или
даже завалить сайт (что может быть нехорошо, если речь идет об уже
работающем проекте). ОК, будучи в здравом уме и трезвой памяти,
осознавая ответственность за свои действия, начинаем.
File->Save, Run->Clear All, Run->Start и идем смотреть Graph Results. Видим,
скажем, такую картинку:
В правом верхнем углу можно наблюдать текущее количество виртуальных
пользователей.
О чем говорит нам этот график? Среднее время отклика (Average) растет, а
скорость обработки (Throughput) не меняется. Это значит, что где-то на
сервере операции становятся в очередь, и производительности не хватает,
чтобы обслужить все запросы. Зайдя браузером на сайт, убедимся, что он
еле ворочается или вообще не респондит. Зачем зря мучить несчастного?
Run->Stop. Ну вот, сайт снова ожил. Неудачная идея во время такого теста —
отвлечься ненадолго и, вернувшись через несколько часов (как это бывает),
обнаружить, что сайт полдня лежал.
В качестве содержательного результата мы получили одно число —
максимальное значение Throughput (183 запроса в минуту). Можно считать
его пределом производительности. Для начала этого числа может быть
достаточно, например, уже ясно, что 100 000 хостов в сутки наш сайт не
потянет.
Внимательно посмотрев на график времени отклика, можно увидеть полочку
в его начале. В это время нагрузка росла, а реакция сервера не менялась, то
есть ему было хорошо. Попробуем более подробно изучить этот диапазон
нагрузок. Уменьшив Number of Threads и увеличив Ramp-Up Period, получаем
такую картинку:
Видим, что сайту поплохело после 3 виртуальных юзеров и 150 запросов в
минуту. Для уверенности теперь есть смысл провести тест со статической
нагрузкой. Ставим Number of Threads = 3, Ramp-Up Period= 0 (вводим потоки
сразу) и смотрим, что получилось. Вроде все нормально, сайт реагирует
живенько. Если хотим, снимаем несколько таких точек и на бумажке строим
график. Эти цифры сильно достовернее, чем наблюдения по графику с
динамической нагрузкой.
Заглянем теперь в Aggregate Report. Там для нас приготовлена статистика по
URL-ам
(лучше всего смотреть после теста с большой, но не чрезмерной статической
нагрузкой). Нас в первую очередь интересует колонка Average, среднее
время отклика. Часто оказывется что есть несколько тяжелых страниц,
которые в первую очередь и создают нагрузку на систему, и если их
оттюнить, общая производительность многократно увеличивается (лучше
всего начинать оптимизацию со страниц, которые по статистике вызываются
часто, а отрабатывают долго). Справедливости ради надо отметить, что не
всегда самые долгоиграющие страницы дают наибольший вклад в нагрузку,
но чаще это так.
Пара слов об интерпретации полученных чисел: 3 виртуальных юзера, 150
запросов в минуту. Как эти величины соотносятся с реальными
пользователями и, скажем, запросами страниц в сутки? Практически никак,
мы не ставили себе цель смоделировать реального юзера. То, что мы имеем
— относительная величина, на которую можно ориентироваться в процессе
тюнинга. В данном случае 3 юзера получены при тестировании по списку
урлов сайта, и «лог» не содержит картинок, css и прочих ресурсов. Так что
150 per minute как раз соответствуют настоящим запросам страниц в минуту.
Если мы использовали реальный лог, то можно взять Aggregate Report,
экспортировать его в csv (внизу есть кнопочка Save Table Data), повыкидывать
из него все обращения к ресурсам, посчитать оставшиеся хиты и разделить
на продолжительность теста.
В заключение хочется предупредить об одном недостатке описанного
способа. Поскольку все виртуальные пользователи выполняют запросы в
одном и том же порядке, эффективность кэширования на всех уровнях будет
очень высокой. В реальности эффективность будет меньше, и это вносит в
результаты наших исследований с трудом оцениваемую погрешность (кстати,
надо будет написать сэмплер, который дергает строчки из лога в случайном
порядке… если руки дойдут).
Но зато такой тест делается легко и быстро и обладает хорошей
производительностью, так что для начала, имхо, в самый раз.
http://easyjmeter.blogspot.com/
http://andrei-zhukov.livejournal.com/1015.html
Исследовательское тестирование: инструкция пользователя, Глеб Рыбалко
Доклад был посвящен исследовательскому тестированию, однако больше
внимания уделялось теории и общему подходу, чем конкретным и
наглядным примерам. Автор предлагает на начальном этапе определить
прежде всего цели исследовательского тестирования.
В определении целей поможет ряд действий. Во-первых нарисовать схему
всего тестирования. И выделить в ней непосредственно исследовательное
тестирование. А далее определить кто будет и как тестировать.
Обязательным условием тестировщика – наличие доменных знаний (знаний
в области проекта, ибо невозможно провести полноценное
исследовательское тестирование, не будучи знакомым со специкой той
сферой где проводится тестирование, будь то спорт или медицина).
При исследовательском тестировании необходимо рассматривать в первую
очередь и использовать:
• Спецификации
• Дизайн системы
• Архитектура системы
• План тестирования
• Тест кейсы
• Руководства пользователя
И непосредственно источники откуда берется информация на практике
• Требования
• Тест дизайны
• Use Cases
• Разработчики
• SUT
• Пользователи
В результате исследовательского тестирование тестировщик получает
дефекты, тестовые сценарии и раннюю обратную связь о продукте
Кроссбраузерное тестирование, Алексей Баранцев
Большинство вебприложений в различных браузерах работают по-разному.
Это связано с несколькими факторами
 неоднозначность стандартов
 баги в браузерах
 разные окружения
 разные версии приложения
Поэтому при кроссбраузерном тестирование в первую очередь надо
смотреть на:
 Верстка
o шрифты, цвета, расположение
 Баги в браузерах
 Навигация
o ссылки, back/forward, cookies
 JavaScript
Веб-приложение должно соответствовать стандартам. Основные стандарты




HTML
CSS
RSS
Accessibility
Помощь разработчику для проверки соответствия стандартам - Firefox Web
Developer
Кроссбраузерное тестирование проводится после того как приложение
 Соответствует стандартам
 Проверена система ссылок
o Xenu Link (рекомендуемый инструмент)
 Проверено в одном браузере (любом). Рекомендовано FF
o функциональность
o верстка, навигация
o производительность
После чего необходимо уже начинать тестирование на кроссбраузерность
 Сравнение с требованиями (особенно если они разные)
 Сравнение с эталоном (особенно если нет требований)
При кроссбраузерном тестирование варьировать также следующие значения
и параметры:
 Разрешение экрана (ширина!)
 Количество цветов
 JavaScript
Не рекомендуется использовать мультипаки (возможно расхождение в
отображение). Рекомендуется виртуальные машины.
 Windows Virtual PC
 Oracle VirtualBox
 Xen
Сервисы скриншотеры не очень хорошо. Сервисы браузеры в облаке –
хорошо. Рекомендуемый сервис scout
Mindmap, cheklist, testcase: способы контроля результатов
тестирования, Станислав Косарев
Доклад о том, как делегировать задачи по тестированию без перепроверок,
экономя своё время и не переживая за результаты тестирования. А также
частично о контроле тестирования.
Для чего нужен контроль?




Контроль для ваших подчиненных
Контроль для вашего руководства
Контроль для заказчика
И др...
При этом контроль не должен быть перепроверкой. Перепроверка плохо.
Вы теряете драгоценное время
Если подчиненные знают что за ними перепроверяют:
- Демотивируются
- Перестают чувствовать ответственность
Инструменты которые могут помочь в данных вопросах:
1.Mind Map
Диагра́мма свя́зей, известная также как интелле́кт-ка́рта, ка́рта ума́ (англ.
Mind map) или ассоциати́ вная ка́рта, — способ изображения процесса
общего системного мышления с помощью схем.
Использование иструмента как:
 Как инструмента для проектирования тестов
 Как инструмента для хранения результатов
 Как таск трекера
Где использовать?





Небольшая команда
Небольшой проект
Исследовательское тестирование
«Документация для себя»
На начальных этапах проектирования тестов
2.Check List
- Как инструмента для создания и хранения тестов
- Как инструмента для хранения результатов
- Как инструмента для сбора метрик
3.Test Case
это артефакт, описывающий совокупность шагов, конкретных условий и
параметров, необходимых для проверки реализации тестируемой функции
или её части
- Как инструмента для создания и хранения результатов
- Как инструмента для сбора метрик
- Как документации для обучения новичков
Где использовать
- В больших проектах
- В проектах с «маленькими оборотами»
- В больших командах
- В системах с надежностью 99.9%
Способы оценки эффективности тестирования, Наталья Руколь
Оценка эффективности тестирования необходима в первую очередь для
самого тестера. Правильно оцененная эффективность позволит принимать
взвешенные решения, улучшать свои результаты.
Оценки бывают
измеримые и субъективные
мнение или цифры
финальные и косвенные
процессные и результатные
как проработали и что сделали
Метрики результата.
 Реакция клиента
o Продажи продукта
o Отзывы клиентов
o % пропущенных дефектов
o Возврата продуктов
 Колличество пропущенных хотфиктсов
 Затраты на поддержку продукта
Метрики проекта





Ошибки (качество и колличество)
Тестовое покрытие
Скорость тестирования
Эфективность планирования
Взаимодействие с командой
Субъективные оценки
 Мнение руководства
 Мнение команды
 Опросы
Опросы позволяют выявить скрытые проблемы, принять новые идеи
состороны, понятие куда двигаться и что нам удалось изменить,
отслеживание прогресса/регресса
Понятие эффективности тестирования – первый путь к совершенствованию