Есть у меня один активный читать, которому я часто бываю благодарен за отзывы и правильные вопросы.
В этот раз он решил мне не поверить, поэтому «буду отвечать за ба..р».
Итак, так как тема очень большая и больная, то я буду вам про нее рассказывать по мере своего изучения.
Начнем с теории и мировых практик. Чтобы не быть совсем голословным скажу, что я это использую в своих неСАП проектах. И мне это помогает.
Теоретическая часть
Тестирование, как мы знаем, строится по уровням. Модульное, компонентное, интеграционное, пользовательское. Кто как группирует. То есть, сначала тестируются точечные вещи, атомы молекулы.
Пример:
модульное тестирование — проверка допустимости ввода вида оплаты в инфотип;
компонентное — вид оплаты можно ввести, посчитать в зарплате и получить результат в расчетном листе;
интеграционное — вид оплаты, введенный в инфотип, корректно проводится в главную книгу;
пользовательское — пользователь создает 15 видов оплаты, 20 полупериодов и хочет, чтобы все это работало «как раньше».
В любом случае, автоматизированное тестирование заключается в простой идее — компьютер выполняет ту работу, которую делает человек, но по заранее определенному алгоритму с фиксированным набором входных и выходных данных. Например, если мы ставим какую-то галочку в системе, то первые пару раз мы можем проверить вручную, а через месяц таких галочек становится множество, в результате чего вручную их все уже не проверить.
Тут и приходят на помощь тесты. Для первой галочки мы написали два алгоритма проверки (например, вид оплаты можно ввести в инфотип, для вида оплаты можно вводить только сумму). На входе мы задаем табельный номер, вид оплаты. Тест — глупая машина, которая пока не обладает ИИ. Следовательно, надо сказать, что есть положительный результат. в конкретном примере выше это системное сообщени — запись была сохранена. То есть, мы делаем два теста, где на входе будут разные наборы данных, но одна проверка — появление сообщения внизу экрана.
Теперь обратная ситуация. Кто-то поменял настройку допустимости. Мы уже накопили тысячу тестов в своей библиотеке. Запускаем ночью прогон всех тестов. И бац, один тест свалился — тот самый, где мы вводили вид оплаты в инфотип. Только из-за изменения настройки теперь нам система выдаст красное сообщение с ошибкой, а не то, которое ожидает наш алгоритм в тесте. Вот и индикатор того, что тест отработал верно, а кто-то нарушил работу системы.
Дальше уже начинают разбираться, нужно переделывать тест, потому что бизнес изменился, или же нужно вернуть настройки допустимости назад.
Теперь отвечаю на вопросы моего читателя.
Практикум
А как насчет потестировать бади на изменение инфотипа PA или соединения объектов в ИТ 1001?
Да легко 🙂 Результатом работы бади является что-то. Что? Например, в бади читается инфотип штатной должности и какой-то атрибут отражается на экране. Входные данные теста — табельный номер. Тест запускает PA30 (все как в LSMW), создает запись инфотипа, отрабатывает бади. И вот тут мы останавливаем тест и просим сохранить в переменную поле с экрана — то самое, где бади должен отразить значение со штатки. И дальше ставится проверка в тесте: результат теста = («контрольное значение» == «переменная теста, которая заполнена данными с экрана»).
А проверить, не сбился ли расчет какой-нибудь суммы в самодельном отчете?
Опять же просто. Делается эталонный пример. Кластер, в нем лежит эталонный расчет. Мы знаем, что правильное значение в отчете равно 153 (или что-то иное). Тест запускает отчет, заполняет селекционный экран, на выходе получается одна цифра или множество. Тест также может получить значение конкретной ячейки. Вот его мы и сравниваем с эталоном — 153. Это и есть результат теста: равно или нет.
Ну или хотя бы удостовериться, что после допиливания схемы расчета зарплаты не сбился расчет страховых взносов.
Аналогично предыдущему примеру. Есть десяток табельных номеров с эталонным расчетом, который распечатан и замурован в сейф. Запускается формирование печатной формы (или расчет зп, вторым шагом отчет по видам оплаты), где и сравнивается значение из формы/отчета с контрольными значениями.
И заодно проверить, что РСВ-1 по-прежнему выдает ожидаемые суммы?
Аналогично предыдущим двум пунктам.
Пошаговая инструкция в картинках eCATT будет несколько позже. Пока аврал 😉
One Comment
Calm
Добрый день, Виталий!
Спасибо за подробный ответ.
>>Да легко 🙂 Результатом работы бади является что-то. Что? Например, в бади читается инфотип штатной должности и какой-то атрибут отражается на экране.
Не-не. Пусть результатом бади будет проверка, можно ли создать соединение. Если можно, то создается соединение, если нельзя — показываем пользователю мессадж, что, мол, нельзя. Кстати, в нагрузку давайте екатом проверим корректность формирования сообщения об ошибки 😉
>>А проверить, не сбился ли расчет какой-нибудь суммы в самодельном отчете? Опять же просто.
Да, всё понятно, я всё ловлю на лету. Но что конкретно имелось ввиду? 🙂 (с)
Какие средства есть у еката для чтения заданной суммы. Мы можем в тесте поискать сумму по заданному виду оплаты (просуммировав по всем сплитам). Или мы же можем работать только на уровне «взять N-ую строку таблицы RT»?
>>Тест также может получить значение конкретной ячейки.
Это я не понял. Что значит «значения ячейки»? Ячейки чего? 🙂
А если отчет, не дай бог, зетовский и генерит какой-нибудь word c числами? к примеру кадровый приказ с установленной суммой надбавки? Там к каким «ячейкам» можно обращаться?
Буду очень признателен за пояснения.
P.S.
>>А за разговор ответишь
Виталий, уверен, что Вы понимаете, что мой скепсис относится к екату, а ни в коем случае не к Вашей компетенции 🙂