В данном случае интересно вот что - вы сами знаете, что данные "нежизненные"?

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

И у вас есть возможность получить и проверить правильные боевые данные?

думаю, я ответил ранее. Да , конечно.

Можно ли спросить у пользователей - насколько эти данные далеки от действительности?

Нет, непосредственно с пользователем мы не общаемся. Наш интерфейс общения с ними - аналитики.

Про тестирование космоса вам именно говорят или это вписано в багобазу в качестве ответа на данную ошибку?

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

А что именно вы тестируете? Я надеюсь, что не финансовые документы с таким округлением?:)

Это аналитический отчет. Если бы это было в финансовом документ. Я бы сюда не писал, а просто блокировал бы выпуск релиза :)

Тема вопроса, прав ли руководитель, советующий (приказывающий) мне не тестировать космос (т.е. заведомо некорректные данные) или я, как истинный тестировщик, который тестирует разные ситуация, возможные и невозможные, но которые явно приводят к ошибке?

1. Ошибку надо записывать всегда
2. Приоритет её определяет менеджер, как и дальнейшую работу по ней
3. Разработчик должен просыпаться в холодном поту с мыслью, что в его коде есть ошибка (в каждой шутке есть доля шутки).

1. ошибка записана.
2. была проанализирована, приоритет понижен, в моем расписании я вновь начал ее продвигать
3. скромно промолчу ...

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

В исходных данных стоит 0,325 или 0.375
в отчете может отображаться
- 0.32 0.38
- 0.32 0.37
- 0.33 0.38
- 0.33 0.37

Простите за дурацкий вопрос, а у вас это происходит именно при одинаковых входных данных, как описано в примере? Потому что если 3.75 округляется до 3.8, и 3.85 округляется до 3.8, то это правильно для финансового отчета - пятерка округляется к четному числу.

Спрашиваю просто на всякий случай, а то мало ли.

Да нет, там странное поведение, то идет округление по математическим правилам, то идет просто отсекание третьего знака. Т.е. проблема в том, что поведение не регулярное и не понятное.

Я получил такой ответ от руководства.

- У пользователей не может быть данных с тремя знаками после запятой. Если эти данные у них появились - это проблемы пользователей. Мы потратили достаточное количество времени на выяснение данной проблемы, она не стоит этого. Потому прошу(приказываю) привести тестируемые данные к значению с точностью до двух знаков. Ошибка устранятся будет возможно в будущем (=не будет). Тему закрыть.

Коллеги,

хотел спросить у вас, возникают ли подобные "конфликты" у вас и как они решаются? Кто прав, кто лев?

Ситуация:
имеется ошибка, связанная с округлением при представлении данных в отчете.
Ошибка проявляется в том, что произвольным образом от прогона к прогону в невыявленной закономерности происходит то округление, то усекание.

В отчете стоит точность отображения ранвая 2 знакам после запятой.
Исходные данные в принципе могут иметь большее количество знаков после запятой.

В исходных данных стоит 0,325 или 0.375
в отчете может отображаться
- 0.32 0.38
- 0.32 0.37
- 0.33 0.38
- 0.33 0.37

Выяснилось, что сейчас хранимая точность значения не может быть лучше 2 знаков после запятой, т.е. значение 0.325 или 0.375 является некорректным.

В чем конфликт
1. Я считаю, что данные хотя и "нежизненные", тем не менее фиксируют ошибку. А слеовательно они просто замечательные
2. Мне говорят, ерунда, это нереальные, несуществующие данные, подобного у пользователей не может проявится, потому нечего тестировать "космос", замените данные и не парьтесь. Есть дела поважнее.

Кто что думает по этому поводу?

Логично. Это ограничений (фича) системы. Не баг.

SALar, в чем фича-то? Почему не баг.

Выяснилось, что сейчас хранимая точность значения не может быть лучше 2 знаков после запятой, т.е. значение 0.325 или 0.375 является некорректным.

"хранимая точность значения" - это что?

И о каких данных идет речь?

Я тоже не совсем понял этого термина, полагаю, что значение коэффициента может иметь точность только до 2 знаков. Данные с точностью 3 знака признаются ошибочными (видимо)

Тема вопроса, прав ли руководитель, советующий (приказывающий) мне не тестировать космос (т.е. заведомо некорректные данные) или я, как истинный тестировщик, который тестирует разные ситуация, возможные и невозможные, но которые явно приводят к ошибке?

Я думаю, если все области/случаи с более высоким приоритетом протестированы, а время свободное осталось :), то надо проверять и такие случаи. ВНЕЗАПНО может оказаться, что для заказчика это высокоприоритетный баг.

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

Причем "ВНЕЗАПНО может оказаться, что для заказчика это высокоприоритетный баг".

Но в целом я понял, что я скорее прав, чем неправ :)

Я бы сюда не писал, а просто блокировал бы выпуск релиза :)

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

Погодите, я не спрашиваю совета, что делать. Тут все ясно. Я считаю, это ошибкой, руководство считает это ошибкой, но столь незначительной, что на нее не стоит и тратить время (зачем тестировать "космос"?). Мне говорят, ИСПРАВЬ эти данные в базе, и ошибка исчезнет. Пользователи ничего не говорят же об этом. Я же пытаюсь доказать, что прав я, что данные должны быть такими, которые позволяют выявить ошибку. А обратился сюда я, за поддержкой своей точки зрения или наоброт, что бы мне указали, что я ошибаюсь в своих выводах и почему.

Это не особенность какого-то окружения на мой взгляд. На VMW в течение 3 лет актвиной эксплуатации на разных хостовых машинах и с разными гостевыми ОС не было такого НИ РАЗУ. А при первом же запуске VB- хлабысь и хлабысь в одном и том же месте. Загадка сия великая есть

Странно, писал ответ. Куда исчез?

Нам никак не удается поработать с VB. Она у нас падает с ошибкой bad_coll_header или bad_pool_header. Ошибка возникает на гостевой винде. Можем повторить вручную при выполнении действий в тестируемом приложении. На VMW этого не происходит. В чем может быть проблема? VB 4+

Для прогона автотестов мы активно используем виртуальную машину. Пока используется VMWare. В самом начале выбора пытались использовать VirtualBox, но вынуждены были от нее отказаться. VB постоянно синхронизировала время с хост-машиной. А нам этого было не надо. Мы активно во время тестирования перемещаемся в прошлое и будущее. Найти ответ на вопрос, можно ли как-то отключить эту синхронизацию в то время не смогли. Потому пользовались VMWare. Однако потребности растут, приходится расширять парк машин и соответственно нужны еще лицензии на VMWare. Потому решили вернуться к экспериментам с VB. Нашли решение. Можно отключить службу VB и тогда синхронизация времени перестает быть проблемой. Но проблемой стало вообще само использования этой виртуальной машины. За все время экспериментов ни разу не удалось прогнать тесты полностью, постоянно вылезали какие-то проблемы, приводящие к зависанию VB или хоста. VB крутилась на 7. Сам файл с окружением и стендами был от VMWare.

Может кто-то поделиться опытом использования VirtualBox? Особенно интересует мнение людей кто перешел на VB с VMWare. Спасибо

Русификация Mantis

Начиная с MySQL 5.0, нужно явно задавать кодировку соединения (utf-8 или cp1251, в зависимости от выбранной русской локализации Mantis). Этот баг уже зарегистрирован http://www.mantisbt....php?bug_id=6782 , и возможно уже исправлен в последующих версиях, но в версии 1.0.6 (если база под MySQL 5.0), нужно добавить строчку-определение кодировки в функцию db_connect, файла core/database_api.php:
$t_result = $g_db->Connect($p_hostname, $p_username, $p_password, $p_database_name );
$g_db->Execute ("SET NAMES utf8");
При этом стоит использовать только «Настройки/Язык» из русских языков стоит использовать только «russian_utf8».

2 galogenIt - отличное владение копипастом

тогда уж копипейстом :)