Здесь представлена часть работ по ручному тестированию и частично по тестированию интеграции, выполненных мной на реальном объекте тестирования в процессе обучения по программе ТУСУР: "Тестирование и контроль качества ПО".
В учебном проекте был подвергнут тестированию интернет-портал «насыщенных путешествий» https://youtravel.me/.
Поскольку задача учебная, никакого ТЗ в моём случае не было. Для ознакомления со структурой и спецификой сайта (его функциональностью) для целей последующего тестирования, пришлось составить "интеллект карту" сайта. Результат выполнения этого шага показан на рисунке 1.1 ниже.
Рисунок 1.1. Интеллект карта сайта youtravel.me
Этот раздел относится к функциональному тестированию. Здесь продемонстрированы результаты ручного тестирования интернет-портала «насыщенных путешествий» https://youtravel.me/, с учётом изложенного в разделе 1, т.е. при отсутствии ТЗ и спецификации. Далее представлены 3 баг-репорта совместно со скриншотами демонстрирующими их проявление, причём баг №2 имеет статус рекомендации (улучшения).
Баг-репорты по результатам ручного тестирования из баг-трекинговой системы (BTS) "Mantis", показаны ниже в разделах: 2.1, 2.2, 2.3.
Рисунок 2.1. Баг_0002485, страница 1
Рисунок 2.2. Скриншот-1 для бага_0002485
Рисунок 2.3. Скриншот-2 для бага_0002485
Рисунок 2.4. Баг_0002485, страница 2
Рисунок 2.5. Баг_0002486, страница 1
Рисунок 2.6. Баг_0002486, страница 2
Рисунок 2.7. Баг_0002487, страница 1
Рисунок 2.8. Скриншот-3 для бага_0002487
Рисунок 2.9. Скриншот-4 для бага_0002487
Рисунок 2.10. Скриншот-5 для бага_0002487
Рисунок 2.11. Баг_0002487, страница 2
Этот раздел также относится к функциональному тестированию. Здесь продемонстрировано применение методики попарного тестирования входных данных к объекту тестирования - интернет-порталу "насыщенных путешествий" https://youtravel.me/. Для проведения тестирования используются два инструмента:
- PICT - инструмент командной строки;
- POT (Pairwise Online Tool) - онлайн инструмент.
Для проведения тестирования с использованием этого инструмента подготовлен такой набор входных данных:
#
# Набор входных данных инструмента PICT
# для "попарного тестирования" сайта: https://youtravel.me/
# в рамках программы обучения ТУСУР "Тестирование и контроль качества ПО"
# Автор: Карышев Е.Н.
# Дата: 28.07.2023
#
Куда: Алтай, Дагестан, Таймыр, Турция, Тайланд
Длительность: 1-5, 5-15, >15
Тип тура: Авторский, На море, Экскурсионный, На снегоходах, Горнолыжный
Сколько человек: 1-5, >5
Возраст группы: 18-39, 30+, 40+, 50+, 60+
Язык тура: Русский, Английский, Китайский
IF ([Куда] in {"Алтай", "Дагестан", "Таймыр"} AND [Тип тура] = "На море") THEN [Тип тура] = "Авторский";
IF ([Куда] in {"Турция", "Тайланд"} AND [Тип тура] in {"На снегоходах", "Горнолыжный"}) THEN [Тип тура] = "Авторский";
Листинг 3.1. Набор входных данных с условиями для инструмента PICT
Инструмент позволяет вводить дополнительные условия (ограничения) по данным (корректности входных данных), что показано в двух последних строках листинга 3.1 выше. Так например туры "На море" для некоторых локаций, например Алтая - невозможны (там нет моря), либо тур "На снегоходах" для Таиланда, поэтому они автоматически заменяются на значение по умолчанию.
Полученные варианты комбинаций входных значений полей в формате CSV-файла, приведены на рисунке 3.1 ниже.
Рисунок 3.1. Результат полученный инструментом PICT в файле формата csv
Тот же вариант, но выведенный в консоль терминала Windows, выглядит так:
Рисунок 3.2. Результат работы инструмента PICT - выведенный в консоль терминала Windows
Этот онлайн инструмент иначе устанавливает ограничения. В нём нельзя выполнить подстановку значения по умолчанию, но можно указать, что пара определённых значений для входных данных не совместима. Для проведения тестирования с использованием этого инструмента на сайте инструмента введён такой набор входных данных:
Рисунок 3.3. Пакет входных данных подготовленный для инструмента POT
В силу иного способа формирования входных пар (их совместимости) и невозможности несовместимые значения заменить на значения по умолчанию, - этот инструмент выдаёт меньшее количество вариантов входных значений. Результат работы инструмента показан на рисунке 3.4.
Рисунок 3.4. Результат работы инструмента POT
Тестируемый портал предлагает либо выполнить классическую авторизацию через email, либо воспользоваться API-интерфейсом авторизации OAuth-2, - т.е. использовать несколько внешних сервисов (соц. сетей), для авторизации через них (см. рисунок 4.1). Этот раздел, как и описанные выше относится к категории функционального тестирования.
Рисунок 4.1. Варианты авторизации на сайте
В таблицах 4.1, 4.2 приведены две таблицы решений, для моего объекта исследования. В таблице 4.3 показаны варианты тест-кейсов, для оптимизированного варианта таблицы решений. Первый тест-кейс "позитивный", - остальные "негативные".
Таблицы 4.1, 4.2. Таблицы решений для авторизации на сайте через email
Таблица 4.3. Тест-кейсы для проверки авторизации на сайте через email
На этом этапе производилось тестирование поиска по сайту. Поскольку ТЗ нет, то были использованы общеприменимые методики (эвристики) с использованием таких вариантов запросов, как например: сокращения слов, английский регистр, словосочетания, регистры ввода и т.д. Результаты тестирования представлены в таблице 5.1 ниже. Этот раздел, как и описанные выше относится к категории функционального тестирования.
Таблица 5.1. Результаты тестирования поиска
На этой фазе обычно производят тестирование ряда показателей, таких как: юзабилити тестирование, нагрузочное тестирование, тестирование производительности, тестирование безопасности и т.д. В моём случае также был протестирован ряд нефункциональных показателей.
К сожалению, на тестируемом сайте выявлены многочисленные грамматические ошибки в тексте содержимого сайта.
Рисунок 6.1. Результаты проверки орфографии на сайте
Также, из-за ошибок в коде разметки страдает производительность работы сайта.
Рисунок 6.2. Ошибки в коде разметки и стилизации
Как уже было сказано в разделе 2.3 (дефекты описаны там же), на сайте отсутствует адаптивность к устройствам "воспроизведения сайта".
Рисунок 6.3. Пример отсутствия адаптива на тестируемом сайте
Ниже приведены два интегральных отчёта о производительности сайта. Первый отчёт выполнен для мобильных устройств, второй отчёт выполнен для настольных устройств. Оценка производительности сайта https://youtravel.me/ проведена с использованием инструмента: https://developers.google.com/speed/pagespeed/insights.
Рисунок 6.4. Показатели производительности для мобильных устройств
Рисунок 6.5. Показатели производительности для настольных устройств
Как видно из представленных данных, - оба теста сайта на производительность не пройдены. В случае с "мобильной версией" показатели составляют примерно одну четверть от возможной производительности, а в случае с представлением для настольного компьютера, показатели составляют примерно одну треть от возможной.
В этом разделе я кратко демонстрирую пример интеграционного тестирования, а именно умение тестировать API приложений с использованием инструмента Postman. В примере я демонстрирую владение JavaScript для написания тестов в пределах фреймворка Chai, встроенного в Postman, а также использование внутри Postman пользовательских переменных окружения.
Рисунок 7.1. Скриншот Postman-клиента с открытым тестом наличия учётки пользователя
Ниже приведён JavaScript-код показанного на рисунке 7.1 теста.
// Карышев Е.Н. июнь 2023г.
// Это исполнение дополнительного задания (со звёздочкой)
// На всякий случай поясню, если не понятно, "что здесь происходит".
// По заданию, нужно сохранить в переменных коллекции следующие свойства 10-ого юзера: id, first_name, email
if (pm.response.to.have.status(200)) { // я запрашиваю у api только нужного мне юзера, если он есть
let jsonData = pm.response.json();
let myUsr = jsonData.data; // выбираю нужный мне элемент-объект (освобождаюсь от массива)
delete myUsr.last_name; // убираю лишние свойства объекта
delete myUsr.avatar;
pm.collectionVariables.set('credentials', myUsr) // сохраняю все нужные по заданию свойства - одним объектом в переменной коллекции credentials
console.log(pm.collectionVariables.get('credentials')); // демонстрирую, что всё работает
}else {
console.log("Нифига нет такого пользователя с ID" + pm.collectionVariables.get('ourUser'));
}Листинг 7.1. Тестирование наличия учётных данных у конкретного пользователя
7.2. Тестирование API на корректность его работы при частичном изменении учётных данных пользователя
Рисунок 7.2. Скриншот Postman-клиента с открытым тестом корректности изменений учётных данных
Ниже также приведён JavaScript-код показанного на рисунке 7.2 теста.
// Карышев Е.Н. июнь 2023г.
// первый тест - "Статус завершения запроса ОК"
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
// второй тест - поле "Дата обновления - не пустое"
pm.test("Date is not empty", function () {
let jsonData = pm.response.json();
pm.expect(jsonData.updatedAt).to.not.empty;
});
// третий тест - "Дата обновления - сегодня"
pm.test("The date of update is today", function () {
let jsonData = pm.response.json();
const moment = require('moment');
let myDate = new Date(jsonData.updatedAt);
let nowDate = new Date(Date.now())
pm.expect(moment(myDate).format("YYYY-MM-DD")).to.eql(moment(nowDate).format("YYYY-MM-DD"));
});Листинг 7.2. Тестирование корректности изменений учётных данных пользователя