-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Получается, что заказчик создал непредусмотренную ситуацию. И чтобы она не повторилась, нужно создать тест, который ее воспроизводит. И исправить код, чтобы тест проходил. И больше никогда такая ситуация у заказчика не возникнет, потому что тесты не дадут возможности ей повториться. Вот для этого и нужны автоматизированные тесты.
А вы никогда не меняете код? Никогда его не оптимизируете, не переписываете, не улучшаете? Тест позволит не потерять такую ситуацию, даже если вы очень сильно измените код, например, для того, чтобы сделать его красивее (чтобы учет специального случая "глаз не мозолил").
С другой стороны, тест - это документация. Вот при таких условиях получится вот такой результат. А если на вход подать ерунду, то будет исключение.
С другой стороны, тест - это документация. Вот при таких условиях получится вот такой результат. А если на вход подать ерунду, то будет исключение.
Оживим тему? 
Я, конечно, не тестировщик, но даже при наличии штата тестировщиков, проводащих ручное тестирование (по багам/доработкам и проверочным сценариям), все равно приходится проверять и находить баги на свою голову (ну, и коллег).
А вот автоматизацию пока не пробовали, предложили-поговорили когда-то давно и все заглохло, у нас тестировщики не заинтересованы в этом (пока что?).
А давайте я дам одну ссылочку
А кто-то пробовал подобное?
Я, конечно, не тестировщик, но даже при наличии штата тестировщиков, проводащих ручное тестирование (по багам/доработкам и проверочным сценариям), все равно приходится проверять и находить баги на свою голову (ну, и коллег).
А вот автоматизацию пока не пробовали, предложили-поговорили когда-то давно и все заглохло, у нас тестировщики не заинтересованы в этом (пока что?).
А давайте я дам одну ссылочку
Ссылка скрыта от гостей
А кто-то пробовал подобное?
и не будет
ИБМ отказалась от развития ЛС и переключилась на java (что не удивительно)Вообще интересует про автоматическое тестирование. Хорошо, а что с жавой можно сделать в этом плане?
Если пойти сначала, т.е. от чего возникла необходимость в авто-тестировании, тогда сможем понять, как эту самую необходимость можно минимизировать, и как собственно и поступают разрабы под Lotus.
Причина 1. Отсутствие хорошей документации по разрабатываемым API (при уволившихся старых сотрудниках и при приёме новых - труба).
Причина 2. Отсутствие нормальных тимлидов, которые бы контролировали разрабатываемые API с точки зрения:
- модульного построения (каждая функция, класс или модуль выполняет только одну присущую ему функцию);
- повторного использования кода.
Или отсутствия времени/желания и т.д.
Компании быстро поняли, что качественный продукт - это долго, лучше заработать много денег и быстро. В итоге получаются ситуации, когда в компании мирового уровня (не буду показывать пальцами) под новую систему набирают 1500 (это реальная цифра!) программистов, которые работают группами по 10-15 человек в команде и не имеют никакого представления о том, что делает соседняя группа (какое API пишет, и можно ли его использовать). В таких условиях и появилась потребность в авто-тестировании. Так ты особо не связан наличием хорошей документации на API и уволившимися програмерами, которые знали архитектуру, и тебя не парит, что твоя система занимает гигабайты памяти (наоборот, с точки зрения маркетинга это хорошо - больше денег).
Как от этого можно уйти - ликвидировать то, что было описано выше, т.е.:
1. Ввести жёсткое правило повторного использования кода. К примеру в коде всей системы не должно быть множества NotesDocument.Save(), тем более с параметрами True, True (за это надо просто прибивать). Надо сделать функцию-обёртку, которая бы это делала. Ну может быть за исключение 1-2 случаев, где установлены другие параметры, но такие случаи должны быть тщательно документированы. Получается, что все обработчики соответствующих ошибок в одном месте, т.е. с этим проблема решена, - не нужно будет лазить в сотнях мест системы и повторно исправлять одни и те же ошибки.
Если вся система будет построена таким образом, то она будет постоянно тестировать сама себя. Поясню.
Любое прохождение документа по маршруту бизнес-процесса на самом деле будет использовать около 75% всего написанного кода. Если сидит тестер, который постоянно что-то тестит, то он при ошибке в коде с очень большой долей вероятности получит эту ошибку и сразу же скажет об этом разрабу, который сделает исправление тут же. Это и есть часть концепции экстремального программирования, но не того, что написано об этом сейчас (сейчас навалено всё в кучу: Scrum, Agile), а того, что подразумевалось в самом начале. А вначале в экстрим-программировании внутренние релизы для тестировщиков вообще не предусматривались. В этом и есть экстремальность, ну и скорость разработки. А сейчас почитаешь... куча умных слов, а отличие одной методологии от другой по сути в сроках поставки релизов...
Приведу пример. Когда-то устроился в одну контору, где использовался Scrum - при каком-либо изменении надо было выпускать внутренний релиз для QA. Т.к. самому нормально оттестить было долгим процессом (настроить юзерам определённые права, создать в разных БД разные документы, запустить документ по определённому маршруту, и где-то на 15-20-м шаге согласования была ошибка), то я создал билд и отправил его на QA, естественно с первого раза пофиксить такую ошибку не удаётся... А у тестера своя программа тестирования, он должен при тестировании билда проверить ещё 20 пунктов, которые мне совершенно не нужны. Короче ответ ты получаешь только на следующий день. Прошло полторы недели этого идиотизма (ну ещё и другие задачи выполнял параллельно, конечно), после чего уговорил тестера не заниматься дурогонией, а клацать только то, что мне нужно. В итоге он определил в чём баг за 20 минут, через 1,5 часа (включая эти 20 минут) ошибка была исправлена.
Вернёмся к нашим баранам.
Сюда же добавляем модульность построения (это та же идея с повторностью использования кода, но на более высоком уровне, - на уровне определённого функционала, а не процедуры). Ещё жёстче - Option Declare, ещё - отказаться от Variant в параметрах, где это только можно.
2. Хорошее документирование. Это важно для поддержания системы новыми сотрудниками.
Причём хорошая документация это не просто сгенеренная по комментам из кода или простое описание назначения полей, а отражающая архитектуру.
При таком подходе смысл авто-тестирования утрачивается. Остаётся только идеей "фикс" ("ох, а если бы!..") в некоторых головах.
Почему ещё лотусисты их избегают:
- затратно - тратится, как минимум, в 5 раз больше времени на написание теста, чем на разработку самого функционала; если же надо проверить логику процесса, как описал выше (с кучей юзеров, доков в разных БД и т.п.), то разработка такого теста превращается в мрак... Такое могут позволить себе ну очень богатые компании.
- при любом более-менее серьёзном рефакторинге ты привязан к тестам, - куча дополнительной работы, а тебя и так заказчики терзают...)
Как-то так. Может коллеги что подскажут.
P.S. О доводах по пользе тестов я в курсе; не надо. По большому счёту, тот базовый функционал и так протестирован годами, уже чуть ли не десятилетиями, так зачем на них тесты, если туда никто влазить и менять что-то уже не будет. В любом случае, при жёстком повторном использовании кода его качество гораздо выше, что опять же умаляет смысл тестов.
Лично видел две системы (не мои), где был даже написан весь функционал (классы) для авто-тестов, но идея так и сдохла по вышеуказанным причинам.
Всех с праздником!
[DOUBLEPOST=1462100706,1462100630][/DOUBLEPOST]
Причина 1. Отсутствие хорошей документации по разрабатываемым API (при уволившихся старых сотрудниках и при приёме новых - труба).
Причина 2. Отсутствие нормальных тимлидов, которые бы контролировали разрабатываемые API с точки зрения:
- модульного построения (каждая функция, класс или модуль выполняет только одну присущую ему функцию);
- повторного использования кода.
Или отсутствия времени/желания и т.д.
Компании быстро поняли, что качественный продукт - это долго, лучше заработать много денег и быстро. В итоге получаются ситуации, когда в компании мирового уровня (не буду показывать пальцами) под новую систему набирают 1500 (это реальная цифра!) программистов, которые работают группами по 10-15 человек в команде и не имеют никакого представления о том, что делает соседняя группа (какое API пишет, и можно ли его использовать). В таких условиях и появилась потребность в авто-тестировании. Так ты особо не связан наличием хорошей документации на API и уволившимися програмерами, которые знали архитектуру, и тебя не парит, что твоя система занимает гигабайты памяти (наоборот, с точки зрения маркетинга это хорошо - больше денег).
Как от этого можно уйти - ликвидировать то, что было описано выше, т.е.:
1. Ввести жёсткое правило повторного использования кода. К примеру в коде всей системы не должно быть множества NotesDocument.Save(), тем более с параметрами True, True (за это надо просто прибивать). Надо сделать функцию-обёртку, которая бы это делала. Ну может быть за исключение 1-2 случаев, где установлены другие параметры, но такие случаи должны быть тщательно документированы. Получается, что все обработчики соответствующих ошибок в одном месте, т.е. с этим проблема решена, - не нужно будет лазить в сотнях мест системы и повторно исправлять одни и те же ошибки.
Если вся система будет построена таким образом, то она будет постоянно тестировать сама себя. Поясню.
Любое прохождение документа по маршруту бизнес-процесса на самом деле будет использовать около 75% всего написанного кода. Если сидит тестер, который постоянно что-то тестит, то он при ошибке в коде с очень большой долей вероятности получит эту ошибку и сразу же скажет об этом разрабу, который сделает исправление тут же. Это и есть часть концепции экстремального программирования, но не того, что написано об этом сейчас (сейчас навалено всё в кучу: Scrum, Agile), а того, что подразумевалось в самом начале. А вначале в экстрим-программировании внутренние релизы для тестировщиков вообще не предусматривались. В этом и есть экстремальность, ну и скорость разработки. А сейчас почитаешь... куча умных слов, а отличие одной методологии от другой по сути в сроках поставки релизов...
Приведу пример. Когда-то устроился в одну контору, где использовался Scrum - при каком-либо изменении надо было выпускать внутренний релиз для QA. Т.к. самому нормально оттестить было долгим процессом (настроить юзерам определённые права, создать в разных БД разные документы, запустить документ по определённому маршруту, и где-то на 15-20-м шаге согласования была ошибка), то я создал билд и отправил его на QA, естественно с первого раза пофиксить такую ошибку не удаётся... А у тестера своя программа тестирования, он должен при тестировании билда проверить ещё 20 пунктов, которые мне совершенно не нужны. Короче ответ ты получаешь только на следующий день. Прошло полторы недели этого идиотизма (ну ещё и другие задачи выполнял параллельно, конечно), после чего уговорил тестера не заниматься дурогонией, а клацать только то, что мне нужно. В итоге он определил в чём баг за 20 минут, через 1,5 часа (включая эти 20 минут) ошибка была исправлена.
Вернёмся к нашим баранам.
Сюда же добавляем модульность построения (это та же идея с повторностью использования кода, но на более высоком уровне, - на уровне определённого функционала, а не процедуры). Ещё жёстче - Option Declare, ещё - отказаться от Variant в параметрах, где это только можно.
2. Хорошее документирование. Это важно для поддержания системы новыми сотрудниками.
Причём хорошая документация это не просто сгенеренная по комментам из кода или простое описание назначения полей, а отражающая архитектуру.
При таком подходе смысл авто-тестирования утрачивается. Остаётся только идеей "фикс" ("ох, а если бы!..") в некоторых головах.
Почему ещё лотусисты их избегают:
- затратно - тратится, как минимум, в 5 раз больше времени на написание теста, чем на разработку самого функционала; если же надо проверить логику процесса, как описал выше (с кучей юзеров, доков в разных БД и т.п.), то разработка такого теста превращается в мрак... Такое могут позволить себе ну очень богатые компании.
- при любом более-менее серьёзном рефакторинге ты привязан к тестам, - куча дополнительной работы, а тебя и так заказчики терзают...)
Как-то так. Может коллеги что подскажут.
P.S. О доводах по пользе тестов я в курсе; не надо. По большому счёту, тот базовый функционал и так протестирован годами, уже чуть ли не десятилетиями, так зачем на них тесты, если туда никто влазить и менять что-то уже не будет. В любом случае, при жёстком повторном использовании кода его качество гораздо выше, что опять же умаляет смысл тестов.
Лично видел две системы (не мои), где был даже написан весь функционал (классы) для авто-тестов, но идея так и сдохла по вышеуказанным причинам.
Всех с праздником!
[DOUBLEPOST=1462100706,1462100630][/DOUBLEPOST]
Да всё, что угодно) Надо гуглить материалы по авто-тестированию на Java.
из того с чем я сталкивался на ЛС - практически не используются классы...
причина - подготовка в коллективах разная
как результат - осложнение управления временем жизни переменных
обилие кода в формах - повальное зло, кот. породил вендор своим убогим редактором
тестирование этого всего (в части отладки) - очень неблагодарная задача
стараюсь выносить код из форм, в т.ч. - вынос вызова в скрытую кнопку на форме и вызов её через JS, коряво, а что делать (не плодить же копии кода для экшенов и формы)
с классами еще пресловутый Ctrl-Alt-L для выхода на строку ошибки (где та индусская сука - кот. догадалась изменять порядок ф-ци в дизайнере)
причина - подготовка в коллективах разная
как результат - осложнение управления временем жизни переменных
обилие кода в формах - повальное зло, кот. породил вендор своим убогим редактором
тестирование этого всего (в части отладки) - очень неблагодарная задача
стараюсь выносить код из форм, в т.ч. - вынос вызова в скрытую кнопку на форме и вызов её через JS, коряво, а что делать (не плодить же копии кода для экшенов и формы)
с классами еще пресловутый Ctrl-Alt-L для выхода на строку ошибки (где та индусская сука - кот. догадалась изменять порядок ф-ци в дизайнере)
Обучение наступательной кибербезопасности в игровой форме. Начать игру!