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





- - - - -

Тестирование и баги, смех...

Опубликовал: Иксилимьюз, 07 Май 2012 · 1 833 Просмотров

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

И за время тестирование уже возникла ни одна смешная ситуация, когда я думал что находил ошибку, после долгих поисков от куда ноги растут, выяснялось что все гораздо проще :)

1. Вижу на своем счету сумму скажем в 15 тыс тнг. У меня есть планируемые платежи (расходы), за стоянку (6000) и отдать долг (12000). Включаю в расчет эти самые планируемые платежи. И вижу что сумма на счету изменилась всего-то в пару тысячь. А? Как такое может быть? Механизм расчета идеально простой и просто не может ошибочно что-то посчитать. Арифметически не возможно! =) Но все равно лезу в код, лезу в базу, пытаюсь найти баг, делаем с Супругой пересчеты в экселе, под этим делом очень активно спорим размахивая руками, я не знаю в чем дело... Моя программа обвинена в глючности и не работоспособности. Я в отчаянии.. Целый день и целую ночь пытаюсь понять в чем же дело! О_о

В итоге, все оказалось куда проче чем я думал ! Я совсем забыл про то что зарплата моей супруги, тоже является планируемой. И так как это первая зарплата, она составляет 17 тыс. Но не в том суть..
Включаю я в расчет планируемые документы. Да к расходам прибавляется 6+12 = 18 тыс. Но и к приходам тоже прибавляется 17 тыс. И в итоге состояние счета изменяется буквально на тысячу с копейками, и создается впечатление что что-то считается не правильно.. А на самом деле просто затупил я =)

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

2. Заметил я разницу в суммах. Та сумма которая выводится в отчете по счету и та которая в главном окне модуля финансов, несколько отличаются. Примерно на 750 тнг... Я опять же замучился искать подвох. Ясное дело что дело в разности выборок. Но запросы и там и тут одинаковы. Фильтры идентичны. В чем дело? А??? Куда девались мои 750 тенге ? Как так? Записей уже в базе не мало, пробую хитрыми запросами вытащить разницу.. Никак..

В общем как только я не пытался выяснить в чем ошибка... Потом уже стал выполнять запросы и фильтры в специальном модуле где просто SQL запросы и табличка. И так и сяк.. Вижу что разница в 2 записи. Почему? Запросы ведь идентичны! Ну как так? Охх...
В общем все оказалось идеально просто. Сперва я добавил пару полей из одного запроса в другой, и добился идентичных результатов. Потом понял почему так.. Я по глупости использовал в запросах UNION вместо UNION ALL.
UNION выбрасывал из выборки одинаковые записи. Когда я добавил в запрос поле ID, эти строки стали разными и перестали выбрасываться из выборки.. А фактически рецепт таков : Переделать запросы на UNION ALL =) Всего лишь навсего)

А в целом, тестирование идет полным ходом, программа очень применима к жизни) После совершения любой покупки иду в программу и записываю расходы. Если кто-то из нас делает какой-то расход, запоминаем его и дома в любом случае заносим в базу. Я программу ношу на флешке и если что-то покупаю перекусить, прям на работе заношу свои расходы в базу) И таким образом у нас отрисован наш баланс, сколько потрачено и сколько есть фактически, и с учетом планируемых расходов и доходов. Это помогает нам понимать и видеть всю картину и не совершать лишних трат, ведь ясное дело что это не экономическая игра и взять судду или считерить - не выйдет :)

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

  • 0



а патча к недисциплинированным пользователям не планируется? :D

а то это ж какую силу воли надо иметь, чтобы не лениться каждый расход вносить :)
    • 0

а патча к недисциплинированным пользователям не планируется? :Dа то это ж какую силу воли надо иметь, чтобы не лениться каждый расход вносить :)


По сути не обязательно вносить каждый расход :) Это просто я такой педант, стремлюсь сделать так что бы фактические наличные копейка в копейку соответствовали тому что есть в базе данных )

Но фактически сама программа не обязывает к чему-то такому. Можно вносит только значимые для вас траты. Которые вы хотите помнить, что такого то числа, вы потратили столько то денег на такой то предмет. Будь то бензин или запчасти на машину или бытовая химия или что-то ещё... =)
А для учета затрат на машину будет в скором времене добавлены спец. инструменты. В частности для учета расхода ГСМ =)

А так в целом, ничего страшного не произойдет если в базе будет отражена лишь часть ваших расходов которую вы железно хотите зафиксировать, а какая-то часть повиснет в воздухе, но вы будете помнить в голове на что примерно у вас ушли эти деньги)

Расчеты по умолчанию производятся с начала месяца до конца месяца, и большой зависимости нет, от первого месяца к третьему =)
    • 0

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

может просто добавить фильтр списка "план/факт" чтоб документы двух разных типов в одной куче не висели

или добавить два фильтра булево:
птица план
птица факт
будут выводиться те документы тип которых в фильтре равен истина, т.о. можно как в куче так и отдельно тот или иной тип видеть
    • 1
Это тоже хороший вариант, тоже думал об этом. скорее всего сделаю :)
    • 0

Вижу на своем счету сумму скажем в 15 тыс тнг. У меня есть планируемые платежи (расходы), за стоянку (6000) и отдать долг (12000).

выходит что ты можешь видеть остаток на определённую дату?
а разворот движений по периодам (периоды в колонках) по различным статьям (статьи в строках) и сравнение в таком виде плана с фактом реализовано или намечается или не намечается?
    • 0

А для учета затрат на машину будет в скором времене добавлены спец. инструменты. В частности для учета расхода ГСМ =)

ты расходы на машину видишь именно с применением этих инструментов а если пользователь захочет видеть авторасходы например в таком виде
  • месячная сумма авторасходов = (годовой ГСМ + годовые Налоги и платежи + годовая страховка + годовое ТО + годовое проч. и проч.)/12
или
  • авторасходы на 1 км = (годовой ГСМ + годовые Налоги и платежи + годовая страховка + годовое ТО + годовое проч. и проч.)/20 000 км
  • и т.д. и т.п
то ты ведь не угадаешь как юзер захочет алгоритмизировать расчёт того или иного вида расходов - это с одной стороны
с другой стороны если на каждый вид расходов делать свои инструменты, получится калейдоскоп инструментов, который например я, даже при наличии желания, не смог бы запомнить

может сделать один универсальный инструмент например "конструктор расходов" который уже позволить создавать шаблоны алгоритмов применимых к тем или иным типам расчётов? это конечно сложнее, но зато универсальнее))
    • 0

Вижу на своем счету сумму скажем в 15 тыс тнг. У меня есть планируемые платежи (расходы), за стоянку (6000) и отдать долг (12000).

выходит что ты можешь видеть остаток на определённую дату?а разворот движений по периодам (периоды в колонках) по различным статьям (статьи в строках) и сравнение в таком виде плана с фактом реализовано или намечается или не намечается?

Крутая схема )) На данном этапе такой возможности нет. Надо будет подумать как такое можно сделать.
По сути есть услово скажем таблица, в которой есть строки с датами. суммами, статьями, и с этим добром можно делать все что угодно, писать всякие хитрые запросы и получать нужные результаты. Ну то есть я думаю что вообще такой отчет возможно будет сделать в будущем. Но пока такой фичи нет.
    • 0

может сделать один универсальный инструмент например "конструктор расходов" который уже позволить создавать шаблоны алгоритмов применимых к тем или иным типам расчётов? это конечно сложнее, но зато универсальнее))


если ты не понимаешь о чём я, то взгляни на справочник "спецификации номенклатуры" (= конструктор расходов) использование этого справочника (спецификации) можно посмотреть как в справке так и в коде следующих объектов:
  • обработка "расчёт плановой себестоимости"
  • документ "отчёт производства за смену"
  • обработка "помощник планирования"
    • 1

может сделать один универсальный инструмент например "конструктор расходов" который уже позволить создавать шаблоны алгоритмов применимых к тем или иным типам расчётов? это конечно сложнее, но зато универсальнее))

если ты не понимаешь о чём я, то взгляни на справочник "спецификации номенклатуры" (= конструктор расходов) использование этого справочника (спецификации) можно посмотреть как в справке так и в коде следующих объектов:
  • обработка "расчёт плановой себестоимости"
  • документ "отчёт производства за смену"
  • обработка "помощник планирования"

Спасибо за ссылки на объекты. Надо будет глянуть как там и что. И вполне возможно что получится реализовать что-нибудь подобное.
Я всегда за универсальность, чем универсальнее тем лучше) Главное придумать способ :)
    • 0

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

мхм, именно, но кроме того что можно всё это выводить в некий универсальный отчёт в котором ты сможешь настраивать условия отбор и вид отчёта
кроме этого для пользователя по любому необходимо предусмотреть парочку стандартных отчётов уже с гораздо более узкими возможностями настройки
    • 0

Спасибо за ссылки на объекты. Надо будет глянуть как там и что.

да не за что, обращайся
когда будешь смотреть рекоммендую не полениться и вначале досконально почитать справку по спецификациям и по тем объектам где она используется, и только потом уже лезть в конфу)))
    • 0

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


Для пользователей сейчас доступен один единственный отчет. Называется состояние счета.
Что с его помощью можно сделать?
Задать диапазон дат, в пределах которого будем смотреть операции приходов, расходов и переводов. По умолчанию берется текущий месяц, с первого числа по последнее число месяца.

Галочка "Учитывать планируемые документы." Если поставить. Увидим так же и планируемые операции.

Далее, выбираем из списка счет. И видим все операции по этому счету. Имеется ввиду (основной счет, копилка, счет в банке)

И видим пелену приходов, расходов, и переводов.
при желании можно так же выбрать типы операций (статьи) которые мы хотим посмотреть. И тогда увидим только расходы принадлежащие конкретной статье..

Все. На текущий момент это единственный отчет. Он просто помогает просмотреть, когда, куда и на что.

Разумеется это базовый и первый, самый необходимый. В дальнейшем по ходу развития программы, количество отчетов будет увеличиваться, по мере поступления предложений, появления необходимостей и т.п.
    • 0

а патча к недисциплинированным пользователям не планируется? :Dа то это ж какую силу воли надо иметь, чтобы не лениться каждый расход вносить :)

По сути не обязательно вносить каждый расход :) Это просто я такой педант

частично согласен с topcraze,
если ввод данных доступен только на десктопе то это усложняет возможность быть педантичным даже если есть желание быть педантичным.
возможно на будущее стоит предусмотреть облачную архитектуру приложения, для того чтобы разместив приложение на сервере, сделать доступ для пользователей через тонкий клиент (веб интерфейс) дабы можно было заходить с мобильных устройств
по архитектуре БД не рискну чтото предлагать.
    • 0
кстати, XIO, а блок-схемы нет?
    • 0

частично согласен с topcraze,если ввод данных доступен только на десктопе то это усложняет возможность быть педантичным даже если есть желание быть педантичным.возможно на будущее стоит предусмотреть облачную архитектуру приложения, для того чтобы разместив приложение на сервере, сделать доступ для пользователей через тонкий клиент (веб интерфейс) дабы можно было заходить с мобильных устройствпо архитектуре БД не рискну чтото предлагать.


В будущем такая возможность есть. Но тут много ньюансов.

Во первых тут две перспективы. Приобретать лицензию на среду в которой сейчас все это разработано. Если выходить на высокий масштаб. Либо все переписывать на другом языке со свободной лицензией. Это один момент.

Во вторых, если все таки приобрести лицензию и отказаться от некоторых шиков, то есть возможность портнуть весь проект на вэб интерфейс. Единственно тут придется конечно полностью пересмотреть СУБД и некоторые моменты безопасности. Это уже большая работа и ответственность. Так как не думаю что кому-то понравится что его сосед хаккер прознает сколько денег он тратит на мебель, к примеру =)

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

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

И по сути идея с он-лайн сервисом мне очень импонирует, была бы лицензия уже сейчас начинал бы в серьез о ней задумываться, но пока лишь мечты и планы)) Время все расставит на свои места :)
    • 0

кстати, XIO, а блок-схемы нет?


Инструментами Access легко можно построить схему связей таблиц =) Могу накидать и поделиться )
    • 0
Ксиочка, а мне можешь построить связи в аксессе? я совсем запамятовала как это делается(((
    • 0

была бы лицензия уже сейчас начинал бы в серьез о ней задумываться

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

Инструментами Access легко можно построить схему связей таблиц =) Могу накидать и поделиться )

Ксиочка, а мне можешь построить связи в аксессе? я совсем запамятовала как это делается(((

если я вас правильно понял, в аксесе есть средства визуализации связей?
    • 0
Tatusha, могу напомнить как это делается))) Показать ) Навести) Обращайся)

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

В Аксессе да, есть такое понятие как схема данных. С её помощью можно визуально построить связи таблиц, но правда не знаю как это повлияет на работоспособность. То есть не помню точно, есть ли возможность с помощью СУБД реализовать каскадное удаление и прочие прелести полноценной реляционной БД =)
    • 0
Ксио, скайпану тебе)))

Нежилец, ты че на меня наехать решил??? Такими непонятными словами)))
    • 0

Поиск по блогу

Декабрь 2016

П В С Ч П С В
   1234
5 6 7891011
12131415161718
19202122232425
262728293031 

пользователей просматривает

0 пользователей, 0 неизвестных прохожих, 0 скрытых пользователей

X

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

© 2011-2016 vse.kz. При любом использовании материалов Форума ссылка на vse.kz обязательна.