Русификация 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 - отличное владение копипастом

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

Это не особенность какого-то окружения на мой взгляд. На 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. Спасибо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В исходных данных стоит 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. Мне говорят, ерунда, это нереальные, несуществующие данные, подобного у пользователей не может проявится, потому нечего тестировать "космос", замените данные и не парьтесь. Есть дела поважнее.

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

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

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

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

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

Просто на форумах не всегда полезный пост сопровождается положенными благодарностями.
Так что я за всех скажу -- muchas gracias!
Побольше бы таких "банальных" ответов, подробно и по существу.

Спасибо, Алексей. Вы не правильно меня поняли :). Я, конечно, не жду благодарности. Ну право слово, все мы бываем воспрошающими и бываем отвечающими. Я интересовался, решена ли проблема? Предложенные варианты удовлетворили топикстартера.

Но все равно, приятно получить "muchas gracias" :)

Может просто сохранить в csv формате?

tab15, совершенно прав. Проще сохранить в csv. Хотя нет никакого труда сохранить в ЛЮБОМ нужном Вам формате. Для этого нужно обратится к Excel как COM_объекту

// Excel - сохранить как----------------------------------------------------------------------------
// тип файла, если 1 - в формате "xls"
//                 6 - в формате "csv"
function SaveAs(aFileName : String; aFileType : Integer = 1) : boolean;
var
  vMsExcel : OleVariant;
begin
  _FileDelete(aFileName);
  vMsExcel := _OleObjectCreate();
  // сохраянем книгу
  vMsExcel.Workbooks.Item[1].SaveAs(aFileName, aFileType);
  vMsExcel.Quit();
  vMsExcel := nil;
  // убиваем процесс
  while Sys.WaitProcess('EXCEL').Exists do
    Sys.Process('EXCEL').Terminate();
  // проверяем, существует ли сохраняемый файл; это и будет проверкой, что данная функция отработала нормально
  result := _FileExists(aFileName);
end;

или

// Excel - сохранить как...
// тип файла, если 1 - в формате xls, 6 - в csv
function ExcelSaveAs(aFileName : String; aFileType : Integer = 1) : boolean;
var
  vMsExcel : OleVAriant;
  p1       : OleVAriant;
begin
  if aqFile.Exists(aFileName) then
    aqFile.Delete(aFileName);
  Delay(2000);  
  // ожидание открытия окна MSExcel
  p1 := Sys.WaitProcess('EXCEL', 120000, -1);
  Delay(2000); // тут уж ничего неподелаешь ... непонятные тормоза независящие от процесса  
  if not (p1.Window('XLMAIN', '*').Window('XLDESK').WaitWindow('EXCEL7', '*', 1, 120000).Exists) then
  begin
    Log.Error('Окно Excel не открылось. Тест продолжен не будет');
    if Sys.WaitProcess('EXCEL').Exists then
      p1.Terminate();
      CloseProcess;  
    Runner.Stop(true);
  end;
  p1.Window('XLMAIN', '*').Minimize(); 
  Delay(5000);
  vMsExcel := Sys.OleObject('Excel.Application');
  vMsExcel.DisplayAlerts := False;
  vMsExcel.Workbooks.Item[1].SaveAs(aFileName, aFileType);
  vMsExcel.Displayalerts := 0; // типа отключить встроенные предупреждения Excel'я
  vMsExcel.Quit();
  vMsExcel := nil;
  
  while Sys.WaitProcess('EXCEL').Exists do
    Sys.Process('EXCEL').Terminate();
    
  if aqFile.Exists(aFileName) then
  begin
    Log.Message('Файл: ' + aFileName + ' - успешно сохранен.');
    result := true
  end else
  begin
    Log.Error('Файл: ' + aFileName + ' - не сохранен.');
    result := false;
  end;
end;

Никому не интересно? Или банальные вещи?

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

Так проще и логичнее.

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

Возможна ли такая схема? Впринципе, что как ты думаешь нужно сделать для ее реализации и успеха?

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

Честно говоря, я сначала испугалась, а не так ли это? :) Потом подумала и пришла вот к чему. В течении недели я слежу за каждой задачей в отдельности. По каждой в отдельности правят баги, если требуется. Перед релизом мне выдаётся кандидат, на котором я смотрю на работу системы в целом и как в неё вписалась новая функциональность. Разве это не приёмочное?
Почему это делаем мы. Заказчик -- министерство. Задачи поступают от внедренца-аналитика, продажника, ещё одного человека, функций которого я не знаю, но реального пользователя. Т.о. нет единого центра, кто бы нёс ответственность за приёмку. Ответственность возложили на тестировщика.

А ещё у нас есть чек-листы, которые должны заполняться при проведении приёмочного. По ним, видно, что проверено и какие баги возникли.

Давайте этот вопрос обсудим подробнее.

Итак у Вас есть заказчки - это министерство, естественно с ним Вы не контактируете. У нас также собственно.
В момент Х вы планируете приемочное тестирование, как я понял у вас есть чек-листы. Кто их составляет? На основании чего их составляют? Как Вы понимаете, что принимаемая вами функциональность работает правильно?

Хм, у нас тут совсем другое понимание приёмочного тестирования, и проводят его тестировщики перед выкладкой сборки на боевой сервер. Основная цель -- быстро пройти по всей функциональности (согласно бизнес процессам), чтобы выявить в первую очередь критические ошибки. Те задания, о которых говорите Вы, у нас проверяются сразу после выставления им статуса Resolved. Это и есть наша рутинная работа. Собственно потому не понимаю, чем же занимаются тестировщики у Вас большую часть времени.

Очень много чего. У нас очень сложно-хитроумный процесс. Кратко это так. Мы постоянно! тестируем одновременно три-четыре инстанса-релиза (старый релиз, молодой релиз, кандидат-релиз и транк). Связано это с тем, что у клиентов могут быть разные версии релизов но обычно в пределах 3 номеров. При этом ошибки возникают во всех релизах к сожалению.
Тестирование у нас в первую очеерд автоматизированное регрессионное. В каждом прогоне порядка 500 тестов, представляющие собой сложные бизнес-цепочки.
Работа начинается с разбора ночных прогонов, разбор тоже частично автоматизирован, формируется совокупный лог отчет. который мы потом анализируем. Чем меньше ошибок тем лучше и быстрее
Другой уровень работы - написание новых тестов для автоматизированных прогонов, расширение покрытия
Третий уровень изучение новой функциональности по транку - по необходимости написание тестов для автоматизациии и проверка прием работ
Четвертый уровенб исследовательское перманентное тестирование

Достаточно?

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

Поскажите, пожалуйста, кто по факту должен выполнять приемочное тестирование. Согласно ГОСТ 34 - это делает заказчик - поскольку это в его интересах. На практике этим скорее всего занимаются и исполнитель, и заказчик.

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

В нашем случае под приемочным тестированием будем понимать прием всех заявленных в релиз фичей. Фичи прописываются через работы-задания. Работы задания пишутся авторами: аналитиками, работы-задания исполняются программистами. В неявном фоне проверяются тестируются тестировщиками, а принимаются окончательно автором работы или иным проверяющим. прверяющим может быть любой компетентный работник - аналитик или тестировщик.

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

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

Я еще раз перечитала первый пост. Так и не поняла - есть заказчик или его нету?
Т.е. работа ведется по чьему-то заказу или речь идет об инициативной разработке?
И почему 34 ГОСТ вспомнили?

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

Часть подобных инноваций инициативные, но все равно первопричины в заявках клиентов.

Про ГОСТ вспомнил SALar. Я лишь сформулировал вопрос: Кто должен осуществлять приемочное тестирование? Постановщик задачи и тестировщик, или исключительно тестировщик? Ясно, что мы можем просто сказать Вася(тестировщик) с сегодняшнего дня ты принимаешь все работы. но будет ли это возможно, и что следует сделать, чтобы было возможно?

Один из лучших видов документации - приемочный тест. Можно в виде ГОСТ 34.603, можно в свободной форме. По ГОСТ писать проще. Меньше думать надо.

А у тебя нет примерчика?

Угу, готовь на ЛАФ-2012 :)