Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

0. grumagargler 664 29.05.20 10:10 Сейчас в теме
Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 3425 29.05.20 23:56 Сейчас в теме
это тесты логики/поведения? как тестировать логику в запросе на 10 экранов?
2. CheBurator 3425 29.05.20 23:59 Сейчас в теме
зачем создавать входные данные какие-то? есть 1-2-3 набора входных данных, которые должны проходить стопудово. Далее пихаем на вход вообще всякий хлам и добиваемся чтобы система вела себя адекватно при этом (не крашилась, не делила на ноль итд)...?
3. CheBurator 3425 30.05.20 00:00 Сейчас в теме
Это нормально когда - например - тестируемая функция по существу 10 строк содержательного кода и 50-100 строк "защита от дурака"...?
4. CheBurator 3425 30.05.20 00:01 Сейчас в теме
Задача тестирования - попытаться уронить систему? - так?
5. grumagargler 664 30.05.20 00:54 Сейчас в теме
(4)
это тесты логики/поведения? как тестировать логику в запросе на 10 экранов?

Это тестирование написанной программы через эмуляцию работы пользователя в ней. Какие при этом вызываются процедуры и выполняются запросы - напрямую не связано с описываемой темой доклада.

зачем создавать входные данные какие-то? есть 1-2-3 набора входных данных, которые должны проходить стопудово. Далее пихаем на вход вообще всякий хлам и добиваемся чтобы система вела себя адекватно при этом (не крашилась, не делила на ноль итд)...?

Не уверен что понял про наборы данных. Есть сценарии на входе которых данные. Методика, при которой вы управляете созданием данных, позволяет идти в ногу с изменяющейся функциональностью вашей программы. Можно конечно создать где-то в сторонке пару наборов данных на основе тз или других требований, но на практике изменения в программе приходится делать не только по причине недоработанных тз.
Это нормально когда - например - тестируемая функция по существу 10 строк содержательного кода и 50-100 строк "защита от дурака"...?

Да, но вероятно я не понял вопрос.
Задача тестирования - попытаться уронить систему? - так?

Нет, не только.
6. BackinSoda 30.05.20 01:02 Сейчас в теме
Такое тестирование, видимо, окупается на крупных проектах, где над одними объектами работает несколько программистов. А то получается, что время затраченное на создание теста превышает время на саму разработку. Особенно для печатных форм, проще же внешнюю создать, сохранил-свернул в предприятие и сразу виден результат, а сколько времени надо на написание логики тестов п.ф. ?
8. grumagargler 664 30.05.20 03:01 Сейчас в теме
(6) мой небольшой цикл статей и докладов пронизан идеей, что для разработчика тестирование - это неотъемлемая часть профессии, и никак не связана с многообразием бизнес-процессов вокруг разработки, размером проектов и бюджетов (включая тестирование не разработчиками). Конечно, это не работает абсолютно для всего, но и тумблером (тестирование вкл/выкл) не является.
9. JohnyDeath 298 30.05.20 09:04 Сейчас в теме
(6) не понял про печатные формы. Вы их глазами что ль сравниваете?
Проверять печатные формы тестами достаточно просто (если речь идет о сверке результата с эталоном).
Вот например как можно гибко делать в тестере: http://test1c.com/businesslogic/#_2
А если же надо просто сравнить полностью два табличных документа, то для этого достаточно вызвать один метод, который вызовет исключение, если табличные документы не совпадают.

По поводу крупных проектов и большой команды. Не согласен с вами. Я в данный момент работаю один. На сопровождении несколько полутиповых допиленных конфигураций, которые надо периодически обновлять поставками от вендора. Каждое новое мажорное обновление - это страх, что может отвалиться то, что дописано сверху (иногда и что-то типовое). Когда у тебя есть хоть немного сценариев, которые эмулируют работу пользователей, то это уже дает +80 к уверенности, что завтра с утра тебе не будут насиловать по телефону и в чатах, что всё сломалось.
А если вести разработку "от тестирования", т.е. когда ты сначала пишешь тест, а потом под него код, то получается и весело и полезно. Пример такой работы есть в видео у автора статьи: https://www.youtube.com/watch?v=Lr6ew_Nu1aE&feature=emb_title
12. BackinSoda 30.05.20 10:09 Сейчас в теме
(9) Про печатные формы - имхо, для дымового теста внешней п.ф. достаточно "глазами сравнить". По идее, если вы её разработчик, то знаете, где какие параметры и что потенциально могло не заполниться.
Не доводилось работать в Тестере, но предполагаю, что на подготовку каждого эталона уходит не мало времени, да и для большинства пф придётся делать новый уникальный эталон, а не использовать готовые.

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

Вот тут согласен, без сценарного тестирования сложно будет обойтись.

пс: В комментариях к полуторачасовому видео есть хороший вопрос про то, какой функционал всё же покрывать тестами ? Вот такую бы статью еще прочитать
ппс: Для неподготовленного пользователя видео тяжело для восприятия, хоть оно и не носит обучающего характера, но всё же
13. JohnyDeath 298 30.05.20 10:42 Сейчас в теме
(12)
Про печатные формы - имхо, для дымового теста внешней п.ф. достаточно "глазами сравнить". По идее, если вы её разработчик, то знаете, где какие параметры и что потенциально могло не заполниться.

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

Если нужно сверить один-в один, то достаточно сохранить однажды распечатанное.
Но лучше, конечно, сделать параметризированный шаблон сверки. Как это сделать в Тестере я кидал выше.
Вот еще из полезного по теме сверке шаблонов: http://test1c.com/faqtesting/#_37
Поверьте, окупается уже на второй-третьей сверке "на глаз".
7. acanta 30.05.20 01:05 Сейчас в теме
А крупных проектов мало потому что автоматизированное тестирование слишком сложное и дорогое, при том что ручное вообще невозможно.
10. acanta 30.05.20 09:10 Сейчас в теме
В екселе есть кнопка макрорекордер. В 1с по моему есть такая примочка, которая перехватывает нажатие клавиш пользователя и может записать это и воспроизвести. Можно ли из этой записи получить полноценный сценарный тест или хотя бы его основы?
11. JohnyDeath 298 30.05.20 09:13 Сейчас в теме
(10) На этом сейчас основаны все фреймворки тестирования, что перечислены в конце статьи (за исключением xUnit)
Пример создания в видео ниже. Но текущий релиз Тестера намного круче преобразовывает запись с клиента во внутренний язык. Просто качните и попробуйте.
https://www.youtube.com/watch?v=ZyqQ-YjKB3A
BackinSoda; acanta; +2 Ответить
14. sorb 30.05.20 15:08 Сейчас в теме
Имхо один из лучших докладов был, спасибо)
Оставьте свое сообщение
Вопросы с вознаграждением