Помогите пожалуйста найти методологическую информацию которая бы описывала какие действия необходимо выполнить пользователю в Предприятии чтобы проверить корректность работы механизмов, разработанных согласно конкретному техническому заданию (ТЗ). Например в ТЗ разрабатывался документ "Списание товаров" значит надо выполнить проверить что, например:
При нажатии на кнопку Заполнить:
- остатки товаров в таблице такие же, как их выдаёт отчёт по остаткам на ту же дату и с теми же отборами
- учитывается момент времени документа и в остатках нет товаров списанных в ту же секунду другим документом
При проведении документ:
- ругается что нет остатков
- учитывает при этом что один и тот же товар может быть в нескольких строках
- нет "проблемы копеек"
В интернете полно материала который говорит какими инструментами/ программами можно выполнить автоматизированное тестирование но не могу найти информацию которая бы говорила какие сценарии надо писать в скриптах. Понятно, что проверяя механизм который выполняет "а+б=в" мы пишем тест который вбивает значения в поля "а" и "б", вызывает событие изменения этих элементов и проверяет чтобы в поле "в" было значение, которое тестер заранее рассчитал по этой же формуле. Хотелось бы подойти к тестированию более научно и систематизировано, например как в описано в приложении к тестированию на Специалиста где есть таблицы с типовыми ошибками которые допускают, например, при решении задач на регистрах накопления.
Пробежался по названиям книг от 1С но не нашёл материала на тему того как именно придумывать тесты на ту или иную ситуацию.
При нажатии на кнопку Заполнить:
- остатки товаров в таблице такие же, как их выдаёт отчёт по остаткам на ту же дату и с теми же отборами
- учитывается момент времени документа и в остатках нет товаров списанных в ту же секунду другим документом
При проведении документ:
- ругается что нет остатков
- учитывает при этом что один и тот же товар может быть в нескольких строках
- нет "проблемы копеек"
В интернете полно материала который говорит какими инструментами/ программами можно выполнить автоматизированное тестирование но не могу найти информацию которая бы говорила какие сценарии надо писать в скриптах. Понятно, что проверяя механизм который выполняет "а+б=в" мы пишем тест который вбивает значения в поля "а" и "б", вызывает событие изменения этих элементов и проверяет чтобы в поле "в" было значение, которое тестер заранее рассчитал по этой же формуле. Хотелось бы подойти к тестированию более научно и систематизировано, например как в описано в приложении к тестированию на Специалиста где есть таблицы с типовыми ошибками которые допускают, например, при решении задач на регистрах накопления.
Пробежался по названиям книг от 1С но не нашёл материала на тему того как именно придумывать тесты на ту или иную ситуацию.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Так это надо в теорию тестирования погружаться, она универсальна, там как раз систематизированно расказывается, как тестировать продукты. 1С это или не 1С - не важно.
Совсем уж кратко можно, напрмер, вот или почитать.
Пробежался по названиям книг от 1С но не нашёл материала на тему того как именно придумывать тесты на ту или иную ситуацию.
Так это надо в теорию тестирования погружаться, она универсальна, там как раз систематизированно расказывается, как тестировать продукты. 1С это или не 1С - не важно.
Совсем уж кратко можно, напрмер, вот или почитать.
(1) Есть такое понятие, как ожидаемое поведение системы. Которое как раз и заключается в том, что с заказчиком прорабатывается конечный вариант поведения системы. Т.е. на этапе проработки ТЗ и описывается ситуация типа "Нажал на большую кнопку и Вашингтону пипец".
А не после разработки.
А не после разработки.
(1) фактически это нигде не описывается прямо под конкретные случаи, все в общем виде подается и каждый раз индивидуально подгоняется под свой случай
вот вы сейчас уже почти все описали, что должен проверить пользователь в части - что я должен получить на выходе и чего не должно случиться
а так, есть ТЗ, есть понимание какие результаты должны получиться, что не должно быть и какие отчеты для проверки результата следует использовать (при необходимости)
и собственно пишите методичку с порядком действий пользователя, можно прямо по ТЗ для начала как-то так
1. открыть док
2. заполнить шапку док
3. заполнить строки док
3.1 должны быть строки с одинаковым товаром
3.2 должны быть строки с копейками в суммах
4. записать док
5 провести док
6. проверить проведение док по регистрам таким-то
7. выполнить отчет такой-то с регистратром док
8. выполнить отчет такой-то без регистратора док
отчеты должны показать правильные данные с учетом "проблемы копеек"
на каждом этапе не должно быть ошибок
в случае ошибки, тестирование прерывается на этапе ошибки, с описанием действий приведших к ней передается разработчику
вот вы сейчас уже почти все описали, что должен проверить пользователь в части - что я должен получить на выходе и чего не должно случиться
а так, есть ТЗ, есть понимание какие результаты должны получиться, что не должно быть и какие отчеты для проверки результата следует использовать (при необходимости)
и собственно пишите методичку с порядком действий пользователя, можно прямо по ТЗ для начала как-то так
1. открыть док
2. заполнить шапку док
3. заполнить строки док
3.1 должны быть строки с одинаковым товаром
3.2 должны быть строки с копейками в суммах
4. записать док
5 провести док
6. проверить проведение док по регистрам таким-то
7. выполнить отчет такой-то с регистратром док
8. выполнить отчет такой-то без регистратора док
отчеты должны показать правильные данные с учетом "проблемы копеек"
на каждом этапе не должно быть ошибок
в случае ошибки, тестирование прерывается на этапе ошибки, с описанием действий приведших к ней передается разработчику
(5)
(5)
В том то и дело, что куча специалистов не первый год работают и получают хорошие продукты, а систематизации знаний нет. Самые организованные, наверняка, пользуются автоматизированным тестированием и, натыкаясь на конкретные проблемы в продакшене, пополняют список сценариев, чтобы ситуация не произошла ещё раз. А вот давайте попробуем поставить себе такую недостижимую цель, что мы выпустим продукт без ошибок! Научным способом мы заранее просчитаем все ситуации и предугадаем их!
В Вашем примере Вы описываете некий сценарий работы, но, не понятно, из каких правил исходит именно такой сценарий. Ну например почему "открыть док" а не "создать док"? Когда нужно только открыть а когда и создать? Хотелось бы чтобы тесты были достаточны и не избыточны. Вот пункт "3.1 должны быть строки с одинаковым товаром", вот с чего Вы взяли что это надо сделать? Вы это сделали неосознанно или знаете какую ошибку Вы пытаетесь поймать и почему именно в этой ситуации она может возникнуть. Например при "Поступлении товаров" строки с одинаковым товаром не вызовут никаких проблем (ну да, будет в регистре 2 записи) так зачем там это проверять?
(5)
Боюсь, что придётся это делать, но очень хотелось бы найти готовое и обкатанное. Ведь есть требования при сдаче экзамена "Специалист" и даже больше, есть "1С стандарты разработки", они описывают "как должно быть" а их бы взять и преобразовать в "какие тесты выполнить чтобы убедиться что требование соблюдается". Чувствуете разницу? Надо к каждому требованию дописать правило тестирования соблюдения этого требования, что-то в этом духе.
Может кто знает как передать заявку наверх в 1С или авторам составителям учебников? Наличие такой систематизированной методики реально бы подняло качество продуктов не меньше, чем сертификация специалистов и продуктов. Кстати, интересно, как сам 1С проводит тестирование, когда выдаёт "1С Совместимо"? Только соответствие кода стандартам при помощи АПК (Автоматизированная проверка конфигураций) или вводят тестовые примеры? Если вводят примеры то исходя из каких соображений?
фактически это нигде не описывается прямо под конкретные случаи
(5)
есть понимание какие результаты должны получиться
В том то и дело, что куча специалистов не первый год работают и получают хорошие продукты, а систематизации знаний нет. Самые организованные, наверняка, пользуются автоматизированным тестированием и, натыкаясь на конкретные проблемы в продакшене, пополняют список сценариев, чтобы ситуация не произошла ещё раз. А вот давайте попробуем поставить себе такую недостижимую цель, что мы выпустим продукт без ошибок! Научным способом мы заранее просчитаем все ситуации и предугадаем их!
В Вашем примере Вы описываете некий сценарий работы, но, не понятно, из каких правил исходит именно такой сценарий. Ну например почему "открыть док" а не "создать док"? Когда нужно только открыть а когда и создать? Хотелось бы чтобы тесты были достаточны и не избыточны. Вот пункт "3.1 должны быть строки с одинаковым товаром", вот с чего Вы взяли что это надо сделать? Вы это сделали неосознанно или знаете какую ошибку Вы пытаетесь поймать и почему именно в этой ситуации она может возникнуть. Например при "Поступлении товаров" строки с одинаковым товаром не вызовут никаких проблем (ну да, будет в регистре 2 записи) так зачем там это проверять?
(5)
пишите методичку
Боюсь, что придётся это делать, но очень хотелось бы найти готовое и обкатанное. Ведь есть требования при сдаче экзамена "Специалист" и даже больше, есть "1С стандарты разработки", они описывают "как должно быть" а их бы взять и преобразовать в "какие тесты выполнить чтобы убедиться что требование соблюдается". Чувствуете разницу? Надо к каждому требованию дописать правило тестирования соблюдения этого требования, что-то в этом духе.
Может кто знает как передать заявку наверх в 1С или авторам составителям учебников? Наличие такой систематизированной методики реально бы подняло качество продуктов не меньше, чем сертификация специалистов и продуктов. Кстати, интересно, как сам 1С проводит тестирование, когда выдаёт "1С Совместимо"? Только соответствие кода стандартам при помощи АПК (Автоматизированная проверка конфигураций) или вводят тестовые примеры? Если вводят примеры то исходя из каких соображений?
(9) ))) вот мне всегда в таких случая вспоминается анектод "ты за кого, за меня или за медведя?"
я пример написал исходя из описания задачи
в задаче
отсюда и возникает тест со строкам одинаковой номенклатуры
сценарное тестирование пишется под задачу
хотите все охватить, не вопрос, никто не мешает, но это будет непосильная задача
лучше разбивать ее на пачку мелких тестов, можно их кстати выполнять как отдельно, так и последовательно
как сейчас 1С проверяет на совместимо, не знаю
раньше было просто соответствие кода стандартам
код соответствует стандартам совместимо - все ок, дальше сами разбирайтесь
но раз проверка глобально не менялась несколько лет, скорее всего сейчас тоже самое, я лично не вижу смысла в чужой продукт так глубоко лезть и какие-то тесты для него писать
помнится, сдавал я специалиста (давно это было), там были требования
потом сдавал коллега, все ему рассказал, но все зря, требования поменялись
это я к чему...
требования будут всегда меняться, сделать на их основе что-то концептуальное можно, по поддерживать актуальность будет сложно
я пример написал исходя из описания задачи
в задаче
- учитывает при этом что один и тот же товар может быть в нескольких строках
отсюда и возникает тест со строкам одинаковой номенклатуры
сценарное тестирование пишется под задачу
хотите все охватить, не вопрос, никто не мешает, но это будет непосильная задача
лучше разбивать ее на пачку мелких тестов, можно их кстати выполнять как отдельно, так и последовательно
как сейчас 1С проверяет на совместимо, не знаю
раньше было просто соответствие кода стандартам
код соответствует стандартам совместимо - все ок, дальше сами разбирайтесь
но раз проверка глобально не менялась несколько лет, скорее всего сейчас тоже самое, я лично не вижу смысла в чужой продукт так глубоко лезть и какие-то тесты для него писать
Ведь есть требования при сдаче экзамена "Специалист" и даже больше, есть "1С стандарты разработки", они описывают "как должно быть" а их бы взять и преобразовать в "какие тесты выполнить чтобы убедиться что требование соблюдается"
помнится, сдавал я специалиста (давно это было), там были требования
потом сдавал коллега, все ему рассказал, но все зря, требования поменялись
это я к чему...
требования будут всегда меняться, сделать на их основе что-то концептуальное можно, по поддерживать актуальность будет сложно
(10)
Тоже люблю применять этот анекдот на работе)
(10)
Считаю что этого не должно быть в описании задачи. В теме я описал примеры тестов. Понимание того, как правильно надо было задавать вопрос, приходит с поступлением уточняющих вопросов, за что отдельное Спасибо всем, кто внёс свои комментарии. А так считаю что не правильно в каждом ТЗ описывать все стандарты и методики. В конце концов клиент нанимает нас чтобы он высказал желание а мы его грамотно реализовали. Мы же перекладываем часть ответственности на клиента, обговаривая какие-то нюансы и потом ссылаемся на них в случае неудачи что мы мол это не закладывали. Ответственность на клиента надо перекладывать в плане того, что софт должен или не должен уметь, а вот как сделать чтобы всё было ОК это уже наша забота. Вот представьте что я или Вы лично оформили договор с фирмой на постройку дома, неужели мы при этом должны отвечать за марку цемента который они будут использовать? Мы требуем количество этажей и срок службы и если конструкция падает то это не наши проблемы как заказчика.
(10)
Само собой задачи как по разработке, так и по тестированию, надо дробить, но вот есть такой пример что надо остатки получать при проведении не на дату, а на момент времени, и нет какого-то мелкого куска кода, анализируя который можно было бы сказать, что под него надо сделать такой тест. Это только набиванием шишек или чтением стандартов. Но тут примерно как в обучении вождению: есть книга с правилами, которую читаешь и вроде всё понятно а вот решать билеты это уже совсем другое, не говоря уже о живой езде.
(10)
Ну тогда под этим статусом может скрываться совсем неработоспособный продукт, но зато как красиво оформлен код)
Кстати часть важных требований как раз узнал из требований к экзамену на Специалиста. Сдал 2 года назад, до этого лет 7 назад пытался и безрезультатно. Действительно поменялись требования к оформлению запросов, появилась "новая методика проведения", но вот ошибочные ситуации, которые код должен правильно обрабатывать, остались те же. И в принципе других и быть не может, пусть даже софт будет написан, например на SAP или FoxPro, ведь тестируется логическая составляющая работоспособности системы учёта.
ты за кого, за меня или за медведя
Тоже люблю применять этот анекдот на работе)
(10)
я пример написал исходя из описания задачи
Считаю что этого не должно быть в описании задачи. В теме я описал примеры тестов. Понимание того, как правильно надо было задавать вопрос, приходит с поступлением уточняющих вопросов, за что отдельное Спасибо всем, кто внёс свои комментарии. А так считаю что не правильно в каждом ТЗ описывать все стандарты и методики. В конце концов клиент нанимает нас чтобы он высказал желание а мы его грамотно реализовали. Мы же перекладываем часть ответственности на клиента, обговаривая какие-то нюансы и потом ссылаемся на них в случае неудачи что мы мол это не закладывали. Ответственность на клиента надо перекладывать в плане того, что софт должен или не должен уметь, а вот как сделать чтобы всё было ОК это уже наша забота. Вот представьте что я или Вы лично оформили договор с фирмой на постройку дома, неужели мы при этом должны отвечать за марку цемента который они будут использовать? Мы требуем количество этажей и срок службы и если конструкция падает то это не наши проблемы как заказчика.
(10)
лучше разбивать ее на пачку мелких тестов
Само собой задачи как по разработке, так и по тестированию, надо дробить, но вот есть такой пример что надо остатки получать при проведении не на дату, а на момент времени, и нет какого-то мелкого куска кода, анализируя который можно было бы сказать, что под него надо сделать такой тест. Это только набиванием шишек или чтением стандартов. Но тут примерно как в обучении вождению: есть книга с правилами, которую читаешь и вроде всё понятно а вот решать билеты это уже совсем другое, не говоря уже о живой езде.
(10)
раньше было просто соответствие кода стандартам
Ну тогда под этим статусом может скрываться совсем неработоспособный продукт, но зато как красиво оформлен код)
Кстати часть важных требований как раз узнал из требований к экзамену на Специалиста. Сдал 2 года назад, до этого лет 7 назад пытался и безрезультатно. Действительно поменялись требования к оформлению запросов, появилась "новая методика проведения", но вот ошибочные ситуации, которые код должен правильно обрабатывать, остались те же. И в принципе других и быть не может, пусть даже софт будет написан, например на SAP или FoxPro, ведь тестируется логическая составляющая работоспособности системы учёта.
(11)
вот тут не соглашусь
ранее (когда был молодым, наивным и бессмертным) сам продвигал тему, что надо за клиента решать если не все, то многое, а заказчик должен только сказать: "хочу большую красную кнопку"
часто это приводил к таким результатам - моя картинка любимая
сейчас же понимаю, что это неверный подход, клиент должен иметь хотя бы начальное представление что и как делается (не имеет, надо уметь его погрузить или привлечь того, кто будет хоть немного понимать о чем вообще я говорю)
а потому четкое описание границ дозволенного при решении задачи и рамки бюджета, и клиент активно привлекается как для контроля, так и для пояснений что и как сделано, планируется сделать, и погружение клиента в разработку
ведь если я, как заказчик дома (или мой представитель), не буду знать, что цемент марки 200 лучше, чем марки 60, то мне его и впарят, а дом потом тупо развалится
Мы же перекладываем часть ответственности на клиента, обговаривая какие-то нюансы и потом ссылаемся на них в случае неудачи что мы мол это не закладывали. Ответственность на клиента надо перекладывать в плане того, что софт должен или не должен уметь, а вот как сделать чтобы всё было ОК это уже наша забота. Вот представьте что я или Вы лично оформили договор с фирмой на постройку дома, неужели мы при этом должны отвечать за марку цемента который они будут использовать?
вот тут не соглашусь
ранее (когда был молодым, наивным и бессмертным) сам продвигал тему, что надо за клиента решать если не все, то многое, а заказчик должен только сказать: "хочу большую красную кнопку"
часто это приводил к таким результатам - моя картинка любимая
сейчас же понимаю, что это неверный подход, клиент должен иметь хотя бы начальное представление что и как делается (не имеет, надо уметь его погрузить или привлечь того, кто будет хоть немного понимать о чем вообще я говорю)
а потому четкое описание границ дозволенного при решении задачи и рамки бюджета, и клиент активно привлекается как для контроля, так и для пояснений что и как сделано, планируется сделать, и погружение клиента в разработку
ведь если я, как заказчик дома (или мой представитель), не буду знать, что цемент марки 200 лучше, чем марки 60, то мне его и впарят, а дом потом тупо развалится
(2)
Хочу абстрагироваться от того, кто и в каких целях разрабатывает продукт. На входе имеем только то, что есть некий оператор, который понимает, что должна делать система, и ему надо подстроить всякие пакостные ситуации, на которые программа должна выдать правильный результат. Пакостные ситуации оператор может создать:
1) Работая с программой строго по инструкции, в указанном порядке заполняя поля, но при этом может словить баг;
2) Работая не по порядку (вроде называется методом "чёрного ящика"), рандомно нажимая кнопки и проверяя, не вылетит ли какая-то ошибка, системная или в расчётах;
3) Сверяя данные, рассчитанные программой по некой формуле, с эталонными значениями.
4) Понимая, какое действие выполняет система, подстроить ей конкретную каверзную ситуацию. Делает расход из регистра, значит давай внесём количество расход больше чем остаток. Ругается на ошибку с остатками, а что если товар будет в 2-х строках по 2 еденицы, при остатке 3? Регистр хранит не только количество но и сумму, а давай в остатках будет сумма=10 и количество=3, в документ внесём 3 и проверим не останется ли после расхода количество = 0 и сумма = 0.01.
Меня сейчас конкретно интересует 4) методология тестирования. Хотелось бы найти материал по неким темам, чтобы, имея конкретный функционал, пробежаться по этим темам и посмотреть, относится ли эта тема к текущему функционалу, если да то прогнать функционал через конкретные каверзные данные.
Пока что непонятен требуемый конечный результат.
Хочу абстрагироваться от того, кто и в каких целях разрабатывает продукт. На входе имеем только то, что есть некий оператор, который понимает, что должна делать система, и ему надо подстроить всякие пакостные ситуации, на которые программа должна выдать правильный результат. Пакостные ситуации оператор может создать:
1) Работая с программой строго по инструкции, в указанном порядке заполняя поля, но при этом может словить баг;
2) Работая не по порядку (вроде называется методом "чёрного ящика"), рандомно нажимая кнопки и проверяя, не вылетит ли какая-то ошибка, системная или в расчётах;
3) Сверяя данные, рассчитанные программой по некой формуле, с эталонными значениями.
4) Понимая, какое действие выполняет система, подстроить ей конкретную каверзную ситуацию. Делает расход из регистра, значит давай внесём количество расход больше чем остаток. Ругается на ошибку с остатками, а что если товар будет в 2-х строках по 2 еденицы, при остатке 3? Регистр хранит не только количество но и сумму, а давай в остатках будет сумма=10 и количество=3, в документ внесём 3 и проверим не останется ли после расхода количество = 0 и сумма = 0.01.
Меня сейчас конкретно интересует 4) методология тестирования. Хотелось бы найти материал по неким темам, чтобы, имея конкретный функционал, пробежаться по этим темам и посмотреть, относится ли эта тема к текущему функционалу, если да то прогнать функционал через конкретные каверзные данные.
(3) Спасибо за ссылки. Понятно, что есть общая теория, но не хотелось бы в неё углубляться а найти сразу что-то более узкоспециализированное. Ну например есть же общая теория по построению клиентских приложений, а есть более узкая теория конкретно о том как создавать удобные формы, а есть ещё более узкая теория, описанная в книге от 1С "Разработка управляемого интерфейса".
Конечно, если не найдётся что-то из области тестирования именно по 1С, то сойдёт и материал который будет описывать тестирование некой абстрактной системы финансового учёта, написанной на любом языке программирования. Ну а если не найдётся и такого то придётся знакомиться с полным курсом абстрактной теории и в этом и предыдущем случае придётся составлять некую методичку, чтобы потом было проще пользоваться как самому, так и передать коллегам.
Было бы намного проще если бы эти правила были описаны под 1С:Предприятие и там бы упоминались конкретно термины: проведение, регистр, ... Не хотелось бы читать как тестировать, например, корректность технических пакетов, лежащих на самом низком уровне модели ISO/OSI, и думать как эти принципы применить к 1С.
Конечно, если не найдётся что-то из области тестирования именно по 1С, то сойдёт и материал который будет описывать тестирование некой абстрактной системы финансового учёта, написанной на любом языке программирования. Ну а если не найдётся и такого то придётся знакомиться с полным курсом абстрактной теории и в этом и предыдущем случае придётся составлять некую методичку, чтобы потом было проще пользоваться как самому, так и передать коллегам.
Было бы намного проще если бы эти правила были описаны под 1С:Предприятие и там бы упоминались конкретно термины: проведение, регистр, ... Не хотелось бы читать как тестировать, например, корректность технических пакетов, лежащих на самом низком уровне модели ISO/OSI, и думать как эти принципы применить к 1С.
(4) Согласен что о тестировании надо думать в момент проектирования а не пост фактум. Но представим себе что клиента, как такового, нет, мы разрабатываем продукт с нуля и хотим его выкатить на рынок готовым. Да и при работе с клиентом считаю непрофессиональным возлагать ответственность за тестирование на клиента. Конечно тут можно долго спорить, но из приведённого мною примера в теме, клиент должен понимать только что документ "Списание товаров" должен уметь уменьшать количество остатков а разработчик, как профессионал своего дела, должен всегда помнить о "проблеме копеек", когда на основании количества по средней стоимости уходит сумма и если ушло всё количество то должна уйти и вся сумма.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот