Русский
Русский
English
Статистика
Реклама

Тестирование игр

Управляемость транспортного средства в симуляторе настраиваем коэффициенты модели

18.01.2021 22:06:54 | Автор: admin


Геймплей симулятора транспортного средства управление движением транспортного средства в пространстве с некоторым количеством степеней свободы. Действия игрока изменяют вектор мгновенного состояния системы в желаемом или не совсем желаемом направлении. Игра вряд ли сможет быть интересной, если объект слабо приспособлен к управлению игроком.

Приспособленность технической системы к управлению человеком (управляемость) довольно сложная и многогранная характеристика. Математической моделью поведения управляемого объекта занимается теория автоматического управления (ТАУ). Модели, принятые в ТАУ, могут описывать и поведение игрока человека-оператора, и поведение системы человек-машина.

Стоит отметить, что создаваемые модели человека всегда актуальны для ограниченного набора условий. По этой причине решение практических задач в области управляемости часто выходит за рамки ТАУ.

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

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

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

Постановка задачи


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

Описание системы


В экспериментах будем использовать симулятор с 3D-графикой.

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

Ниже будут применены следующие упрощения:

1. Направление движения объекта принимается совпадающим с его продольной осью.

2. Вращательное движение объекта может рассматриваться как сумма независимых составляющих вращательных движений относительно трех осей связанной с объектом системы координат (ССК).

3. Угловое ускорение в отдельном канале управления (вокруг отдельной оси ССК) определяется линейной комбинацией текущих значений управляющего действия и угловой скорости в этом канале.

Приемлемость первого упрощения в моделировании реальных объектов определяется свойствами системы и решаемой задачей. Например, общеизвестным свойством дротиков является их способность лететь после броска острием вперед. Этой простой модели достаточно, чтобы получить полезный вывод: не стоит подбрасывать дротик вверх над собой.



Но если необходима точная модель для определения последствий контакта дротика с целью, то следует учитывать, что в полете его вектор скорости составляет некоторый угол с продольной осью.

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

П. 2 устанавливает взаимную изолированность каналов управления, прикрепленных к осям ССК.



Оси ССК: продольная (X) направлена от хвоста к носу объекта, вертикальная (Y) направлена в плоскости симметрии объекта вверх при его начальном положении, боковая (Z) направлена перпендикулярно первым двум вправо. Соответственно, вращение вокруг оси X боковой канал, вокруг оси Y путевой канал, вокруг оси Z продольный канал.

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

П. 3 устанавливает наличие только двух крутящих моментов в каждом канале управления:

  • управляющий момент, пропорциональный сигналу от управления игрока;
  • момент демпфирования, пропорциональный текущей угловой скорости.

Дифференциальное уравнение вращения вокруг оси i выглядит следующим образом:



Здесь омега угловая скорость вращения, t время, x управляющий сигнал, а коэффициенты в правой части уравнения частные производные углового ускорения по управляющему сигналу и угловой скорости.

Первый коэффициент будем называть коэффициентом эффективности управления, второй коэффициентом демпфирования.

Угловое ускорение измеряется в [рад/с2], угловая скорость в [рад/с]. Управляющий сигнал обычно измеряется в единицах перемещения рычагов или усилий на них, реже в единицах положения промежуточных элементов системы управления, но для управления с клавиатуры примем эту величину безразмерной. Размерность коэффициента демпфирования [1/c], а коэффициента эффективности управления [рад/с2] с учетом принятой размерности управляющего сигнала.

Необходимые теоретические сведения
Система, описываемая уравнением (1), с точки зрения ТАУ является апериодическим звеном первого порядка. Ниже рассмотрим альтернативный набор параметров, определяющих свойства такого динамического звена. Роль всех параметров в поведении объекта оценим с помощью нескольких характеристик, принятых в ТАУ:

  • переходной функции;
  • амплитудной частотной характеристики (АЧХ);
  • фазовой частотной характеристики (ФЧХ).

Входной сигнал звена в уравнении (1) x, выходной угловая скорость. В стандартном виде уравнение апериодического звена первого порядка записывается следующим образом:



Здесь х(t) входной сигнал, y(t) выходной сигнал, точка над y производная по времени, k коэффициент усиления звена, T постоянная времени, характеризующая инерционность звена.

Сопоставление уравнений (1) и (2) приводит к следующим соотношениям:





Рассмотрим переходную функцию (переходный процесс) системы, описывающую ее реакцию на ступенчатый входной сигнал в виде функции Хевисайда. Значение такого сигнала равно нулю для отрицательных значений аргумента (времени) и единице для неотрицательных. Переходная функция зависимость от времени выходного сигнала.



Переходный процесс апериодического звена первого порядка описывается следующим уравнением:



Уравнение демонстрирует роли коэффициентов:

  • k соответствует установившемуся значению выходного сигнала;
  • T оправдывает название постоянная времени, например, за время t = 3T выходной сигнал достигает уровня 0,95k.

Переходному процессу можно дать следующее неформальное описание:

1. В начальный момент времени ускорение достигает максимального уровня (равно коэффициенту эффективности управления), скорость не успела получить приращения, и демпфирование на систему не влияет.

2. Скорость растет, рост скорости влечет за собой рост влияния демпфирования, суммарное ускорение снижается.

3. Демпфирование асимптотически приближается по своему уровню к управляющему действию, соответственно, ускорение становится пренебрежимо малым, а скорость приближается к значению коэффициента k.



Таким образом, ступенчатый входной сигнал управления приводит к плавному нарастанию угловой скорости до некоторого уровня. Достигаемое значение и плавность нарастания зависят от величин k и T.

Частотные характеристики описывают реакцию системы на входной сигнал в виде гармонических колебаний. АЧХ и ФЧХ являются функциями частоты входного сигнала.

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

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

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




При заданной частоте входного сигнала значение АЧХ соответствует амплитуде установившихся колебаний выходного сигнала, отнесенной к амплитуде колебаний входного сигнала. Значение ФЧХ равно сдвигу фазы колебаний выходного сигнала относительно колебаний входного.

Значение АЧХ апериодического звена первого порядка при отсутствии колебаний (значение частоты равно нулю) соответствует значению k. Это свойство легко выводится из рассмотренной выше переходной характеристики.



Снижение амплитуды выходного сигнала с ростом частоты входного определяется значением T (или значением коэффициента демпфирования). Звено с меньшим значением T лучше пропускает сигнал.

ФЧХ определяется только значением коэффициента демпфирования (или T).



Фазовое отставание растет с увеличением частоты, асимптотически приближаясь к уровню минус ПИ/2. Меньшее фазовое отставание при равных частотах входа соответствует моделям с меньшими значениями T.

Частотные характеристики наглядно показывают роли коэффициента демпфирования и постоянной времени звена: слабое демпфирование (большие значения T) ведет к потере амплитуды выходного сигнала и росту его фазового отставания.

Условия эксперимента и критерии качества модели


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

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

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

Управление аппаратом будет осуществляться с ограничениями по углам крена и тангажа (60 градусов в обоих направлениях для обоих углов): выход за ограничения ведет к аварии. Также к аварии ведет столкновение с горизонтальной поверхностью, расположенной над объектом. Эта часть условий отвечает за составляющую выдерживания параметров в задаче игрока.

Значение модуля линейной скорости объекта принимается постоянным. Это означает, что управление акселератором, как и неравномерность сопротивления среды, в симуляторе отсутствует.

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

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

A, B, C N, O,
A, B, C N, O,
A, B, C N, O
.

Каждому экспериментальному прохождению предшествовала одна тренировочная игра с соответствующей моделью.

Симулятор


Экспериментировать с коэффициентами модели самостоятельно можно здесь.

Управление коэффициентами находится в правом верхнем углу экрана. Параметр efficiency коэффициент эффективности управления, параметр damping коэффициент демпфирования, взятый с обратным знаком.

Управление игрой:

  • Пробел старт игры;
  • W/S вращение вокруг оси Z ССК, нос вниз/нос вверх;
  • A/D вращение вокруг оси Y ССК, поворот влево/поворот вправо;
  • 4/6 на нумпаде вращение вокруг оси X ССК, крен левый/крен правый.

На индикаторе лобового стекла игрок видит искусственный горизонт, а также текущие значения курса (heading) и глубины (depth), то есть расстояния до опасной поверхности. Также показывается остаток времени игры и текущий результат (score) количество посещенных локаций.

Код симулятора написан на JavaScript с применением библиотеки Three.js. Значения параметров движения объекта обновляются в игровом цикле численным интегрированием уравнения (1) по методу Эйлера. В каждой итерации вызывается метод update() объекта vehicle, выполняющий вычисления для каждого канала управления:

vehicle.update = function () {    //определение интервала времени в секундах:    game.elapsed = (new Date() - game.time) / 1000;    game.time = new Date();    //другие действия...    //обновление значений угловой скорости в радианах в секунду:    vehicle.omegaX += (vehicle.epsilonX - vehicle.omegaX * vehicle.damping) * game.elapsed;    vehicle.omegaY += (vehicle.epsilonY - vehicle.omegaY * vehicle.damping) * game.elapsed;    vehicle.omegaZ += (vehicle.epsilonZ - vehicle.omegaZ * vehicle.damping) * game.elapsed;    //другие действия...}

Поля epsilonX, epsilonY и epsilonZ объекта vehicle содержат составляющие углового ускорения при отсутствии демпфирования. Значение каждого из этих полей получается умножением входного сигнала на коэффициент эффективности управления:

function init() {    //другие действия...    //ввод с клавиатуры:    document.addEventListener('keydown', function (event) {        if (game.state == "READINESS")            if (event.code == "Space") {                //запуск игры...            }        if (game.state == "RUN")            switch (event.code) {                case "KeyW":                    vehicle.epsilonZ = vehicle.efficiency;                    break;                case "KeyS":                    vehicle.epsilonZ = -vehicle.efficiency;                    break;                case "KeyA":                    vehicle.epsilonY = -vehicle.efficiency;                    break;                case "KeyD":                    vehicle.epsilonY = vehicle.efficiency;                    break;                case "Numpad4":                    vehicle.epsilonX = vehicle.efficiency;                    break;                case "Numpad6":                    vehicle.epsilonX = -vehicle.efficiency;                    break;            }    });    document.addEventListener('keyup', function (event) {        switch (event.code) {            case "KeyW":                vehicle.epsilonZ = 0;                break;            case "KeyS":                vehicle.epsilonZ = 0;                break;            case "KeyA":                vehicle.epsilonY = 0;                break;            case "KeyD":                vehicle.epsilonY = 0;                break;            case "Numpad4":                vehicle.epsilonX = 0;                break;            case "Numpad6":                vehicle.epsilonX = 0;                break;        }    });    //другие действия...}

Результаты эксперимента


Показатель качества модели будем рассматривать как функцию двух переменных. Соответственно, результаты исследования в графическом виде представляют собой 3D-поверхность, каждая точка которой определяет свою модель управляемого объекта.



Рассмотрим ключевые особенности некоторых моделей. На графике обсуждаемые модели обозначены латинскими буквами.

При минимальном значении коэффициента эффективности управления (0,5 рад/с2) существует модель с наилучшим значением коэффициента демпфирования (точка А). Модель А характеризуется слабой способностью объекта к динамичным маневрам.

Изменение модели А в сторону усиления демпфирования приводит к созданию моделей, имеющих крайне низкие максимальные значения угловой скорости. Объект окончательно теряет способность к маневрированию.

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

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

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

Модель C объединяет достоинства моделей A и B. Объект управляется достаточно эффективно, но без раскачки. Значение показателя результативности игры у модели C заметно выше, чем у предыдущих моделей. Тем не менее, эта модель не является наиболее результативной.

Форма изолиний результативности игры в окрестностях точки C показывает, что улучшению результата соответствует движение в направлении модели D.

Это движение соответствует снижению значения T при сохранении k на постоянном уровне (около 0,6 рад/с). Модели, расположенные между C и D, превосходят C по результативности игры. В игре с этими моделями объект управления более четко следует нажатиям клавиш.

При движении от модели C к модели D происходит еще одно изменение: ухудшение естественности поведения объекта. Постоянная времени приближается к уровню, при котором длительность переходного процесса и сдвиг фазы выходного сигнала перестают быть заметными для пользователя.

Изменение модели D в сторону дальнейшего снижения значения T при сохранении значения k уже не дает существенных улучшений, потому что сдвиг фазы выходного сигнала и длительность переходного процесса у модели D и без того достаточно малы для восприятия игрока.

Модели, получаемые дальнейшим улучшением D, с точки зрения игрока ничем не отличаются от реализации усилительного звена: в игре отсутствует угловое ускорение объекта, угловая скорость при нажатии клавиши мгновенно принимает установившееся значение.

Проведенный анализ позволяет сделать следующие выводы:

1. Оптимальные значения параметров модели соответствуют ее вырождению в усилительное звено (значение k составляет около 0,6 рад/с, T = 0 с) и потере естественности поведения объекта.

2. Модель, обеспечивающая хорошую управляемость при естественном поведении объекта, соответствует точке C на графике (коэффициент эффективности управления: от 2 до 3 рад/с2; коэффициент демпфирования: от -4,5 до -3,5 1/с).

3. Изменение модели C в направлении снижения значения T при k = const позволяет получить объект с улучшенной управляемостью за счет ухудшения естественности его поведения.

Неучтенные факторы


Вместе с упрощениями физики управляемого объекта на качество результатов исследования влияют и другие упрощения условий исследования:

1. Модель управляемости описывалась двумя значениями параметров, во всех каналах управления объект вел себя одинаково. Для получения точной картины следует варьировать значения шести параметров, поскольку нет оснований считать свойства игрока одинаковыми для всех каналов.

2. Полученные результаты актуальны для настроек поля зрения камеры, используемых в игре. Изменение этого параметра окажет заметное влияние на взаимодействие игрока с объектом.

Наиболее серьезный недостаток исследования отсутствие статистики. Любое эргономическое исследование должно ориентироваться на свойства целевой аудитории в целом. Более полные результаты могут быть получены при участии группы игроков.
Подробнее..

Самый полный список метрик тестирования на русском языке

15.03.2021 14:07:31 | Автор: admin

За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот высокоинтеллектуальная управленческая задача. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании?

Ключевой парадокс тестирования за эти годы так и остался нерешенным: как оценить результаты процесса, который не производит конкретный, ожидаемый заказчиком продукт? Никому не нужны баг-репорты и тест-кейсы, всем нужен только качественный софт, да ещё и выпущенный вовремя. Как в таких условиях показать ценность работы QA-команды? Здесь нам на помощь приходят метрики, и на текущий момент наверное уже в каждом проекте по разработке софта собираются какие-то измеримые показатели тестирования. Тест-менеджеры понимают, что какие-то метрики им надо внедрить, это в тренде, и начинают искать, что бы им такого померять на проекте? Статьи, форумы, доклады на конференциях пестрят конкретными примерами метрик, которые начинающие тест-менеджеры спешат посчитать на своих проектах. Но так не работает!

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

Для чего нужны метрики?

1. Оценка прогресса. Если перед нами стоит какая-то задача, которую невозможно выполнить здесь и сейчас, нам нужен инструмент оценки, чтобы понять, ведут ли наши действия к ожидаемому результату?

Допустим, вам повезло, и выдумыванием целей заниматься не нужно. Руководитель проекта ставит задачу: надо проводить тестирование сборки не более, чем за 3 дня, чтобы мы могли своевременно выдавать новые версии заказчику. Вы считаете текущее положение дел - сборка тестируется 6 дней. Что делать? Оптимизация тестовых наборов, автотесты, расширение штата, аутсорс Разобрав все возможные решения в команде, вы выбираете путь тотальной автоматизации, и усиленно работаете в этом направлении. Через полгода приходит раздосадованный РМ, машет руками и кричит Что за фигня?!. Вы смотрите, сколько в среднем уходило последние релизы на тестирование - 8 дней. Как так??

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

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

Начнём наш пример опять с готовой цели: высокие оценки пользователей в аппсторе. Сейчас у нас в среднем 3.7, а руководство требует 4.5. Простые измеримые показатели, считать просто, над дверью повесить - не проблема Но зависит ли от нас напрямую этот показатель? И как мы будем его улучшать сегодня и завтра, если ближайший большой релиз только через полгода?

В таком случае мы ищем косвенные процессные метрики, которые будут вести нас к повышению оценок. Читаем отзывы и выясняем, за что снижены оценки. Находим три лидера по упоминаниям среди жалоб: падения на нестандартных окружениях, медленная скорость работы, нехватка запрошенных фич. Отлично, с этим уже значительно понятнее, как работать, чем с абстрактной оценкой нравится/не нравится! Мы можем выбрать метрики, которые помогут нам оценить свою работу (покрытие тестами на разных окружениях, проведение тестов производительности), так и общепроектные метрики: скорость работы и готовность запрошенных фич. Таким образом мы поможем и самим себе, чётко отслеживая рост требуемого тестового покрытия, и другим участникам команды, сразу показав, чего не хватает для релиза. До выпуска полгода, а поднять число тестовых окружений на 6% я уже могу сегодня!

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

Первый случай - когда в вашей компании кто-то недоволен тестированием, но не может высказать это вслух, или не может сформулировать, чего же он хочет-то. Есть какие-то недомолвки, неудовлетворенности, но понять, что именно не устраивает других участников команды, не представляется возможным. Возникает вопрос: что же именно у нас не так? В этом случае мы начинаем искать подходящие метрики, которые помогут нам сначала выявить проблему, а потом уже поработать над ней. Что-то не так постепенно вырисовывается в пропуски критичных дефектов на прод более 20% или невозможность принимать нужные решения по релизу без оценки показателей качества.

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

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

Допустим, вы приходите к руководству со стандартным списком жалоб: ресурсов не хватает, времени слишком мало, требований нет, код отстой. Скажите ему это, и он будет отмахиваться от вас всеми доступными способами.

Хотите получить результат вместо отмашек? Придите с метриками. Покажите, что экономия ресурсов тестирования в 2000$ обходится проекту в 9000$ на штрафах по договору. Проиллюстрируйте, как экономия недели в начале релиза на написание требований ведёт к задержке релиза в три недели из-за разного понимания ожиданий. Такая беседа всегда будет конструктивнее и результативнее пустой болтовни, не подтверждённой измеримыми показателями!

Метрики: как выбрать и внедрить

Если по написанному выше ещё не стало понятно, что циферки ради циферок не нужны, придётся повториться: никогда не пытайтесь внедрить какую-то метрику просто потому, что она вам кажется логичной или полезной. Всегда идите от задачи, например:

  1. Согласуйте ожидания руководства, зафиксируйте, а потом уже думайте: какими показателями можно оценить именно эту цель?

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

    2.1. Как оценивать прогресс в достижении этого показателя?

    2.2. Как измерять достижения на уровне процесса, пока ключевой показатель, возможно, не меняется?

  3. Вы хотите решить какую-то проблему, непосредственно в команде тестирования или на проекте в целом.

    3.1. Как оценивать эту проблему, в чём её можно измерить?

    3.2. Какие могут быть предпосылки для этой проблемы, очевидные или кажущиеся совсем нелогичными?

    3.3. Как можно обнаружить корень этой проблемы, или узкое горлышко?

  4. Вам надо обосновать что-то своему руководству, и вы исчерпали аргументы:

    4.1. как проиллюстрировать наличие проблемы?

    4.2. как показать пользу от предлагаемого вами решения?

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

  • срывы сроков (для обработки жалобы от РМа)

  • причины срыва сроков (чтобы найти решения проблеме)

  • низкое качество тестирования (для решения жалоб от техподдержки)

  • низкое качество кода (чтобы конструктивно пожаловаться руководителю разработки)

  • отчётность для РМа по качеству продукта (по которой он сможет принимать взвешенные решения)

  • и т.д.

Только когда у вас появится список неуточнённых метрик, вы можете задуматься, как их измерять. Сначала - цели, потом - инструменты!

Примеры метрик в тестировании с описанием вариантов их использования

В рамках курса Аудит и оптимизация QA-процессов мы с Олегом Грабко помогаем ученикам выявлять те метрики, которые будут им максимально полезны в конкретных ситуациях. Из тех более трехсот метрик, которые мы когда-либо использовали, мы выбрали 94, наиболее наглядно иллюстрирующих возможности этих инструментов и приложили их в качестве дополнительного материала к уроку 3. Я очень надеюсь, что изложенной выше статьи достаточно для того, чтобы вы смогли внедрить нужные вам показатели с пользой и существенно улучшить с ними свой процесс тестирования.

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

Скорее всего в этих примерах вы найдёте такие показатели, которые помогут в решении стоящих перед вами задач. Но что делать, если необходимость в метрике вы выявили, но подходящего варианта для её расчёта не нашли? Пишите нам! Обещаем по каждому запросу на вариант внедрения метрики подготовить такой способ расчёта и визуализации, который получится внедрить в ваши условия. Таким образом, постепенно мы сделаем этот документ ещё более полным и полезным для всей отрасли.

Всем качественных продуктов, растущих показателей и зрелых процессов!

Подробнее..

Перевод Ошибку Rockstar может совершить каждый (и я тоже)

12.06.2021 16:15:59 | Автор: admin

Несколько месяцев назад в новостях всплыла потрясающая статья [переводы на Хабре: один и второй] о Grand Theft Auto Online.

Советую прочитать статью целиком, но если вкратце, GTA Online имела внезапно квадратичную производительность при парсинге большого JSON-блоба (из-за многократных вызовов strlen); после устранения этой ошибки время загрузки уменьшилось почти на 70%.

Это вызвало оживлённые дискуссии: в этом виноват C? Или, возможно, "web shit"? Или капитализм и его стимулы?

Однако все были солидарны в одном: они бы ни за что не написали подобной глупости.

(Вы уже чувствуете, что надвигается?)


Одним из моих побочных проектов является высокопроизводительная программа для просмотра 3D-моделей под названием Erizo.


Благодаря продуманному коду она открывает 97-мегабайтный двоичный файл STL на Macbook Pro 2013 года всего за 165 миллисекунд. Это потрясающая скорость.

Из соображений совместимости я написал небольшой парсер и для ASCII STL.

ASCII STL это формат обычного текста с плохой спецификацией, который выглядит вот так:

solid cube_corner          facet normal 0.0 -1.0 0.0            outer loop              vertex 0.0 0.0 0.0              vertex 1.0 0.0 0.0              vertex 0.0 0.0 1.0            endloop          endfacet          facet normal 0.0 0.0 -1.0            outer loop              vertex 0.0 0.0 0.0              vertex 0.0 1.0 0.0              vertex 1.0 0.0 0.0            endloop          endfacet          ...endsolid

Я написал чрезвычайно надёжный парсер, добавив в комментарий такое описание:

/*  Самый либеральный парсер ASCII STL: игнорирует всё, кроме *  слова 'vertex', а затем одно за другим считывает три значения float. */

Загрузка ASCII STL всегда казалась немного медленной, но я предполагал, что причина этого в неэффективном текстовом формате.

(Тучи сгущаются.)



За несколько дней произошло несколько событий:


Вот логи загрузки 1,5-мегабайтного ASCII STL метками времени (в секундах):

[erizo] (0.000000) main.c:10      | Startup![erizo] (0.162895) window.c:91    | Created window[erizo] (0.162900) window.c:95    | Made context current[erizo] (0.168715) window.c:103   | Initialized GLEW[erizo] (0.178329) window.c:91    | Created window[erizo] (0.178333) window.c:95    | Made context current[erizo] (1.818734) loader.c:109   | Parsed ASCII STL[erizo] (1.819471) loader.c:227   | Workers have deduplicated vertices[erizo] (1.819480) loader.c:237   | Got 5146 vertices (7982 triangles)[erizo] (1.819530) loader.c:240   | Waiting for buffer...[erizo] (1.819624) loader.c:326   | Allocated buffer[erizo] (1.819691) loader.c:253   | Sent buffers to worker threads[erizo] (1.819883) loader.c:258   | Joined worker threads[erizo] (1.819887) loader.c:279   | Loader thread done[erizo] (1.821291) instance.c:32  | Showed window

С момента запуска до отображения окна прошло больше 1,8 секунды!

Посмотрев на парсер ASCII свежим взглядом, я увидел, что причина очевидна:

    /*  The most liberal ASCII STL parser:  Ignore everything except     *  the word 'vertex', then read three floats after each one. */    const char VERTEX_STR[] = "vertex ";    while (1) {        data = strstr(data, VERTEX_STR);        if (!data) {            break;        }        /* Skip to the first character after 'vertex' */        data += strlen(VERTEX_STR);        for (unsigned i=0; i < 3; ++i) {            SKIP_WHILE(isspace);            float f;            const int r = sscanf(data, "%f", &f);            ABORT_IF(r == 0 || r == EOF, "Failed to parse float");            if (buf_size == buf_count) {                buf_size *= 2;                buffer = (float*)realloc(buffer, buf_size * sizeof(float));            }            buffer[buf_count++] = f;            SKIP_WHILE(!isspace);        }    }

Можно заметить, что в коде есть sscanf, считывающая одно значение float из начала потока данных и каждый раз проверяющая длину всей строки.

Да, я совершил ту же ошибку, что и программисты, работавшие над GTA Online: написал внезапно квадратичный парсер!

Замена вызова sscanf на вызов strtof снизила время загрузки почти в 10 раз: с 1,8 секунды до 199 миллисекунд.

[erizo] (0.000000) main.c:10      | Startup![erizo] (0.178082) window.c:91    | Created window[erizo] (0.178086) window.c:95    | Made context current[erizo] (0.184226) window.c:103   | Initialized GLEW[erizo] (0.194469) window.c:91    | Created window[erizo] (0.194472) window.c:95    | Made context current[erizo] (0.196126) loader.c:109   | Parsed ASCII STL[erizo] (0.196866) loader.c:227   | Workers have deduplicated vertices[erizo] (0.196871) loader.c:237   | Got 5146 vertices (7982 triangles)[erizo] (0.196921) loader.c:240   | Waiting for buffer...[erizo] (0.197013) loader.c:326   | Allocated buffer[erizo] (0.197082) loader.c:253   | Sent buffers to worker threads[erizo] (0.197303) loader.c:258   | Joined worker threads[erizo] (0.197306) loader.c:279   | Loader thread done[erizo] (0.199328) instance.c:32  | Showed window



Это стало идеальным напоминанием о том, что даже если программируешь много лет, ловушки находятся всегда. В документации sscanf не указана её временная сложность, поэтому это особо хитрый пистолет для выстрела себе в ногу, и мне кажется, что не один я блуждал во тьме невежества.

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

(Очевидно, мораль истории такова: не используйте sscanf для многократного парсинга одиночных токенов из начала строки; уверен, у вас всё будет нормально, если вы просто избежите этого.)



На правах рекламы


VDSina предлагает мощные и недорогие VPS с посуточной оплатой. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!

Подробнее..

MMORPG прошлого века как мы создали первый Киевский игровой сервер

09.05.2021 10:20:54 | Автор: admin

Давным давно на далеком сервере...

Вторая половина девяностых. В СНГ интернет как таковой еще только начинает развиваться. Коммерческих сайтов практически нет (а если и есть, то исключительно айтишной тематики). Web еще не стал тем местом, где пользователи проводят основную часть времени. Доминирующая технология последней мили - dial-up, на котором в основном читают почту и сидят в ICQ. Но энтузиасты айтишники уже пользуются и ньюсами и IRC и несколькими другими сервисами. И конечно играют в сетевые игры!

Doom, в который можно было поиграть вдвоем по модему или вчетвером в локальной сети уже смещен с позиции самой популярной сетевой игры. Сейчас поднимают пиратские батлнет сервера на PVPGN - там можно сразиться в Starcraft и Diablo уже в компании до 4-8 игроков (чем больше игроков, тем больше вероятность лагов). В шутерах доминирует Quake и Quake2 - в игре одновременно может быть уже десяток игроков, и уже не зависеть от чужих лагов (ибо UDP).

Кто-бы мог подумать, что примерно всего через десять лет появятся игры, в которые может одновременно играть сотня или тысяча игроков, и даже больше!

Но что это только что было?
Неужели такие игры уже есть?
Да, уже есть! А если взять англоязычный мир, так уже давным-давно!

Рождение FD

В 1998 году официально запускается первый Киевский MUD (Multi User Dungeon/Dimension) сервер "Forgotten Dungeon".
Для него по шапочному знакомству выделили немного места на одном из FreeBSD-серверов в общежитии Киевского Политехнического института.

Это не первый русскоязычный MUD сервер, но один из них.
Московский "Мир Мерлина" был запущен примерно на год раньше.
А вот с другими серверами в СНГ старшинство уже можно и оспорить (привет, Zmey и ко.!).

Благодаря большой локальной сети общежитий КПИ, раскинутой на витой паре, коаксиале и честном слове, сервер быстро заполняется игроками.
В активные дни количество игроков находящихся в мире превышает 100, то и 150, что по тем меркам весьма немало!
Такой онлайн позволяет не просто побегать по миру в компании практически в любое время суток, но и наладить дипломатические отношения между кланами и даже альянсами.

Внешний канал для института был проблемой - интернет в то время был медленным и дорогим, поэтому были периоды, когда игровой сервер не был доступен снаружи.
Но по договоренности с ректоратом, для "Forgotten Dungeon" в конечном счете все-таки сделали исключение, как для общественно-полезного проекта.
Снаружи он был известен по адресу mud.ntu-kpi.kiev.ua:4000 до конца своей активной жизни (2005-2007).
Хотя, честно говоря, внешние игроки составляли не более 10% основного онлайна.

С одной стороны это несколько ограничивало популярность, но с другой стороны давало свои уникальные преимущества, практически недоступные другим MUD-ам.
Регулярные встречи игроков и разработчиков в реале еженедельно а то и несколько раз в неделю. Обычная рядовая пятничная сходка могла собрать более половины всего состава.

Такая тесная и регулярная связь и общий энтузиазм вдохновляли на множество безумных идей, и "Forgotten Dungeon" очень быстро обрастал сложной боевой/магической механикой и уникальными фичами.

Конечно, по современным меркам, все разработчики в основном не дотягивали даже до джуниоров - обычные студенты, из которых не все отличали компилятор от линкера.
Мы просто писали код с горящими глазами.
Сервер падал - его поднимали и писали скрипты с автоматическим рестартом.
Сервер ломался - его чинили и писали новые фичи с новыми ошибками, которые снова чинили.
Иногда появлялись игроки и "мимокрокодилы" с факультетов информатики, которые могли написать немного больше, чем "hello world". Они делали свой вклад и пропадали.

Однако, несмотря на полное отсутствие коммерческого опыта разработки, мы были открыты к любой полезной информации.
В какой-то момент, узнав про существование систем контроля версий, я перевел все на CVS с коммитами и странной системой версионирования.
Еще не было Jenkins/Teamcity, не было gitlab/gerrit и других привычных CI инструментов, но у нас при коммите новых изменений уже триггерилась сборка новой версии с отправкой логов. А админ, не выходя из игры мог командой перезагрузить игровой сервер с обновлением на новую версию, что позволяло разграничить права доступа, давая возможность вносить изменения в код, но не давая доступ к полной админке.
На каждое падение сервера, автоматически генерировался отчет с отладочной информацией (dbg стектрейс) и уходил на почту.
Для тех времен, это было очень круто!
За почти 10 лет существования сервера, вклад в разработку внесло несколько десятков человек. Без контроля версий, и этих на коленке сделанных скриптов, наверное не получилось бы и половины вещей довести до ума.

Конечно, несмотря на все наши значимые (как нам тогда казалось) попытки причесать код, он очень далек от того, на что можно равняться.
Но мне кажется, это довольно неплохой проект "на поиграться" для начинающих разработчиков, которые хотят освоиться в Си, и научиться работать с базовыми вещами - условия, циклы, структуры данных, неважно тебе 10 или 30+ лет.
По слухам, на кодовой базе нашего сервера, было даже несколько человек, защитивших свои дипломы.
Но были и отчисленные за неуспеваемость слишком увлеченные игроки... Каждый берет что может (;

Технические данные

За базу был взят один из отделившихся от DikuMud движок, а именно ROM 2.4b4a - довольно популярная кодовая база на то время.
К сожалению, сам репозиторий со всей историей коммитов не удалось сохранить (это современные системы типа git хранят всю историю локально, а более старые CVS только на сервере).
Но сохранилась последняя версия исходного кода.
При помощи Google и stackoverflow я смог довести код до состояния, когда он собирается и запускается на современном Линуксе.
В коде есть текстовый файл, где вручную писали комментарии на жуткой смеси русского(нецензурного)/английского, но посторонним его читать не рекомендуется.

Еще до запуска сервера в институте, он стоял у меня на рабочем сервере, я игрался с ним в одиночку (зарегистрировались несколько знакомых, которые заходили в основном потестить какие-то фичи). Но раскручивать я его не собирался, ибо не был готов хостить полноценный сервер на работе, так что я и КПИ нашли друг друга (:
Добавил поддержку кодировок (koi-8, cp-866, win1251 и транслитерацию), добавил поддержку контрольных символов для ANSI colors, поправил какие-то ошибки.
И даже придумал и реализовал систему простых автоматических квестов.
Но эти вещи можно найти практически в каждом MUD, а я хочу поделиться некоторыми уникальными инсайдами или просто забавными моментами.

Делаем простые вещи

Если говорить о базовых элементах программирования - например на практике понять разницу между знанием синтаксиса if/then/else и умением им пользоваться хорошо, то игровые механики в таких простеньких консольных или браузерных играх это просто превосходный вариант для начинающих! Ведь для того, чтобы увидеть результат нового супер-пупер заклинания, тебе не нужен гейм-дизайнер, художник, музыкант и кто-то еще. Многие вещи делаются простыми командами.

Например: научился проверять значение переменной, и создал новую переменную, статус "friendly fire". Добавляем немного условий - и код готов. А с точки зрения игрока - полностью меняется боевая составляющая, потому что теперь можно сражаться команда на команду или клан на клан или стая однотипных монстров против игроков, пользуясь массовыми заклинаниями и не вредя своим "друзьям".

Можно сделать переменную "Статус зрителя", и создать арену для дуэлей, на которой могут находиться зрители в полной безопасности. Еще немного переменных - и можно уже делать ставки на победителя, и вот уже "просто посмотреть за чужой дуэлью" превращается в азартное зрелище вроде "арены гладиаторов" с букмекером! А учитывая что игра текстовая - все зрители могут смотреть, так сказать, с лучшего места в первом ряду ;)

Пробуем что-нибудь посложнее

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

Техническая реализация заклинания "полиморф" уже была посложнее. Высокоуровневый маг может превратиться в любой предмет. Полноценный. Его можно было взять. Если это было оружие, им можно было вооружиться и сражаться. Если это была еда, ее можно было съесть (съеденный игрок умирал :).
Сложность заключалась в том, что все триггеры на оповещение персонажа (кто-то зашел, кто-то сел, кто-то встал и ушел) - были завязаны на объект "персонаж". Следовало добавить многочисленные проверки и триггеры в код, чтобы игрок, превратившийся в объект "предмет", получал полную информацию из мира.
С заклинанием было связано довольно много проблем, чем с радостью пользовались "злоумышленники", но все они в конечном счете были исправлены, а само заклинание внесло значительные изменения в командную игру и особенно клановые войны.

Уникальные локации

Игровой мир в Forgotten Dungeon был довольно большим. И становился еще больше. Несколько карт было скачано с разных ресурсов, адаптировались, переводились, подключались.
Но еще больше карт рисовали сами игроки. Так была нарисована собственно карта и самого Киевского Политехнического института с кучей локальных мемов и отсылок. Среди NPC фигурируют фамилии преподавателей и ректоров. И наверное хорошо, что на тот момент эти люди были далеки от игр и компьютеров, ибо цензура на сервере была минимальна ;)
Парочка фамилий, которые можно встретить в игре: Федорова, Куцик, Сенько, Шпортюк, Кравцов, Савицкий, Скоробагатько, Линчевский и др.

Воспоминания про армию

Однажды мы придумали армию.
Натуральную.
По достижению 18 уровня, все вещи у игрока забираются, и его переносит в закрытую локацию.
В этой локации он даже пообщаться с другими игроками не может, за исключением тех, кто уже в "армии". Из внешнего мира можно было прийти в специальную "комнату переговоров", в котором можно было пообщаться и даже передать предметы (только с типом "вода" или "еда").
Без поддержки друзей, клана и хороших предметов, нужно было выжить три уровня с высокоуровневыми агрессивными монстрами (сержанты, солдаты, прапорщики..), пока на 21 уровне товарищ Майор не отправлял тебя назад в общий мир. Иногда даже игроки из враждующих кланов объединялись в армии =)
Но за смерть в армии не штрафовали, поэтому рано или поздно армию проходили все.
Казалось бы - ну придумали и придумали.
Но Армия оказала заметное социальное воздействие.

Небольшое отступление: в середине 90х во многих MUD у игроков вообще могла отсутствовать возможность сражаться друг с другом, так как многие MUD создавались как социальные игровые "чаты" с ролевой составляющей в стиле DnD (или другой тематикой). На ресурсах со списком серверов, даже отдельно указывалась поддержка PK (Player Killing) в описании сервера.

Смерть персонажа в игре воспринималась неприятно - потеря опыта, потеря предметов, и в отличие от уже одиночных RPG, нельзя было сохраниться.
Но Армия в нашем MUD "сделала из тварей дрожащих львов и тигров".
После армии, страх перед смертью заметно падал, отношение к игровому персонажу менялось.
Я слышал пару историй, когда игроки из нашего мира уходили в другие миры и наводили там шороху.
Даже верю, что это могло оказать какое-то влияние и в реале. Ну собственно для кого-то это так и было.
Конечно с армией тоже было связано много багов, которыми пользовались любители халявы, но мы это дело находили и прекращали:

Сотни мелочей

Введено много уникальных рас, с действительно заметными отличиями. Сейчас в MMORPG это уже норма, а тогда и рас было мало, и в базовом движке их отличие было в основном в небольшом разбросе изначальных параметров - силы, ловкости и так далее.
У нас вводились заметные изменения.
Раса Вампиров, которые заметно прибавляли в силе по ночам и вынуждали игроков следить за сменой дня и ночи в игре.
Банальные вещи - Ящеры умеют плавать. Пикси - летать. Этериалы - проходить сквозь двери и сопротивляться режущему оружию. Зомби могут не есть и не дышать. У Кентавров четыре ноги, поэтому удар двумя копытами вполне заменял серьезное оружие.
Гномы могут перековывать предметы, улучшая их при помощи специальных артефактных компонентов (да, у нас гномы-игроки уже были прародителями современных крафтеров).
В общем сотни мелочей, которые в сумме значительно влияли на то, как следует одевать/вооружать/прокачивать и отыгрывать своего персонажа в зависимости от расы.

Введены перерождения с частичным сохранением навыков предыдущего класса, позволяя создавать сложные комбинации (например вор/маг и маг/вор - далеко не одно и тоже, а это ведь необходимо дважды прокачаться до 101 уровня.)

Админы и игроки творят вместе

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

У нас были "отношений", включая секс, свадьбы, разводы и даже возможность получить статус "родственника". Да, следует ставить рейтинг 18+.

Были игроки-одиночки, которые не хотели в клан. Но клановые фичи были довольно "вкусные". И мы сделали для них специальный клан для одиночек "LONER". Он ни к чему не обязывал, но указывал, что человек сам по себе и давал возможность пользоваться защищенным тепленьким местом с кроватью для отдыха.

Внутренняя кухня

Некоторые решения были довольно странные по архитектуре. Например, никто из нас не умел работать с базами данных и не особо разбирались в том, насколько это удобно. Честно говоря, в то время из известных баз были Foxpro и MS Access. MySql еще не был известен. А Oracle какой-то версии 5-6 был жутко тяжелым и решения на его базе только начинали продаваться далеко в Москве.
В большинстве MUD движков данные игроков хранились в файлах. Проблемным моментом в этом было то, что сохранение файла игрока обычно происходило во время его выхода из игры, и практически все сервера были подвержены ошибке с дублированием предметов.
Рецепт примерно такой: Ты узнаешь любой баг в игре, который приводит к падению сервера (это встречалось частенько и в разных мадах).

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

Мое ужасное но рабочее решение было в лоб - если игрок производил любые манипуляции с предметами, на него вешался флаг "сохранить".
При сохранении какого-либо игрока, сохранялись все игроки с таким флагом одновременно.
При онлайне 100-200 игроков вопрос производительности не стоял, файлы игроков занимали в среднем 3-4 килобайта.
Решение сработало отлично, и duplicate bug в нашем мире исчез (главное чтобы не крашилась сама процедура сохранения).

Можно было просто почитать документацию о fopen/fwrite, и вот - добавлены административные команды для работы с оффлайн игроками.
Администраторам игры было полезно уметь забанить, разбанить, проверить информацию по игрокам, которые сейчас оффлайн, без доступа к консоли сервера.

Работаем с текстом

Переводя фразы изначального движка и создавая новые, текст для действий старались строить таким образом, чтобы он звучал корректно вне зависимости от пола игрока.
Например: "Ты уже благословил Aelita" - звучит неблагозвучно, если заклинание колдует девушка.
Нейтральная фраза выглядит как: "Aelita уже под божественным благословлением".

Но затем была придумана и реализована система работы с полом.
В коде это выглядело как: "Ты уже благословил$a Aelita", (ch->sex)
Нужное подбиралось из массива ["","а","о"] для он, она, оно.
Или с использованием готовой функции: act_new("Задание перв$b выполнил$r $n!",ch,NULL,NULL,TO_ALL,POS_DEAD);

Чуть позже, по той же схеме добавили обработку падежей.
Для этого в описании персонажей (в основном для NPC) нужно было руками прописать склонения: "волшебн|ый|ого|ому|ого|ым|ом дракош|а|и|е|у|ей|е".

В тексте фразы указывалась нужная форма:
act("$c1 выдыхает облако кислоты в $C4.",ch,NULL,victim,TO_NOTVICT);
Функция проверяла есть ли для данного персонажа набор падежей, если нет - просто брала инфинитив.

Карты правда обновлять не успевали, но вроде бы в центральных городах и новых картах можно было порадоваться некоторой естественности и благозвучностью окончаний:

Каждый мир существовал в своем небольшом сообществе и действительно был гораздо более уникален, чем пиратские шарды современных MMORPG, которые в основном отличаются только "рейтами".

Зарубежом

История зарубежных англоязычных МАДов гораздо более долгая. Она начинается чуть ли сразу с появления первых сетей - второй половины семидесятых. Общее количество игроков и онлайн на отдельно взятом крупном сервере могло посоревноваться с общим онлайном всех серверов в СНГ вместе взятых.

Например Arctic MUD, который появился еще в 1992 году, к концу девяностых мог похвастать онлайном свыше 1000 человек, доходя в пиковое время почти до двух тысяч. Многие англоязычные MUD могли позволить себе монетизирование, которое в то время в СНГ было бы непонятым и попросту невозможным. Также для игры в MUD, точнее комфортной игры, желательный уровень английского языка заметно выше чем elementary. Это также было довольно серьезным барьером для желающих поиграть.
Вполне возможно что за рубежом было придумано и воплощено много разных интересных вещей, и многие из наших нововведений могли оказаться вторичными.

Пик MUD серверов в рунете пришелся на тот небольшой промежуток времени, когда сама идея многопользовательских текстовых игр была уже неплохо проработана. Существовало несколько готовых движков с разным подходом к основной механике: level-based (dikumud, ROM, Merc and many other), когда персонаж получает уровни и от уровня уже получает навыки, заклинания и улучшения параметров (elf 80-го левелу), или skill-based (Avalon, Clok, DartMUD), когда уровня нет вообще, или он ни на что не влияет, а значение имеет только уровень владения различными навыками и заклинаниями (владение двуручным мечом 12 уровня).

Но уже всего через несколько лет на хвост начали наступать первые "графические МАДы", как их называли вначале - Ultima Online, Everquest. А затем подтянулись уже и более современные MMORPG - Lineage/Aion/WOW и другие. Поэтому отечественные мады, ярко вспыхнув, горели не слишком долго - около десяти лет (примерно с 1997 по 2005-2007), вытесненные более современными играми.

Я потратил примерно одинаковое количество времени на администрирование "Forgotten Dungeon" и шарда Lineage2, и могу сказать, что с точки зрения игровой механики, МАД конечно гораздо глубже, шире, и предоставляет больше возможностей и свободы для игроков.

Легкость введения новых возможностей и требования к уровню разработчиков просто не сопоставима. Вдобавок для игры не нужен современный компьютер или мощная видеокарта. Даже требования к скорости подключения весьма скромные.

Но удобство и простота управления, привлекательность и конечно визуальная составляющая - конечно на стороне графических игр.

Я подсчитал, что в "Forgotten Dungeon" есть примерно 350 команд, которые можно ввести (правда часть из них административные, часть эмоции), около 120 заклинания и примерно 50 навыков (активных и пассивных). Гайдов и форумов практически не было в силу неразвитости веб, есть только довольно обширная но запутанная внутренняя справка. Примерно месяц занимало просто чтобы игрок стал чувствовать себя в игре уверенно и ориентироваться в мире.
А для большинства графических игр - месяц это зачастую если и не ветеран, то уже довольно опытный игрок.

На текущий момент (2021 год) еще можно найти несколько живых серверов в СНГ (http://www.mudconnector.su/MudList), но это лишь тень минулого и зачастую они пустуют.
А вот среди англоязычных серверов можно найти десяток серверов, с онлайном в 500-800 игроков.

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

Конец истории

Я уверен, что наши восторженные "открытия" тех времен сейчас вряд ли кого-то удивят.
Подход к разработке заметно изменился. Количество готовых наработанных решений за 20 лет можно найти практически на любой случай. Паттерны, структуры данных (словари, двухсторонние списки с уже готовыми методами работы) и множество других вещей - уже встроено в язык.
Но эта статья - кусочек реальной истории одного из первых виртуальных миров Украины и рунета.

Исходники "Forgotten Dungeon" доступны на https://github.com/sfkulyk/fdungeon
Кстати, выложить код в github (правда без некоторых последних правок), я успел еще до https://archiveprogram.github.com/, поэтому можно надеятся, что исходники FD переживут всех нас ;)

Сам игровой мир (пусть и пустой) живет по адресу mud.saboteur.com.ua:4000, чисто из чувства ностальгии. Много он не просит, а вдруг кто зайдет пустить слезу по временам, когда трава была зеленее.

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

Буду благодарен, если при этом вы сохраните в текстах наши юные смешные имена..

Спасибо всем, кто дочитал до конца.

Подробнее..

Фундаментальная теория тестирования

25.03.2021 02:08:58 | Автор: admin
Тестирование это не точная наука. Тут нет чётких устоявшихся определений, которые можно собрать в словарь и выучить перед собеседованием. Каждый IT-проект уникален, что порождает огромное количество разной, часто противоречивой информации. Важным в тестировании, как и в любой профессии, становится понимание процессов и подходов. Важно не только знать, как называется тот или иной процесс, вид тестирования, а что он из себя представляет и для чего он нужен на проекте.




Перейдем к основным понятиям.



Тестирование программного обеспечения (Software Testing) проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

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


Принципы тестирования


  • Принцип 1 Тестирование демонстрирует наличие дефектов (Testing shows presence of defects). Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но не гарантирует их отсутствия.
  • Принцип 2 Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible). Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
  • Принцип 3 Раннее тестирование (Early testing). Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки ПО или системы, и должны быть сфокусированы на определенных целях.
  • Принцип 4 Скопление дефектов (Defects clustering). Разные модули системы могут содержать разное количество дефектов то есть плотность скопления дефектов в разных частях кода может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей.
  • Принцип 5 Парадокс пестицида (Pesticide paradox). Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот парадокс пестицида, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
  • Принцип 6 Тестирование зависит от контекста (Testing is concept depending). Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
  • Принцип 7 Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.


Обеспечение качества (QA Quality Assurance) и контроль качества (QC Quality Control) эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) Контроль качества продукта анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
  • проверка готовности ПО к релизу;
  • проверка соответствия требований и качества данного проекта.


QA (Quality Assurance) Обеспечение качества продукта изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:
  • проверка технических характеристик и требований к ПО;
  • оценка рисков;
  • планирование задач для улучшения качества продукции;
  • подготовка документации, тестового окружения и данных;
  • тестирование;
  • анализ результатов тестирования, а также составление отчетов и других документов.


Скриншот

Верификация и валидация два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.

Верификация (verification) это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.

Валидация (validation) это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

  1. Проектная документация включает в себя всё, что относится к проекту в целом.
  2. Продуктовая документация часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.


Этапы тестирования:


  1. Анализ продукта
  2. Работа с требованиями
  3. Разработка стратегии тестирования и планирование процедур контроля качества
  4. Создание тестовой документации
  5. Тестирование прототипа
  6. Основное тестирование
  7. Стабилизация
  8. Эксплуатация


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

Программный продукт проходит следующие стадии:
  1. анализ требований к проекту;
  2. проектирование;
  3. реализация;
  4. тестирование продукта;
  5. внедрение и поддержка.


Требования


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

Требования к требованиям:
  1. Корректность каждое требование должно точно описывать желаемый функционал.
  2. Проверяемость требование должно быть сформулировано так, чтобы существовали способы однозначной проверки, выполнено оно или нет.
  3. Полнота каждое требование должно содержать всю информацию, необходимую разработчику, чтобы правильно спроектировать и реализовать требуемую функциональность.
  4. Недвусмысленность требование описано без неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание.
  5. Непротиворечивость требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
  6. Приоритетность приоритет требования представляет собой количественную оценку степени значимости (важности) требования.
  7. Атомарность требование нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
  8. Модифицируемость характеризует простоту внесения изменений в отдельные требования и в набор требований.
  9. Прослеживаемость у каждого требования должен быть уникальный идентификатор, по которому на него можно сослаться.


Дефект (bug) отклонение фактического результата от ожидаемого.

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

Атрибуты отчета о дефекте:
  1. Уникальный идентификатор (ID) присваивается автоматически, может содержать в себе данные о требовании, на которое ссылается дефект.
  2. Тема (краткое описание, Summary) кратко сформулированная суть дефекта по правилу Что? Где? Когда?
  3. Подробное описание (Description) более широкое описание сути дефекта (при необходимости).
  4. Шаги для воспроизведения (Steps To Reproduce) последовательное описание действий, которые привели к выявлению дефекта (которые нужно выполнить для воспроизведения дефекта). Описываются максимально подробно, с указанием конкретных вводимых значений.
  5. Фактический результат (Actual result) указывается, что не так работает, в каком месте продукта и при каких условиях. Описывая фактический результат, необходимо ответить на три вопроса: что? где? когда?
  6. Ожидаемый результат (Expected result) указывается, как именно должна работать система по мнению тестировщика, основанному на требованиях и прочей проектной документации.
  7. Вложения (Attachments) скриншоты, видео или лог-файлы.
  8. Серьёзность дефекта (важность, Severity) характеризует влияние дефекта на работоспособность приложения.
  9. Приоритет дефекта (срочность, Priority) указывает на очерёдность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправить дефект.
  10. Статус (Status) определяет текущее состояние дефекта. Отражает жизненный цикл дефекта от начального состояния до завершения. Названия статусов дефектов могут быть разными в разных баг-трекинговых системах.
  11. Окружение (environment) указывается окружение, на котором воспроизвелся баг.


Жизненный цикл бага


Скриншот

Severity vs Priority



Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):
  • Блокирующий (S1 Blocker)
    тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
  • Критический (S2 Critical)
    критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
  • Значительный (S3 Major)
    не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
  • Незначительный (S4 Minor)
    часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
  • Тривиальный (S5 Trivial)
    почти всегда дефекты на GUI опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.


Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):
  • P1 Высокий (High)
    Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критичным для проекта.
  • P2 Средний (Medium)
    Ошибка должна быть исправлена, ее наличие не является критичным, но требует обязательного решения.
  • P3 Низкий (Low)
    Ошибка должна быть исправлена, но ее наличие не является критичным и не требует срочного решения.


Существует пять базовых типов задач:
  • Эпик (epic) большая задача, на решение которой команде нужно несколько спринтов.
  • История (story) часть большой задачи (эпика), которую команда может решить за 1 спринт.
  • Задача (task) техническая задача, которую делает один из членов команды.
  • Под-задача (sub-task) часть истории / задачи, которая описывает минимальный объем работы члена команды.
  • Баг (bug) задача, которая описывает ошибку в системе.


Тестовые среды



  • Среда разработки (Development Env) в ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.
  • Среда тестирования (Test Env) в этой среде работают тестировщики. Тут тестируются новые билды. Здесь тестировщики проверяют функционал, проводят регрессионные проверки, воспроизводят ошибки. Эта среда появляется во время начала динамического тестирования.
  • Интеграционная среда (Integration Env) иногда реализована в рамках среды тестирования, а иногда в рамках превью среды. В этой среде собрана необходимая для end-to-end тестирования схема взаимодействующих друг с другом модулей, систем, продуктов. Собственно, необходима она для интеграционного тестирования. Поддержка среды также, как и в случае со средой тестирования.
  • Превью среда (Preview, Preprod Env) в идеале, это среда идентичная или максимально приближенная к продакшену: те же данные, то же аппаратно-программное окружение, та же производительность. Она используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к боевым. Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и/или пользователи проводят приемочное тестирование (User Acceptance Testing (UAT)), а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.
  • Продакшн среда (Production Env) среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3.


Основные фазы тестирования



  • Pre-Alpha: ПО является прототипом. Пользовательский интерфейс завершен. Но не все функции завершены. На данном этапе ПО не публикуется.
  • Alpha: является ранней версией программного продукта. Цель вовлечь клиента в процесс разработки. Хороший Альфа-тест должен иметь четко определенный план тестирования с комплексными тестовыми примерами. Это дает лучшее представление о надежности программного обеспечения на ранних стадиях. В некоторых случаях тестирование может быть передано на аутсорс.
  • Beta: ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
  • Release Candidate (RC): основываясь на отзывах Beta Test, вы вносите изменения в ПО и хотите проверить исправления ошибок. На этом этапе вы не хотите вносить радикальные изменения в функциональность, а просто проверяете наличие ошибок. RC также может быть выпущен для общественности.
  • Release: все работает, ПО выпущено для общественности.


Основные виды тестирования ПО



Вид тестирования это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

Скриншот

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

  2. Классификация по доступу к коду и архитектуре:
    • Тестирование белого ящика метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
    • Тестирование серого ящика метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
    • Тестирование чёрного ящика также известное как тестирование, основанное на спецификации или тестирование поведения техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.

  3. Классификация по уровню детализации приложения:
    • Модульное тестирование модульные тесты используются для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками.
    • Интеграционное тестирование предназначено для проверки насколько хорошо два или более модулей ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
    • Системное тестирование процесс тестирования системы в целом, чтобы проверить, соответствует ли она установленным требованиям.
    • Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

  4. Классификация по степени автоматизации:
    • Ручное тестирование.
    • Автоматизированное тестирование.

  5. Классификация по принципам работы с приложением
    • Позитивное тестирование тестирование, при котором используются только корректные данные.
    • Негативное тестирование тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.

  6. Классификация по уровню функционального тестирования:
    • Дымовое тестирование (smoke test) короткий цикл тестов, выполняемый для каждой новой сборки для подтверждения того, что ПО стартует и выполняет основные функции без критических и блокирующих дефектов.
    • Тестирование критического пути (critical path) направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
    • Расширенное тестирование (extended) направлено на исследование всей заявленной в требованиях функциональности.

  7. Классификация в зависимости от исполнителей:
    • Альфа-тестирование является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
    • Бета-тестирование ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.

  8. Классификация в зависимости от целей тестирования:
    • Функциональное тестирование (functional testing) направлено на проверку корректности работы функциональности приложения (корректность реализации функциональных требований).
    • Нефункциональное тестирование (non-functional testing) анализ атрибутов качества компонента или системы, не относящихся к функциональности, то есть проверка, как работает система.
      1. Тестирование производительности (performance testing) определение работоспособности, стабильности, потребления ресурсов в условиях различных сценариев использования и нагрузок.
      2. Нагрузочное тестирование (load testing) оценка поведения системы при возрастающей нагрузке, а также для определения нагрузки, которую способны выдержать компонент или система.
      3. Тестирование масштабируемости (scalability testing) тестирование программного обеспечения для измерения возможностей масштабирования.
      4. Объёмное тестирование (volume testing) тестирование, при котором система испытывается на больших объёмах данных.
      5. Стрессовое тестирование (stress testing) вид тестирования производительности, оценивающий систему на граничных значениях рабочих нагрузок или за их пределами.
      6. Инсталляционное тестирование (installation testing) тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
      7. Тестирование интерфейса (GUI/UI testing) проверка требований к пользовательскому интерфейсу.
      8. Тестирование удобства использования (usability testing) проверка того, насколько легко конечный пользователь системы может понять и освоить интерфейс.
      9. Тестирование локализации (localization testing) проверка адаптации программного обеспечения для нового места эксплуатации (например, при смене языка).
      10. Тестирование безопасности (security testing) тестирование программного продукта, чтобы определить его защищённость.
      11. Тестирование надёжности (reliability testing) тестирование способности приложения выполнять свои функции в заданных условиях на протяжении заданного времени.
      12. Регрессионное тестирование (regression testing) тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
      13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.



Тест-дизайн это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна:
  1. Тестирование на основе классов эквивалентности (equivalence partitioning) техника тест-дизайна на основе метода чёрного ящика. Помогает разрабатывать и выполнять меньше тест-кейсов, при этом сохраняя достаточное тестовое покрытие.
  2. Техника анализа граничных значений (boundary value testing) проверка поведения продукта на крайних значениях входных данных.
  3. Попарное тестирование (pairwise testing) разработка тестов методом чёрного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
  4. Тестирование на основе состояний и переходов (State-Transition Testing) применяется для фиксирования требований и описания дизайна приложения.
  5. Таблицы принятия решений (Decision Table Testing) способ компактного представления модели со сложной логикой. А ещё это техника тестирования чёрного ящика, которая применяется для систем со сложной логикой.
  6. Исследовательское тестирование (Exploratory Testing) это подход, когда тестировщик не использует тест-кейсы, а тестирует приложение по определённому сценарию, который часто составляется прямо во время проверки.
  7. Доменный анализ (Domain Analysis Testing) это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования.
  8. Сценарий использования (Use Case Testing) Use Case описывает сценарий взаимодействия двух и более участников (как правило пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя.


Типы тестирования



Скриншот

Тестирование белого ящика метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика это:
тестирование, основанное на анализе внутренней структуры компонента или системы;
тест-дизайн, основанный на технике белого ящика процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему белый ящик? Тестируемая программа для тестировщика прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

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

Согласно ISTQB, тестирование черного ящика это:
тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
тест-дизайн, основанный на технике черного ящика процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.

Тестовая документация



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

Тест план должен отвечать на следующие вопросы:
  • Что надо тестировать?
  • Что будете тестировать?
  • Как будете тестировать?
  • Когда будете тестировать?
  • Критерии начала тестирования.
  • Критерии окончания тестирования.


Основные пункты тест плана:

В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:
a) Идентификатор тест плана (Test plan identifier);
b) Введение (Introduction);
c) Объект тестирования (Test items);
d) Функции, которые будут протестированы (Features to be tested;)
e) Функции, которые не будут протестированы (Features not to be tested);
f) Тестовые подходы (Approach);
g) Критерии прохождения тестирования (Item pass/fail criteria);
h) Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
i) Результаты тестирования (Test deliverables);
j) Задачи тестирования (Testing tasks);
k) Ресурсы системы (Environmental needs);
l) Обязанности (Responsibilities);
m) Роли и ответственность (Staffing and training needs);
n) Расписание (Schedule);
o) Оценка рисков (Risks and contingencies);
p) Согласования (Approvals).

Чек-лист (check list) это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:
  • Предусловия (PreConditions) список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
  • Шаги (Steps) список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
  • Ожидаемый результат (PostConditions) что по факту должны получить.


Резюме


Старайтесь понять определения, а не зазубривать. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.
Подробнее..

Немного о нашей безымянной студии и о том, что мы делаем

31.01.2021 22:19:51 | Автор: admin

Привет всем! Пока мы, на самом деле, безымянная студия и проект, который делаем имеет техническое название "CGDrone". Сегодня мне захотелось написать эту короткую статью. Понимаете, замучался от всей этой работы со скетчами, цветами, алгоритмами и исправлением багов во вращениях, которые реализованы с помощью кватернионов. Последние, к слову, меня порядочно побили.

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

Начало

Дело было в институте, конец магистратуры. Мы с моим товарищем из параллельной группы решаем создать свою супер-пупер 3D-головоломку от первого лица. Такую что просто ну просто бомба и огонь. Надеюсь вы поняли меня. Почему решили делать игру? У меня есть опыт в рисовании, закончил школу с ИЗО уклоном, у напарника есть опыт в создании 3D-моделей. Ну и оба мы программисты как-никак, поработали в фирмах в т.ч. игры делали. Почему головоломку? Потому, что нам нравятся головоломки.

Работу мы разделили примерно пополам ну или делали кто что может. С одной стороны, если в команде 2 человека, то делить работу можно пополам! Удобно же :) И на контроль за результатами работы всех разработчиков не так много времени уходит как, скажем, ушло бы если бы в нашей команде было 30 человек.

В итоге все встало на свои места: я стал отвечать за весь код и графон (шейдеры, освещение, пост-эффекты), а напарник за уровни и юридические вопросы. Вначале, кстати, он моделил лучше меня. Но со временем стало понятно, что просить его перемоделивать что-то каждый раз - это дергать человека и отрывать от основной работы. К тому же требования к моделям могут меняться и человек сойдет с ума от 1000 правок в день. Так что позже модели перешли под мою ответственность.

В самом начале мы придумали идею, игровые законы, механики, протестировали все в голове, на бумаге, и в Unity, запланировали сетевой режим.

Не поверите, но у меня набралось 2 папки со скетчами по проекту и иногда мне все еще приходится набрасывать картинки/перебирать идеи/сопоставлять обьекты. Скетчи, которые я набрасывал выглядят примерно так:

На данный момент мы опубликовали большую часть скетчей в твиттере / инстаграме.

Были еще знакомые, мы попытались подключить их к проекту. Кроме нас в команде было две девушки (дизайнеры-художники), гейм-дизайнер и программист. Через 2-3 недели программист пошел работать в крупную фирму, после попыток прописать структуру проекта и сборки одного игрового обьекта - условный обьект с "глазом" (который следит за игроком). Потом нас покинули дизайнеры. Гейм-дизайнер оказался крепким. Он был с нами до последнего, а вот результатов его работы у нас не было :)

Кстати, игра на тот момент выглядела так:

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

Еще несколько скетчей:

Коротко о некоротком, о сети

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

Мы много чего сделали по сетевой части, в том числе и организовали сетевой чат (иконка конверта) и систему общения голосом (иконка микрофона).

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

Лучше синица в руках, чем журавль в небе

Попытки расширить команду

Позже мною предпиримались попытки привлечь в проект крутых художников. Но не пошло. Очевидные вещи, которые я выяснил:

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

  • по большей части непрофессилнальные художники (из моего личного опыта) любят покреативить и вместо того чтобы сделать все максимально по ТЗ, их заносит и они по-полной берут на себя роль главного ГД и начинают работать уже в этом направлении

  • мотивировать команду - это работа на которую затрачивается много времени

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

Надеемся только на крепость рук, На руки друга и вбитый крюк - И молимся, чтобы страховка не подвела.

На данный момент мы все так же усердно работаем над проектом. Сделали кучу основной работы, работаем над оптимизацией, полировкой графона, анимациями и историей.

Так же в последнее время к нам присоединился переводчик, который взялся прорабатывать сценарий :) Уже вот год работает с нами как и мы на энтузиазме.

А вот и ссылки на нас:

https://twitter.com/CGAleksey

https://www.instagram.com/cgaleksey

https://vk.com/treload

Подробнее..

Гена против Сандро история автоматизации одной сетевой партии в Героях 3

25.12.2020 08:10:45 | Автор: admin


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


С тех пор были скитания по густым лесам, игры в прятки с рыцарскими патрулями, бесконечные попытки хотя бы отдалённо понять, в какие края его занесло. Пока что он понял только то, что ему, скорее всего, конец: с одним дохлым скелетом в рыцарских землях надеяться на что-либо было решительно невозможно.


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


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


Сандро не подозревал, что исход всех его приключений давно предопределён. Вся его история окончится через несколько минут (хоть для него это будет казаться целой неделей) ведь именно столько занимает прогон автотеста кроссплатформенной игровой партии по сети в Героях 3. Действиями Сандро управляет платформа Testo, которая готова прогонять его историю снова и снова.


Будучи разработчиком этой самой платформы Testo, я решил под Новый Год немного повеселиться и соединить своё профессиональное произведение и любимую игру, в которой затерялись тысячи часов моей жизни. И вот что из этого получилось.


Disclaimer

Уважаемые друзья! В этой статье, помимо привычных технических вещей, вы также найдёте историю противостояния некроманта Сандро и никудышного рыцаря Гены в сеттинге нашей любимой и обожаемой игры Герои меча и магии 3. Эта история изобилует большим количеством художественных вымыслов относительно игровых механик этого замечательного произведения игростроения. Пожалуйста, не стоит относиться к этим вымыслам слишком серьёзно: я точно так же, как и вы, люблю и ценю Героев 3, и лишь предлагаю взглянуть на привычные всем вещи с новой, забавной стороны. Любые совпадения случайны, я отказываюсь от любых намёков на какие-либо реальные вещи в реальном мире.


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


Всего ещё год назад Гена был самым несчастным рыцарем во всей Эрэфии. После выпуска из рыцарского военного ВУЗа его по распределению отправили служить на передовую. У Гены никогда не было склонности к военному искусству (он с трудом мог отличить обычного грифона от королевского), но всегда был талант сомелье. Он и поступил-то в военный ВУЗ только по указке своих родителей рыцарей в пятидесятом поколении. Они же помогли замять резонансное дело, когда Гена умудрился пропить всех вверенных ему грифонов в одной из таверн. О военной карьере, понятное дело, речи больше идти не могло, и Гену вместо виселицы отправили от греха подальше дослуживать свой рыцарский контракт в самые дальние далёкие тылы, которые только были в Эрэфии охранять замок Балашов и его окрестности.


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


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


Всё это мало беспокоило Геннадия, ведь пол года назад он обнаружил гостеприимное логово феечек совсем недалеко от крепости. В этом заведении он чувствовал себя по настоящему счастливым: в дали от всяких проблем, в окружении бочек вина и очаровательных феечек, он наконец-то чувствовал, что нашел применение всем своим природным талантам. В последний раз в замке Гена был месяц назад. Забрав из погреба аж шесть бочек с вином и убедившись, что в окрестностях всё также ничего не происходит, он укатил обратно к своей сладкой жизни. Жизни, которую так ненавидел Сандро, старательно собирая по всем округам ресурсы для своего преобразователя скелетов.


Начальные условия


Для запуска Героев я решил использовать проект VCMI. В этом замечательном открытом проекте все ключевые компоненты Героев 3 были с нуля переписаны на С++. Проект является кроссплатформенным, поэтому с его помощью вы можете играть в Героев по сети на Макбуке с другом, который едет в метро и сидит в своём телефоне на Андроиде. Как раз-таки этой кроссплатформенностью я и воспользовался для этой статьи.


Похождения Сандро и Гены происходят вот на такой карте, которую я накидал в редакторе за 15 минут (все ссылки доступны в конце статьи):



Гена находится в синем углу ринга, отдыхая в гостях у феечек, тогда как Сандро в красном углу только что закончил строительство простенькой базы и готов отправиться на сбор крестьян.



Игра происходит по сети в режиме "человек против человека". Сандро выбрал Ubuntu Desktop 20.04 в качестве машины для запуска, а Гена решил не рисковать и придерживаться проверенного варианта с Windows 7. Сандро на правах более опытного пользователя создаёт конференцию и выступает в качестве сервера, а Гене лишь нужно подключиться к Сандро по сети.


За развёртывание, настройку стенда, установку VCMI и прогон всей игровой партии отвечает платформа Testo. Возможно, вы уже видели на Хабре краткое описание этой платформы, или примеры автотестов для антивируса Dr. Web (без малейшего доступа к исходникам). Помимо тестов, Testo можно применять и для автоматического развёртывания интересных виртуальных стендов (например, контроллер домена AD вместе с рабочей станцией).


Краткое описание Testo

Testo это новый фреймворк для системных (End-To-End) автотестов, который позволяет автоматизировать взаимодействие с виртуальными машинами с помощью скриптов на специальном, простом для понимания языке. Testo построен на распознавании объектов на экране с помощью нейросетей, поэтому для его работы не требуется устанавливать специальные агенты внутрь виртуальных машин.


В Testo все действия с виртуальными машинами находятся внутри тестов, которые выстраиваются в дерево "от простого к сложному". В нашем случае такое дерево будет выглядеть вот так:



Благодаря механизму кеширования в Testo, все эти тесты вовсе не нужно будет прогонять с нуля каждый раз. Поэтому самые долгие и неинтересные тесты *install и *configure (установка и первичная настройка ОС) прогонятся вовсе только один раз, после чего вечно будут закешированы. Разбирать эти тесты я не буду, но желающие смогут найти исходники этих тестов в ссылках в конце статьи.


С остальными тестами и интересными моментами из них мы познакомимся чуть позднее, а сейчас самое время узнать, как продвигаются дела у Сандро.




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


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


Летом ночи не такие длинные, а сделать нужно ещё очень много. Сандро направился к следующему дому, наслаждаясь тишиной и повиновением своих новых скелетов, пусть пока что в своих бесполезных кожаных оболочках.


Установка VCMI


Похоже, дела у Сандро идут вполне неплохо.


Что ж, первые тесты прошли (где-то за кадром), пришло время заняться установкой VCMI. За это отвечают два теста: ubuntu_install_vcmi и win7_install_vcmi. В них происходит установка самого дистрибутива VCMI и копируются почти все необходимые файлы с оригинальными данными Героев 3 в папки VCMI (Чтобы VCMI мог их подхватить). Точнее, копируются все файлы, кроме папки Maps (в которой лежит только одна карта, скриншот которой вы видели выше). Эта папка будет скопирована чуть позже. Вот так выглядит этот процесс на примере Ubuntu:



Уважаемые читатели, автор в курсе про правило не выкладывать код скриншотами, но тесты написаны на языке Testo-lang, и Хабр не поддерживает подсветку этого языка. Я считаю, что лучше уж выложить скриншот, зато код не будет сливаться в одно месиво. Ссылки на все тесты доступны в конце статьи, вы всегда можете увидеть их текстовое представление там.

Пробежимся вкратце по тесту:


  1. Сам VCMI устанавливается из репозитория ppa:vcmi/ppa.
  2. Нужно один раз запустить VCMI Launcher, чтобы он создал свои служебные папки в ~/.local/share.
  3. Копируем с хоста папки Data, Mp3, Mods/vcmi в служебные папки VCMI. Папки Data и Mp3 содержат файлы с данными оригинальных Героев. Папка Mods/vcmi содержит мод vcmi, который позволяет устанавливать нормальное разрешение экрана.
  4. Копируем файл vcmi_settings.json с настройками VCMI, чтобы не нужно было прокликивать настройки с помощью мышки.

А что же с папкой Maps? Почему бы её тоже сразу не скопировать? Не буду вас перегружать сейчас деталями этого решения, вы сами всё увидите ближе к концу статьи.


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




Некромант? Здесь, в Балашове? Что вообще происходит? эти и многие другие мысли наперебой мелькали в голове у Гены, пробиваясь сквозь пелену худшего похмелья в его не такой уж и долгой жизни.


Он сидел в комнате для совещаний, закрыв лицо руками, и не верил своим ушам. Помимо него в комнате находилось ещё двое: крестьянин из Вилларибо и единственный штатный монах во всём Балашове по имени Станислав. Станислав, в отличие от Гены, был отправлен в Балашов на пенсию, а не чтобы не отсвечивать. Навоевался монах в свои годы, и просто хотел на старости лет отдохнуть.


Крестьянин только что закончил рассказывать, как он чудом спасся от скелета в плаще, который ходил по домам и забирал с собой всех, кого найдёт. Станислав же мрачно озвучил свой вердикт, который теперь эхом гудел у Гены в голове.


Откуда он тут взялся? это оказался единственный вопрос, который был способен сгенерировать Генин разум в этой ситуации.


Я не знаю, да это и неважно. Важно лишь то, что все крестьяне из обоих деревень скоро станут скелетами, если уже не стали. Это больше 400 скелетов. С этой армией он наверняка захочет захватить наш замок, Станислав был мрачен, но непоколебим.


И что нам теперь делать?


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


Так и как же быть?


Достраивать защитные и тренировочные сооружения тоже не получится уж лучше стать скелетом, чем потом объясняться с руководством почему мы всё это построили без согласования.


И какие у нас варианты?


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


Так каков в итоге план?


Мы построим гильдию магов первого уровня и выдадим тебе книгу заклинаний. С этой книгой ты пойдёшь на срочные курсы повышения магической квалификации. За пару дней тебе придётся стать мало-мальски достойным магом. Пока ты будешь просвещаться, мы достроим гильдию магов до приемлемого уровня. Если нам повезёт с заклинаниями, то у нас будет шанс.


Замыленные месяцем возлияний мозговые шестерёнки в голове у Гены наконец-то со скрипом прокрутились, и он с ужасом осознал: ему придётся изучать магию. МАГИЮ! Магию изучают ЗУБРИЛ! Сам же Гена всегда был свято уверен, что жизнь слишком коротка, чтобы тратить её на изучение каких-то ветхих непонятных книг.


Гена был потрясён и обескуражен до глубины души. В мгновение ока он забыл про некроманта, про орды скелетов и про залежи вина в погребах. Заикаясь, Гена выдавил:


Я, я не могу изучать м-магию. Мне нельзя магию! Мне нельзя доверять книгу заклинаний, я даже грифонов в таверне умудрился пропить! Нам лучше сдать замок и эвакуироваться!


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


Запуск сетевой игры


За запуск сетевой игры отвечает тест launch_game. Это первый тест, куда "сходятся" отдельные ветки Ubuntu и Windows 7. Это и понятно, ведь для запуска сетевой игры требуется наличие в тесте обоих машин (ранее мы могли всё делать по отдельности). Ubuntu (Сандро) выступает в качестве сервера, а Windows (Гена) в качестве клиента. Так что тест выглядит следующим образом:


1) Копируем папку Maps с хоста на Ubuntu и запускаем VCMI. Создаём новую конференцию для игры по сети.


Сниппет


2) Копируем папку Maps с хоста на Windows 7 и запускаем VCMI. Подключаемся к конференции по IP-адресу.


Сниппет


3) Каждый игрок выбирает себе начальный бонус, после чего игра запускается.


Сниппет


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


Но дальше начинается сама игра. И если вы думаете, что вся партия будет выглядеть как простой набор прокликиваний по куче картинок, то вы заблуждаетесь. Нет, здесь начинается самая интересная часть нашей статьи. Благодаря небольшому тюнингу языка и специальным нейросетям я смог научить платформу Testo неплохо ориентироваться в мире иконок и моделей Героев 3.




Просто поставь подпись в ведомости вот здесь, пробормотал Игорь, теперь давай сюда свою книгу, сейчас мы её разблокируем


Гена молча протянул свою свежую и абсолютно пустую книгу заклинаний. В гильдии магов ему пришлось отдать за неё 500 золотых и даже проставили какие-то картинки в неё, но он не имел ни малейшего понятия, как ей пользоваться.


Игорь достал из кармана какую-то печать и проштамповал все страницы книги, после чего протянул книгу обратно со словами Ну всё, теперь можешь использовать заклинания третьего уровня.


В смысле могу?! Я же ничего не знаю! Я не умею в МАГИЮ!


Конечно можешь. Я же только что проштамповал книгу печатью базовой мудрости.


Гена просто молчал.


Ты что, вообще не знаешь, как работает магия?


Больше молчания.


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


По умолчанию в книгу можно проставлять только слабенькие заклинания, 1-2 уровней. Чтобы заносить заклинания помощнее, нужно разблокировать книгу специальными печатями. Станислав попросил меня проставить тебе печать базовой мудрости, так что вот теперь и заклинания третьего уровня можно заносить.


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


Гена никогда ещё не получал так много информации в такие сжатые сроки. Но он знал, что ради родного Балашова (и родных феечек) он должен стать лучше! Он должен попробовать вникнуть!


А пользоваться то этой книгой как?


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


На слове малограмотные Гена непроизвольно сглотнул слюну. Слово аутентификация он решил просто проигнорировать.


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


Гена сомневался, что он хоть один вопрос сможет осилить, но решил снова промолчать.


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


Гене нравилось слово шпаргалка, но не нравилось слово зубрить. Зубрить шпаргалки это же почти и есть Учиться! Но выбора у Гены не было, так что он спрятал в рюкзак свою книгу заклинаний и поплёлся проставлять оставшиеся печати.


Похождения на карте и не только



Начинается игра, и возникает вопрос: а как автоматизировать действия героев на карте? Сначала я пошёл довольно топорным путём: каждый пункт назначения Сандро и Гены был оформлен в виде изображения-шаблона, который затем передавался на вход действию mouse click img. То же самое касалось любых других действий: нажатие иконок, постройка зданий и так далее. То есть я применял довольно прямолинейный (и распространённый) способ управлять действиями на экране виртуалки поиск изображения по образцу.


А потом количество заготовок стало зашкаливать, да и не все они хорошо работали: например, при попытке кликнуть по нужной звёздной оси поиск образа не всегда отрабатывал как нужно, ведь в этом объекте присутствует анимация:



Так что я подумал, а почему бы не сделать отдельную нейросеть для работы исключительно с объектами в Героях 3? За счёт того, что этой нейросети придётся работать с ограниченным набором объектов, она сможет довольно качественно их распознавать, даже несмотря на анимацию, вариативность цветов и так далее.


А чтобы этой нейросетью можно было удобно пользоваться, я решил добавить новую возможность в язык Testo-lang. Теперь действия wait и mouse click помимо текста и картинок поддерживают возможность ожидания и кликов по объектам Героев!


Вот так выглядил один из фрагментов теста до преобразований:



А вот так после:



Стало ли удобнее? На первый взгляд может показаться, что разница минимальна, но это не так: за каждой картинкой в img скрывается ручная работа: требуется сделать скриншот виртуальной машины и вырезать оттуда требуемый шаблон. Поиск с помощью homm3 работает на основе нейросетей, так что никаких действий с моей стороны не требуется только пользуйся. К тому же нейросети берут на себя заботы по возможной анимированности искомых объектов и помогут ещё в ряде случаев (подробности будут дальше).


Уважаемые читатели! Функционал платформы Testo по поддержке работы с объектами Героев 3 я выполнил в режиме Proof Of Concept и исключительно just for fun. Этот функционал очень сильно недоделан и не подходит для полноценного использования с Героями 3. В конце статьи доступна экспериментальная сборка Testo, на которой вы сможете запустить примеры, но доделывать полноценный вариант я не решился из-за сомнительной ценности и больших трудозатрат.

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




Сандро скомандовал последней порции крестьян пройти обряд улучшения (как он это называл). Люди, один за одним, отправились в сторону преобразователя скелетов. В их глазах была вселенская тоска от понимания своей участи (в конце концов, все они видели, что происходит с их предшественниками), но никто не посмел возразить властному некроманту.


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


В мгновение ока Сандро превратился из остерегающегося патрулей скрытого агента в могущественного предводителя армии тьмы (роль, к которой он очень сильно привык). И он знал, куда он направит свою армию тьмы в первую очередь. Повинуясь беззвучной команде Сандро, орды скелетов направились в сторону виднеющегося вдали замка.


Обучение геройской сети


Итак, мы решили создать нейросеть, чтобы облегчить себе прокликивание различных объектов. С чего же нам начать? Создание любой нейросети начинается с данных для обучения. В нашем случае мы решаем задачу, которая называется object detection. Соответственно, для обучения нам понадобятся скриншоты Героев, для каждого скриншота должен быть список объектов, которые изображены на нём, их классы (например, "герой" или "город") и их координаты (так называемый bounding box, сокращённо bbox). Причем данных нам понадобится много: гигабайты, а ещё лучше десятки гигабайт. Как же нам создать такой большой датасет? Давайте рассмотрим основные варианты:


  1. Можно вручную наснимать 100 тысяч скриншотов Героев и так же вручную их разметить. По понятным причинам этот вариант отметаем сразу.
  2. Мы можем воспользоваться тем фактом, что VCMI движок перед отрисовкой очередного кадра и так знает, где какие объекты находятся. То есть теоретически мы можем подправить исходники VCMI таким образом, чтобы он нагенерил нам большое количество скриншотов и сохранил информацию об объектах куда-нибудь в файл, например. Исходники VCMI довольно хорошего качества, однако реализовать такой план не так-то просто, потому что логика отрисовки объектов тесно переплетена с механикой игры. Нельзя просто так взять и сказать "отрисуй мне вот эту карту". К сожалению, придётся отказаться от этого плана из-за слишком больших трудозатрат.
  3. Есть ещё один компромиссный вариант, который подходит для большинства задач класса object detection. Идея заключается в том, чтобы вручную разметить относительно небольшое количество скриншотов (допустим 100 штук), а затем разнообразить их путём отрисовки в случайных местах тех объектов, которые мы собирается потом детектить. Разумеется, дополнительно можно применить и другие способы искажения изображений: кадрирование, масштабирование, отражение слева-направо, изменения контраста и яркости, инверсия цветов и т.д. Этот вариант вполне рабочий, а главное его можно реализовать всего за пару дней.

Сказано сделано. Разметить 100 скриншотов не представляет никакой сложности, особенно, если использовать подходящий инструмент разметки. Можно использовать любой из свободных инструментов, например LabelImg. Но я использую собственный интрумент разметки на базе Electron и KonvaJS. Использование своего инструмента удобнее с той точки зрения, что его легче затачивать именно под решение своих задач.



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


  1. В первую очередь, конечно, это анимированные объекты, потому что иначе действие wait img просто не будет работать. К таким объектам относятся, например, анимированные иконки построек в меню города.
  2. Объекты, у которых может быть разный фон (иначе понадобится вырезать новую картинку на каждый новый фон). Пример такого объекта иконка героя или любого другого объекта на карте.
  3. Объекты, у которых может быть много вариаций. Например кнопка ОК. У неё в игре есть где-то 5-6 разных вариантов отрисовки. Вырезать 5-6 картинок это не проблема, но каждый раз подбирать, какая же картинка лучше подходит в данном конкретном случае нет никакого желания.

Для того, чтобы извлечь оригиналы иконок объектов с альфа каналом я использовал проект lodextract. На вход ему подаются .lod файлы из оригинальной версии игры, а на выходе он выдаёт неимоверно большое количество .png картинок (десятки тысяч), например, вот таких:



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



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


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


Таким образом мы плавно подошли к обучению нейросети. Для начала нам нужно определиться с её архитектурой. Я выбрал yolov3-tiny, но на самом деле это не так уж важно. Для нашей очень простой задачи, впринципе, подойдёт любая архитектура, выполняющая детект объектов. Гораздо бОльшее значение здесь имеет датасет. Нейросети имеют удивительное свойство "выдавать результат" несмотря на их небольшой размер или неоптимальную архитектуру. Главное не давать сети зацикливаться на косвенных признаках объектов. Например, нейросеть может подумать, что коричневые пиксели это учёный (scholar), если на скриншотах в датасете больше не встречается объектов коричневого цвета. Поэтому так важно иметь большой и качественный датасет. А архитектура нейросети это второстепенный вопрос.


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



На вход сети подаётся набор картинок, а на выходе для каждой картинки мы получаем по несколько тысяч векторов (для больших картинок, типа FullHD). Это одна из особенностей работы нейросетей: мы в какой-то степени использум брутфорс, нежели какую-ту изощренную логику. Каждый вектор состоит из следующих значений:


  • вероятность, что этот вектор описывает какой-то объект на картинке (objectness score). Для большинства векторов это значение будет около нуля.
  • координаты центра объекта (x, y), а также его ширина и высота (w, h)
  • набор значений, описывающих вероятности того, что этот объект принадлежит к каждому из классов (class scores)

То есть выход нейросети требует ещё некоторой постобработки. Нужно отфильтровать вектора с низким objectness score, а также объединить вектора, которые указывают на один и тот же объект. Эти операции не добавляются в модель нейросети, потому что они плохо подходят под архитектуру GPU (у нас получится размерность выходных данных всё время разная). К этому вопросу мы вернёмся чуть позже, а пока предлагаю мельком взглянуть на код нейросети, написанный с ипользованием фреймвока PyTorch:


Код модели
import torchimport torch.nn as nnimport torch.nn.init as initimport torch.nn.functional as Ffrom dataset import classes_namesdef Conv(in_ch, out_ch, kernel_size, activation='leaky'):    seq = nn.Sequential(        nn.Conv2d(in_ch, out_ch, kernel_size=kernel_size, padding=kernel_size//2),        nn.BatchNorm2d(out_ch),    )    if activation == 'leaky':        seq.add_module("2", nn.LeakyReLU(0.1))    elif activation == 'linear':        pass    else:        raise "Unknown activation"    return seqdef MaxPool(kernel_size, stride):    if kernel_size == 2 and stride == 1:        return nn.Sequential(            nn.ZeroPad2d((0, 1, 0, 1)),            nn.MaxPool2d(kernel_size, stride)        )    else:        return nn.MaxPool2d(kernel_size, stride)# Псевдо-слой сети, служит для конкатенации выходов из нескольких других слоёв class Route(nn.Module):    def __init__(self, layers_indexes):        super().__init__()        self.layers_indexes = layers_indexesclass Upsample(nn.Module):    def __init__(self, scale_factor, mode="nearest"):        super().__init__()        self.scale_factor = scale_factor        self.mode = mode    def forward(self, x):        x = F.interpolate(x, scale_factor=self.scale_factor, mode=self.mode)        return xnum_classes = len(classes_names)# Псевдо-слой сети, служит для нормализации выходов предыдущего слоя и # преобразования x,y,w,h в пикселиclass Yolo(nn.Module):    def __init__(self, anchors):        super().__init__()        self.anchors = anchors        self.mse_loss = nn.MSELoss()        self.bce_loss = nn.BCELoss()        self.obj_scale = 1        self.noobj_scale = 100    # Вычесление intersection over union двух bbox-ов    def bbox_wh_iou(self, w1, h1, w2, h2):        inter_area = torch.min(w1, w2) * torch.min(h1, h2)        union_area = w1 * h1 + w2 * h2 - inter_area        return inter_area / (union_area + 1e-16)    def forward(self, x, img_w, img_h):        B, C, H, W = x.shape        num_anchors = len(self.anchors)        prediction = x.view(B, num_anchors, num_classes + 5, H, W) \            .permute(0, 1, 3, 4, 2) \            .contiguous() # преобразуем к формату (B, num_anchors, H, W, num_classes + 5)        # размеры одной ячейки (ширина и высота) в пикселях        stride_x = img_w / W        stride_y = img_h / H        # номера столбцов и строк        grid_x = torch.arange(W).repeat(H, 1).view([1, 1, H, W]).to(x.device)        grid_y = torch.arange(H).repeat(W, 1).t().view([1, 1, H, W]).to(x.device)        # размемы якорей (ширина и высота) в пикселях         anchor_w = x.new_tensor([anchor[0] for anchor in self.anchors]).view((1, num_anchors, 1, 1))        anchor_h = x.new_tensor([anchor[1] for anchor in self.anchors]).view((1, num_anchors, 1, 1))        # преобразуем x,y,w,h в пиксели        pred_x = (prediction[..., 0].sigmoid() + grid_x) * stride_x        pred_y = (prediction[..., 1].sigmoid() + grid_y) * stride_y        pred_w = prediction[..., 2].exp() * anchor_w        pred_h = prediction[..., 3].exp() * anchor_h        # приводим вероятности к диапазону [0, 1]        pred_conf = prediction[..., 4].sigmoid()        pred_cls = prediction[..., 5:].sigmoid()        # из матрицы делаем список        # это позволит объединить вместе выходы Yolo разных размеров        return torch.cat(            (                pred_x.view(B, -1, 1),                pred_y.view(B, -1, 1),                pred_w.view(B, -1, 1),                pred_h.view(B, -1, 1),                pred_conf.view(B, -1, 1),                pred_cls.view(B, -1, num_classes),            ),            -1,        )class Model(nn.Module):    def __init__(self):        super().__init__()        # размеры якорей        anchors_1 = [(81,82), (135,169), (344,319)]        anchors_2 = [(10,14), (23,27), (37,58)]        # список всех слоёв сети        self.module_list = nn.ModuleList([            Conv(3, 16, 3),            MaxPool(2, 2),            Conv(16, 32, 3),            MaxPool(2, 2),            Conv(32, 64, 3),            MaxPool(2, 2),            Conv(64, 128, 3),            MaxPool(2, 2),            Conv(128, 256, 3),            MaxPool(2, 2),            Conv(256, 512, 3),            MaxPool(2, 1),            Conv(512, 1024, 3),            #############            Conv(1024, 256, 1),            Conv(256, 512, 3),            Conv(512, (num_classes + 5) * len(anchors_1), 1, activation='linear'),            Yolo(anchors_1),            Route([-4]),            Conv(256, 128, 1),            Upsample(2),            Route([-1, 8]),            Conv(128 + 256, 256, 3),            Conv(256, (num_classes + 5) * len(anchors_2), 1, activation='linear'),            Yolo(anchors_2)        ])    def forward(self, img):        layer_outputs = []        yolo_outputs = []        x = img        # просто применяем очередной слой к выходу от предыдущего слоя        # (или объединяем выходы нескольких слоёв в случае с Route)         for module in self.module_list:            if isinstance(module, Route):                x = torch.cat([layer_outputs[i] for i in module.layers_indexes], 1)            elif isinstance(module, Yolo):                x = module(x, img.shape[3], img.shape[2])                yolo_outputs.append(x)            else:                x = module(x)            layer_outputs.append(x)        return torch.cat(yolo_outputs, 1)

У нас получилась модель, которая на диске занимает примерно 35Мб. На самом деле это перебор для такой простой залачи, как детект объектов в Героях. Я уверен, что можно безболезненно уменьшить размер модели где-то до 5Мб, при этом не потеряв в точности детекта. Но на это нет времени, история Гены и Сандро ждёт своего продолжения. Двигаемся дальше.


Имея датасет и код нейросети, обучить её не составяет труда. Запускаем обучение и уходим погулять часа на 3.



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


Сеть обучена, замечательно. Однако возникает резонный вопрос, как это дело интегрировать в конечный продукт (если он не на питоне)? Самый простой, наверное, способ это слинковаться с libpytorch. Более того, мы могли бы вместо того, чтобы писать код нейросети на питоне написать его сразу на С++ и даже получить некоторый прирост производительности, благо PyTorch предоставляет C++ frontend. Однако, не очень то хочется тащить за собой весь PyTorch, ведь он даже в заархивированном виде весит целый гигабайт. Поэтому я использую OnnxRuntime. Он позволяет сократить размер дистрибутива в два раза, а также увеличить производительность работы нейросетей. Как следует из названия, этот проект позволяет загружать обученные модели нейросетей в формате onnx и запускать их, так что нам для начала нужно экспортировать нашу модель в этот формат:


model = Model()model.load_state_dict(torch.load("path_to_model.pt", map_location=torch.device('cpu')))model.eval()x = torch.randn(1, 3, 480, 640)output = model(x)torch.onnx.export(model, x, "model.onnx",    input_names=["input"],    output_names=["output"],    dynamic_axes={        'input': {            2: 'height',            3: 'width'        },        'output': {            2: 'height',            3: 'width'        }    },    opset_version=11)

Я указал здесь параметр dynamic_axes, это позволит подавать на вход сети картинки любого размера. Вообще, с экспортом в формат onnx нужно быть очень осторожным. Когда мы пишем код модели на питоне то мы используем привычные нам циклы, условия и переменные. А формат onnx описывает граф с вершинами и ребрами. Сконвертировать одно в другое это совершенно нетривиальная задача. Убедиться в том, что экспорт прошел успешно, можно с помощью просмотрщика формата onnx, например с помощью Netron. Но скорее всего, если что-то пойдёт не так, PyTorch выдаст предупреждение. Экспортировав модель в формат onnx, мы можем загрузить её из С++/C#/Java/NodeJS. Ниже пример для питона:


import onnxruntimeimport numpyort_session = onnxruntime.InferenceSession("model.onnx")x = numpy.rand(1, 3, 480, 640)ort_inputs = {"input": x}ort_outs = ort_session.run(None, ort_inputs)

Вот здесь как раз можно выполнить постобработку результатов работы нейросети. Векторы с низким objectness score просто отбрасываем, а к остальным применяем алгоритм Non-Maximum Suppression. Давайте, наконец, запустим нашу свежеобученную нейросеть и посмотрим, как она работает:



Я обучал нейросеть детектить только те объекты, которые мне нужны для теста, поэтому на скриншоте выше подсвечены не все объекты. Ура! Вроде всё работает, а значит мы можем автоматизировать похождения Гены и Сандро по карте:



Битва


Гена стоял на стене замка и в тайне надеялся, что он до сих пор находится в страшном алкогольном сне. За свою недолгую военную карьеру Гена так и не успел повидать не то, что настоящего некроманта, но даже простого скелета. Сейчас же скелетов перед ним было столько, что они даже не помещались в одно поле зрения.


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


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


Но скелетов было так много, что даже обостренный ум Гены мог не выдержать. Всё могло решиться в самых мелочах.




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


Ну вот мы и добрались до кульминации эпического противостояния молодого безалаберного рыцаря и умудрённого тысячелетиями некроманта.



Битва будет протекать по такому сценарию:


  1. Сандро будет атаковать на автопилоте.
  2. Гена кастует экспертное замедление и перемещает феечек наверх карты.
  3. Пока Сандро медленно продвигает своих скелетов вперёд, Гена кастует "Уничтожение нежити".
  4. Через 5 ходов Гена обновляет замедление и перемещает феечек в низ карты.
  5. Гена продолжает кастовать "Уничтожение нежити" пока у него не кончится мана или пока не кончатся скелеты.

Тест может закончиться тремя исходами:


  1. Бой заканчивается поражением Гены меньше, чем за 13 ходов провал.
  2. Бой длится 13 ходов и больше провал.
  3. Гена побеждает быстрее, чем за 13 ходов успех.

Вот так это выглядит в виде теста:



Часть действий я инкапсулировал в виде макросов cast_slow_routine и blue_battle_routine, чтобы тест не выглядел слишком загромождённым.


Исход битвы, пожалуй, не буду спойлерить лучше посмотрите сами.



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


Сколько раз за один ход королевский грифон может ответить на атаку противника? гласила надпись на книге. Это был первый вопрос, которого не было в шпаргалках Гены.


За всё своё время рыцарства Гена так и не удосужился узнать хоть что-нибудь об этих ужасных страшных созданиях. Его познания о грифонах ограничивались тем, что если пропить их в таверне, тебя сошлют в Балашов.


Гена стал судорожно подбирать правильный ответ. Книга допускала 2 неверные попытки, после чего заклинание блокировалось на какое-то время. У Гены этого времени не было: оставшиеся скелеты уже ломились к нему на стену замка. От фей тоже было мало проку: они забились в угол и ждали, когда Гена, наконец, прочтёт завершающее заклинание.


Варианты 2 и 3 раза не понравились книге заклинаний.




Гена стоял со связанными руками перед преобразователем скелетов и думал, что же пошло не так. Как победа умудрилась выскользнуть из его рук? Если бы только он был немного умнее Если бы он хоть немного слушал на лекциях своих преподавателей, которые не раз и не два рассказывали про этих проклятых грифонов Было ли бы этого достаточно чтобы победить злого Сандро? Эх, чего уж теперь гадать, пора шагать в преобразователь.


А где же хеппи энд?


Действительно, не можем же мы завершить такую эпичную сагу на такой негативной ноте. Новый год же! Как мы увидели, Гена вполне себе уверенно шёл к успеху, пока у него неожиданно закончилась мана. Может быть, надо просто сделать Гену изначально несколько "умнее"? Так давайте! Откроем редактор карт и добавим Гене немного "знаний":



Ну а теперь я наконец то могу ответить на вопрос, почему же я в тестах копирую папку Maps не в тесте install_vcmi, а в тесте launch_game. Как только мы поменяли файл Villaribo_and_Villabadjo_lose.h3m, Testo сбросит кеш того теста, где этот файл задействован (т.е. launch_game). Потерявший кеш тест (и его потомки) запустится заново. Если бы я копировал Maps в тестах install_vcmi, то именно эти тесты потеряли бы кеш. А значит, пришлось бы заново прогонять установку vcmi и копирование других папок (Data, Mp3 и прочее).


Я просто построил дерево тестов таким образом, чтобы редактирование карты не запускало повторную установку vcmi.



А вот и хэппи энд подъехал! Оказывается, Гене всего лишь нужно было лучше слушать преподавателей в военном ВУЗе!


Заключение


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


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


Репозиторий со всеми необходимыми сценариями и артефактами (в том числе с экспериментальной сборкой Testo) можно найти вот тут:


https://github.com/testo-lang/testo-articles/tree/master/HOMM3

Подробнее..

Обзор рынка труда QAQC в Москве

07.01.2021 14:19:53 | Автор: admin
"Word cloud" на основе описаний вакансий из раздела "Тестирование" по Москве."Word cloud" на основе описаний вакансий из раздела "Тестирование" по Москве.

Я всегда с интересом читаю обзоры рынка труда, которые публикуются на Хабре. Но, после них у меня всегда оставалось чувство легкого голода: нехватало более подробного анализа по моему сегменту рынка и региону. Да и с регулярностью все было не то чтобы хорошо. Так пару лет назад, у меня появилась идея сделать что-то вроде дашборда по рынку труда QA специалистов Москвы на основе данных HH.ru. Результаты мне показались достаточно интересными, чтобы принести их сюда.

Начну с того, чего в этом отчете нет. Не буду отбирать хлеб у авторов с "Хабр Карьера" их опросы по зарплатам трудно превзойти по степени достоверности, поэтому в моих отчетах нет цифр по заработной плате. Также нет точности в абсолютных цифрах. Причины в том, что атрибуция вакансий на HH.ru сделана своеобразно и одна вакансия может публиковаться несколько раз под разными ID. С другой стороны, одно объявление может соответствовать нескольким открытым позициям в компании. Поэтому рассматривать абсолютные цифры следует с осторожностью. Но проводить сравнительный анализ эти данные все же позволяют. Для сбора вакансий использовалась открытая часть API HH.ru, которая отдает описание вакансий в формате JSON. Часть графиков построена на базе параметров переданных в JSON-формате, часть на основе анализа текстовых описаний вакансий. Наблюдение велось с марта 2019 по декабрь 2020 гг. в разделе "Тестирование" по г. Москве. Запрос был сужен до специалистов по тестированию, вакансии из этого раздела с другой специализацией отбрасывались.

Посмотрим как менялся совокупный спрос в этом году на фоне прошлого:

Видно , что по понятным причинам весенне-летнего пика, как в прошлом году, не случилось. Тем не менее, после провала в апреле он начал устойчиво расти и начиная с сентября превысил прошлогодний за аналогичный период. Можно сказать, что отрасль ИТ оказалась достаточно стойкой к вызовам пандемии и психологическое падение весной привело к реализации отложенного спроса в конце года.

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

На HH.ru есть возможность указать и вид найма с выбором из списка: полная занятость, частичная, проектная или стажировка. Но, в сравнении с прошлым годом, по этим показателям изменения минимальные. Полная занятость по-прежнему превалирует с долей в 97%.

Требования к опыту кандидатов изменились мало, и это "дрейф" в ожидаемом направлении: категория "от 3 до 6 лет" отъела по проценту от категорий "без опыта" и "от года до трех". Разница на грани статистической ошибки и об устойчивости этой тенденции можно будет говорить по итогам следующих лет. Кроме, того я предполагаю, что в само изначальное распределение долей внесена систематическая ошибка, о чем я напишу ниже.

Есть еще одна причина по которой я не стал делать анализ абсолютных цифр заработной платы: при попытке выделить предложения зарплаты по категории "без опыта", я получил совершенно не реалистичные цифры. При просмотре ценовых аномалий стало понятно, что описания множества вакансий не совпадают с категорией в которой вакансия публиковалась. То есть под грифом "без опыта" регулярно попадались вакансии ведущих инженеров и тест-менеджеров с зарплатами от 150 т. р и выше. О причинах я могу только гадать. Первое что пришло мне в голову это банальная лень и невнимательность среди тех, кто вносит описания вакансий. Не исключено, что к этому их подталкивает и пользовательский интерфейс. Не знаю как выглядит форма создания вакансии на HH.ru, но не удивлюсь, если значение "без опыта" там предлагается по умолчанию.

Тем не менее, из параметров вакансий, можно выделить косвенный показатель, который описывает изменения в зарплатной политике. Это доли вакансий с указанной и не указанной зарплатой и доли вакансий в которых диапазоны зарплат открыты вверх или вниз. Доля вакансий в которых не указан размер оплаты труда выросла на вполне заметные 5%, причем за счет вакансий с "закрытым" диапазоном и тех, где диапазон был открыт в сторону повышения. Доля вакансий с указанием только верхней границы изменилась незначительно. Мой вывод: если есть возможность сэкономить на фонде заработной платы в ситуации всеобщей неопределенности, то желающие это сделать обязательно найдутся. К счастью, волны массовых сокращений не случилось, если не считать отдельных случаев, как, например, с Wildberries. Но, зато часть столичных компаний обнаружила, что можно использовать рабочую силу из провинции без релокации, а "удаленка" у нас традиционно была поводом для дисконта в пользу работодателя.

Остальные графики в отчете относятся к техническим средствам тестирования и делались на основе частоты упоминаний этих средств в текстовых описаниях вакансий. Например, вполне ожидаемая четверка лидеров среди языков программирования (в порядке убывания): Java, Python, C#, JavaScript. Сюрпризом стал только взлет языка Kotlin c восьмого места в 2019 году, на пятое в 2020-ом. В целом, в этой группе отчетов я не нашел особых откровений, лидеры было вполне ожидаемы. Но, думаю, что для тех кто выбирает сейчас "ветвь развития" в профессии такие графики будут полезны.

Не буду занимать место под подробное описание чартов с инструментами: каждому будет интересен свой раздел. За подробностями лучше обратиться к полной версии отчета (осторожно, возможен хабра-эффект). Тем более, что она пересчитывается каждый день, на основе свежих вакансий. Если на графиках не нашлось места для вашего любимого языка, тестового фреймворка или другого инструмента тестирования пишите. Я готов расширить списки отслеживаемых инструментов, так же как и внести другие улучшения.

Подробнее..

Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist

19.01.2021 10:15:06 | Автор: admin

Привет, хабровчане. Сегодня я хочу осветить и обсудить тему локализации (L10N) и интернационализации (I18N). В интернете и, в том числе и на Хабре уже есть полезные и интересные статьи, но часто они дают более-менее общую информацию о подходах, без углубленной информации о том, что и как можно проверить. Я бы хотел с вами поделиться своим опытом, просуммировать кое что из статей, которые вы можете найти в интернете, а также постараюсь описать большой checklist с самыми распространёнными кейсами как для локализации, так и для интернационализации. В чеклистах я буду стараться упоминать только те проверки, которые вы можете сделать сами, без (глубоких) знаний языка новой для вас локали.


image


Что такое I18N, L10N и G11N?


Для начала давайте в целом разберём, что же такое интернационализация, локализация и, как следствие глобализация (globalization) и для чего это всё нам нужно.
Зачем же нам нужна локализация? В первую очередь распространение нашего продукта на глобальный рынок. Чем в большем количестве стран он будет доступен, тем больше ширится список потенциальных и фактических клиентов. Следующим пунктом является так называемый "customer satisfaction", ведь всем приятно пользоваться продуктом на родном языке, даже если вы хорошо владеете иностранными. Как следствие из пунктов выше наш доход и прибыль увеличиваются! Стоит сразу сказать, что локализация не равно перевод. Локализация это перевод и культурная адаптация продукта к особенностям определенной страны или региона. Несколько хороших примеров частных случаев локализации можно посмотреть тут, а я пока продолжу.
Хоть английский и является самым распространённым интернациональным языком, но участники глобального рынка не ограничиваются одними США и англоговорящими странами. Показательным примером будет тот же Tik-Tok, активных пользователей которого насчитывают около 1 миллиарда, а количество скачиваний на сегодняшний день перевалило за 2.6 миллиарда. При этом большинство пользователей данного приложения из США, Индии и Китая. И такая тенденция просматривается на всём рынке приложений.


Как же можно создать локализованное приложение? Тут я могу выделить несколько подходов:


  1. В принципе можно пойти в лоб и создать по 1 приложению на каждый регион/страну. Такой вариант очень дорого и неудобно поддерживать, ведь работать нужно будет с каждым продуктом отдельно. Понятно, что никто так делать в наше время не будет =)
  2. Далее приходит на ум более удобный вариант создать 1 приложение, которое включает в своём коде локализацию для всех необходимых вам регионов/стран. Вариант уже лучше, но и его достаточно сложно будет поддерживать. Да и хранить инфу о всех регионах/странах значит сильно увеличить размер приложения + велика вероятность, что данные локализации будут вплотную пересекаться с основным кодом приложения.
  3. Как итог наших умозаключений, мы приходим к мысли, что было бы удобно создать продукт, в котором региональные и культурные особенности (текст, картинки, форматы даты, времени и т.п.) будут вынесены в отдельные блоки (никакого хардкода в переводимых местах), которые будут подгружаться при использовании того или иного региона/страны. Данный набор ресурсов называют "локалью" (locale).

Такой вариант дизайна приложения имеет множество плюсов:


  • Помогает избежать хардкода для ресурсов, которые должны быть переведены. Если вы переключились на какой-то регион/язык, но видите текст не на ожидаемом языке это явно баг, если вы изначально не решили, что определённые места не будут переведены (подробнее об этом можно узнать в разделе о псевдо-локализации ниже)
  • Файлы, нужные для локали, уже предопределены, их удобно отслеживать, обновлять и создавать новые для новых локалей.
  • В случае, если нужно добавить новую локализацию, то всё, что нужно сделать создать нужные данные для вашего региона/страны и подгрузить их в приложении. И да, вы уже знаете, что и где нужно тестировать!
  • Также стоит отметить, что не нужно хранить все локали изначально в вашем продукте. Такой подход уменьшает изначальный размер приложения.
  • Баги, найденные при тестировании локализации, как правило, будут связаны непосредственно с локалью, а не с самим приложением. Если баг связан с кодом приложения, то скорее всего проблема связана с тем, что данный ресурс не был вынесен в локаль или не был переведён, т.е. это баг интернационализации вашего приложения, либо самой новой локали.

Интернационализация (I18N)


Звучит интересно, но как же нам заставить всё это работать именно в таком виде? Тут нам на помощь приходит интернационализация. Интернационализация процесс разработки приложения, при котором код самого приложения независим от любых языковых и культурных особенностей региона/страны (cultural specific data). Internationalization принято сокращать как "I18N", где 18 это число символов между "I" и "N". Суть интернационализации в том, чтобы сделать процесс локализации проще, дешевле и быстрее. Реализацию I18N обычно начинают на ранних этапах проекта, чтобы подготовить ваш продукт к будущей локализации.
Во время процесса интернационализации определяют, что будет изменяться для будущих локалей (например текст, изображения и т.п.) и выносят эти данные во внешние файлы. Также во время интернационализации нужно добавить возможность изменять календари, форматы даты, времени, цифр, денежных символов и в целом символов, специфичных для определенных языков и многое другое. Как итог, в идеальном варианте, добавление новой локали не должно требовать от нас изменения исходного кода продукта!


Локализация (L10N)


Теперь можно поговорить чуть подробнее и о локализации. Локализация (localization или L10N) это процесс перевода и культурной адаптации продукта к особенностям определенной страны, региона. Как упоминалось выше, на этой стадии участники разработки продукта работают с локалями внешними ресурсами (файлами), которые подгружаются приложением для загрузки локализации для вашей страны/региона. Нюансов, на которые стоит обратить внимание, очень большое количество и их я приведу в разделе с чеклистом ниже, а пока хочу выделить основные зоны локализации:


  • текст и связанные с ним функции (например сортировка, поиск, поддержка спец. символов и т.п.)
  • документация (мануалы, гайды, FAQ, helps и т.п.)
  • форматы даты и времени
  • формат чисел
  • формат денежных величин
  • поддержка различных календарей
  • изображения (картинки, иконки)
  • звук (в частности, озвучка, если таковая имеется)
  • реклама (текстовая, аудио, видео)
  • и т.д.

Глобализация (G11N)


Завершая обзорную часть, хотелось бы ещё упомянуть термин Globalization (G11N), который используется для обозначения комбинации I18N и L10N. Также он используется для обозначения процесса, благодаря которому компания может выпустить свой продукт на глобальном рынке. Честно говоря не скажу, что есть конкретное определение глобализации вашего продукта (т.е. использования такого количества локалей, после которого ваша глобализация достигает 100%), поэтому я бы охарактеризовал процесс глобализации формулой вида: G11N = I18N + n*L10N, где n количество локалей, используемой вашим продуктом.
Напоследок я бы хотел ещё указать сокращение для Translation T9N. На практике используется редко, но тоже встречается.


Тестирование локализации. Метод псевдо-локализации (Pseudo-localization)


Разобрав что есть что, можем перейти непосредственно к тестированию локализации. Здесь я бы выделил 2 подхода: когда у нас есть локаль и когда её нету. С первым вариантом всё просто, берём локаль и проводим необходимый комплекс операций для проверки её качества. Но, как ни странно, 2й вариант тоже имеет место на жизнь и будет крайне полезен, когда интернационализация вашего продукта только завершилась и у вас ещё нету новой локали. В данном случае нам очень поможет техника псевдо-локализации (Pseudo-localization approach). В рамках этого подхода вам нужно подготовить псевдо-локаль (сделать это может и сам тестировщик, не имеющий знаний нужного языка), используя любой другой язык и добавить в файлы необходимые вам данные, например спец. символы определенного языка. Также можно добавить большее количество символов в строки, чтобы проверить будет ли обрезаться текст (truncate), ведь текст может стать длиннее после перевода на новую локаль и не вместиться в отведённое для него пространство. Ещё такой подход поможет вам найти проблему с объединением строк (concatenation) и проблемы, связанные с отображением шрифта, если таковые имеются. Для того, чтобы такие проблемы можно было проще найти, то в начало и конец строки можно добавить какой-нибудь символ. К примеру Microsoft использует такой подход ещё с 90х и вставляет квадратные скобки для обозначения начала и окончания строки.


Для более наглядной иллюстрации нашёл хороший пример. Вот скриншот оригинального приложения
image


А вот как это же приложение выглядит после подгрузки псевдо-локали с использованием всех подходов, описанных выше:
image
В принципе, вы без труда сможете обнаружить здесь целый ряд проблем, которые нужно обдумать и решить.


Собирая всё вышесказанное вместе, ниже вы можете найти скриншот, на котором изображено то, что без труда может выявить псевдо-локализация:
image


Internationalization checklist


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


  1. Установка и удаление продукта при использовании локали, отличной от дефолтной. Раз мы можем и должны использовать различные локали, то мы должны иметь возможность устанавливать и удалять приложение, используя любой язык.
  2. Настройка приложения на локали, отличной от дефолтной. Все изменения в настройках должны сохраняться и использоваться.
  3. Приложение должно работать на окружении, локаль которого отличается от дефолтной локали нашего приложения.
  4. При запуске приложения на новой локали вам нужно проверить, что форматы даты, времени, спец.символы алфавита, денежных валют, календари и прочие вещи, связанные с культурными особенностями можно переключать в приложении без каких-либо ошибок (вручную или автоматически). Как правило такие ошибки выявляются при первом запуске новой локали.
  5. Локализованный текст, изображения и прочие ресурсы не вшиты (hard-coded) в приложение. Баги такого рода вы найдёте достаточно быстро, ведь, к примеру, оставшиеся английские слова будут сразу видны на фоне азиатского текста.
  6. Также я бы посоветовал обратить внимание на то, что документы (к примеру гайды, FAQ и т.д.) переключаются на нужный вам язык при смене локали.

Localization checklist


Разобравшись к тому, что можно отнести к проверка интернационализации, давайте перейдём к самой масштабной части данной статьи. Для удобной навигации я разобью все проверки на разделы и приведу примеры для большей наглядности. Очень хорошим источником знаний мне послужила Globalization Overview документация от Microsoft.


image


Региональные и культурные особенности


Раздел, на проверки которого нужно обратить внимание в первую очередь. Сюда можно внести:


Календари


В мире используются разнообразные календари и это стоит учитывать, когда вы оцениваете кто будет вашей аудиторией и удобство использования вашего приложения для этого региона. В большинстве англоязычных стран, а также на территории СНГ используется Григорианский календарь (Gregorian Calendar). Если же ваше приложение нацелено на глобальный рынок, то вы должны иметь возможность использования других календарей. К примеру можно выделить следующие: японский, буддийский, хиджринский, еврейский лунный и тайваньский. Одно из основных различий между календарями заключается в том, что каждый из них может иметь разное значение года для текущей даты, в зависимости от старта исчисления времени текущего периода. Давайте рассмотрим несколько примеров различий разных календарей:


  • 2016 год по григорианскому календарю это двадцать восьмой год в японской эре Хэйсэй и 1437 год в календаре хиджры.
  • Первый день года может не быть 1 января.
  • Китайский Новый год приходился на 8 февраля (в 2016 году) по григорианскому календарю.

Продолжительность года и месяцев может варьироваться, также как и способы обработки високосных лет. Даже первый день недели может начинаться в день, отличный от понедельника (Европейские страны) или воскресенья (США). Ну а напоследок стоит отметить, что в некоторых локалях может использоваться более одного календаря как, например, в японской локали на Windows.
image


Форматирование дат


Когда мы говорим о дате, обычно мы подразумеваем такие ее составляющие как день, месяц и год. Однако стоит отметить, что в мире не существует какого-либо общего используемого стандарта отображения этих данных, а в некоторых случаях различия могут существовать даже в разных регионах одной страны.
Для отображения даты обычно используется маска вида DD/MM/YYYY, где D день, M месяц, а Y год. При этом количество букв в каждой части обозначает количество символов, которые будут указаны в каждой секции. Например для маски вида DD/MM/YYYY дата будет выглядеть как 16/06/2021, а для маски вида DD/MM/YY 16/06/21.


По полноте отображения даты я бы выделил 4 основных формата:


  1. короткий (short) 16.06.2020
  2. средний (medium) 16 Jun 2020
  3. длинный (long) 16 June 2020
  4. полный (full) Monday, 16 June 2020

Не стоит забывать и о символах-разделителях. В зависимости от формата, разделители могут отличаться. Самые распространенные косая черта (/), точка (.), пробел ( ).


Каждый отдельный элемент в дате может быть записан в своём формате, который может меняться в зависимости от региона. Давайте возьмём в качестве примеру дату "16.06.2020" и посмотрим на различные варианты записи её составляющих:


  1. День: 01, 1
  2. Месяц: 06, 6, June, Jun, J
  3. Год: 2020, 20
  4. День недели: Monday, Mon, Mo, M, 01, 1

Варианты, представленные выше, даже достаточно экзотические типа J, M и т.д., на самом деле не являются чем-то из-ряда вон выходящим. К примеру все эти варианты для использования вы можете найти в системных настройках языка и региона в MacOS.


Говоря об не самых распространённых вариантах записи, я бы хотел обратить ваше внимание и на различные элементы и составляющие даты, которые могут быть использованы:


  • День недели (Monday)
  • Месяц (June)
  • День месяца (1)
  • Год (2020)
  • Эра (AD)
  • День года (153)
  • Неделя года (23)
  • Неделя месяца (1)
  • День недели в месяце (1)
  • Квартал (2)

Подытоживая тему с датами, обязательно стоит упомянуть и специфическое написание дат для разных регионов/стран. Давайте сравним даты, написанные в формате таких стран как США, Мексика, Япония (используем длинный формат даты long date):


  • USA -Tuesday, October 12, 1954
  • Mexico: martes 12 de octubre de 1954
  • Japan: 19541012

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


Рассмотрим также пример с коротким форматом даты (short date):


  • United States: 10/12/54
  • Mexico: 12/10/54
  • Japan: 54/10/12

В короткой дате мы снова видим, что в мексиканском примере порядок день/месяц/год, в США это месяц/день/год, а для Японии порядок такой год/месяц/день. Это может вызвать путаницу, если не следить внимательно. Например, в зависимости от того, в какой стране вы находитесь, дата, указанная как 07/04/01, может означать:


  • United States: July 4th, 2001
  • Mexico: April 7th, 2001
  • Japan: April 1st, 2007

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


Форматирование времени


Как и в случае работы с датами и календарями, форматы времени не являются константой во всем мире. Хоть самым распространённым представлением является "часы, минуты, секунды", формат их написания и разделительные символы могут сильно различаться. Различия могут быть даже в рамках разных регионов одной страны. Ниже вы найдёте различные варианты отображения форматов времени и комментарии к ним:


  • Использование 12-часового или 24-часового формата.
    В большинстве европейских и азиатских регионов используется 24-часовой формат времени вместо 12-часового (AM/PM), который, к примеру, используется в США. Также AM/PM часть может отображаться на языке страны, а местоположение этой части может быть как до, так и после числового значения времени.


  • Разделительный символ для часов, минут и секунд.
    Хотя двоеточие (:) и является самым распространённым разделителем, в некоторых азиатских языках используются идеографические символы. Кроме того, в некоторых регионах требуется использование символов "h", "m" и "s" для соответствующей части при отображения времени.


  • Отображение часовых поясов.
    Наиболее распространенным форматом отображения часового пояса является формат вида: GMT +3:30. Давайте его разберем на составляющие. Один из вариантов отображения часового пояса, по совместительству самый распространённый, это отображение времени по Гринвичу (используется аббревиатура GMT Greenwich Mean Time) или его современной замены UTC (Coordinated Universal Time). Затем следует символ, показывающий смещение времени в положительную (+) или отрицательную (-) сторону от данного стандарта. Далее же идут конкретные значения смещения, отображаемые в часах и минутах. (В некоторых часовых поясах используется 30-минутное или 45-минутное смещение.) Например, часовой пояс для Бангалора, Индия, будет отображаться как UTC +5:30, а для острова Чатем, Новая Зеландия, это будет UTC +12:45. Другой способ отображения часовых поясов использование названий местных часовых поясов.



При проверке отображения часовых поясов вы должны принять во внимание следующее:


  1. Не все страны используют местные названия для часовых поясов.
  2. Аббревиатуры часовых поясов не уникальны.
  3. Не во всех странах используется летнее время, при этом летнее время может начинаться и заканчиваться в разные дни для разных стран.
  4. Один часовой пояс может иметь много разных названий в зависимости от страны и языка.
  5. Как упоминалось выше, смещение может быть не только на пол часа или час, но также и на 15-минутное значение (к примеру UTC +12:45 для острова Чатем в Новой Зеландии).

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


  • короткий (short) 23:20 (часы, минуты)
  • средний (medium) 23:20:59 (часы, минуты, секунды)
  • длинный (long) 23:20:59 GMT+3 (часы, минуты, секунды, часовой пояс)
  • полный (full) 23:20:59 Moscow Standard Time (часы, минуты, секунды, полное локальное обозначение часового пояса)

Каждый элемент выше может писаться в своём формате, например:


  • Часы: 1-12, 01-12, 0-23, 00-23, 0-11, 00-11, 1-24, 01-24
  • Минуты: 01, 1
  • Секунды: 01, 1
  • Часовой пояс: GMT+3, Moscow Standard Time, Belarus Time, bymsq, Europe/Minsk, +0300, +03:00, GMT+03:00

Если углубиться и разбить время на элементы для использования, то я бы выделил следующие:


  • Часы (07)
  • Минуты (08)
  • Секунды (09)
  • Обозначение времени суток (AM/PM)
  • Часовой пояс/Временная зона (GMT+3)
  • Миллисекунды (000)

Интересный момент касательно обозначения времени до и после полудня: в некоторых системах, к примеру на Mac OS, вы можете задать свои обозначения вместо стандартных AM и PM.


Первый день недели


Как упоминалось выше, первый день недели может варьироваться в зависимости от региона/страны. Этот пункт стоит выделить отдельно, т.к. часто он остаётся незамеченным, но от этого он не становится менее важным.


Форматирование чисел


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


  1. Разделитесь для тысяч
    Разделительный символ для тысячных значений отличается в зависимости от региона/страны. К примеру в США используется запятая (,), в Германии точка (.), а в России, Беларуси, Швеции пробел ( ).


    • США запятая (1,147)
    • Германия точка (1.147)
    • Россия, Беларусь пробел (1 147)

  2. Разделитель дробной части
    В качестве символа разделителя дробной части обычно используются точка (.) или запятая (,).


    • США точка (1,147.55)
    • Германия запятая (1.147,55)
    • Россия, Беларусь запятая (1 147,55)

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


    • -123
    • 123-
    • (123)
    • [123]

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


    • Латинские числа 0 1 2 3 4 5 6 7 8 9
    • Арабские числа
    • Японские числа
    • Корейские числа

  5. Группировка чисел
    Речь о количестве символов, содержащихся между каждым разделителем для всех групп цифр, которые появляются слева от десятичного разделителя (единицы, десятки, сотни и т.д.). В большинстве культур группировка идёт по 3 числа (к примеру Англия 123,456,789.00), однако есть и исключения, например в Хинди все части числа, кроме сотен, группируются по 2, а сами сотни по 3: 12,34,56,789.00


  6. Местоположение символа процента (%)
    Как и в случае со знаком отрицания, его местоположение и форма записи может варьироваться:


    • 98%
    • 98 %
    • %98
    • 98 pct

  7. Нумерованные списки
    В разных регионах нумерованные списки могут использовать разные цифры, как стандартные (латинские), так и, к примеру, римские. В некоторых случаях могут встречаться и более экзотические варианты, например нумерация по системе Iroha в Японии.



Форматирование значений валюты


В качестве символа валюты может использоваться заранее определенный символ (например европейский евро , Доллар США $, Новый Израильский Шекель ), комбинация букв (Доллар США USD, Белорусский рубль BYN), а также их сочетание (к примеру новый тайваньский доллар пишется как NT$). Местоположение символа валюты может быть как до, так и после цифрового значения суммы. Стоит также отдельно выделить, что для отображения отрицательных значений сумм могут использоваться разные способы:


  • Знак ставится до символы валюты и суммы: UK (-127.54), France (-127,54 )
  • Знак ставится до суммы, но после символа валюты: Denmark (kr-127,54)
  • Знак используется после суммы: Netherlands 127,54-
  • Вместо отрицательного знака используются круглые скобки: US ($127.54)

В качестве разделителя десятичных значений и тысяч в сумме, чаще всего используется тот же разделитель, что и для чисел в этой локали, но бывают исключения. К примеру в большинстве мест в Швейцарии в качестве десятичного разделителя используется запятая (Sfr. 127,54), однако есть исключения, где используется точка (Sfr. 127.54).


Значение температуры


Важно следить правильные ли значения для подсчета температуры используются в вашей локали. Как правило используются значения в Цельсиях (3C) и Фаренгейтах (3F). Здесь стоит ориентироваться на возможные значения шкал Цельсия и Фаренгейта, а также на правила записи чисел, что мы уже обсудили выше.


Системы мер


В большинстве случаев вы столкнетесь с одной из 2х систем: метрическая система мер (метры, литры, граммы и т.д.) и английская система, её ещё называют имперская система (футы, дюймы, фунты и т.д.). Речь идет о таких измерениях как: длина, вес, площадь, объем, обозначение угла и т.п. Таким образом, необходимо убедиться, что если вы имеете дело с измерениями, то можете отображать их с помощью различных систем. Кроме того, убедитесь, что пользователю ясно, какая система используется в данный момент. В некоторых случаях английская/имперская система может быть разбита на подвиды для разных стран. К примеру Mac OS позволяет вам выбрать систему измерений из 3х вариантов: Metric, UK, US.
Интересный факт: зонд Марса был утерян, потому что его система наведения была разработана для одной системы мер, а ученые, использующие ее, думали, что это была другая система мер.


Где и как можно переключить региональные настройки на операционной системе вашего ПК


Вы можете изменить параметры используемые для вашего региона на странице свойств Региональные параметры/Regional Options, затем переходите на Язык и региональные стандарты/Regional And Language Options.


  • Windows 10 Control Panel > Clock, Language and Region > Region (часть настроек тут) > Additional Settings (большая часть настроек тут).
  • Mac OS Apple menu > System Preferences > Language & Region > General (часть настроек тут) > Advanced (большая часть настроек тут)
  • Ubuntu System menu > System Settings > Region & Language

Буквенные и числовые значения


Алфавит/Шрифт


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


  1. Усечение/обрезка слов и предложений.
  2. Не вместимость текста в нужный элемент из-за его увеличения после перевода.
  3. Закодированный (hard-coded) текст.
  4. (Не) отображение спец. символов для данного языка.
  5. (Не) отображение конкретного шрифта.
  6. Объединение нескольких строк в одну.
  7. Размер символов шрифта на экране (к примеру некоторые иероглифы могут быть слишком маленькие на вашем элементе, из-за чего их крайне сложно или невозможно прочитать).

Также стоит учитывать и то, что в одной стране может быть несколько государственных языков. Тут уже вам решать, реализовывать ли все варианты или только определённые. К примеру в Беларуси государственных языка 2: белорусский и русский.
В дополнении, я хочу выделить ещё несколько нюансов, которые не связаны с отображением символов, но их всё равно важно учитывать при добавлении элементов нового языка:


  1. Сам шрифт может весить достаточно много и, если у вас нету запаса памяти для таких прожорливых шрифтов, то в процессе работы ваше приложение рано или поздно может выдать Out Of Memory exception и прекратить работу.
  2. На одном из моих game-dev проектов были случаи, когда возникали проблемы при игре людей с разными локалями, например English и French. В этих случаях игра, в лучшем случае теряла соединение с сервером, в худшем крашилась. В такой ситуации, в наихудшей ситуации у вас будет сразу 3 разных локали: у каждого игрока своя + локаль сервера, не совпадающая ни с одной из локалей игроков. Так что есть смысл проверить конект всех локалей со всеми методом тестирования всех пар.

Ориентация текста


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


Сортировка строк


Эта тема достаточно обширная. Здесь я пробегусь вкратце. Больше информации и примеров можно найти в документации Microsoft.
Каждый язык имеет свой уникальный набор правил (иногда более одного) описывающий как языковые строки должны быть отсортированы или сопоставлены в упорядоченный список. Ожидания пользователей от этих списков могут варьироваться в зависимости от того, где представлена информация, например, таблицы, словари, телефонные справочники и т.д. Однако бывают случаи, например для файловых систем или веб-URL, когда согласованность компьютеров важнее правил любого человеческого языка. В таких случаях реализация сортировки может быть изменена под наши нужды. Стоит учитывать, что, как правило, пользователи вообще не думают о сортировке, пока с ней не что-то не так =)
В азиатских языках существует несколько различных порядков сортировки в зависимости от фонетики, радикального порядка и т. д., а сам фонетический порядок может зависеть от контекста.


Формат адреса


Адрес это, пожалуй, самая нестандартная часть для проверки. Здесь стоит быть максимально внимательным и проявлять гибкость при проверке данных. Учитывайте то, что нету универсального порядка записи адреса. В разных странах способ написания может отличаться, к примеру где-то это может быть "Страна/Город/Улица/Дом/Квартира", а где-то "Улица/Дом/Квартира/Страна/Город". Также некоторые данные могут опускаться либо наоборот, добавляться, в зависимости от страны. Есть достаточно распространённый пример: часто бывает так, что какое-нибудь поле, например, "State" (для USA) или "Province" (для Канады) делают обязательным при вводе адреса. Для данных стран такой подход является верным и правильным, но ведь во многих других странах нету такого понятия как "штат". И тут мы сталкиваемся с проблемой, ведь пользователь не знает, что вписать в это, обязательное(!!!), поле.
Крайне важно следить за способом ввода адреса, особенно если вы работаете на проекте связанным с магазинами, доставкой, логистикой и т.п. Но не редки и случаи-исключения, когда официально какой-то район может принадлежать одному населенному пункту, а на сайте он числится за другим. Как показывает моя практика, это скорее частные случаи, специально реализованные для удобства использования на конкретных проектах.
Ещё одним хорошим примером является проверка формата почтового индекса (ZIP code для США или Postal code для остального мира). Как вы уже догадываетесь, почтовый индекс не имеет какого-либо универсального формата или длины, а также он может состоять не только из цифр. Варианты написания почтового индекса можно привести следующие:


  • только цифры, например 5 цифр у США и Франции (85001) или 6 цифр у Беларуси (220123)
  • почтовые индексы Канады состоят из двух групп по три символа M5R 3H5
  • в некоторых странах/регионах код страны или региона вставляют перед почтовым индексом F-92300

Формат телефонных номеров


И опять мы сталкиваемся с тем, что в мире нету универсального формата формат телефонных номеров. Здесь может разниться количество чисел, так и их группировка, использование дополнительных символов и символов-разделителей, таких как дефис (-), точка (.), знак международного префикса (например знак плюс (+)), круглые открывающие и закрывающие скобки (), пробел ( ) и т.д. Обычно для записи номера телефона используется 7-11 цифр.
Давайте рассмотрим несколько примеров форматов телефонных номеров для разных стран (без учета кода самой страны):


  • Китай 1234 5678
  • Франция 01-23-45-67-89
  • Польша (12) 345.67.89
  • Сингапур 123 4567
  • Тайланд (01) 234-5678 или (012) 34-5678
  • Великобритания 0123 456 7890 или 01234 567890
  • США (123) 456 7890
  • Беларусь +375-29-123-45-67

В некоторых странах наравне с международным стандартом набора номера, может использоваться еще и "полный локальный" вариант записи номера телефона. К примеру в Беларуси как раз есть оба варианта. Например, если стандартный номер телефона для населенного пункта имеет вид "123-45-67", то полная запись может выглядеть как 8-029-123-45-67 (полный номер телефона для набора внутри страны), так и +375-29-123-45-67 вариант записи для международных звонков. Также вместо знака международного префикса (+) могут быть использованы его эквиваленты, чаще всего они цифровые. К примеру при замене и звонке из России в Беларусь, номер будет выглядеть следующим образом "8 10 375 код города/мобильного оператора номер телефона", а из Молдовы в Беларусь, следующим образом: "0 0 375- код города/мобильного оператора номер телефона". Как видите, варианты форматов номеров может быть большое количество даже внутри одной страны.
Напоследок, стоит упомянуть про работу со службами, которые могут использовать короткие номера телефонов (к примеру 911, 101 и т.д.). Это ещё один хороший пункт для проверки.
Обязательно ознакомьтесь с тем, какие варианты чаще используются в необходимой вам стране/регионе!


Размеры листов бумаги


Кто бы ждал подвоха тут! И вновь все нюансы лезут из-за разных форматов. К примеру размеры бумаги в США и Канаде (например, Letter, Legal и т. д.) не совпадают со стандартами с других частей света. Например, в большинстве стран Европы и Азии используется всем нам известный формат A4, который имеет немного другие размеры (297 x 210 мм) нежели чем упомянутые выше (например размер Letter в США составляет 279 x 216 мм).


Общие советы по локализации (потенциальные проблемы)


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


image


Изображения


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


  • не встраивайте текст в картинки/иконки и т.п. Если у вас написан текст поверх изображения, то лучше реализовать текст как отдельный слой и наложить поверх. Так вы сможете обновлять ваш текст заменой значения стринги, а не созданием новой картинки для каждой локали.
  • если вам необходимо использовать изображение с людьми (например ваше приложение пользуется популярностью в европейском, азиатском и африканском регионах), то постарайтесь использовать варианты с силуэтами людей (или другой абстракцией). Так пользователи из разных стран смогут ассоциировать себя с людьми на картинке. Как альтернатива, можно использовать изображение (фото) с людьми разных национальностей. Это поможет избежать неловких ситуаций и улучшит лояльность ваших потребителей.
  • не стоит использовать изображения-ребусы, если на то нет веской причины. То, что будет понятно пользователем одной локали, может быть непонятно или даже вызвать недоумение у пользователей другой локали. Не всегда легко предугадать как тот или иной ребус будет воспринят в определённом регионе.
  • старайтесь не использовать картинки и иконки с различными символами или жестами. В разных культурах они могут быть интерпретированы самыми разными способами, в зависимости от культурных и исторических особенностей того или иного региона. Даже, казалось бы привычные и позитивные жесты, в наши дни могут поменять свой смысл из-за чей-то шутки в интернете.

Числовые и цветовые ассоциации


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


Рекламные ограничения


С рекламой всё тоже не так однозначно. Одни и те же вещи могут иметь различные возрастные ограничения в разных странах. К примеру кино, имеющее ограничение в США 12+, в странах СНГ может иметь ограничение 16+ или даже 18+ по тем или иным причинам. Что-то так вообще запрещается рекламировать в одном регионе/стране, но без проблем можно в другом.


Звуки


Звуки, как и музыкальные ассоциации, тоже могут быть интерпретированы по разному. К примеру часто различается текстовое и звуковое использование звуков животных, природы, механизмов и т.д. Например, если в русской речи мы привыкли, что кот говорит "мяу", то в японском кот уже говорит "ня/няу".


И давайте поговорим немного о функциональности


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


  • гиперссылки могут работать некорректно либо переводить пользователей на некорректные версии сайтов.
  • валидация полей ввода и вывода. Не всегда пользователи могут вводить данные на их языке при использовании их или другой локали, также как и вывод не всегда может отображаться корректно.
  • как писалось выше, сортировка должна работать корректно на каждой локали.
  • в некоторых случая шорткаты клавиатуры могут отличаться в зависимости от используемой локали. К примеру сочетание клавиш для файлов, которые в English локали завязаны на букву F (от слова File), для German локали желательно переделать, чтобы использовалась буква D (от слова Datei), т.к. в данном слове вообще нету буквы F. А такие языки как, например, Китайский, Японский и Корейский вообще не основаны на латинском алфавите. Для таких групп языков обычной практикой является сохранение сокращений исходного языка на основе латыни.

Заключение


Как вы видите, тестирование интернационализации и локализации это интересное и комплексное занятие, на которое должно уделяться приличное время. I18N и L10N очень важные аспекты современных приложений для запуска на глобальном рынке! Локализация не заключается в простом переводе текста с одного языка на другой. При этом заниматься тестированием интернационализации и локализации могут не только соответствующие команды, но и QA инженеры, которые никак не связаны с ними, так как многие аспекты можно проверить без (глубокого) знания языка локали!
Статью можно дополнить ещё большим количеством менее распространённых проверок для частных случаев, например лицензии, карты, обработка кредитных карточек и т.д. и я буду обновлять её по мере появления такого опыта. Также будет здорово, если вы поделитесь своим опытом в комментариях и эта информация появится здесь ещё раньше! Так мы сделаем эту статью ещё полезнее большему количеству людей!
Надеюсь вам была полезна данная информация и вы узнали для себя что-то новое. Буду рад пообщаться с вами по теме в комментариях!

Подробнее..

Mind Map в помощь тестировщику

29.01.2021 00:15:15 | Автор: admin

Майндмап, Майнд карта, интеллект-карта, ассоциативная карта, диаграмма связей и т.д. устоявшегося русскоязычного термина пока нет.
Как, зачем, когда и надо ли?

Материал готовила для начинающих, но возможно и более опытные найдут полезные моменты.

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

Для сложной структуры, на первых порах, в походных условиях удобно чёркать обычным карандашом. Не бойтесь исправлять это нормальный рабочий процесс.

Когда (если) структура понятна, можно переходить к электронному варианту.

Интеллект-карта визуализирует структуру связей!

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

А на других призывают рисовать действия-глаголы, но ни в коем случае не Интерфейс:

Какая точка зрения верна?

Обе!
Противоречие только кажущееся, к этому вопросу мы вернемся позже.

Для начала нарисуем карту связей для ситуации бытовой посещение Торгового центра.

Декомпозируем верхнеуровневый Торговый центр до отделов которые нужно посетить.

Декомпозиция до отделовДекомпозиция до отделов

Теперь добавляем цель посещения (декомпозируем до товарных позиций, которые предстоит купить).

Декомпозиция до товарных позицийДекомпозиция до товарных позиций

А теперь смотрим на симпатичную карту и честно отвечаем на два вопроса:

Она вам поможет в ТЦ?

Стали бы рисовать такую для себя?

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

Так что немного тормозим и хорошо запоминаем:

визуализация призвана помогать, не стоит рисовать картинки ради картинок.

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

Декомпозиция до базовых действий (индивидуальная юзер стори)Декомпозиция до базовых действий (индивидуальная юзер стори)

И запоминаем второе правило:

Имеет значение: вы готовите рабочие документы для себя или для команды. Во втором случае учитывайте уровень подготовки/знаний о продукте тех кто будет работать с этими документами.

А если надо протестировать весь ТЦ?
Очевидно, что вносить все товарные позиции в карту совсем не вариант.
Здесь нужен уже другой подход.
Предположим, вам на проверку достался Цветочный павильон и у вас на руках есть макеты как это должно выглядеть. Нарисуем карту Интерфейса, она поможет проверить GUI, убедившись, что ничего не упущено и все соответствует требованиям.

ИнтерфейсИнтерфейс

Составлять чек-лист по карте весьма удобно. Технически саму карту можно использовать как готовый чек-лист. Лично мне эта схема не кажется удобной, для меня чек-листтаблицей предпочтительнее, но видела вполне успешные варианты (смотрите ниже ссылку на доклад Натальи Руколь).

С GUI разобрались, но Логику (прописанную в спецификации) нам тоже надо проверить.
В этом случае первый шаг декомпозиции будет по типу объектов (либо по зонам) с которыми взаимодействует пользователь.
Второй шаг декомпозиции: либо действия возможные с этими объектами (или в этой зоне), либо следующий уровень элементов для взаимодействия.

ЛогикаЛогика

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

Карта сценариев / юзер сториКарта сценариев / юзер стори

Как видите Mind Map, в отличие от, например, таблицы принятия решений, не имеет единой формы. Это просто инструмент визуализации, позволяющий работать в рамках актуальных задач.

И, возвращаясь в начало публикации: наставники, уточняячто должно присутствовать на карте, а что нет, озвучивают требования не к майнд-карте как таковой, а применительно к конкретной ситуации.

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

Контекст определяет подходы к тестированию и содержание конкретной интеллект-карты

И, как следствие, правы оба наставника.

Если говорить про ограничения, пожалуй надо упомянуть и про Карту (диаграмму) состояний и переходов (State & Transition).
Это конкретная техника тест-дизайна!
Не путайте ее с Интеллект-картами, невзирая на то, что Карту состояний вполне можно отрисовать в том же XMind (либо другой программе которой вы пользуетесь).

В карте состояний и переходов мы отслеживаем состояние одного объекта (!!!) в рамках одного процесса по шагам переходов.
В оригинале ("A Practitioner's Guide to Software Test Design" Lee Copeland) карта начинается с точки и ей же заканчивается.
В моем примере вместо начальной точки (вход) используется верхнеуровневая плашка с названием объекта Заказ букета, анализируем не букет, а именно заказ, прописывая его состояние, обязательно указывая действие на линии перехода. Постоянно задавая себе вопрос а что если. Это позволит не пропустить проверку сценариев передумал покупать, не хватило денег, не буду оплачивать и обнаружил брак, хочу вернуть.

НЕ путать с Картой состояний и переходов (State&Transition)НЕ путать с Картой состояний и переходов (State&Transition)

Возвращаемся к Mind map.

Интеллект-карты в тестировании бывают большими и подробными, такие я называючтоб не забыть.
Вот хороший пример мнемоник мобильного тестирования I SLICED UP FUN

и LONG FUN CUP

Хотите еще больше?
Смотрите шикарную карту Тестирование новой фичи от Катерины Спринсян из Badoo (публикацию читать! там же можно посмотреть карту "ближе")

Интеллект-карта также может быть и последовательной, применимо, например, при составлении тест-плана

С другой стороны, небольшие рабочие Интеллект-карты бывает полезно использовать для решения каких-то конкретных небольших задач. Особенно если у вас доминирует визуальный канал восприятия.

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

На этом, пожалуй, всё.
Хотяэто далеко не все варианты использования Интеллект-карт в тестировании, но даже приведенного здесь полагаю достаточно для утверждения:
Интеллект-карты это удобный и наглядный инструмент визуализации позволяющий структурировать информацию и отслеживать связи.

Говорят даже что работа с картами положительно сказывается на мыслительных процессах :)


Ну и немного ссылок:
.

Mind Mapping, или как заставить свой мозг работать лучше http://personeltest.ru/aways/habr.com/ru/company/devexpress/blog/291028/

Вебинар для Аналитиков от Натальи Руколь, о пользе MindMap https://www.youtube.com/watch?v=-kPdHMBz-so

А еще карты можно рисовать фломастерами. Состояния и переходы от Натальи Руколь https://www.youtube.com/watch?v=8H9HgjrwQHA

Как нарисовать карту приложения http://okiseleva.blogspot.com/2020/01/mind-map.html

Mind map вместо тест-кейса http://personeltest.ru/aways/habr.com/ru/company/badoo/blog/418353/

MindMaps для груминга задач http://personeltest.ru/aways/habr.com/ru/company/avito/blog/437952/

Ps Бонусом для начинающих две задачи по тест-дизайну с ответами, комментариям, вариантами решений. / Совет: вначале решаете сами, потом уже листаете на ответ. https://drive.google.com/file/d/1bUoYe6KeNO8bR3hhv-9ChuNPo0CwG1PX/view

Подробнее..

Как стать тестировщиком

05.02.2021 10:09:34 | Автор: admin

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


Как стать тестировщиком с нуля

Для того чтобы компании стали рассматривать вашу кандидатуру на должность тестировщика, вам нужно соответствовать следующему списку критериев:

1)Опыт работы в IT-Сфере (фактически любой).Хотя позиция инженера по ручному тестированию считается низшей, все же туда предпочитают брать людей с каким-то минимальным опытом в IT. Например, можно устроиться в техническую поддержку в любую IT-компанию или оператора связи. Спустя 6 месяцев вы получите нужный опыт.

2) Познакомиться с тем, что такое тестирование.Вам нужно самостоятельно нагуглить определение следующих терминов и прочитать все, что есть про них в тех источниках, что вы нашли:

  • Что такое тестирование

  • В чем заключается цель тестирования

  • Виды тестирования ПО

  • Что такое тест-кейс

  • Как правильно писать тест-кейс

  • Что такое тест-дизайн

  • Что такое тестирование белого ящика

  • Что такое тестирование черного ящика

  • Что такое тестирование серого ящика

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

3) Изучить профессиональные книги по тестированию ПО.Дальше повышаем градус сложности и профессионализма и переходим к профессиональной литературе по тестированию ПО. Я настоятельно рекомендую прочитать книги:

  • Тестирование Дот Ком или Пособие по жестокому обращению с багами в интернет-стартапахот Романа Савина

  • Искусство тестирования программот Гленфорда Майерса.

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

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

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

Что нужно, чтобы стать тестировщиком

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

Если вы выберете карьеру инженера по тестированию, то вам нужно быть уверенным, что вы сможете каждый день делать одинаковую, монотонную работу и внимательно относиться ко всем мелочам.

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

Как стать тестировщиком игр

Многие ребята мечтают стать тестировщиками игр и весь день заниматься тем, что играть в игры. И это на самом деле можно осуществить, тестеры игр действительно играют и проверяют игры.

Тестировщик игр не сильно отличается от обычного тестировщика ПО. Он также получает задания от начальника и по определенному алгоритму выполняет их, описывания все неточности. Единственное различие заключается в том, что если вы хотите тестировать игры, то вам нужно пройти обучение на инженера по тестированию, а потом просто пойти наниматься в компании, которые занимаются разработкой игр.

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

Подробнее..

Какая бывает документация

13.02.2021 22:06:51 | Автор: admin

Когда мы говорим о тестировании документации, то обычно подразумеваем тестирование требований, ТЗ. И это тестирование на полноту, однозначность и прочая. Смотрим, как новый функционал будет коррелировать со старым, не будет ли проблем. Заранее продумываем свои тесты, обсуждаем реализацию...

Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Эта статья как чек-лист, что еще нужно найти и проверить.

Итак, давайте посмотрим, какая бывает документация:

  1. ТЗ требования

  2. Пользовательская документация

  3. Примеры

  4. Письма от системы

  5. Сообщения об ошибках

  6. Поп-ап сообщения

  7. Предупреждения что вводить

  8. Инструкция по установке

  9. Описание полей

  10. Маркетинговые материалы

  11. Обучение FAQ, презентации

  12. Поздравляшки

  13. Кнопки

  14. Остальное

  15. Итого

1. ТЗ требования

ТЗ техническое задание. Это основной тип документации для тестировщика. Если ТЗ есть, его всегда надо тестировать. Как само ТЗ, так и систему на соответствие этому ТЗ. Помните самые простейшие баги? Когда есть четкие требования, но система работает по другому.

Виды требований

В каком виде могут быть требования? Есть разные варианты:

Техническое задание

Сухое описание того, как система должна работать. Что уметь делать и как реагировать на ошибки.

Вариант использования

Описание через взаимодействия пользователя с системой:

Пользователь делает то

Система в ответ делает се

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

Пользовательский сценарий

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

В общем, градация от сухое ТЗ до интересная история широкая. Как ваш аналитик решил записать, так и будет.

Картинка

Да да, именно картинка! Вид ее может быть любой:

  • Блок-схема

  • Диаграмма состояний и переходов

  • Скриншот, раскрашенный красным тут должно быть вот так, а тут эдак

  • Схема движения транзакций

  • ...

То есть снова есть простор для творчества. Хотя обычно, конечно, используют от силы блок-схемы. Но и на том спасибо =)

Что-то другое

Я уверена, что могут быть и другие варианты. Но так как это статья от тестировщика тестировщику, ограничимся базовыми вариантами. За остальным к аналитику =)

У меня на одном из проектов, например, ТЗ было в виде презентации PowerPoint. Вот как генеральный продавал проект спонсорам, так мы и должны были сделать. Картинки + немного текста вот и всё ТЗ. Что непонятно, уточняйте устно.

Размер требований

Опять же, размер может быть любой. Все зависит от проекта, на который вы попадете.

Подробное описание

Обычно встречается на гос проектах. Ооооо, сколько там ТЗ!

Я участвовала на одном таком проекте, где описание функционала, который описывается одной строчкой (есть авторизация через email) занимало 10 листов А4 пошаговое описание интерфейса с картинкой через строку.

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

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

Плюсы:

  • Требования может проверить даже новичок (даже если там бухгалтерия или еще что-то сложное, в чем он ни в зуб ногой)

  • Если это ТЗ для интеграции у Заказчика будет возникать меньше вопросов А что будет, если...?. Ведь всё уже прописано в ТЗ.

Минусы:

  • Неактуальность документации (я бы написала сложно поддерживать актуальность, но она все равно в итоге будет неактуальна. Слишком много её)

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

Краткое описание

Буквально одна страничка на довольно большой объем работы. Там не расписываются подробно все ошибки или что может пойти не так, это скорее как напоминалка, какие функции должны быть.

Однако тут описано все необходимое для разработчика. Просто без кучи скриншотов, воды и прочего лишнего.

Плюсы:

  • Легко поддерживать актуальность.

  • При грамотном описании все понятно, без воды.

Минусы:

  • Начинающий тестировщик может пропустить тесты он не догадается, что тут можно было бы проверить (иногда ведь в ТЗ расписываются и все сообщения об ошибках, даже думать не надо, читаешь и делаешь).

  • Если отдать ТЗ третьим лицам (например, заказчику или его тестировщикам), получите много вопросов А что будет, если...?, и придется дополнять требования.

Однако минусы не так уж страшны. Так что если есть возможность пишите кратко!

Нечто среднее

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

Требований нет!

Бывает и такое. Приходите на проект, на, держи, тестируй. А где документация? А нету ее, так проверяй. Что делать?

На самом деле не бывает такого, что требований нет. Они всегда есть. Просто иногда в голове. Заказчика, аналитика, архитектора...

Ваша задача в этом случае эти требования узнать. И сохранить:

  • Найти носителя информации.

  • Выяснить все подробности.

  • Кратенько записать.

  • Попросить его проверить.

Тут вы можете сказать:

Эй, але! Я тестировщик! Поставлю задачу аналитику и пусть он делает.

Ну-ну. Вы думаете, если до вас процветало разгильдяйство, то сейчас все резко изменится? Что нужно было просто задачку на аналитика поставить? Если документации до сих пор нет значит, всех всё устраивает.

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

2. Пользовательская документация

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

Чем отличается от ТЗ? Тем, что в ТЗ вы можете использовать сленг, сокращения, не писать какую-то очевидную для коллег информацию. А вот пользователь ваших сокращений не знает, ему пишите понятнее.

У нас, например, в вики-системе есть разделы по проекту:

  • Внутренний пользователи его не видят. Там все потроха, а еще описание реализации и тестов.

  • Внешний общий доступен всем пользователям. Тут лежат инструкции по разворачиванию системы (для администраторов) и по работе в ней (для пользователей), описание API-методов, примеры их вызовов Это всё пользовательская документация.

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

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

  • Требования требования для реализации.

  • Пользовательская документация информация о работе системы.

Ограничивается ли документация этими пунктами? Разумеется, нет! Поэтому я и написала эту статью, чтобы вы не забыли про остальные пункты ))

3. Примеры

Всегда проверяйте примеры. Просто ВСЕГДА!

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

Другой вопрос а что относится к примерам? Что проверять то нужно? Давайте разбираться!

Файл-образец

Возьмем для примера Дадату. Туда можно грузить файлики, и система причешет данные внутри. Как вы будете проверять, подойдет ли вам Дадата?

  1. Возьмете свой файлик и попробуете сразу на нем.

  2. Возьмете пример из системы.

Первый вариант возможен, да. Но часто ли у вас под рукой нужный файл? Это надо еще пойти в систему, сделать выгрузку... А зачем напрягаться, если вас Дадата не устраивает исходно? Конечно, сначала проще взять образец и посмотреть на нем, что умеет система.

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

  • Скачивается (вдруг ссылка побилась??)

  • Обрабатывается без ошибок, выдаёт правильный результат.

Предзаполненные поля в форме ввода

Что, если у нас просто форма ввода? И туда можно добавить пример! Вот как в Дадате сделано:

Все поля заполнены по умолчанию. Можно просто ткнуть на кнопку Проверить и посмотреть результат. А потом уже обрабатывать свои данные. И поверьте, большинство просто ткнет в кнопку для начала, просто потому, что так проще.

Примеры вызова API-методов

Что может быть приятнее, чем скопировать пример и отлаживаться на нем? То есть сначала послали запрос, который 100% работает, а потом уже варьируем под свои данные.

Это очень важно для интеграции. Вы ведь пытаетесь соединить свою систему с чужой. Чужую вы почти не знаете, как она работает? Спасает только наличие ТЗ.

Но что, если требований тааааак много и они довольно сложные, а интегрировать уже пора начинать? Сначала стоит выполнить простейший сценарий. А где его взять? Конечно, из примера! Выполняем пример вручную. Работает? Тогда пишем вызов уже из кода. Написали? Теперь уже сидим и вчитываемся подробнее, разбирая всякие альтернативные сценарии.

Именно поэтому примеры очень важны. С них начинают работу с системой.

Другие примеры

Примеры могут быть в любой документации лендинг-страница, пригласительное письмо, документация на работу системы... Посмотрите, сколько пунктов в этой статье, и в любом из них могут скрываться примеры!

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

Итого по примерам

Примеры очень важны. С них начинают работу с системой.

  • Если у вас их нет просите добавить.

  • Если они есть тестируйте их!

Если вы делаете внешнее API для заказчика или вообще публичное, опишите его и добавьте примеров. Именно с них пользователь начнет знакомство с методом.

Но и в простом интерфейсе есть место для примеров. Можно облегчить пользователям жизнь, подготовив файл-образец или предзаполнив форму ввода. И они обязательно этими примерами воспользуются. Поэтому примеры мы ОБЯЗАТЕЛЬНО тестируем. Всегда. Это лицо нашего приложения, оно должно работать.

4. Письма от системы

О, это тоже очень важный пункт! Сейчас многие системы присылают приветствия, напоминания, уведомления... Так вот эти письма это тоже документация, причем очень важная ее часть!

Типичные проблемы писем плейсхолдеры, которые:

  • не разименовались;

  • разименовались, но неправильно.

Что такое плейсхолдер? Это заглушка, которая меняется на нужное значение при отправке письма. Разработчик же не знает заранее, как вас зовут. Но допустим, что он хочет сделать именное письмо:

Привет, Ольга! Спасибо за регистрацию на нашем сайте...

Привет, Андрей! Спасибо за регистрацию на нашем сайте...

Привет, Сладкий пупсик! Спасибо за регистрацию на нашем сайте...

Разработчик пишет письмо, оставляя плейсхолдер вместо имени:

Привет, $username! Спасибо за регистрацию на нашем сайте...

И говорит в коде: Вместо $username подставь имя, которое пользователь ввел при регистрации. Возьми значение из такого-то поля. Теперь, когда Маша-Ваня-Петя регистрируются на сайте, они получают личное письмо со своим именем!

Обычно такие подмены делают на имена и даты. Например, дата, на которую куплен билет. Главное подставить нужное значение! А с эти бывает беда...

В апреле 2017 года я летела в Екатеринбург, на конференцию DUMP[1]. Купила билеты в S7 Airlines заранее в феврале. Перепроверила даты, вроде все правильно, вылетаю 13.04.

Упорный бот пытался впарить мне отель через их сайт и отказ не принял. А 02.02.2017 он прислал мне напоминалку, что у меня скоро полет... И поставил дату... Сегодня о_О

Когда-когда мой полет?? Эй, он же в апреле!Когда-когда мой полет?? Эй, он же в апреле!

Эй, але, я покупала билеты на апрель! Холодный мороз по коже а вдруг я ошиблась? Нашла письмо с билетами, нет, все хорошо:

Вот же, 13.04!

Значит, просто накосячили в письме. Благо понятно как, раз дата сегодняшняя то вместо моего реального времени полета вставили SYSDATE. Или там и должно быть sysdate, но письмо должно было быть отправлено в апреле...

Проблемы бывают самые разные:

Иногда письмо приходит с опозданием и получается оплатите счет до вчера.

Иногда тебе пишут Привет, username!. Забыли подставить значение =))

Иногда неправильно склоняют имя

Иногда неправильно определяют пол

...

То есть в первую очередь мы проверяем в письмах все переменные и плейсхолдеры правильно ли они подставились? Если это строка с именем, проверяем такие моменты:

  • А если я пустым оставлю поле?

  • А если на другом языке напишу?

  • А если спецсимволы введу?

  • А если очень длинное имя?

Аналогично с датой:

  • Когда придет письмо сразу после регистрации, за день до назначенного времени?

  • Правильная ли дата будет в письме?

Ну и, конечно, надо хотя бы разок вычитать все письма на орфографические ошибки!

5. Сообщения об ошибках

Да да, это тоже документация! Поэтому их надо все найти и проверить. Зачем? Давайте я расскажу вам про Pretty roses (взят из интернета, исходного автора давно утеряли):

PASSWORD EXPIRED

"Sorry, your password has been in use for 30 days and has expired You must register a new one."

roses

"Sorry, too few characters."

pretty roses

"Sorry, you must use at least one numerical character."

1 pretty rose

"Sorry, you cannot use blank spaces."

1prettyrose

"Sorry, you must use at least 10 different characters."

1fuckingprettyrose

"Sorry, you must use at least one upper case character."

1FUCKINGprettyrose

"Sorry, you cannot use more than one upper case character consecutively."

1FuckingPrettyRose

"Sorry, you must use no fewer than 20 total characters."

1FuckingPrettyRoseShovedUpYourAssIfYouDon'tGiveMeAccessRightFuckingNow!

"Sorry, you cannot use punctuation."

1FuckingPrettyRoseShovedUpYourAssIfYouDontGiveMeAccessRightFuckingNow

"Sorry, that password is already in use. "

Пользователи всегда ошибаются. Неумышленно делают что-то не так. Они могут вставить вместо имени копипасту огромного текста из буфера обмена, вместо картинки загрузить txt, промахнувшись при выборе файла... Они могут сломать что-то просто потому, что не знают, как система работает...

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

  1. При вводе символа ругаться Ты что, дурак? Тут только цифры!

  2. При вводе символа ругаться В поле можно вводить только цифры

  3. Не давать возможность ввести символы обрезать их при копипасте и игнорировать при вводе с клавиатуры.

Разумеется, идеальным будет третий вариант. А второй мы оставим на случай, если пользователь обойдет наше ограничение.

Ведь не дать ввести символы это ограничение, установленное на клиенте. При знании нужных инструментов его легко обойти (начните с Web developer toolbar, вкладка Forms). Поэтому нужно оставить защиту на сервере если пользователь символы таки ввел, выведем ошибку.

См также:

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

Общая мысль:

Если негативный сценарий можно избежать, сделайте это.

Если избежать его нельзя, тогда уже делайте сообщение об ошибке.

Ну а подробнее про то, как будет лучше пользователю, смотрите в литературе по usability. Вот мой список книг, см раздел Usability-тестирование.

Как искать сообщения

В систему можно загружать файл? Тогда пробуем грузить пустой файл, неправильного формата, расширения, разрешения...

В форме редактирования есть обязательные поля? Пробуем их не заполнять или заполнять неправильно...

Система передает ответы через SOAP/JSON? А если отправить неправильный запрос, пустой, с неполными или некорректными данными?

И так далее, и тому подобное.

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

Каким должно быть сообщение об ошибке

Каким должно быть сообщение об ошибке?

Коротким, иначе пользователь заснет, читая его.

Понятным, иначе как понять, что я сделала не так?

Из сообщения должно быть понятно:

В чем моя ошибка?

Что мне сделать, чтобы исправить ее?

При этом сообщение должно быть в мире пользователя. Мне будут одинаково непонятны тексты:

Извините, что-то сломалось.

Error 38759245, see line 333 in code

Неправильно введены данные.

Особенно на форме из 100 полей. Какие именно данные я ввела неверно? И даже если их подсветили красным, а что неверно то? Как верно будет? Вы мне скажите, что делать то надо.

А еще можно сделать сообщение интересным и смешным! Как? Вот, посмотрите, какая прелесть:

Примеры сообщений об ошибках

Dadata

В Дадату можно загружать файлы формата Excel или CSV. Система заранее предупреждает о том, какой должен быть файл:

Если попробовать грузануть туда JPEG, система понятно объясняет, что надо сделать:

Сообщение об ошибке в Дадате понятноСообщение об ошибке в Дадате понятно

Это пример как хорошо, а дальше разберем, как плохо =)

Wildberries, галерея стиля, загрузка фото

Один раз я попробовала загрузить фото в Галерее стиля (туда пользователи выкладывают фоточки в вещах из магазина) и невольно потестировала документацию сайта...

Итак, заходим в личный кабинет, оттуда в Мои образы. Читаем информацию, но увы, ни слова о том, какие файлы допустимы:

Читаем условия по загрузке фотоЧитаем условия по загрузке фото

Вроде никаких ограничений нет...

Итак, возрадовались возможности создать образ, грузим фоточку.

Выбираем фото для образа...Выбираем фото для образа...

Ага, вот и первое ограничение! Файлы должны быть размером поменьше...

Но ведь так айпад снимает... Ладно, берем стандартные виндовые ножницы, обрезаем фото и сохраняем как JPEG, чтобы уж наверняка мало весить стал. Грузим снова:

Не хочешь 2 Мб, на тебе 100 КбНе хочешь 2 Мб, на тебе 100 Кб

И что бы вы думали, мне говорят?

Что значит поддерживается только jpg? А я что гружу?

Я ведь jpg и гружу, але!Я ведь jpg и гружу, але!

Я гружу JPEG, а мне говорят, что формат неверный, грузи JPEG? о_О

Ладно-ладно! Снова открываю фоточку, снова вырезаю ножницами и сохраняю как PNG, на рисунке чуть выше мы его видим, он в 6 раз побольше весит, качество получше, все дела... Но ситуация повторяется...

Ох ох ох, у меня так было на первых попытках загрузки фоток, пошли старым дедовским методом вставить картинку в Paint, уменьшить масштаб и сохранить как jpg. И вуаля, блин! Загрузилось!

Я, как пользователь, посылаю разработчикам лучи ненав добра и нежности в такие минуты.

Знаете, в чем оказалась проблема? В регистрозависимости расширения файла:

  • jpg грузится;

  • JPG нет.

Виндовые ножницы сохраняли расширение заглавными буквами, а система не могла его обработать.

Как это исправлять? Можно, конечно, разжевать пользователю, что jpg могу, JPG не могу, но... Зачем? Лучше сделать функцию проверки формата регистронезаивисимой. Помните о том, что лучше предотвратить ошибку, чем красиво ее расписать?

Далее, если загрузить слишком маленькую картинку, то получим ошибку:

Файл должен быть не менее 500 пикселей в ширину и 700 в высоту.

Откуда пользователю узнать про этом ограничение? Нужно предупредить! Можно завести такое улучшение:

**********************************************************************

Подсказывать правильный формат и размер файлов для загрузки в ГС

Указать ограничения еще до того, как пользователь начнет грузить файлы. В раздел Мои образы https://lk.wildberries.ru/mylooks добавить надпись:

Принимаются фото:

jpg, jpeg, gif, png, bmp до 2Мб

не менее 500 пикселей в ширину и 700 в высоту

**********************************************************************

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

Какие пиксели? Что надо делать, чтобы сделать их больше или меньше?

Имхо, лучше грузить фото покрупнее, до 3-4 Мб и ужимать их на программном уровне, чтобы не хранить тяжесть в базе. В галерее все равно небольшая фоточка отображается, поэтому обидно врядли будет, если делать как радикал, который сам уменьшает фото до 800 px.

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

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

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

Wildberries, форум, загрузка фото

Попробовала добавить аватарку на форуме. Иду в Мой кабинет на форуме, далее Изменить фотографию, выбираю фото и...

БЛИН, ДА В ЧТО, ИЗДЕВАЕТЕСЬ, ЧТОЛИ?!!!

Вот что я должна понять из этого сообщения? Почему неудачно? Я что-то сделала не так? Система сломалась? Совсем или мне попробовать через 5 минут?

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

Wildberries, галерея стиля, комментарии

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

Почему черт знает? Потому что текст сообщения непонятный:

Поле содержит ссылку или некорректное выражение

Вроде все ясно, да? Ну нефиг ссылки лепить, всего и делов... Но под огонь попадают нормальные слова или фразы. Например, слово ребенок:

А теперь представьте, что вы написали большой комментарий в духе Ой, какой красивый ребенок! А как хорошо на нем курточка сидит, прямо вау, самой такую захотелось взять....

Пытаетесь отправить и получаете комментарий Поле содержит некорректное выражение. Эм, и как его найти с такими вводными? Только разве что бисекционным делением.

В общем, когда пишете сообщение об ошибке, думайте о пользователе. Что я из него пойму? Смогу ли исправить ошибку? Пойму вообще, что я сделала не так? Если да то всё круто! Если нет сделайте так, чтобы поняла.

6. Поп-ап сообщения

Pop-up это всплывающее окошко, как навязчивое а вы уже лайкнули нас в фейсбуке?.

В веб приложениях это обычно:

  • уведомление о регистрации;

  • акционное предложение;

  • мини-версия корзины с покупками;

  • ...

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

В мобильных игрушках:

  • реклама новой игрушки;

  • временная акция;

  • поздравляшка с успешным окончанием уровня;

  • не-поздравляшка ты провалил уровень;

  • ...

Что тут стоит проверить? Влезает ли текст в отведенное ему место =))

Пример бага в веб-приложении мы находили в рамках The FedEx Tour: если ввести слишком длинный емейл при регистрации, получим такую картину:

А вот и пример поп-апа в игрушке из серии три в ряд. Если не успел освободить ежа за N ходов, выпадает такое сообщение:

Это на mini ipad было дело. Так что учтите, не только акции во всплывашках! И тестировать такое надо на самых мелких экранах, а потом на средних. А то, может, для телефонов изображение уменьшили, а для айпадов оставили одно, что для макси, что для мини, большой же экран, влезет!

Или вот ещё пример из той же игрушки. Прочтете текст снизу: когда закончится акция?))

7. Предупреждения что вводить

Это когда около поля заранее пишут требования к нему:

Логин должен содержать латинские символы и цифры.

Пароль должен быть длиннее 8 символов и содержать как символы, так и цифры.

...

Чтобы не допустить сообщение об ошибке, предупреждаем о правилах заранее! А требования те же самые, что и у сообщений об ошибках, предупреждения должны быть:

понятные;

в мире пользователя;

выполнимые.

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

Про выполнимость расскажу такую историю:

Изменение пароля, банк

На одном проекте я работала с банком. Чтобы посмотреть логи сервера, нужен удаленный доступ к виртуальной машине.

И вот меня зарегистрировали в закрытом портале банка их админы, прислали мне ссылку и первичный пароль. После первой авторизации пароль нужно изменить. Страница изменения выглядит вот так:

Вроде все верно, тут говорят сразу, что пароль должен соответствовать политике безопасности. Я не против, но это вся страница. Никакой ссылки на политику безопасности... И где же мне ее взять?

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

Я же подбирала пароль наугад, а что делать...

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

А если к вашему приложению будет доступ у третьих лиц, то ссылки на внутреннюю документацию стоит убрать. Напишите лучше около поля, каким должен быть пароль. Это не займет места больше, чем эта унылая цитата =))

8. Инструкция по установке

Пользовательское приложение

Если это простое или общедоступное ПО его будут устанавливать сами пользователи.

В идеале, конечно, инструкции нет, вместо нее просто .exe файл (если речь про Windows). Помните, как последний раз что-то устанавливали? Скачал, запустил, 10 раз кликнул далее-далее-далее, профит!

Но что, если вы решили установить то же приложение на Linux? Ну ладно, ладно, там тоже бывает просто, запустил команду скачивания, и вот у тебя уже всё есть.

Но что, если недостаточно просто запустить установочный файлик? Что, если нужно прописать какую-то переменную в Path, например? Тогда комбинируем файл быстрой установки + краткая инструкция.

Например, установка maven. Скачиваем, читаем инструкцию по установке. Она мега-простая, но она есть. Для винды:

1. Check environment variable value e.g.

echo %JAVA_HOME%

C:\Program Files\Java\jdk1.7.0_51

2. Adding to PATH: Add the unpacked distributions bin directory to your user PATH environment variable by opening up the system properties (WinKey + Pause), selecting the Advanced tab, and the Environment Variables button, then adding or selecting the PATH variable in the user variables with the value C:\Program Files\apache-maven-3.6.0\bin. The same dialog can be used to set JAVA_HOME to the location of your JDK, e.g. C:\Program Files\Java\jdk1.7.0_51

3. Open a new command prompt (Winkey + R then type cmd) and run mvn -v to verify the installation.

Переведем:

1. Проверьте текущую переменную окружения, есть ли у вас Java на компьютере?

echo %JAVA_HOME% команда проверки

C:\Program Files\Java\jdk1.7.0_51 результат команды, он говорит, что Java установлена, так как существует переменная %JAVA_HOME%

2. Добавьте maven в PATH: добавьте ссылку на директорию bin в пользовательскую переменную PATH. Для этого откройте системные настройки (WinKey + Pause), выберите вкладку Advanced, нажмите кнопку Environment Variables и добавьте переменную PATH, или выберите ее, если она уже существует. Добавить туда надо значение пути до директории bin, например: C:\Program Files\apache-maven-3.6.0\bin. Аналогично можно и JAVA_HOME добавить, прописав путь до JDK, например C:\Program Files\Java\jdk1.7.0_51

3. Откройте НОВУЮ командную строку (Winkey + R, а потом написать cmd) и выполните команду mvn -v, чтобы проверить установку.

Фактически для установки нужно выполнить ОДНО действие добавить ссылку на директорию bin в PATH. Еще два пункта для проверки того, что все установилось. Maven обращается к JAVA_HOME, поэтому такая переменная должна существовать, что мы и проверяем. И саму установку maven тоже проверяем командой mvn -v.

Это оптимальная инструкция, ничего лишнего. Или приложение устанавливается само, или к нему есть короткая инструкция на действия, которые надо сделать именно вам.

Серверное приложение

Это полноценное приложение, которое Заказчик сам устанавливает на свои сервера. Например, система работы с клиентами в банке. Она требует конкретных ресурсов и настроек системы, просто далее-далее-далее тут не обойтись.

В этом случае нужно обеспечить полноценную инструкцию по установке, считая, что:

  1. Сервер создан с нуля, там НИЧЕГО нет.

  2. А вот Касперский наверняка есть, и он может обрубать вашу работу. Да, и на линукс некоторые умудряются его вкорячить.

  3. Разворачивать сервера будут админы, которые с компьютером на вы.

Учитывая третий пункт, пишем максимально подробно, максимально понятно. Если просим выполнить команду даем саму команду, чтобы вставил в командную строку и все. Если сервер можно поднимать как на винде, так и на линуксе, дублируем инструкции одна для Windows, другая для Linux. И везде даем примеры команд.

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

В идеале, конечно, ставим на голом сервере докер и не паримся с операционными системами и настройками. Выдали готовый докер-файл, готово!

Но бывает и так, когда докер ставить нельзя. Служба безопасности не одобряет: Мало ли, что вы в этом докере на сервер установите? Нет-нет, давайте инструкцию по развертыванию с нуля, мы сами всё настроим.

Тогда инструкция будет сильно больше! Что может в нее входить:

Подготовка к развертыванию

  • Методика расчета требований к аппаратному обеспечению будьте уверены, вас обязательно спросят, откуда такие требования к железу. Проще один раз записать, чем каждый раз снова объяснять.

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

  • Требования к настройке программно-аппаратной платформы об этом чуть ниже

Требования к настройке какие программы установить, какие права доступа выдать. Соберите всю информацию в одном месте:

  • Настройка рабочей станция для ваших сотрудников

  • Настройка сервера приложений для ОС *nix

  • Настройка сервера приложений для ОС Windows

  • Настройка сервера СУБД Oracle

  • Настройка сервера СУБД MariaDB

  • Настройка Active Directory

  • ...

Видите? Windows отдельно, Linux отдельно. Если умеете работать с разными базами данных напишите под каждую отдельную статью.

Инсталляционный пакет

Описание файлов, которые подрядчик передает заказчику, с их описанием.

Установка системного и специального ПО

Например, продукт написан на Java, а сервер приложения Wildfly. Тогда здесь будут примерно такие разделы:

  • Установка параметров ОС Windows

  • Создание пользователей ОС Linux

  • Установка параметров ОС Linux

  • Установка Java

  • Установка Wildfly

Каждая статья подробно расписывает, как выполнить установку. И не забывайте о примерах!

Установка системы

Инструкция по установке системы.

Запуск системы

Короткая инструкция, в которой прописаны команды для запуска и остановки системы.

Что-то ещё

Может быть ещё целая куча документации:

о том, как настраивать систему ПОСЛЕ установки;

о дополнительных настройках типа шифрования паролей, горячего резерва, и прочего.

Главное, о чем следует помнить если по вашей инструкции будет проходить другой человек, она должна быть максимально простой и понятной. Желательно с примерами, прям копируй и вставляй.

9. Описание полей

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

Вот, например, регистрация в Дадате:

Зачем указывать имя? Чтобы к вам обращались в письмах по нему.

Зачем указывать почту? Чтобы мы могли прислать состояние обработки и баланс.

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

10. Маркетинговые материалы

Рассылки, которые вы шлете пользователям.

Статьи на Хабре или другом ресурсе.

Это тоже документация, которая имеет прямое отношение к вашей системе. И будет неплохо ее хотя бы изучить. А в идеале участвовать в процессе создания. Потому что лучший материал пишут специалисты по системе, а не по маркетингу или копирайтингу. Работайте с вашими авторами, тестируйте их статьи!

Еще один вариант рекламы какой-нибудь купон, который вылезает на сайте или в мобильном приложении.

  • Вычитываем текст, чтобы не было ошибок.

  • Если это поп-ап окно, проверяем, что его можно закрыть.

  • Если это всплывашка в мобилке, проверяем, не вылезает ли она за экран на небольшом смартфоне.

11. Обучение FAQ, презентации

Обучающие материалы это тоже документация. И снова они бывают самых разных видов, зависит от типа продукта и бюджета.

Tutorial

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

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

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

FAQ

Одна или несколько статей, где собраны ответы на типовые вопросы.

F1

Документация из серии Помощь.

Online help

Если у вас есть робот-помощник с зашитыми в него скриптами это тоже документация!

Обучающие статьи

Они могут быть в закрытом или открытом доступе. Это то, где вы рассказываете, как сделать ту или иную вещь с помощью вашей программы.

Если статья открытая, то туда может вести ссылка прямо с сайта.

Если статья закрытая, вы даете к ней доступ только своим клиентам. Она может быть в вашей вики-системе, ворд-файле или гуглодоке.

Видео

Если у вас есть видео в помощь их тоже надо тестировать на устаревание!

Это может быть полноценное видео или кликабельные слайды, такие можно сделать в Wink.

Презентация

Это может быть:

продающая презентация что умеет наш продукт;

обучающая презентация как им пользоваться.

И этотоже документация, которую надо тестировать:

  • Выдержан ли стиль компании в презентации?

  • Актуальны ли картинки? Не менялся ли интерфейс?

  • Насколько полно раскрыта тема? Может, стоит что-то добавить?

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

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

12. Поздравляшки

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

Так вот, когда вы заканчиваете уровень или всю игру, вылезает поздравляшка. Обычно этот всплывающее окно с текстом Поздравляем!. Еще чаще текст будет английским Congratulations!.

Английская версия длиннее, отсюда могут возникнуть проблемы разряа сообщение вылезло за экран телефона. Конечно, сейчас уже нет тех экранчиков, на которых тестировала я (старый siemens, например, с диагональю 3 дюйма). Но и среди смартфонов встречаются малыши, их стоит проверить!

И даже если разработчик дает вам чит-коды, чтобы пропускать уровень, обязательно проверяйте, как отображатся такие поздравляшки. Особенно здорово, если можно попасть сразу на конец игры и посмотреть, а что там будет.

13. Кнопки

Текст на кнопках тоже документация! Вроде очевидно, но все же. Я, например, сталкивалась и с таким:

Как можно пропустить такой баг? Ведь регистрация в интернет-магазине основной кейс, потому что без нее пользователь не может продолжить покупки. Значит, ее тестируют. Видимо, у всех так замылился глаз уже, что подписи на кнопках просто не читают... А вы читайте! =)

Раз уж столкнулась с такой проблемой, то вот, решила вынести ее в отдельный пункт. Не забывайте всё читать, не по диагонали, а целиком.

14. Остальное

Документации очень много. Это все, что видит пользователь и что может показаться неочевидным:

Гарантийный талон это тоже документация (которую редко читают, но всё же). Он обычно встречается у бытовой техники или компьютера.

Пользовательское соглашение / оферта а это то, что заменяет нам договор или гарантийный талон в современном ИТ-мире. Пользуясь онлайн-сервисом, вы автоматически соглашаетесь с офертой, которая есть у него на сайте, даже если вы ее не читали ))

Упаковочный текст и графика помните, раньше игры покупали на DVD в специальных магазинах? Так вот обертка диска, текст и графика на нем это тоже документация, которую надо проверять!

А то вдруг у вас слишком завышенные требования к железу и никто не купит диск?

Или вдруг требования занижены и игра просто не запустится на слабом компьютере? Тогда рассерженный пользователь вернется в магазин и будет требовать назад свои деньги.

Итого

Видов документации очень много! Она не ограничивается только лишь требованиями )) Не забывайте про остальную документацию на проекте. И обращайтесь к этому чек-листу за поиском вдохновения что я ещё забыл проверить =)

Самые важные виды документации:

  • ТЗ требования

  • Пользовательская документация

  • Примеры

  • Сообщения об ошибках

Чуть менее, но все еще важно:

  • Предупреждения о том, как заполнять поле

  • Описание поля (зачем мне его заполнять?)

  • Предзаполненный текст в поле ввода

  • Инструкция по установке

  • Маркетинговые материалы

  • Статьи на Хабре или где-то еще

  • Обучение материалы

  • FAQ

  • Online help

  • Презентации

А еще есть:

  • Пользовательское соглашение / оферта

  • Гарантия

  • Упаковочный текст и графика

Это тоже нужно проверять, но уже не в приоритете!

PS больше полезных статей ищите в моем блоге по метке полезное. А полезные видео на моем youtube-канале

Подробнее..

Перевод Как тестировали в 2020 технологии QA, общемировая статистика и тренды

19.03.2021 16:09:40 | Автор: admin

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

Кому будет полезно: QA-лидам, тест-дизайнерам, тест-менеджерам, другим неравнодушным.

Тенденции инструментов тестирования

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

  • Согласно отчету PractiTest, 47% опрошенных тестировщиков используют инструменты для тестирования или обеспечения качества, такие как HP ALM, Team Foundation Server, PractiTest или Xray.

  • Согласно отчету JetBrains, 44% разработчиков регулярно используют баг-трекинговые инструменты, а 10% используют инструменты для проверки кода, такие как Collaborator, Review Assistant или CodeScene.

  • Самым распространенным баг-трекером остается Jira (68%). На втором месте GitHub Issues (26%).

В исследовании Russia Quality Report от Performance Lab за 2020 год говорится, что Jira в качестве TMS используют 73% российских компаний, 29% применяют Excel. Свои разработки в этой сфере применяют 13% опрошенных.

Что касается инструментов автоматизации, в совместно подготовленном исследовании QATestLab и Test IT говорится о том, что наиболее популярными для веб-тестирования являются Selenium и Apache JMeter, для API Postman.

К слову, у Test IT есть своя одноименная разработка система управления тестированием, в которой удобно вести документацию, а также создавать, запускать и анализировать ручные и автотесты. Ребята активно завоевывают российский и зарубежный рынок.

Тенденции методик тестирования

Быстрота выпуска продукта на рынок остается приоритетным критерием для оценки тестирования и одной из главных целей QA. Без методологии тестирование похоже на бесцельное блуждание в направлении релиза вы думаете, что куда-то идете, но не можете ни к чему приблизиться, потому что не можете отслеживать прогресс. Обратите внимание на нижеперечисленные тенденции методик тестирования ПО, чтобы выбрать подходящую.

  • Самая распространенная модель тестирования разработки программного обеспечения Agile или нечто похожее на Agile: 87% компаний использовали этот подход в 2019 году. Следующим шагом был DevOps с показателем 36% по сравнению с 28% в 2018 году (по данным PractiTest).

  • 82% компаний используют исследовательское тестирование в качестве методологии тестирования программного обеспечения, а 61% используют обычную проверку на основе сценариев (по данным PractiTest).

  • 78% организаций используют автоматизацию тестирования для функционального и регрессионного тестирования. Только 11% компаний не автоматизируют тесты (по данным PractiTest).

Рост популярности Agile в России, впрочем, не означает, что отечественные компании перестали сталкиваться с проблемами при внедрении в практику гибких методологий разработки. Согласно исследованию Russia Quality Report, чаще всего опрошенные указывали на невозможность применения автоматизации тестирования в необходимом объеме. Еще 17% респондентов отметили недостаточное понимание подходов Agile к тестированию.

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

Тенденции разработки ПО

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

  • Наиболее востребованным языком программирования на сегодняшний день является Rust (83,5%), за ним следует Python (73,1%). Разработчики больше всего не любили VBA (75,2%), а Python хочет изучить 25,7% опрошенных программистов (StackOverflow).

  • 25% сотрудников мировой IT-индустрии считают, что самая большая проблема, стоящая перед стартапами, приоритизировать разработку ПО (CodingSans).

  • Безопасность горячая тема: 69% респондентов отметили, что разработчики должны уметь писать безопасный код, но 68% считают, что добрая половина разработчиков не может самостоятельно обнаружить уязвимые части кода, которые обнаруживаются позже (GitHub).

Тенденции тестирования ПО

Известно, что процесс обеспечения качества включает в себя все от стратегического планирования и общения с разработчиками до документирования ошибок и других проблем; тем не менее главная часть QA это непосредственно тестирование.

Если вы являетесь руководителем QA-отдела или тестировщиком, вы хорошо представляете, из чего состоит рабочий день вашей команды. Сравните приведенные ниже тенденции тестирования с вашим опытом?

  • Тестировщики часто выполняют работу за рамками своей роли в компании. 74% тестировщиков также пишут сценарии и делают автоматизацию, 57% также выполняют тесты управления данными (PractiTest).

  • В 35% компаний тестирование может проводить кто угодно, кроме тестировщиков, но 55% компаний все же используют профессиональных тестировщиков для подавляющего большинства тестов (PractiTest).

  • Web по-прежнему является самой популярной платформой для тестирования, 77% тестировщиков работали над web-тестированием в 2019 году. Это меньше, чем 79% в 2018 году (PractiTest).

Также важной частью QA-процесса является нагрузочное тестирование.

Тенденции QA-команд

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

  • Сложности: 44% тестирующих команд назвали сложным или невозможным участие в проектах своей компании в начале процесса, в то время как 43% командам трудно работать с данными и тестовыми средами (PractiTest).

  • Состав: 48% QA-команд состояли из 1-5 сотрудников, а 24% имели от 6 до 15 тестировщиков в 2019 году (PractiTest).

  • Задачи: по статистике, 63% задач команд по тестированию связаны с анализом требований, 55% задач связаны с ретроспективными встречами по проектам.

Карьерные тенденции в QA

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

  • Только 18% тестировщиков планировали стать тестировщиками ПО и изучали процессы. 24% стали тестировщиками случайно (PractiTest).

  • 65% получили знания о тестировании ПО в процессе самого тестирования. 58% читали книги по тестированию, а 44% закончили курсы и получили профильные сертификаты (PractiTest).

  • 75% отметили важность коммуникативных навыков, 63% назвали необходимым умение писать тестовые сценарии и умение автоматизировать тесты (PractiTest).

Тенденции дефектов ПО

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

  • Баг-репорты являются наиболее распространенной тестовой документацией, используемой компаниями 79% пользователей отмечают их использование (PractiTest).

  • 76% тестировщиков использовали баг-трекеры, такие как Jira Bugzilla или Redmine, что делает их наиболее распространенным инструментом управления тестированием. Следующим по популярности инструментом был Agile Workflow tools (59%) (PractiTest).

  • Наиболее распространенной ошибкой на проде было выкатывание непроверенного или сломанного кода более чем на 60%. Второй наиболее распространенной ошибкой была удаленная база данных (HackerRank).

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

Другие тенденции QA

Границы между тем, где заканчивается разработка и начинается тестирование, зачастую размыты. Если вы достигли в своих поисках того плана по обеспечению качества программного продукта, считайте, вам очень повезло. Сравните общемировые тенденции QA с процессами в вашей компании.

  • В 2019 году 36% тестировщиков были подотчетны PM, по сравнению с 43% в 2018. 34% тестировщиков отчитывались перед руководителем отдела разработки (PractiTest).

  • 73% разработчиков заявили. что научились программированию самостоятельно, чуть меньшее количество училось разработке на курсах или в университете (69%) (HackerRank).

  • На 100 тыс. человек приходится 5,2 тестировщиков. В Ирландии самый высокий процент тестировщиков на душу населения 61,2 на 100 тыс. человек. Далее следуют США и Канада, затем в списке Израиль (QualiTest Group).

Согласно исследованию Russia Quality Report, в России большинство работодателей не считает, что профильное образование в сфере IT или дополнительные сертификаты так уж необходимы тестировщику. Значение придается наличию у соискателя опыта работы (в среднем - 1-3 года) и таким личным качествам, как внимательность, ответственность и дотошность.

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

Помните, баги всегда прячутся в самых неожиданных местах. Удачи!

Перевод статьи

Автор: Nuala Turner

Также при подготовке использовался источник RQR2020 и исследование QATestLab и Test IT

Подробнее..

Перевод Паттерны и Методологии Автоматизации UI Примеры из жизни

01.04.2021 16:06:37 | Автор: admin

Полезные паттерны для автоматизации тестирования UI

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

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

Паттерн Декоратор (Decorator)

Мой фреймворк должен поддерживать различные варианты компонентов веб-сайта. Это необходимо, потому что наше веб-приложение постоянно меняется, и A/B-тесты выполняются на уровне компонентов.

Если у вас есть подобное требование, паттерн Декоратор может вам подойти! Он позволяет упаковать компоненты в конверты, которые перезаписывают или дополняют только определенные функции. Вам не нужно писать новый класс для каждой новой характеристики компонента: должны быть реализованы только изменения. Вы также можете использовать этот метод, если веб-компоненты меняются в зависимости от размера браузера или типа устройства.

Пример Декоратора

В этом примере у нас есть два компонента Login. У второго есть дополнительная кнопка отменить.

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

Давайте посмотрим на это с точки зрения декоратора!

LoginComponent - это интерфейс для каждого компонента Login. В нем говорится, что каждый компонент должен иметь определенный метод login.

package decorator;public interface LoginComponent {   void login(String user, String password);}

BasicLoginComponent имеет конкретную реализацию метода login. В этом примере он просто выводит Basic login в командную строку.

package decorator;public class BasicLoginComponent implements LoginComponent {   @Override   public void login(String user, String password) {       System.out.println("Basic login: " + user + ", " + password);   }}

Этот класс является сердцем паттерна. LoginDecorator может брать любой LoginComponent и оборачивать его нужными функциями. После этого результатом остается LoginComponent.

package decorator;public abstract class LoginDecorator implements LoginComponent {   private final LoginComponent loginComponent;   public LoginDecorator(LoginComponent loginComponent) {       this.loginComponent = loginComponent;   }   @Override   public void login(String user, String password) {       loginComponent.login(user, password);   }}

MobileLoginDecorator переопределяет функциональность login новым классом, специфичным для мобильных устройств. Опять же, он просто выводит Mobile login, чтобы этот пример был коротким.

package decorator;public class MobileLoginDecorator extends LoginDecorator {   public MobileLoginDecorator(LoginComponent loginComponent) {       super(loginComponent);   }   @Override   public void login(String user, String password) {       System.out.println("Mobile login: " + user + ", " + password);   }}

CancelButtonDecorator может добавить функцию cancel в любой компонент Login.

package decorator;public class CancelButtonDecorator extends LoginDecorator {   public CancelButtonDecorator(LoginComponent loginComponent) {       super(loginComponent);   }   public void cancel() {       System.out.println("Click the cancel button");   }}

Теперь мы можем проверить, как все это работает!

package decorator;public class Main {   public static void main(String[] args) {   System.out.println("DECORATOR PATTERN");   System.out.println("=================");   // This is the basic login component   LoginComponent loginComponent = new BasicLoginComponent();   loginComponent.login("User", "PW");   // Let's turn it into a mobile login component.   loginComponent = new MobileLoginDecorator(loginComponent);   loginComponent.login("User", "PW");   // Finally, we can add a cancel functionality.   loginComponent = new CancelButtonDecorator(loginComponent);   ((CancelButtonDecorator) loginComponent).cancel();   }}

Результат всего этого:

DECORATOR PATTERN=================Basic login: User, PWMobile login: User, PWClick the cancel button

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

Page Object и Page Component

Одним из первых паттернов, характерных для автоматизации UI, является паттерн Page Object. Это означает, что все функции конкретной страницы заключены в класс. Это хорошо для простых представлений без большого количества возможностей взаимодействия, поскольку объекты страницы ясны и управляемы.

Однако, если страница содержит много функций, классы объектов страницы могут стать огромными и превратиться в сложный и хаотичный код. Здесь и появляется расширение объектов страницы: Page Component. Идея состоит в том, чтобы обернуть функциональность компонента в класс, а не всю страницу.

Пример Page Object

Это очень простой интернет-магазин, который включает поиск и список результатов найденных продуктов. Если вы реализуете это с помощью Page Object, результат может выглядеть примерно так, как этот класс WebshopPage.

package pageobjects;public class WebshopPage {   public void search(final String queryString) {       System.out.println("Enter " + queryString);       System.out.println("Click search button");   }   public void checkResultHeadline() {       System.out.println("Check if the headline is correct.");   }   public void checkResults() {       System.out.println("Check if there are search results.");   }}

Все действия, которые можно выполнить на этой странице, включены сюда. Мы можем проверить это с помощью простого Main класса.

package pageobjects;public class Main {   public static void main(String[] args) {   System.out.println("PAGE OBJECTS");   System.out.println("============");   WebshopPage webshopPage = new WebshopPage();   webshopPage.search("T-Shirt");   webshopPage.checkResultHeadline();   webshopPage.checkResults();   }}

Как и ожидалось, это дает нам следующий результат:

PAGE OBJECTS============Enter T-ShirtClick search buttonCheck if the headline is correct.Check if there are search results.

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

Пример Page Component

Здесь на помощь приходит Page Component. В нашем случае вы можете разделить страницу на два компонента: панель поиска и список результатов.

Класс SearchBar должен содержать только метод поиска.

package pagecomponents;public class SearchBar {   public void search(final String queryString) {       System.out.println("Enter " + queryString);       System.out.println("Click search button");   }}

Методы проверки заголовка результата и самих результатов относятся к ResultList:

package pagecomponents;public class ResultList {   public void checkResultHeadline() {       System.out.println("Check if the headline is correct.");   }   public void checkResults() {       System.out.println("Check if there are search results.");   }}

Есть еще WebshopPage, но в этой версии просто доступны два компонента.

package pagecomponents;public class WebshopPage {   public SearchBar searchBar() {       return new SearchBar();   }   public ResultList resultList() {       return new ResultList();   }}

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

package pagecomponents;public class Main {   public static void main(String[] args) {   System.out.println("PAGE COMPONENTS");   System.out.println("===============");   WebshopPage webshopPage = new WebshopPage();   webshopPage.searchBar().search("T-Shirt");   webshopPage.resultList().checkResultHeadline();   webshopPage.resultList().checkResults();   }}

Результат все тот же:

PAGE COMPONENTS===============Enter T-ShirtClick search buttonCheck if the headline is correct.Check if there are search results.

Это решение требует большего количества классов, но в каждом из них гораздо меньше кода, что облегчает его понимание и поддержку. Это также позволяет улучшить повторное использование каждого компонента в случае, если он появляется более чем на одной странице.

Паттерн Фабрика (Factory)

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

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

Пример Фабрики

Для этого примера мы можем расширить приведенный выше пример и использовать фабрику для создания компонентов.

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

package factory;public class Component {   public void initialize() {       System.out.println("Initializing " + getClass().getName());   }}

Каждый из перечисленных выше компонентов может быть унаследован от этого класса Component:

public class ResultList extends Component {    ...}public class SearchBar extends Component {    ...}

Недостающая часть - это фабричный класс, который отвечает за производство компонентов. Для иллюстрации фабричный класс принимает имя компонента в качестве аргумента, создает экземпляр соответствующего класса, вызывает его метод initialize и возвращает его обратно.

package factory;public class ComponentFactory {   public static Component getComponent(final String componentName) throws Exception {   System.out.println("Creating " + componentName + "...");   // Create a component instance for the passed in component name.   Component component;   switch (componentName){       case "SearchBar":           component = new SearchBar();           break;       case "ResultList":           component = new ResultList();           break;       default:           throw new Exception(componentName + " unknown.");   }   System.out.println("Component created: " + component);   component.initialize();   return component;   }}

Код Main класса не выглядит иначе, потому что WebshopPage по-прежнему отвечает за управление его компонентами.

package factory;public class Main {   public static void main(String[] args) throws Exception {   System.out.println("FACTORY PATTERN");   System.out.println("===============");   WebshopPage webshopPage = new WebshopPage();   webshopPage.searchBar().search("Berlin");   }}

Результат измененного примера:

FACTORY PATTERN===============Creating SearchBar...Component created: factory.SearchBar@3d075dc0Initializing factory.SearchBarEnter BerlinClick search button

Компонент запрашивается, создается и инициализируется должным образом.

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

Внедрение зависимости (Dependency Injection)

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

Как правило, программное обеспечение, использующее внедрение зависимостей, полагается на какую-то специализированную среду, такую как Spring или Guice, которая обрабатывает создание и внедрение объектов. Чтобы прояснить концепцию, в следующем примере фреймворк не используется.

Пример Внедрения зависимости

Здесь мы хотим предоставить функции входа в систему для тестирования UI простого веб-сайта. Однако мы хотим хранить имя пользователя и пароль непосредственно внутри класса, поэтому нам не нужно передавать их всякий раз, когда мы хотим вызвать логин. Кроме того, наше требование состоит в том, что у нас может быть несколько наборов имени пользователя и пароля в зависимости от тест-кейса. Это новое требование не позволяет нам просто включить данные для логина на страницу Login, поскольку она должна оставаться гибкой. Вот почему вводить данные извне - хороший выбор.

Это интерфейс LoginData, который должны реализовывать все наши экземпляры данных для входа. Он просто возвращает имя пользователя и пароль.

package dependencyinjection;public interface LoginData {   String getUserName();   String getPassword();}

Давайте рассмотрим две реализации: одну для реальных, а другую для фейковых данных для логина.

package dependencyinjection;public class LoginDataReal implements LoginData {   @Override   public String getUserName() {       return "Real user";   }   @Override   public String getPassword() {       return "Real password";   }}package dependencyinjection;public class LoginDataFake implements LoginData {   @Override   public String getUserName() {       return "Fake user";   }   @Override   public String getPassword() {       return "Fake password";   }}

Конструктор LoginPage принимает экземпляр класса LoginData и использует его в своем методе login. Таким образом, фактическое имя пользователя и пароль для использования не управляются самой страницей LoginPage, а вместо этого выбираются и вводятся извне.

package dependencyinjection;public class LoginPage {   private final LoginData loginData;   public LoginPage(final LoginData loginData) {       this.loginData = loginData;   }   public void login(){       System.out.println("Logging in with " + loginData.getClass());       System.out.println("- user: " + loginData.getUserName());       System.out.println("- password: " + loginData.getPassword());   }}

Единственная отсутствующая часть - это тестовый класс, который использует оба набора данных для входа.

package dependencyinjection;public class Main {   public static void main(String[] args) {   System.out.println("DEPENDENCY INJECTION");   System.out.println("====================");   LoginPage loginPageReal = new LoginPage(new LoginDataReal());   loginPageReal.login();   LoginPage loginPageFake = new LoginPage(new LoginDataFake());   loginPageFake.login();   }}

Этот класс создает две отдельные страницы входа в систему, которые отличаются только переданными данными входа. Запуск класса выводит следующее:

DEPENDENCY INJECTION====================Logging in with class dependencyinjection.LoginDataRealuser: Real userpassword: Real passwordLogging in with class dependencyinjection.LoginDataFakeuser: Fake userpassword: Fake password

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

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

И наконец: Две Методологии

Мы только что просмотрели много кода. Итак, давайте завершим эту статью чем-то совершенно другим: методологиями!

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

Не усложняй (Keep It Simple)

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

Вам это не понадобится (You Arent Gonna Need It)

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

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

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

Подробнее..

Welcome on board или по ту сторону оффера

05.04.2021 18:06:45 | Автор: admin
Где-то над Балтийским моремГде-то над Балтийским морем

"Войти в АйТи" уже не кажется чем-то за гранью фантастики и привилегией для избранных. Бытует мнение, что тестировщик - легкая профессия. Полтора - два месяца на курсах и Voila! Вы в IT-community. Порог входа низкий, наличие технического образования не обязательно. И любой, от курьера до домохозяйки, может освоить данную профессию. Так ли это?

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

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

Итак, данная статья написана в формате интервью. И будет полезна тем, кто собирается "войти в АйТи" через тестирование. И особенно тем, у кого нет сильного технического бэкграунда.

Погнали ;)

Респондент: Екатерина Бернадцкая, тестировщик из Кремниевой долины, опыт работы в тестировании 4 года. В настоящее время работает в IT компании по разработке приложения для ресторанов. Имеет опыт работы ручным тестировщиком в одной из крупнейших IT компаний России. Технического образования нет. В Штаты попала, выиграв грин карт. Собственно, выигрыш и послужил стимулом переквалифицироваться в тестировщики ПО. Пол года назад начала писать тесты на Python. Считает, что это именно тот случай, когда человек выбрал правильный путь.

- Катя, расскажи о своем первом месте работы. Ты была одним тестером на проекте или работала в команде? Опиши кратко процесс онбординга.

- Катя: Первое место работы - одна из крупнейших IT компаний России. Я попала в распределенную команду сильных профессионалов с четкой структурой, отлаженными процессами. Как такового онбординга с погружением, с тьюторами не было. Мне предложили посмотреть видео о компании и ее продуктах. И тут сразу возникла первая сложность. Люди, которые уже в компании проработали какое-то время (от полугода, к примеру) знают продукт, процессы. Соответственно, у них и не возникает мысли о том, что кому-то может быть трудно и что-то понятно. Я считаю, что это проблема для новичков, особенно, когда входишь в новую профессию. Знаний в этой сфере недостаточно. Профессия сложная, продукт неочевидный. Сложно влиться, понять, чего от тебя хотят и начать полноценно работать. Если бы этот процесс был хорошо организован, то сократился бы уровень стресса и времени, на то, чтобы влиться в коллектив и почувствовать себя полноценным членом команды.

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

- Как проходило взаимодействие с командой?

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

Сейчас, когда я сама бываю очень занята, я тоже не очень охотно отвечаю на вопросы. Иногда злюсь, когда у меня спрашивают что-то очевидное. Но в эти моменты я переношусь на 4 года назад и вспоминаю себя. Беру себя в руки и терпеливо объясняю. Рисую схемы пока не увижу, что человек действительно понял. Ребята все были сильные, хорошие, умные. И просто времени не было что-то мне объяснять. Многие злились, кто-то откровенно показывал свое раздражение. Да, сначала тебя рассматривают, как винтик, который должен работать и не задавать дурацкие вопросы. Но когда я дошла до определенного уровня, стало проще. Люди привыкли ко мне. Мы стали дружить. Ходить, пить кофе. Был забавный парень ведущий программист на проекте. Он всегда после релиза покупал мне кофе. Я буду всегда с теплотой вспоминать, как этот чудесный парень покупал мне кофе. И знал, что я люблю лавандовый (улыбается).

- Как и кто оценивал твою работу?

- Катя: В основном, менеджер QA команды и продакт менеджеры. После окончания испытательного срока был сделан разбор полетов. И мне сказали, что нужно стараться больше. Они видели, что я старалась, но нужно стараться больше. И это было большим ударом по самооценке. И тем не менее я начала стараться больше. Но самое сложное было понять, куда стараться. Потому что старайся больше - слишком абстрактная фраза. И я не понимала, что делаю не так и в какую сторону двигаться. Были странные ощущения. Ты лезешь из кожи вон, не спишь ночами, читаешь, штудируешь какие-то дополнительные материалы, задерживаешься на работе, стараешься брать задачи посложнее, берешь задачи соседней команды, чтобы понять как работает система, а не конкретно твой болтик. И при всем при этом люди говорят: Старайся больше. Это неприятно. Но знаете, что самое удивительное? Когда ты начинаешь работать чуточку больше, чуточку дольше, ты начинаешь понимать, чего от тебя хотели. Ты начинаешь понимать, довольный клиент - самый основной показатель, показывающий, как хорошо ты поработал. Клиент доволен, компания не теряет, а зарабатывает деньги. Значит ты поработал хорошо и получишь свою зарплату (улыбается).

- Как ты распределяла свое рабочее время?

- Катя: Расскажу на примере текущей компании в Штатах. Многие думают, что тут работают какие-то нереальные гики, и все строго. Да еще и работают сутками на пролет. Это не так. Здесь работать гораздо проще. В российской компании время распределялось очень строго. Мы отчитывались за каждую минуту. Писали, сколько времени потратили на какой тикет, весь процесс фиксировался в багтрекере, сколько тикет висел в каком статусе. Если тикет висел в статусе testing слишком долго, нам задавали вопросы, с нами проводились беседы. Рабочий день с 10 до 19. А если ты пришел позже или ушел раньше,в конце недели получал письмо с фамилиями тех, кто позволил себе опоздать на 10 минут.

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

Мне комфортнее работать в Штатах. Я люблю наш продукт, сама являюсь активным пользователем. А с недавнего времени начала работать над автоматизацией. Очень много всего нужно сделать. У меня всегда есть какая-та работа. Или просто я умею найти эту работу (смеется). Сейчас в приоритет ставлю тикеты, один день в неделю на автоматизацию. Никто не стоит над душой, время четко не учитывается, я давно работаю в компании и все знают, что я покажу результат. И если я взялась за это дело, то доведу его до конца.

- С техническими скиллами были сложности? Чему ты научился на первом проекте?

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

А научилась всему (улыбается). Помню, меня очень напугало слово рефакторинг. Я погуглила и не особо поняла, что же они имели ввиду. Пошла спрашивать: Мальчики, что это за тикет? Как его проверить? Они: Да это же рефакторинг. Я про себя думаю: Ага, замечательно. Очень понятно. Хорошо, что муж - разработчик. Он мне и объяснил, что это такое, и что от меня хотят. Так что пришлось учить все, несмотря на то, что я думала, что готова. Миллион курсов прошла перед тем, как искать первую работу, но практику и опыт ничто не заменит.

- От чего пришлось отказаться (взгляды/убеждения)?

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

В Долине были сложности с языком. При этом, уезжая туда, я думала, что все знаю. В России я училась на языковой специальности, путешествовала, меня понимали. А когда пошла на первую работу в Штатах, поняла, что не только я не понимаю, что мне говорят, но и меня не понимают. Первые полгода было очень тяжело. Но американская культура располагает задавать вопросы. Это хорошо. Если ты чего-то не знаешь, ты не дурак, ты человек, который хочет что-то узнать. Пришлось привыкнуть к тому, что задавать вопросы и чего-то не знать, это нормально. И сейчас я придерживаюсь политики, что не нужно начинать тикет, если ты не понял, о чем он. Приходит тикет, ты читаешь. Не понятно. Начинаешь общаться с разработчиком. И общаешься с ним до тех пор, пока не поймешь, о чем тикет. И даже, если человек воет от моих вопросов, меня это мало волнует (смеется). Меня волнует только то, что это нужно проверить. Эта фича должна работать, а чтобы это проверить, я должна знать, как она должна работать.

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

- У тебя есть лайфхаки?

- Катя: Я всегда строю таблицы, диаграммы и матрицы. А еще составляю план. Не тыкаю бездумно. Бездумное тыканье, без плана - это не exploratory testing. На мой взгляд, скорее, неорганизованность и нежелание развиваться. Когда человек говорит, что потратил весь день на исследовательское тестирование, он либо новичок, либо лентяй. Ты должен понимать, что ты делаешь, и к чему хочешь прийти, а не делать что-то в хаотичном порядке.

- Если бы у тебя была возможность дать совет/напутственное слово себе тогда, вначале пути. Что бы ты, имея уже определенный опыт и знания, себе сказала?

- Катя: Как бы не было тяжело, нужно идти вперед. Если есть цель и желание развиваться в тестировании. Если в процессе поймете, что тестирование все-таки не ваше, это тоже нормально. Не всем это нравится. Но, если ваше, то идите. И поймите для себя, зачем это нужно. Если есть понимание зачем, то и все ресурсы организма будут собраны и мобилизованы. И цель будет достигнута. А еще сказала бы, как бы не было сложно сейчас, продолжай. Потому что все эти сложности даны для того, чтобы было легче потом. Ничего не бывает просто так.

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

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

И, конечно, учи как можно больше всего. Сейчас я изучаю Python. Помню, смотрела первый курс. Ничего не понятно. Ладно, смотрю второй и стало понятно 5%. Смотрю третий курс. Вспоминаю слова и определения из первых двух, и картинка складывается. И вот на десятом курсе напишется функция, метод или класс. Да, кому-то нужно больше времени, кому-то меньше. Но получится у всех. Составь список того, что нужно выучить. Иногда нужно учить не для того, чтобы понимать это и быть в этом специалистом, а знать, где это можно найти.

- Согласна ли ты с утверждением, что тестер - лёгкая профессия в IT?

- Катя: Приведу пример. Это было уже здесь, в Штатах. К нам в компанию пришла девочка китаянка, биолог по образованию. На тот момент она не знала ничего. Я к тому моменту работала в компании года полтора. И объясняла ей все. А через два года эта девочка стала программистом. И теперь я проверяю ее тикеты. Так что да, если есть желание.

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

- И последний вопрос. Назови пять качеств, которыми должен обладать тестировщик

- Катя: Заинтересованность, целеустремленность, усидчивость , хорошие коммуникативные навыки и желание постоянно видеть что-то новое. И стремиться узнать, как это новое работает.

В тестировании нужно любить новое и к этому новому уметь адаптироваться. И это не должно вызывать какой-то дикий страх. Помню, когда я получала тикет, читала его. Мне было страшно даже начинать, потому что все непонятно. Что это? Что эти люди хотят от меня? А сейчас такого страха нет. Теперь у меня возникаю совершенно другие мысли: О, прикольно! Что-то новое придумали. Зарелизим, посмотрим, как работает. Или наш говнокод упадет (смеется)?

В качестве заключения

Хочу подчеркнуть, что это опыт Кати, ее мысли и ощущения. У Вас может быть совершенно другой опыт. И возможно, Вы столкнетесь с совершенно другими сложностями. А те, о которых говорила Катя, Вас обойдут стороной. И это нормально. Все мы разные, классные и уникальные. У каждого будет что-то свое. Главное, помните, что сложности, это нормально. Без них нет роста и развития. Так что, ничего не бойтесь! Идите вперед! И добро пожаловать на борт ;)

PS: Благодарю Катю за интервью. И читателей за то, что дочитали до конца.

Подробнее..

Перевод Лучшие практики автоматизации тестирования решение, что и когда автоматизировать

18.05.2021 20:09:49 | Автор: admin

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

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

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

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

Автоматизируйте ваши смоук тесты

Смоук тесты очень важно выполнять для получение уверенности, что ваше приложение функционирует на базовом уровне, после каждого измененияили при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:

  1. Поможет быстро обнаружить блокирующие ошибки, например, не загружается приложение/веб-страница, пользователь не может войти в систему, пользователь не может создать учетную запись или платежные сервисы не работают.

  2. Обеспечивает более быстрое устранение новых и регрессионных багов. Смоук тесты по своей природе имеют большой охват и небольшую глубину. Это приводит к тому, что тестируется широкий спектр тест-кейсов, не углубляясь в приложение. Когда эти критические области заработают, вы сможете глубже изучить приложение, чтобы протестировать другие функции.

  3. Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.

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

Это позволяет вам иметь набор стабильных тестов, жизненно важных для приложения. Например, создание учетной записи пользователя необходимо будет выполнить до того, как пользователь сможет войти в систему и просмотреть панель управления, совершать платежи и т. д. Создавая набор автоматизированной регрессии, вы можете:

  1. Запускать тесты, которые быстро выявляют любые ошибки, возникающие в результате изменений в программном обеспечении. Эти изменения могут быть новыми функциями или исправлениями багов.

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

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

Автоматизируйте обширные тесты

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

Автоматизируйте тесты, требующие нескольких конфигураций

Речь идет о тестах в различных операционных системахи комбинациях браузеров. Делать все это вручную - утомительно. Также, автоматизация таких тестов может помочь сэкономить время. Автотесты можно запускать в различных средах (таких как Dev, QA, Staging, Integration или PROD), просто изменив переменную среды. Тесты также можно запускать параллельно, что сокращает время, необходимое для выполнения. Вы можете использовать различные инструменты CI, такие как CircleCI, чтобы указать ОС, браузеры и среды, в которых вы хотите запускать параллельные тесты. Убедитесь, что вы следуете лучшим практикам при создании параллельных тестов, чтобы получить от них максимальную пользу.

Автоматизируйте ваши тесты производительности

Это позволяет избежать сбоев при запуске, и снижения производительности. Тестирование производительности проверяет, как система работает под нагрузкой и стрессом, а также выявляет узкие места. Он проверяет скорость, время отклика, надежность, использование ресурсов и масштабируемость программного обеспечения в соответствии с ожидаемой рабочей нагрузкой. Автоматизация может помочь вам легко сгенерировать тысячи пользователей, чтобы увидеть, как приложение отреагирует. Например, Fandango - один из крупнейших в Америке сайтов по продаже билетов (около 36 миллионов посетителей в месяц покупают билеты на их сайте), и они хотели убедиться, что готовы к фильму Звездные войны: Последний джедай. Они хотели узнать, какова их пиковая производительность и определить узкие места. QualityWorks автоматизировала тесты производительности и предоставила им отчеты, которые помогли бы выявить узкие места, и в результате они успешно запустили продажу фильмов. Это то, что они могут продолжать использовать, чтобы гарантировать, что производительность их веб-сайта соответствует определенным стандартам.

Ваш следующий шаг

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

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

Подробнее..

Перевод Cypress VC Selenium

17.06.2021 18:06:38 | Автор: admin

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

Вот вам вопрос на миллион долларов: является ли Cypress чем-то большим, чем платформа для автоматизации веб-тестов и может ли он заменить Selenium?

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

Краткое описание

Cypress - это тестовая веб-платформа нового поколения. Она была разработана на основе Mocha и Chai и представляет собой платформу для сквозного тестирования на основе JavaScript.

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

Архитектура

Cypress работает в одном цикле выполнения приложения. Node.js. является серверным методом, лежащим в основе Cypress. Процессы Cypress и Node.js постоянно взаимодействуют, синхронизируются и совместно выполняют задачи. Кроме того, Cypress работает на сетевом уровне, интерпретируя и изменяя веб-трафик. Это позволяет Cypress не только редактировать все браузеры, но и обновлять коды, которые могут повлиять на автоматизацию браузеров.

В Selenium, когда мы запускаем сценарий автоматизации Selenium, клиентская библиотека Selenium взаимодействует с Selenium API, который отправляет команду привязки драйверу браузера с помощью проводного протокола JSON. Драйвер браузера использует реестр HTTP для фильтрации всех команд управления HTTP-запроса и HTTP-сервера. Затем команды браузера выполняются в скрипте selenium, а HTTP-сервер отвечает скрипту автоматизированного тестирования.

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

Установка

В Cypress нет никакой предварительной настройки, просто установите файл.exe и автоматически настройте все драйверы и зависимости. Автоматизация может быть выполнена за считанные минуты. Одной из философий дизайна Cypress было сделать весь процесс тестирования удобным и комфортным для разработчиков, упаковки и объединения.

Чтобы использовать Selenium в проекте автоматизации, необходимо установить библиотеки линковки языков для использования предпочитаемого языка. Кроме того, в отношении браузеров, для которых вы хотите автоматически проводить проверки, вам понадобятся двоичные файлы для WebDriver.

Если мы также примем во внимание время и сложность имплементации, здесь Cypress имеет преимущество над Selenium.

Поддерживаемые языки

Cypress поддерживает только JavaScript. Поддержка других языков отсутствует, что иногда вынуждает пользователя изучать определенный язык сценариев.

Selenium, в свою очередь, поддерживает широкий спектр языков Java, C#, Python, Ruby, R, Dar, Objective-C, Haskell и PHP, а также JavaScript.

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

Кросс-браузерная поддержка

Cypress поддерживает Canary, Chrome, Chromium, Edge, Edge Beta, Edge Canary, Edge Dev, Electron, Firefox (бета-поддержка), Firefox Developer Edition (бета-поддержка), Firefox Nightly (бета-поддержка).

Selenium поддерживает почти все основные браузеры на рынке, что является дополнительным преимуществом Selenium. Ниже приведен список поддерживаемых браузеров: Chrome (все версии), Firefox (54 и новее), Internet Explorer (6 и новее), Opera (10.5 и новее), Safari (10 и новее).

Selenium имеет более качественную кросс-браузерную поддержку по сравнению с Cypress, потому что Selenium обеспечивает поддержку почти всех доступных на рынке браузеров, в то время как в Cypress вы не можете проводить тестирования на Safari.

Параллельное исполнение пакета автоматизированного тестирования

По сравнению с Selenium в параллельной проверке, cypress отстает.

Selenium имеет много вариантов для параллельного исполнения, что для автоматизации тестирования очень важно. Grid широко используется в сообществе QA с TestNG для параллельного исполнения. А контейнеризация Docker может быть быстро интегрирована.

Производительность

Так как у Cypress нет нескольких архитектурных слоев, в отличие, например, от Selenium, он работает в браузере аналогичным образом. Именно поэтому мы наблюдаем его значительное преимущество над Selenium в скорости выполнения тестов.

Selenium имеет несколько уровней кода между тестом и браузером, в чем, например, Cypress проигрывает.

Интеграция процессов автоматизации с CI/CD

Cypress: Возможна, но ограничена. Существует только одна альтернатива для командной строки и библиотеки npm - Mocha. Служба CI должна поддерживать npm, а запись тестов для большинства записей на сервере CI будет платной.

Selenium: Возможно применение CI/CD. Любая библиотека тестов, их запись и шаблоны исполнения могут использоваться и быстро адаптироваться к требованиям.

Лицензирование

Cypress также доступен под лицензией MIT как open-source. Однако, если сравнивать его с Selenium, все функции Cypress не будут бесплатными, например, приборная панель Cypress бесплатна для seed и платна для Sprout, Tree и Forest. (https://www.cypress.io)

Selenium разрешен под лицензией Apache 2.0, правообладатель Software Freedom Conservation.

Поддержка ОС

Cypress: Windows, Mac, Linux

Selenium: Windows, Linux, Mac, Android, iOS

Поддержка BDD и DataDrivenTesting

Selenium поддерживает BDD и data-driven с помощью внешних библиотек, что в Cypress невозможно.

Локаторы для идентификации объектов

Cypress поддерживает только CSS и Xpath.

Cypress поддерживает все виды веб-локаторов, такие как ID, Name, XPath, селекторы CSS, текстовые ссылки, текстовые частичные ссылки и т.д.

Отчет о выполнении

Selenium: Extent, Allure и любые другие дашборды могут быть реализованы в наборах автоматизации.

Cypress: Дашборд - это как раз Cypress.

Окончательный вердикт

Selenium больше ориентирован на специалистов по автоматизации тестирования, а Cypress - на разработчиков для повышения эффективности TDD. Selenium был представлен в 2004 году, поэтому у него больше поддержки экосистемы, чем у Cypress, который был разработан в 2015 году и продолжает расширяться. Когда мы используем Selenium, в браузере можно манипулировать несколькими различными опциями, такими как Cookies, Local Save, Screen, Sizes, Extensions, Cypress control line options, но опция сети может быть обработана только при использовании Cypress.

Однако, вот некоторые из преимуществ, о которых заявляет Cypress:

1. Программа будет делать скриншоты во время проведения экспериментов. Затем мы можем просмотреть каждый запрос в качестве разработчика теста на панели Test Runner, чтобы увидеть, что произошло на каждом этапе.

2. Для тестирования с помощью Cypress не требуется никакого ожидания или режима сна. Прежде чем продолжить, он немедленно ожидает команд и утверждений.

3. Подобно модульным тестовым ситуациям, "шпионы" Cypress могут подтверждать и проверять действия функций, ответы сервера или таймеры по времени. С помощью Cypress вы можете заглушить сетевой трафик и персонализировать вызовы API в соответствии с вашими потребностями.

Надеемся, что приведенные выше пункты помогут определить, какой метод вам лучше использовать и изучить.


В преддверии старта курса "Java QA Engineer. Professional" приглашаем всех желающих на бесплатный двухдневный интенсив, в рамках которого мы рассмотрим CI- и CD- процессы, изучим основные инструменты и ключевые понятия (Server, agents, jobs. Fail fast, Scheduling, WebHooks). Подробно познакомимся с программной системой Jenkins и научимся интегрировать ее с git и Docker.

Записаться на интенсив:

Подробнее..

Тулзы ручного тестировщика приложений на базе Windows

25.04.2021 20:19:15 | Автор: admin
Моё лицо, когда не удается найти причины появления очередного блокераМоё лицо, когда не удается найти причины появления очередного блокера

Я занимаюсь тестированием десктоп приложений на базе Windows и в данный момент слежу за качеством одной отечественной ММОРПГ. Со временем я оброс некоторыми тулзами, позволяющими улучшить процессы ручного тестирования. В данной статье не хочу трогать полноценную автоматизацию (зависящую от ЯП, игрового движка и желания куашника лезть в эти дебри), а больше рассказать про ПО, которым я сам пользуюсь и которое не так часто всплывает в подобных темах (зачастую упор на мобилках и вэбе).

Virtual Box

Когда использовать: инсталляционное тестирование.

По данным Steam на апрель 2021 наиболее популярной ОСью является Windows 10 64 bit (92.38%). Следом за ней идут Windows 7 64 bit (2.33%) и Windows 8.1 64 bit (1.08%). Среди языков наиболее популярные: английский (39.27%), упрощенный китайский (18.83%) и русский (11.18%). Если с языками в рамках одной ОСи и можно поиграться, то иметь несколько разных ОСей на одной машине и переключаться между ними, прогоняя тесты, удовольствие, скажем честно, на любителя.

Здесь нам и приходят на помощь средства виртуализации, где имхо самым простым и удобным будет Virtual Box. Позволяет прямо здесь и сейчас раскатать несколько образов систем разных разрядностей, языков, объемов ПЗУ и ОЗУ. Создать клон виртуальной машины или сделать снимок системы, к которому можно откатываться после прогона тестов. Образы виртуального диска можно копипастить и использовать на разных физических машинах. Из минусов, в виртуалку не прокинуть видеокарту, в Virtual Box данного функционала попросту нет. link_virtualbox

NetBalancer и Tmeter

Когда использовать: стресс тестирование.

То, что замечательно работает при 500 Мбит, может быть абсолютно неюзабельным при 1 Мбит. Как проводить подобные тесты? Можно, конечно, понизить пропускную способность сетевой карты средствами windows, урезав, скажем, значение до 10 Мбит и поиграть с дуплексом. Или потыкаться в настройках роутера. Но хочется все же более точных цифр и статистики.

Решение для богатых - NetBalancer. Решение для чуть менее богатых Tmeter. Оба приложения позволяют редактировать скорость всего трафика или выставить ограничения на конкретный процесс, задавать правила и фильтры, отображать кол-во полученных и посланных байт в риалтайме. Оба выводят виджет с графиками, имеют приятный интерфейс и гибкую настройку.

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

AutoHotKey

Когда использовать: когда угодно.

Простейшая автоматизация рутинных процессов. Как быстро заполнять поля или отправить в игровой чат тысячу сообщений нажатием одной кнопки? Или воспроизвести последовательность действий, не прожимая кучу кнопок? Ответ - быстрый и ч0ткий AutoHotkey. link_ahk Например, можно зафиксировать шаблон баг репорта с заранее подготовленным форматированием:

^+v::sendinput, *Краткое описание проблемы:*sendinput, {ENTER}sendinput, {ENTER}sendinput, *Шаги воспроизведения:*sendinput, {ENTER}sendinput, 1.sendinput, {ENTER}sendinput, *Фактический результат:*sendinput, {ENTER}sendinput, {ENTER}sendinput, *Ожидаемый результат:*sendinput, {ENTER}sendinput, {ENTER}sendinput, *Окружение:*sendinput, {ENTER}sendinput, {ENTER}sendinput, *Комментарий:*sendinput, {ENTER}sendinput, -return

При нажатии сочетания клавиш ctrl+shift+v поле будет выглядеть так:

Process monitor и DebugView

Когда использовать: когда угодно/анализ данных для баг репорта.

Допустим, вы запускаете игру и ловите синий экран смерти. С чего начать диагностику? Безусловно пойдем изучать журнал windows и тыкать клиентские логи приложения. Но в дополнение к этому я бы выделил сразу две тулзы: Process monitor и DebugView. Первая выводит список всех процессов с указанием времени, позволяет сохранить их в табличку в csv/xml. Быстро, просто и удобно. Вторая позволяет смотреть в риалтайме на события системы во время использования приложения. С какой-то стороны DebugView может ответить на вопрос, что думает винда о том, как ты бьешь орков в вове. link_prmonitor и link_debugview

MSI Afterburner

Когда использовать: когда угодно/нагрузочное тестирование.

Как быстро понять, привели ли изменения в проекте к улучшению производительности и увеличению кол-ва кадров в секунду? А если бы еще можно было бы подключить к этой программе свои скрипты так вообще была бы сказка. Ну так есть такое! MSI Afterburner. Можно вывести на экран не просто кол-во кадров, а всю инфу с нагрузкой на железо (ОЗУ, ЦПУ, ГПУ, МГУ). А также поиграться с настройкой видюхи! Вольтаж, память, регулировка скорости вентиляторов и кучу всякого разного. Еще раз отмечу, что MSI Afterburner позволяет запускать сторонние приложения на свои события. Так, например, я делаю питонячим скриптом скрины экрана в местах, где ФПС значительно проседает. link_msiab

Intel Graphics Perfomance Analyzers

Когда использовать: когда графическое приложение в конкретном месте безбожно тормозит.

Не совсем для всех и каждого. Приложение подойдет для мониторинга производительности программ с упором на графическую составляющую. Включает в себя целый список программных средств: GPA System Analyzer, Frame Analyzer, Trace Analyzer. Позволяет запустить прилажку, поставить ее на паузу, захватить фрейм, собрать по нему объемную информацию и передать на анализ, скажем, техартистам, которые уже и будут заниматься оптимизацией. Еще никогда процесс сбора подобной информации не был так прост. Кому захочется почитать подробнее, вот хорошая статья на русском. link_intel_gpanalyzers

Самописные тулзы

Когда использовать: когда угодно.

Не хотел трогать автоматизацию, но считаю, что стоит упомянуть о самописных тулзах, которые можно использовать каждый день и на всех этапах тестирования. Отправка запросов, работа с БД, парсинг json`ов, анализ любых внутренних данных в свои тулзы можно запихнуть все, что нужно и все, что угодно. Вариаций может быть масса. Я же использую Python и библиотеку pysimplegui, у которой есть отличный cookbook с примерами. А с помощью auto-py-to-exe легко и просто гуишка упаковывается в исполняемый файл.

Отладочные команды для куа отдела это, конечно, круто. Но GUI оболочка под них (какой бы она не была) зарекомендовала себя как инструмент не только для куа, но и для ГД, арта, звука, продюсеров и других отделов. Конечно, можно попросить сделать это прогеров и потратить их время, но можно сделать все это и самостоятельно.

Разумеется, это не полный список, но и время у всех нас не резиновое. Скидывайте в комментарии ваши рабочие инструменты, интересно почитать, где и что можно усовершенствовать и дополнить. И спасибо за внимание!

Подробнее..

Recovery mode Восстание игроков замечание об однопользовательских играх

25.03.2021 16:19:55 | Автор: admin

Всем тем, кто не хочет читать: игра не игра, когда она выступает против игрока, то есть наделяется какой-то определённой целью выступать против или за. Понятие "уровня" и "lvl", стоит только его ввести в концепт игры - убивает саму игру, превращая её в обыкновенный спорт, порождающий спидранерство. Но если на территории вашего уровня существует множество некоторых песочных мелочей, которые позволяют не следовать главной "цели", - аркадная игра превращается в отыгрыш собственной личности в пределах закодированного пространства и тех "фич", за счёт которых сие можно производить (например "кулинарии"). Если же изначально игра делается "ролевой", вы опять-таки игру наделяете "самоцелью", а потому разрушаете её бесцельность, и поэтому сталкиваетесь с тем явлением, что именуется манчикизмом. Манчкизм что в RPG, будь они настольные или в киберпространстве, что в MMORPG производится строго по той причине, что игрока обязывают соблюдать эти самые условия прохождений "сюжета" и "уровней", игнорируя тот факт, что сам по себе игрок не хочет участвовать в вашем спектакле, а хочет уйти в лес. Дайте ему возможность погулять в лесу больше, чем спускаться в ваше подзмелье. Ответ хейтерам.

Его (тип игрока*) нельзя изучить, используя методы социологии, потому что он не связан строго ни с каким определённым социумом такой игрок не есть ни человек пользы, приобретения, профессии, труда[1]. Здесь об этом стоит возразить следующим образом: игрок есть адаптирующийся субъект в условии бесцельного экзистенциирования; играть - адаптироваться в условии бесцельного экзистенциирования соответственно. И только на этом моменте понимания "игрока" как адаптатора могут вступить в полемику Юнгеровские счастливый случай, искусность и подражание, к которым сводятся все игры; с того момента как процесс адаптации завершается, то завершается и игра. Но при этом это не будет означать что игра завершится благоприятным или неблагоприятным исходом, завершение игры может произойти и посредством её прервания, ведь сама из себя игра вовсе и не обязана к чему-либо приводить.

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

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

Само воззрение о тождественности рационального и игрового поведений нивелируется, и не потому что противник определяется неизвестностью (за счёт тайного знания механик) объективного оценивания сложности игроком, сколько потому, что игра для игрока таким образом может резко поиметь цель; цель победить высокий уровень сложности. Мало того, но с того момента как игрок остаётся один на один с уровневой системой, его противником начинает выступать не игрок, а сама игра, в связи с чем игра в те же шахматы симулируется, как и симулируется игра. Её бесцельное онтологическое основание становится лишь иллюзорной видимостью, ведь теперь она не существует сама по себе, а наделяется вполне конкретной целью: создавать иллюзию реального противника за счёт запрограммированного рационального поведения.

И еще раз: всё где играет компьютер в собственной игровой программе уничтожает саму бесцельность лишь постольку, поскольку симуляция игрового поведения выраженного в уровнях сложности не является отдельной категорией данное заложено в коде игры и является её неотъемлемой частью, а не зрителем, помощником или вирусом. По сему поэтому всё что относится к категории однопользовательской компьютерной игры игрой не является. Общепринято именовать геймплеем то, о чем сейчас шла речь. В этой убийственной для Игры аркадности кроется одно примечательное свойство любой нереальный уровневый противник есть симуляция игры лишь до тех пор, пока на сторону программы не присоединится реальный игрок; в этом же случае участие запрограммированной игры в игре превращается в полноценную механику, формируя самой из себя обязательные выраженные объекты (включая сам "движок"), и лишь за них отвечает программирование и IT в той равной степени, в которой заводы отвечают за изготовление спортивного инвентаря. То единственное, что объективно может предложить для Игры киберпространство многопользовательский киберспорт, или реконструкция игр без участия "уровня".

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

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

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

Из всего этого можно вывести тезис: киберпространственные игры есть игры только ролевые для одиночного игрока, или спортивные игры для (что очевидно) спортсменов. То же, что совмещает спорт и ролевую игру в киберпространстве не есть массовая многопользовательская ролевая онлайн- игра, поскольку мморпг лишь иллюзорно обладает спортивными элементами командного соперничества: ММОРПГ не заканчивается НИКОГДА, в ней НЕЛЬЗЯ ни победить, ни проиграть, и собственно умереть в ней нельзя. ММОРПГ является в своей сути ни киберспортом, и не киберролеплеем, - это есть одно из самых настоящих порождений киберигровой мифологии.


[1] Ф.Г. Юнгер: Игры и ключ к их значению, стр.68

[2] Г.В.Ф. Гегель: Феноменология Духа, стр.28

Подробнее..

Перевод Тестирование игр 101 основные советы и стратегии

24.05.2021 16:18:49 | Автор: admin

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

Этапы основного процесса тестирования игр

Чтобы успешно выявить ошибки в игре, тестировщики выполняют несколько основных шагов.

  • Планирование и разработка теста. Это первый шаг в процессе тестирования игры.

    СОВЕТ: для завершения этого шага вы можете помочь себе такими вопросами, как: Что изменилось в спецификации дизайна с момента последней сборки? Какие новые конфигурации будет поддерживать игра? Какие дополнительные тестовые случаи были добавлены? Какие функции были сокращены?

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

  • Проведите тестирование. Наборы тестов запускаются с новой сборкой. Если обнаружена ошибка, проведите как можно больше тестов в ее окружении, чтобы узнать про все детали, которые потом будут занесены в отчет.

  • Сообщить о результатах. На этом этапе составляется отчет со всеми найденными ошибками и недочетами.

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

Вернитесь к шагу 1 и проведите повторное тестирование.

СОВЕТ: Чтобы процесс тестирования игры прошел легко и с успешным результатом, действуйте следующим образом: делайте записи, не спешите, следуйте процедуре, всегда проверяйте правильность тестируемой версии и не отвлекайтесь от игры.

Планирование стратегии

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

СОВЕТ: Для того чтобы результаты были как можно лучше, постарайтесь сделать планирование более подробным и тщательным, насколько это возможно.

Методы и стратегии тестирования игр

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

1. Ad-Hoc тестирование

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

" Ad-hoc тестирование очень важно для тех типов игр, которые выпускает Obsidian. Я заметил, что использование планов тестирования и контрольных списков позволяет выявить очевидные ошибки на поверхности игры, но самые отвратительные ошибки, похоже, обнаруживаются во время ad-hoc сессий". Брэндон Адлер (Ведущий тестировщик (QA Lead), Obsidian Entertainment)

2. Тестирование функциональности

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

Пример ошибки в видеоигре.Пример ошибки в видеоигре.

3. Тестирование на совместимость

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

4. Прогрессионое тестирование (Тест на прохождение)

При использовании этой техники стараются дойти до конца игры без каких-либо перерывов. Тестировщики игр ищут сбои и зависания во время линейного прохождения игры. Примерно в 99% случаев перерывы в проходке вызваны проблемами со сценариями. Оставшийся 1% вызван особенно неприятными местами, где можно застрять.

5. Регрессионное тестирование

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

Для эффективного тестирования игр сотрудничайте с лучшими профессионалами

Если вы хотите, чтобы тестирование вашей видеоигры было действительно эффективным, сотрудничайте с настоящими профессионалами в этой области. Имея более чем 10-летний опыт работы в индустрии видеоигр, Starloop Studios предоставляет услуги по QA-тестированию мультиплатформенных игр во время создания прототипов, разработки, мягкого запуска и после выпуска. Очень важно убедиться, что ваша игра максимально очищена от ошибок перед запуском, поэтому если вам нужны услуги QA-тестирования, превосходящие все ожидания, смело обращайтесь к нам.


Перевод статьи подготовлен в преддверии старта курса "Game QA Engineer".

УЗНАТЬ ПОДРОБНЕЕ О КУРСЕ

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru