Comments 4
Круть крутейшая. И все это за 85 часов? Две недели? С трудом в это верится, но ладно.
А например, если бы нужно было не только текстовое содержание PDF, но и верстку проверять, как бы в принципе к этому подошли? Ну выгрузка в картинку скажем, напрашивается сама собой. Но в картинке ведь будут некоторые области статические (напр. таблицы), а некоторые динамические (напр. календарная дата). Или как у вас на картинке с печатью, срок действия подписи поменяется.
Я думал вводить области которые заведомо не будут проверяться (типа местами зачерненный шаблон). Либо будут проверяться через OCR, либо с другим пороговым значением. Которое придется подбирать, чтобы с высокой точностью отличать допустимое отклонение от недопустимого
А например, если бы нужно было не только текстовое содержание PDF, но и верстку проверять, как бы в принципе к этому подошли? Ну выгрузка в картинку скажем, напрашивается сама собой. Но в картинке ведь будут некоторые области статические (напр. таблицы), а некоторые динамические (напр. календарная дата). Или как у вас на картинке с печатью, срок действия подписи поменяется.
Я думал вводить области которые заведомо не будут проверяться (типа местами зачерненный шаблон). Либо будут проверяться через OCR, либо с другим пороговым значением. Которое придется подбирать, чтобы с высокой точностью отличать допустимое отклонение от недопустимого
А вот еще один организационный вопрос. Обьем автоматизации (типа покрытие) подход и прочие вещи дали решать Вам, типа «ну окей, делайте» или с Вас стребовали сперва какой-то более формализованый подход к реализации?
Ваше предложение правильное. По крайней мере, я делал также.
Если нужно в одном файле проверять статические и динамические данные, то необходимо его разбивать на разные области. Верстка (статика) проверяется тем же самым скриншот тестированием. То есть либо вырезаем нужную нам область картинки и сохраняем для сравнения, либо сохраняем всю, а уже средствами, например, Yandex aShot игнорируем не интересующие нас области (динамика). Их как раз можно проверить через парсинг.
Возьмем ту же печатную форму со штампом. Ее можно разбить на 3 части:
1. Шапка документа – всегда статична. Мы ее обрезаем и сохраняем как картинку, в тесте проверяем через сравнение скриншотов.
2. Номер документа, дата – ее как раз можем проверить через сохранение файла и парсинг данных.
3. Штамп – почти статичен. Идем путем из п.1.
Данные в штампе зависят от ЭП. Но мы можем с уверенностью сказать, когда эта подпись изменится (срок действия) и поменять эталон изображения в тестах. Это происходит не так часто. Например, сейчас используем подпись, которая действительна 1 год. Не вижу в этом проблемы.
По поводу порогового значения при сравнении изображений. Я бы не советовал такой подход использовать. Был не очень положительный опыт, тесты становятся хрупкие и ненадежные. Лучше вырезать и игнорировать ненужные области на картинках.
Если нужно в одном файле проверять статические и динамические данные, то необходимо его разбивать на разные области. Верстка (статика) проверяется тем же самым скриншот тестированием. То есть либо вырезаем нужную нам область картинки и сохраняем для сравнения, либо сохраняем всю, а уже средствами, например, Yandex aShot игнорируем не интересующие нас области (динамика). Их как раз можно проверить через парсинг.
Возьмем ту же печатную форму со штампом. Ее можно разбить на 3 части:
1. Шапка документа – всегда статична. Мы ее обрезаем и сохраняем как картинку, в тесте проверяем через сравнение скриншотов.
2. Номер документа, дата – ее как раз можем проверить через сохранение файла и парсинг данных.
3. Штамп – почти статичен. Идем путем из п.1.
Данные в штампе зависят от ЭП. Но мы можем с уверенностью сказать, когда эта подпись изменится (срок действия) и поменять эталон изображения в тестах. Это происходит не так часто. Например, сейчас используем подпись, которая действительна 1 год. Не вижу в этом проблемы.
По поводу порогового значения при сравнении изображений. Я бы не советовал такой подход использовать. Был не очень положительный опыт, тесты становятся хрупкие и ненадежные. Лучше вырезать и игнорировать ненужные области на картинках.
Был критический функционал, который необходимо покрыть в первую очередь. И который нужно было проверять от релиза к релизу.
Со стороны руководства и других членов команды (аналитики, внедренцы) был четко обозначен этот функционал + вещи на которые стоит обратить внимание при проверке (ПФ, лист согласования, корректность движения задач по процессу).
Как это все будет проверятся и в каком объеме — решала непосредственно QA-команда.
Если что-то пропустили или не учли, то уже на следующих итерациях это исправлялось. Например, нашли баг в функционале, который автотесты не покрывали. После его исправления добавили тест, который это момент проверяет.
Со стороны руководства и других членов команды (аналитики, внедренцы) был четко обозначен этот функционал + вещи на которые стоит обратить внимание при проверке (ПФ, лист согласования, корректность движения задач по процессу).
Как это все будет проверятся и в каком объеме — решала непосредственно QA-команда.
Если что-то пропустили или не учли, то уже на следующих итерациях это исправлялось. Например, нашли баг в функционале, который автотесты не покрывали. После его исправления добавили тест, который это момент проверяет.
Sign up to leave a comment.
Как e2e автотесты на Selenide помогают QA-команде при частых релизах