А за разговор ответишь

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

В этот раз он решил мне не поверить, поэтому «буду отвечать за ба..р».

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

Теоретическая часть.

Тестирование, как мы знаем, строится по уровням. Модульное, компонентное, интеграционное, пользовательское. Кто как группирует. То есть, сначала тестируются точечные вещи, атомы молекулы.

Пример:

модульное тестирование — проверка допустимости ввода вида оплаты в инфотип;

компонентное — вид оплаты можно ввести, посчитать в зарплате и получить результат в расчетном листе;

интеграционное — вид оплаты, введенный в инфотип, корректно проводится в главную книгу;

пользовательское — пользователь создает 15 видов оплаты, 20 полупериодов и хочет, чтобы все это работало «как раньше».

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

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

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

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

Теперь отвечаю на вопросы моего читателя.

Практикум.

А как насчет потестировать бади на изменение инфотипа PA или соединения объектов в ИТ 1001?

Да легко 🙂 Результатом работы бади является что-то. Что? Например, в бади читается инфотип штатной должности и какой-то атрибут отражается на экране. Входные данные теста — табельный номер. Тест запускает PA30 (все как в LSMW), создает запись инфотипа, отрабатывает бади. И вот тут мы останавливаем тест и просим сохранить в переменную поле с экрана — то самое, где бади должен отразить значение со штатки. И дальше ставится проверка в тесте: результат теста = («контрольное значение» == «переменная теста, которая заполнена данными с экрана»).
А проверить, не сбился ли расчет какой-нибудь суммы в самодельном отчете?

Опять же просто. Делается эталонный пример. Кластер, в нем лежит эталонный расчет. Мы знаем, что правильное значение в отчете равно 153 (или что-то иное). Тест запускает отчет, заполняет селекционный экран, на выходе получается одна цифра или множество. Тест также может получить значение конкретной ячейки. Вот его мы и сравниваем с эталоном — 153. Это и есть результат теста: равно или нет.
Ну или хотя бы удостовериться, что после допиливания схемы расчета зарплаты не сбился расчет страховых взносов.

Аналогично предыдущему примеру. Есть десяток табельных номеров с эталонным расчетом, который распечатан и замурован в сейф. Запускается формирование печатной формы (или расчет зп, вторым шагом отчет по видам оплаты), где и сравнивается значение из формы/отчета с контрольными значениями.
И заодно проверить, что РСВ-1 по-прежнему выдает ожидаемые суммы?

Аналогично предыдущим двум пунктам.

 

Пошаговая инструкция в картинках будет несколько позже. Пока аврал 😉

А за разговор ответишь: 1 комментарий

  1. Calm

    Добрый день, Виталий!
    Спасибо за подробный ответ.

    >>Да легко 🙂 Результатом работы бади является что-то. Что? Например, в бади читается инфотип штатной должности и какой-то атрибут отражается на экране.

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

    >>А проверить, не сбился ли расчет какой-нибудь суммы в самодельном отчете? Опять же просто.

    Да, всё понятно, я всё ловлю на лету. Но что конкретно имелось ввиду? 🙂 (с)

    Какие средства есть у еката для чтения заданной суммы. Мы можем в тесте поискать сумму по заданному виду оплаты (просуммировав по всем сплитам). Или мы же можем работать только на уровне «взять N-ую строку таблицы RT»?

    >>Тест также может получить значение конкретной ячейки.
    Это я не понял. Что значит «значения ячейки»? Ячейки чего? 🙂
    А если отчет, не дай бог, зетовский и генерит какой-нибудь word c числами? к примеру кадровый приказ с установленной суммой надбавки? Там к каким «ячейкам» можно обращаться?

    Буду очень признателен за пояснения.

    P.S.
    >>А за разговор ответишь
    Виталий, уверен, что Вы понимаете, что мой скепсис относится к екату, а ни в коем случае не к Вашей компетенции 🙂

Добавить комментарий