Перейти к содержимому

Фотография

Составление схемы состояний системы


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 14

#1 CyberRich

CyberRich

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 07 мая 2019 - 14:55

Здравствуйте!
 
Я являюсь разработчиком 1С, работаю в организации штатным программистом. У нас нет отдельных аналитиков, архитекторов, тестировщиков,
поэтому программисты понемногу занимаются всеми аспектами разработки. Для развития навыков именно в направлении тестирования я зарегистрировался
на этом форуме.
 
Вопрос мой состоит в следующем: есть довольно сложная система учета. Даже на отдельно взятом участке количество вариантов развития событий,
состояний, которые может принимать информационная сущность, слишком велико для удержания в памяти. 
Например, документ Интернет-заказ создается в системе и уже может иметь множество сочетаний значений свойств: у него есть вариант доставки, вариант оплаты,
время резерва, склад наличия и т.д. В зависимости от значений этих свойств, заказ может идти по множеству различных путей развития:
если заказ должен вовремя не предоплачен, а истекло время резерва, то резерв снимается, при этом время резерва зависит от нахождения в конкретном магазине.
Сама сумма предоплаты (полная/частичная) зависит от суммы заказа. Также от места нахождения товара и суммы заказа зависит, включена ли в стоимость
доставка. После оформления заказа его может отменить клиент, а может менеджер. В зависимости от того, была ли предоплата, может быть запущен
алгоритм ее возврата или заказ просто закрыт. Если при этом была предоплата доставки, она, в зависимости от того, передан ли заказ в ТК, она может быть
удержана или нет.
С каждым шагом количество вариантов развития событий растет и предусмотреть "в уме" все их, чтобы протестировать, очень сложно.
 
Так вот, есть ли в дисциплине тестирования ПО какие-то методики, позволяющие постепенно составить схему развития состояний системы, чтобы максимально
покрыть все варианты развития событий?
 
Извиняюсь, если сумбурно объясняю, я в тестировании, как в отдельной дисциплине, почти полный ноль.

  • 0

#2 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 07 мая 2019 - 15:11

секрет в том, что все варианты и не надо проверять, и максимально ничего не надо покрывать

 

проверяйте только важные места

 

ну а у вас вообще 1С - там всё должно и так работать. чем больше будете тестировать тем меньше денег получите


  • 0

#3 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 07 мая 2019 - 16:34

 

Так вот, есть ли в дисциплине тестирования ПО какие-то методики, позволяющие постепенно составить схему развития состояний системы, чтобы максимально

покрыть все варианты развития событий?

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

 

Что можно сделать:

- Для начала, отделить те проверки, которые не относятся к "развитию событий", а проверяют единовременное влияние каких-то условий ("Сама сумма предоплаты (полная/частичная) зависит от суммы заказа", "от места нахождения товара и суммы заказа зависит, включена ли в стоимость доставка" и т.п.)

- Проверка пользовательских сценариев. Сначала проходим основные сценарии, потом ищем возможные ответвления на каждом шаге и пишем для них отдельные сценарии. Сценарии покрывают наиболее реалистичные варианты развития событий.

- Если есть много времени и возможность делать подробные проверки, то да - можно нарисовать диаграмму состояний и пройти по ней все пути.  Только не нужно переусердствовать и включать туда всё, что есть в бизнесе. Нужно выделить какой-то ограниченный набор состояний. (Например, отдельно - статусы резервирования. Если какое-то действие приводит к переходу в следующий набор состояний, не относящийся к резервированию, то это будет последнее действие в тесте.) Способов обхода такой схемы множество. Например, отметить два состояния как "начальное" и "конечное" и сделать такой набор тестов, которые начинаются с "начального" и заканчиваются "конечным". При этом нужно, чтобы этот набор тестов покрывал все возможные переходы. Если начальных и конечных состояний несколько, то это не значит, что надо проходить от каждого к каждому, просто на конечных надо заканчивать. Также, разумеется, не надо покрывать переходы, которые уже проверены пользовательскими сценариями.

- Если нужно проверить, что разные действия приводят к разным последствиям в зависимости от набора входных параметров, а комбинаций с параметрами много, то включать все эти варианты в схему переходов не нужно. Ищите тему "таблица решений" или "decision table".


  • 1

#4 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 07 мая 2019 - 22:47

CyberRich, читаем Коберна про описание систем. Пробуем BPT. Через полгода забиваем болт, судя из вашего текущего состояния дел.
  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#5 CyberRich

CyberRich

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 08 мая 2019 - 06:01

 

- Если нужно проверить, что разные действия приводят к разным последствиям в зависимости от набора входных параметров, а комбинаций с параметрами много, то включать все эти варианты в схему переходов не нужно. Ищите тему "таблица решений" или "decision table".

 

Во, вот это может быть интересно, судя по тому, что пишет Википедия. Честно говоря, некоторое время назад "с нуля" додумался до чего-то подобного, но в сильно упрощенном варианте. Но, наверно, не поверил в эффективность и забросил. А если оказывается, что есть уже продуманная и разработанная методика, то следует поподробнее ее изучить. Спасибо за подсказку!


  • 0

#6 CyberRich

CyberRich

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 08 мая 2019 - 06:06

CyberRich, читаем Коберна про описание систем. Пробуем BPT. Через полгода забиваем болт, судя из вашего текущего состояния дел.

 

Подскажите, пожалуйста, что такое ВРТ ?


  • 0

#7 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 08 мая 2019 - 06:33

 

CyberRich, читаем Коберна про описание систем. Пробуем BPT. Через полгода забиваем болт, судя из вашего текущего состояния дел.

 

Подскажите, пожалуйста, что такое ВРТ ?

 

 

business process testing


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#8 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 08 мая 2019 - 06:36

 

 

- Если нужно проверить, что разные действия приводят к разным последствиям в зависимости от набора входных параметров, а комбинаций с параметрами много, то включать все эти варианты в схему переходов не нужно. Ищите тему "таблица решений" или "decision table".

 

Во, вот это может быть интересно, судя по тому, что пишет Википедия. Честно говоря, некоторое время назад "с нуля" додумался до чего-то подобного, но в сильно упрощенном варианте. Но, наверно, не поверил в эффективность и забросил. А если оказывается, что есть уже продуманная и разработанная методика, то следует поподробнее ее изучить. Спасибо за подсказку!

 

 

Для сложной бизнес-логики?) Интересно, что у вас получится, выложите сюда?


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#9 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 08 мая 2019 - 06:37

CyberRich, все таки, какую цель конечную преследуете?


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#10 CyberRich

CyberRich

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 08 мая 2019 - 07:51

CyberRich, все таки, какую цель конечную преследуете?

 

Преследую цель предусмотреть все способы работы с будущей программой. Чтобы сначала учесть их при написании, а затем - протестировать.

 

Как только система достигла определенной степени сложности, как снежный ком начало расти количество ситуаций, когда пользователи работают с программой так, как никто не предусмотрел. Хочется отойти от построения и удержания "в голове" всех возможных сценариев и освоить методику (если такая существует) нахождения всех сценариев работы системы, которые следует предусмотреть.


  • 0

#11 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 08 мая 2019 - 08:02

 

Здравствуйте!
 
Я являюсь разработчиком 1С, работаю в организации штатным программистом. У нас нет отдельных аналитиков, архитекторов, тестировщиков,
поэтому программисты понемногу занимаются всеми аспектами разработки. Для развития навыков именно в направлении тестирования я зарегистрировался
на этом форуме.
 
Вопрос мой состоит в следующем: есть довольно сложная система учета. Даже на отдельно взятом участке количество вариантов развития событий,
состояний, которые может принимать информационная сущность, слишком велико для удержания в памяти. 
Например, документ Интернет-заказ создается в системе и уже может иметь множество сочетаний значений свойств: у него есть вариант доставки, вариант оплаты,
время резерва, склад наличия и т.д. В зависимости от значений этих свойств, заказ может идти по множеству различных путей развития:
если заказ должен вовремя не предоплачен, а истекло время резерва, то резерв снимается, при этом время резерва зависит от нахождения в конкретном магазине.
Сама сумма предоплаты (полная/частичная) зависит от суммы заказа. Также от места нахождения товара и суммы заказа зависит, включена ли в стоимость
доставка. После оформления заказа его может отменить клиент, а может менеджер. В зависимости от того, была ли предоплата, может быть запущен
алгоритм ее возврата или заказ просто закрыт. Если при этом была предоплата доставки, она, в зависимости от того, передан ли заказ в ТК, она может быть
удержана или нет.
С каждым шагом количество вариантов развития событий растет и предусмотреть "в уме" все их, чтобы протестировать, очень сложно.
 
Так вот, есть ли в дисциплине тестирования ПО какие-то методики, позволяющие постепенно составить схему развития состояний системы, чтобы максимально
покрыть все варианты развития событий?
 
Извиняюсь, если сумбурно объясняю, я в тестировании, как в отдельной дисциплине, почти полный ноль.

 

https://www.bizagi.c...m-suite/modeler удобная, бесплатная тулза. Очень удобно делать схемы какраз для 1Сных проектов.

 

Схема переходов у вас обязательно должна быть. Не слушайте глумящихся... 


  • 2

#12 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 08 мая 2019 - 08:08

 вот вам примерчик.

Прикрепленные файлы


  • 0

#13 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 08 мая 2019 - 10:34

 

CyberRich, все таки, какую цель конечную преследуете?

 

Преследую цель предусмотреть все способы работы с будущей программой. Чтобы сначала учесть их при написании, а затем - протестировать.

 

Как только система достигла определенной степени сложности, как снежный ком начало расти количество ситуаций, когда пользователи работают с программой так, как никто не предусмотрел. Хочется отойти от построения и удержания "в голове" всех возможных сценариев и освоить методику (если такая существует) нахождения всех сценариев работы системы, которые следует предусмотреть.

 

Почитать "Туры" Виттакера. Если вы знаете свою систему, то "Туры" могут подсказать вам, что вы упустили


  • 0

#14 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 08 мая 2019 - 21:00

вот вам примерчик.


Картинка красивая, BPMN-нотация, для бизнес-аналитиков, сколько всего таких у вас, как с практической т.зр., в сопровождении, трудозатрат, тестировщикам нравится тестировать, картинка всегда актуальная, кто поддерживает, на какой стадии производства рисуете и кто?
  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#15 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 13 мая 2019 - 08:09

 

вот вам примерчик.


Картинка красивая, BPMN-нотация, для бизнес-аналитиков, сколько всего таких у вас, как с практической т.зр., в сопровождении, трудозатрат, тестировщикам нравится тестировать, картинка всегда актуальная, кто поддерживает, на какой стадии производства рисуете и кто?

 

если кратко, да =) 

 

поддерживает подрядчик с согласованием рук проекта, без таких картинок, к сожалению, невозможно сделать и поддерживать, даже среднесложные проекты оперативного и управленческого учёта организации. таких у меня несколько на каждую сущность в управленческом учёте. В сопровождении удобно. трудозатраты окупаются снижением необходимых доработок после первой итерации внедрения. тестировщиков нет, тестируем на бизнес пользователях =) (моя компания, что хочу то и делаю )) ) Рисуем на стадии предпроектного обследования, Рук проекта, доработка совместно с рук проектом подрядчиком.


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных