Вопрос к тестировщикам
Дорогие форумчяне, особенно тестировщики,помогите советом! Хочу идти в направлении мануального тестирования.
1.Коротко о ситуации:
43 года;
В Германии 3 года;
Последний год ушёл на изучение немецкого от А1 до В2(Berufsbezogene) уже сдан;
Образование профильное (диплом европейский, 6-летней давности,по специальности не работала);
Английский плохой, но есть отличный итальянский (знаю, многие скажут: "Что за бред, итальянский! К чему он?").
2. Как лучше сделать? :
а) Идти на С1 (Berufsbezogene, 4 месяца) + 3-4 месяца для подтягивания тех.английского и сдавать на STQB сертификат и пробовать устраиваться;
б) оставаться на уровне B2 по немецкому и лучше заняться STQB и английским сейчас .
Может подскажете хорошие книги?Сейчас штудирую Спиллнера (STQB Basiswissen),смотрю школу Портнова.
Заранее благодарна тем, кто уделит свое время.
iSTQB обычно делается за счет работодателя (банк). Там на одну подготовку несколько тысяч евро уйдет.
зачем тебе идти в мануальщики, если в Test Automation & enablement гораздо меньше конкуренции и гораздо больше денег?
Там за одно только умение писать модули для жиры тебя разорвут на части и потом клонируют.
Zertifikat als Software Tester (z. B. ISTQB) erwünscht
или просто плюс
Не помешает конечно, но это не главное. Я как то работал с тестершей, в свободное время преподавала музыку. Ну она умела ошибки находить.
Никто из мужиков не додумался бы во время приема сигнала кабель из разъема выдернуть, а она додумалась 
Причём подобная ситуация была не чисто теоретическая.
И так часто было. Главное, немного в технических вещах разбираться.
Думаю, что путь в целом правильный. Хорошо бы еще немного знать область в которой используются программы и понимать как разрабатываются программы и программисту часто не до различных мелочей.
https://dou.ua/lenta/articles/testing-newbie-guide-0/
http://okiseleva.blogspot.com/2015/05/blog-post_27.html
Надеюсь, что конкуренция за рабочее место в Германии не такая жесткая.
тяжело сказать, нужно знать сколько человек ищет работу.
Я вот ради интереса глянул на stepstone по всей Германии предложения
424 Treffer für Softwaretester Jobs 1065 Treffer für Tester/in Jobs 17850 Treffer für QA Software Tester Jobs 18244 Treffer für Tester Software Jobs 20639 Treffer für Testen (Software) Jobs 512 Treffer für Softwaretestentwickler/in Jobs 2847 Treffer für Junior-Softwareentwickler/in Jobs 7572 Treffer für Softwareentwickler Jobs
Да предложений для тестера много,каждый день что-то приходит ( "агенты" у меня стоят). Но почти все хотят с опытом. Одно объявление недавно было, прямо для меня написано: и язык программирования тот что надо и опыт не требуют, и даже знание языков на выбор (англ,фр или ит!) .Так город за 70 км от меня находится- это для меня не приемлемое расстояние! Я все-же отправила туда Lebenslauf, если пригласят на собеседование, поеду ради того, чтобы опыта в собеседовании набраться. Пока ответили, что рассматривают (Geduld bitte!). Поди узнай потом сколько человек на место было!
Язык стабильный В2, просто за год уже поднадоела эта постоянная зубрежка и PrüfungИ..Я бы с удовольствием пошла вместо С1 бесплатно потестировала 4 месяца и опыта набралось...С другой стороны понимаю, что с С1 лучше без особых знаний английского. На этой неделе будет беседа по телефону с одной "Personal & Recruiting" , посмотрю что она скажет по поводу языка. До начала курсов у меня есть 3 недели на размышление.
эта статистика не о чем не говорит. Конкуренция - это когда немцы готовы работать дешевле тебя.
По моим наблюдениям это всегда ПХП.
Для работы тестировщиком нужны знания доменной области. Это никак не Б2. И там конкуренция огромна.
Для работы разработчиком в тестировании тебе не нужны знания немецкого. Это вам будут и на собеседовании говорить, и это будет подтверждается практикой.
Кроме того, по моим наблюдениям там обязательны знания как раз русского языка. Т.к. единственным другим программистом, который сможет тебе ответить на вопрос (в телеге) будет человек, умеющий только русский.
бесплатно потестировала 4 месяца и опыта набралось.
Чисто как идея. Найти Open source проект и его потестировать, комментарии на странице проекта можно сделать.
И вот еще для теста. Представьте программу в которой есть два поля для ввода данных и кнопка результат. Допустим эти два поля просто суммируются.
Как вы будете енто тестировать?
Кроме того, по моим наблюдениям там обязательны знания как раз русского языка.
откуда велось наблюдение - из Москвы? 
Даже если есть русские коллеги на рабочем месте, все равно немецкий.
Без нормального знания немецкого юниорам надеяться вообще не на что.
Хороший спец еще и с английским прокатит.
эта статистика не о чем не говорит.
кому как. По крайней мере зависит сильно - что именно искать. Ну и 20 тыс. предложений тоже показатель
будет человек, умеющий только русский.
странно и как же он работает совместно с немецкими коллегами
Попробую так:
Как сказал бы Портнов: "А где требования?"
Потом какие цифры суммируются: положительные,отрицательные,целые или дроби, самое маленькое и самое большое значение?
Окно результат существует?Куда уходит сумма? На экран?В базу данных?
Кто пользователь?
1.Открываем программу,проверяем в разных браузерах и системах, на полный экран и нет.
2.С точки зрения GUI все в порядке?
3.Функциональность:(Positiv &Negativ)
Здесь можно много: хорошо проверяем крайние значения,промежуточная сумма верная?Error message выдаётся корректно при вводе букв и символов( проверяем отдельно на каждое окно и на два одновременно).
Изменится ли output если будем кликать много раз на кнопку сумма...
ЭТО примерно все что я до сих пор поняла...
Попробую так:
Для начала, довольно неплохо. Хотя вопросы не совсем корректно сформулированы с точки зрения программиста, как мне кажется.
"какие цифры суммируются" - лучше употребить "значения", а не цифры (0,1,2,....)
"целые или дроби" - обычно говорят о дробных или вещественных значениях.
"самое маленькое и самое большое значение" - совершенно правильный вопрос, но подразумевается часто в подобных случаях min double/max double. Обязательно нужно проверить и на переполнение. Попробовать ввести штук 30 цифр и больше. Может при вводе прога сразу загнется. Хорошо бы знать и границы: byte, int, long, float, double. (8/16/32/64 бит целые)
"Окно результат существует?" - дополнительное окно для подобного приложения как бы нонсенс. А без поля "результат" - смысл приложения вообще теряется.
"Куда уходит сумма?" - записывается / передается / как
используется. База данных в подобном примере тоже излишество.
"Кто пользователь?" - что под этим подразумевалось?
"проверяем отдельно на каждое окно" - видимо имелись в виду поля ввода.
Используемым слова при собеседовании также могут играть роль. Кто то может переспросить, что имелось в виду. А кто то подумает, нее не подходит....
"Изменится ли output если будем кликать много раз на кнопку сумма" - замечательная идея, я бы не проверил.
"Error message выдаётся корректно при вводе букв и символов" - лучше конечно, если некорректные символы вообще нельзя набрать. ну и проверить на "---", ".." и прочие комбинации допустимых символов.
Но как видите, даже при простейшей программе проверок нужно проделать оочень много. А если программа посложнее? Нужно уже ограничения на проверки делать.
язык нужен на уровне очень близком к родному. имею ввиду в предметной области. потому что нужно умето очень четко (желательно еще и грамотно, но и немцы не все грамотные) излагать. причем часто - по-телефону. и понимать, что белькочет в ответ собеседник (иногда именно так это и слышится). так что язык для тестировщика - вещь первостепенная.
ооо!! вам требуется тестировщик, и вы уже проводите интервью : )
я бы начал в вашем примере с того, что нет поля вывода результата. только кнопка и два поля ввода : )
зы. вывод голосом?
и вообще цель "тестирования" неясна: определить, можно ли с этим жить, или проверить, соответствует ли поведение спецификации. она должна быть, иначе не стоит и начинать.
Полностью с вами согласна- спец.терминология должна быть повторена. Все сразу делать у меня не получится..поэтому сначала С1 , потом еще 3 месяца на повторенье и ученье (надеюсь что С2 не понадобится).В немецкой компании багрепорты, наверное, пишут на немецком , если программисты на нем разговаривают или всё таки на английском.
В немецкой компании багрепорты, наверное, пишут на немецком , если программисты на нем разговаривают или всё таки на английском
Как уже сказали, сильно зависит от компании. Но я не стал бы утверждать, что преимущественно на английском, скорее наоборот.
Если уж все наименования с комментами в софте обожают писать на немецком, то что говорить об остальном.
Это только если действительно коллектив из разных стран.
я бы начал в вашем примере с того, что нет поля вывода результата.
Я думаю, было здорово если бы каждый придумал пример для тестирования. Чисто для отработки подхода.
ТС
https://quality-lab.ru/key-principles-of-gray-box-testing/
https://quality-lab.ru/key-principles-of-black-box-testing...
Вот и пришёл вчера первый негативный ответ на мой Bewerbung (до сих пор я отослала их в 2 фирмы и один рекрутеру).Это была как раз позиция джуниора за 70 км от меня, (требовались знания итальянского и язык программирования именно тот, что учила).Очень вежливо так, с просьбой o paзрeшении архивиировать мои Zeugnisse сроком на 1 год в их филиале, который находится 10 км от моего города.
Сначала это немного меня огорчило....
А сегодня это меня порадовало! Вообще куда я собралась, какое собеседование...что я им могла бы предложить на данный момент?
Диплом 6-летней давности и ни капли опыта?
Рано мне ещё даже и думать о BewerbungAX.
Язык,HTML,SQL и потом бесплатная практика в стартапе...Это реалистично...Вообще у нас тут юниор позиций очень мало- все хотят сразу профи...
Пс: забыла ещё TSP/IP ,английский и книгу ISTQB.
два бевербунга? у меня, пока я не получил первую работу здесь, накопилось 2 см толщиной (если сжать) отказов. и это только те, что ответили, и только те, что не имэйлом. а два - это как в ванной забросил удочку и за пять минут ничего не клюнуло.
а что такое TSP/IP, и что вы о нем знаете?
на бевербунге будут вас не как специалиста оценивать, а как личность, поверьте. люди к вам тянутся или вас избегают? вы очень расстраиваетесь, если заметите, что кто-то вами недоволен, или вы кому-то не понравились?
Ну я не совсем чайник,чтоб не знать что такое ТСР/IP (хоть и с ошибкой написала).Был у нас такой предмет,затрудняюсь его на русскомой сказать :System date administration and elaboration, так вот ТСР оттуда, Сети,Binary system,стандарты ,модели Iso/Osi и так. д.- много мы там изучали, просто это было давно, спроси меня сейчас на собеседовании ещё и на немецком...будет сложно объясниться. Я к этому говорила...Конечно я понимаю что сразу так никто не находит работу. Просто рано мне ещё на собеседования...Я к этому вела.
с просьбой o paзрeшении архивиировать мои Zeugnisse сроком на 1 год
------
Это очередные дурацкие требования ЕС об сохранности личных данных.
Сделай себе файл/ехцел/базу - картотеку - для записей об компаниях и опиши что имело место быть.
Будет полезно при длительных поисках...
Я тестировщик и молчать не буду. :)
Мое имхо, бросить силы на поиск работы, но язык не забрасывать. Идти на курсы С1 и искать работу. Если найдется работа, то курсы можно прекратить (и перейти на уроки по Скайпу).
Когда я приехала в Германию, то язык был около В1. Я закончила изучать немецкий за 6 лет до приезда в страну, после учебы практики не было никакой. Через полгода после приезда пришлось устроиться тестировщиком. Сначала лексика была не наработана, но дуден наше все. В2 - это вполне себе неплохой уровень. Был бы В1, то имело бы смысл дотянуть до В2. Я не думаю, что с С1, вы найдете работу легче и быстрее, чем с В2. Все упирается в то, что у вас нет опыта.
Quatsch! Первостепенная вещь для тестировщика - логическое мышление.
Язык нужен в той степени, чтобы был наработан лексикон предметной области. Это возможно через практику, а не через курсы. К лексикону надо уметь ещё понимать грамматические конструкции, в том плане чтобы не путать последовательность действий, будущее с настоящим и уметь описывать найденные проблемы.
Требования не пишут литературным заумным языком. Хорошие требования сформулированы всегда по одному шаблону и предельно просты. Непонятные слова легко находятся в словарях. А если требования плохо написаны, то тогда разночтения бывают и у носителей языка. Я с этим не раз на практике сталкивалась.
Не обращайте особо внимания на то, что требует работодатель. Шлите везде, где требуются тестировщики. Главное, чтобы бевербург был составлен грамотно.
Тестировщика сложнее найти чем программиста. Мой шеф берет и без опыта, и без профильного образования (но в технической области). Жалуется, что технически подкованных сложно найти. Информатики в большинстве своем умеют программировать, вот и не идут на тестировщиков, а идут на разработчиков.
Поэтому стучитесь в двери и какая-нибудь из них обязательно откроется.
Quatsch! Первостепенная вещь для тестировщика - логическое мышление.
ну, это - вообще, по жизни, а не только для тестировщиков...
но на собеседовании только глупые фирмы будут проводить "тести на айкью" и подобное. умные люди попытаются, как я уже писал, оценить вас как личность. ну и опыт ваш и прочее в разговоре сами вырисуются. в конце-концов, с вами в случае приема придется жить 40 часов в неделю вместе. если вы - гений тестирования, но личность просклизнет гнилая, то лучше с меньшим айкью поискать хорошего человека. это то, что я хотел донести.
Насчёт опыта: сегодня у меня была беседа по телефону с одной Beraterin Perrsonal&Rekruiting. Я её спросила, могу ли я устроиться на Praktikum куданибудь бесплатно на 2-3 месяца. Она сказала "нет" , т.к. это можно сделать или до Studium либо сразу после...А в остальном сказала то-же,что и Вы: мол В2 вполне достаточно...
Конечно С1 никому не навредит))). Спасибо ещё раз за советы.
если вы - гений тестирования, но личность просклизнет гнилая, то лучше с меньшим айкью поискать хорошего человека. это то, что я хотел донести.
В прошлом своем сообщении вы говорили о языке.
А в этом уже о другой вещи, о коммуникабельности, удобности и мягких скиллах. С этим соглашусь. Больше смотрят на личность, чем на профессионализм. Лично меня это огорчает, но се ля ви.
Ищите еще в направлении трейни.
Вы пишете, что у вас профильное образование. Это информатика? Если да, почему вы хотите именно в тестирование?
По поводу языка. У меня есть в электронной форме небольшой словарик по информатике и "Kommunizieren im Beruf". Если хотите, то могу скинуть.
дело в том, что работа тест инженера мало чем отличается от работы обычного "программиста".
Но по уровню зарплат ты выигрываешь в разы. В нескольких сотнях метров от тебя программисты говновеба месяцами не получают "зарплату" в 10 раз меньше чем у тебя. Это реальный случай.
Это одна из причин, почему чистый веб такой не популярный среди программистов.
язык очень хороший нужнен для того, чтобы тестировщик мог выполнять свою работу. хотя я видал QA, которые общались с французскоговорящим клиентом на аглицком, будучи сами поляками. но поляки же были разработчики, которые работали в бельгии. догадываюсь, что денег у них было немного, иначе нашли бы франкоязыких разработчиков и таких же QA. но это было - мы разрабатываем здесь, клиент - там, по очереди кто-то из нас сидит у клиента. а если тестировщик - в свою немецкоговорящюю команду с немецкоговорящими клиентами, а тестировщик - или мычит, или вообще "чужой в стае", то и бесплатно зачем он нам?
Во-первых, QA и тестирование это разные процессы. Тестирование полагает улучшить качество продукта, но QA - это нечто другое.
Во-вторых, зачем тестировщику общаться с клиентами? Я этим ни разу не занималась. Тестировщику важно понимать требования, но там не настолько сложный язык. Важно уметь так описать баг, чтобы это было понятно другим. Для этого сойдёт средний уровень немецкого. Мычать - это удел уровня А2, с В2 уже можно говорить, может быть с запинками ( зависит от врожденной болтливости), но говорить так, чтобы понимал собеседник.
Ничего не делаю с этим словариком, слишком поздно его нашла, когда лексика уже была наработана. Просто лежит пылится на диске. Но в самом начале работы в Германии пригодился бы для расширения немецкого лексикона. Растолкование коллеге или клиенту тут ни при чем. Но вот слово Laufwerk выучила я не сразу. Или вот ещё слово hochladen было мне не сразу известно. Herunterladen я знала, а обратное направление нет.
Во-первых, QA и тестирование это разные процессы. Тестирование полагает улучшить качество продукта, но QA - это нечто другое.
ну да, вы "вроде как бы и правы", даже гоголь вас поддерживает (спросить "qa vs testing").
например здесь https://intersog.com/blog/tech-tips/qa-vs-testing/:
Testing: The process of executing a system with the intent of finding defects including test planning prior to the execution of the test cases.
Quality Control: A set of activities designed to evaluate a developed working product.
Quality Assurance: A set of activities designed to ensure that the mobile app development and/or maintenance process is adequate to ensure a system will meet its objectives.
еще здесь https://www.functionize.com/blog/quality-assurance-vs-qual...:
Quality assurance is process oriented. It is all about preventing defects by ensuring the processes used to manage and create deliverables works. Not only does it work, but is consistently followed by the team. Moreover, QA is about engineering processes that assure quality is achieved in an effective and efficient way.
Quality control, alternatively, is product oriented. It is the function of software quality that determines the ending result is what was expected. Whereas QA is proactive, QC is reactive. QC detects bugs by inspecting and testing the product. This involves checking the product against a predetermined set of requirements and validating that the product meets those requirements.
Testing is a subset of QC. It is the process of executing a system in order to detect bugs in the product so that they get fixed. Testing is an integral part of QC as it helps demonstrate that the product runs the way it is expected and designed for.
думаю, в крупных фирмах со сложными продуктами, с численными командами разработчиков это близко к тому, что говорит гоголь. но в большинстве фирм эти гоголевы определения - далекая абстракция. работал в фирмах, где не было вообще ни тестировщиков, ни qa, ничего подобного. но продуктом пользовался весь мир (ну, половина : ), и человек 5 сидело на телефонах и имэйлах, успокаивали клиентов, которые и были и тестерами, и qa фактически. это - как оно бывает в реальности.
был и в фирме, где ничего такого не было-не было, пока клиент не ряфкнул и не сказал, что он поищет другого, если мы
не обзаведемся qa. "создали". людей новый не набрали, просто пару человек отслоили от разработчиков, и они стали заниматься этим "как бог послал". клиент успокоился и, насколько я знаю, до сих пор доволен. то есть мне вживую не пришлось пережить классическую гоголевскую формулировку. для меня это "как должно бы быть, но нигде не бывает, потому что ни времени, ни людей, ни денег в бюджете"
если кто-то расскажет, как это у них реально происходит, прочту с интересом.
Да, ваш словарик на вес золота для начинающего тестера!!!Я тоже такой хочу, буду безмерно благодарна! Я специально книгу по ISTQB на немецком читаю и учу, т.к.там полно этих спец.терминов.Она даже на немецком очень понятна, помогают уже кое-какие знания и прочитанные книги на русском по тестированию.
думаю, в крупных фирмах со сложными продуктами, с численными командами разработчиков это близко к тому, что говорит гоголь. но в большинстве фирм эти гоголевы определения - далекая абстракция.
Для тех, кто сертифицирован по ИСО 9001 - это не абстракция 
Это стандарт никак не связан с ПО, но тем не менее определяет менеджмент качества. Мелкие конторы тратить на это деньги не хотят. Мой прошлый работодатель таким был. Единственное требование в тестировании было, чтобы к каждому требованию был как минимум один тест. Качество требований оставляло желать лучшего. Слишком обобщенные, выдвинутые клиентами и мало как обработанные коллегами. Вечно приходилось задавать каверзные вопросы, которые потом уточняли у клиента. Бррр. Ныненшняя фирма куда больше, сертифицирована по ИСО 9001. Сейчас еще готовятся к ассесменту по ASPICE. Тут совсем другой подход к тестированию, проводятся ревью тестов, в целом требований к тесту куда больше. И вот
в этой фирме есть коллеги по обеспечению качества.
если кто-то расскажет, как это у них реально происходит, прочту с интересом.
Сейчас расскажу, но так как я тестировщик, а не QM, то может выйти сумбурно. С моей колокольни видится, что эта работа слишком бумажная. У них есть свои чек-листы. Они проверяют. все ли нужные для проекта/продукта документы есть, в актуальном ли они состоянии. Перед какждым релизом проводится внутреннее Lieferfreigabe (Delivery Approval) с программистом и тестировщиком. QMщик проходит по своему списку и проверяет на рэндомном тикете соблюдены ли требования нашего процесса. К примеру, должен быть проведен статический анализ кода/модели. Разработанный код и тесты его должны ссылаться на требования. Для кода и тестов должны быть проведены ревью. На данном проекте у нас упрощенная схема, делаем это в GitLab. А так в принципе существует шаблонный эксель документ с кучей макросов от QM, в который вносятся найденные пункты во время ревью.
Вот к примеру, ревью. Можно проводить ревью не только кода или теста, но и любого документа. В глобальном смысле можно ревьюить все что угодно. Ревью - это же ведь не тестирование, но одно из мероприятий обеспечения качества.
Возвращаюсь к Lieferfreigabe. QM проверяет если ли тест репорт и все такое прочее. На основе этих пунктов подсчитывается оценка релиза. Главная страница этого документа распечатывается, подписывается важными персонами из разработки, тестирования, проекта. Затем сканируется и вставляется к эксель документ Кроме этого, QM пишут еще какой-то QM-Plan. В общем работа у
них есть, но их у нас трое человек на коллектив из примерно 80 человек.
Сфоткала кусок документа, где перечислены их задания.
Прикреплённые файлы
Я специально книгу по ISTQB на немецком читаю и учу, т.к.там полно этих спец.терминов
Это правильно 
Вот ссылка на словарик. https://cloud.mail.ru/public/2uiY/52NxskXzN
ЗЫ Аааааа, что за дурацкий аватар в этом посте висит???
Ура, впревые работодатель за собственный счет литературу купил мне.
Неужели персонально вам? 
Думаю, что все же себе, а вам благосклонно позволяет пользоваться))
По моему опыту это вроде нормальная практика, покупать литературу по заказу работника. Я правда книжку по тест менеджменту купила себе сама, чтобы можно было спокойно дома читать, когда есть настроение. Б/у обошла в 17 евро. Состояние хорошее, просто форзаца нет, видимо там раньше печать фирмы была.
О...спасибо! А я вам уже в личку написала...
Я так долго смеялась, когда узнала что oбычный "линк" -это целый " Verknüpfung "...
Скажите, если не секрет, вы баг- репоры на немецком или на английском пишите?
Требования и тест-кейсы тоже на немецком?
Или?
Скажите, если не секрет, вы баг- репоры на немецком или на английском пишите?
Требования и тест-кейсы тоже на немецком?
На немецком. Не довелось еще в такой компании работать, где язык переписки - английский. Когда в прошлой фирме начала работать, немецкий был еще слабоват, писала тест спецификацию на английском. Никто ничего не сказал. Потом плавно перешла писать на немецком.
В нынешней фирме все на немецком, но когда-нибудь хотят перейти на английский. Может быть относительно скоро, так как нас влили в концерн с зарубежными филиалами.
Второй отрицательный ответ сегодня получила...где стартапы искать? на степ-стоуне и пр. одни "солидные" фирмы...Буду продолжать "стучать во все двери".
Честно сказать отказы немного нервируют и сбивают с толку...ну это нормально...Отрицательный результат- это тоже результат...
у меня хороший опыт с https://de.indeed.com/. Кроме этого на удивление впервые сработал xing. Рекрутер сам меня нашел, сам все предложил и из 4 им предложенных фирм - 3 пригласили на собеседование! До этого писал месяца два, отказы шли пачками. Кроме этого судя по всему там велась подготовительная работа, потому как встречали меня каждый раз с большим интересом. Кстати в двух фирмах мне признались, что на сегодня найти именно тестировщиков невероятно трудно. Это я о том, что пишите бевербунги дальше. Хорошего Б2 хватит по началу, т.к. там как раз вся важная грамматика уже пройдена. Ц1 это уже больше анализ текста, что конечно тоже нужно, но оно с такой работой само придет, по крайней мере по специальности. Обязательно пройдите теорию
от общего к частному. Работодатель хочет видеть, что у человека есть структурированные знания и он представляет весь процесс, хотя бы теоретически. В любой фирме все равно есть свои ньюансы продукта и все придется осваивать заново. Кстати у меня сертификатов нет и на последнем разговоре дали понять, что очень жаль. На что я очень издалека намекнул им на то, что не сертификаты будут работать, а человек со своей сноровкой, а главное мотивацией. Может повезло, но никто не рассердился) Но в будущем конечно же это учту и постараюсь исправить
Спасибо за советы!!! Вот именно так и у меня ...отказы....отказы...В нашем городе все сразу с опытом хотят...Городок небольшой и полно институтов выпускающих программистов, которых они потом на практикум тестировщиками зовут (не каждый пойдёт, конечно, но все-же). Я и Лебенслауф только сейчас до "нужной кондиции" довела. А так, уже первый "шок" от отказов пережила, теперь нормально себя чувствую)). Значит в Германии Ксинг....в Америке хорошо, говорят, Линкедин работает по этому вопросу. Только как с рекрутерами потом это выглядит: типо ляйфирма или работодатель ему заплатит за работника и все? А если потом придётся уволиться или ещё что (всякое бывает), то что тогда? Вы в курсе?
Пс: про какие сертификаты "сожалел" работодатель? Про ISTQB?
Только как с рекрутерами потом это выглядит: типо ляйфирма или работодатель ему заплатит за работника и все?
Мне чаще всего попадался вариант 2, но фирмы носом крутят. За дополнительные деньги хотят получить только то что хотят, никаких отклонений в сторону.
А отказов будет очень много, просто посылайте дальше. Нужно просто привыкнуть к этому.
Уже привыкла:)...посылать дальше в надежде на то, что "звезды всё таки сойдутся" и найдется кто-то, кому ты подходишь (между тем прокачивая, конечно, скиллы). Пока даже на бесплатный Практикум и на тот отказ сегодня получила (как тут не смеяться!)...))). Они, кстати, как я поняла, практикантов только учащихся в УНИ берут, иначе это никак не оформить с точки зрения Vertraga...или я ошибаюсь. В смысле, реально где-то бесплатно поработать месяца три ,за опыт, или такого тут не бывает? Вы не знаете? Спасибо!
В смысле, реально где-то бесплатно поработать месяца три ,за опыт, или такого тут не бывает?
Вообще то всё реально, только вероятность наступления события неизвестна. Возьмите любой опен соурс проект, который интересен и начните его тестировать, потом даете ссылку на описание найденных ошибок. Хотя английский желательно знать.
Звёзды начинают сходится...Иду на месячный курс Softwaretester ISTQB .Получила оплачиваемый практикум на 2 месяца с сентября в хорошей компании. Проблема в том, что культуры тестирования в фирме нет, все тесты делают сами программисты. Документации тоже никакой: тест кейсы, тест планы и требований тоже по-моему нет. С какой стороны подходить...Кто- нибудь сталкивался с таким? Курсы мне, конечно, помогут разобраться немного....
Заранее спасибо тем, кто что-то посоветует.
Кто- нибудь сталкивался с таким?
-----
У самого так. И в большинстве мест где работал.
С какой стороны подходить...
-----
Тебе дают - ПРАКТИКУ - подходи со всех сторон. Даже с той, которой нету, но которую придумаешь сама.
Звёзды начинают сходится...
-----
Когда звезды сходятся - они взрываются. Обычно после этого ближайшее окружение вымирает, а удаленное - мутирует...
С какой стороны подходить...
Я ни секунды не тестировщик :) Но посоветовать могу :D
Подходить к созданию теста нужно с вопроса: что я хочу проверить этим тестом? Как только ты сможешь сформулировать ответ на этот вопрос, считай, что половина теста уже сделана.
Фактичечки тесты являются документацией к тестируемому продукту. Если к продукту нет требований, то соответственно нет и тестов :D Поэтому твоей первой задачей будет собрать требования к продукту.
Что такое тест план я себе плохо представляю, если только коллекция тестов. Т.е. для внутреннего резиза тест план, скажем из 10 тестов, а для финального релиза - тест план из 100 тестов. Главное, чтобы в тест плане не была прописана очередность тестов.
Вообще нет требований, а как они разрабатывают? Может хотя бы тикеты есть с описанием задач.
Как от практиканта от вас наверное будут ожидать выполнения типичных user flows и поиска багов, т.е. вы будете в роли пользователя. Когда получите функционал на тестирование, пройдитесь по типам тестирования и подумайте, как бы вы могли их к этому функционалу применить.
Поздравляю с первыми шагами!
Ну разрабатывают они все равно на основе какой-то информации, не из головы же. Поинтересуйтесь, где эту информацию найти. В самом худшем случае идите к разработчику и пусть рассказывает, как это должно работать. Тест кейсы можете сами записывать, потом если что показать для отчетности. Тест план вам незачем, его пишет тест менеджер, но раз у них так не очень хорошо с тестированием, то документа этого естественно нет, но и с вас он не нужен. По-хорошему, если взяли на практику, то задания сами должны давать. Если будет так, что дадут продукт и скажут, тестируйте (было у меня такое ), то поинтересуйтесь, какой функционал наиболее критичен, тот и тестируйте. Или попросите свежую сборку и спросите, что на
данный момент в разработке, то и попробуйте протестировать.
все тесты делают сами программисты. Документации тоже никакой
знакомая ситуация
С какой стороны подходить...
для начала разобраться с продуктом, что он должен делать и как с ним работать. Заодно всё и опишите.
Затем берем какой-то функционал и бъём по нему со всех сторон. Ну вот например задача - сложить два числа.
Программист будет обычно тестировать просто, возьмет 2 и 2 получит 4 и успокоится 
Тестеру же нужно будет проверить 0+0, -1+1, 10000000000000+100000000000000, и т.п. пока фантазии хватит. Если параллельно можно еще что запустить - запустить.
Спасибо всем за подсказки. Привет Raperonzolo! Про требования, конечно я утрировала - должны быть по-любому. Хотя я спросила про "Anforderungen"( скорее всего мы не поняли друг друга).
Меня как раз и "прикрепили" к двум разработчикам (одна- Фронтэнд, второй-не поняла). Их приглашали по очереди на собеседование и спрашивали, готовы ли они со мной "возиться" по 2 часа в неделю примерно или нет. Проблема, что у них Agile, ну даже если это и гибкая разработка, не значит, что требований не должно быть. Ещё у них мало Webа как я поняла после прочтения их портфолио в интернете. Они готовят в основном высокотехнологичные фичи ( включая искусственный интеллект) для очень известных производителей, банков, страховых и Big Data ещё есть.
Поэтому я немного стрессую: ну где
искусственный интеллект - а где я...
Зато есть личные проекты сотрудников, выставленные на сайте, в процессе разработки - это в основном Web.
Интересно узнать мнение программистов, тех кто уже работает с тестировщиками или без них. Ведь тестеры, в принципе, берут часть вашей работы на себя. И, скажем, её нудную и кропотливую часть, оставляя вам больше времени на разработку. Тем самым улучшая качесво продукта. Значит, в принципе, это есть хорошо, иметь у себя в конторе хорошего тестера-миддла (я не говорю про юниора, разумеется). Или кто-то считает наоборот...
вы считаете, что...
-----
...тестировщику, как и программисту, надо уметь читать то, что написано, а не то что он читает...
не вижу в этом логики
-----
Они влияют именно на конечный продукт.
Но влияют - опосредованно - находя места возможных/реальныx ошибок, которые не нашел программист.
Лучше ли качество кода, если в команде есть тестировщик? Нет, не лучше.
Ну... опосредованно. Смотря как разделить "качество кода" и "качество продукта", конечно. Если тестер что-то делает, то как минимум улучшается "Functional Suitability" (ISO 25010).
Но вообще не согласен - код после исправления ошибок, найденых тестером, становится качественнее, так как лучше соответствует требованиям.
код после исправления ошибок, найденых тестером, становится качественнее
-----
Интересно, почему, в случае длительного сопровождения, нахождения и фиксинга кучи багов, именно код - деградирует?
Оно как? Кто-то написал, потом ушел, потом оно где-то сдохло, посыпались массовые жалобы, тестеровщик - подтвердил наличие проблемы, открыли таску на фиксинг и скинули на свободного, пофиксил он как мог в отведенное время - откуда будет качество у кода?
Смотрю сейчас код.
Чел написал:
- сделать выборку, слегка отредактировать в данных что можно, склонировать структуру полученной таблицы, удалить несколько колонок.
- с остальным работать используя в цикле целочисленные индексы для доступа к полям в строке.
Из того что вижу - выход индексов за пределы количества полей - регулярный.
Пофиксил - индекс перестал выпрыгивать за пределы строки.
Качество кода улучшилось? С чего бы - Я все так же не понимаю что и как он считает - Я пофиксил, как мог, только выход индекса за пределы строки и код слегка деградироваl...
Качество кода - это в первую очередь то, что понимается под clean code, т.е. это документация, создание интуитивно понятного (читаемого) кода, создание тестируемого (юнит-тестами) кода итд. На все это тестировщик никак не влияет.
На качество конечного продукта тестировщик влияет, но влияние это оказывается зачастую с задержкой. Дело в том, что тестирование продукта идет по существующим тест-кейсам. Тест-кейсы создаются двумя путями: 1) тестировщик смотрит требования к продукту и проверяет рабочий функционал и пограничные параметры и 2) клиент сообщает об ошибке и таким образом описание бага конвертируется в тест-кейс. По моему опыту тест-кейсов созданных по 2-му пути больше, а это значит, что клиент уже минимум один раз был недоволен продуктом :) Т.е. да, наличие тестировщиков улучшает качество конечного продукта, но и тут есть нюансы :) А именно, количество тест-кейсов всегда только увеличивается, а значит, рано или поздно наступит момент, когда выполнить все имеющиеся тест-кейсы станет невозможно. Ну просто из-за того, что потребуется слишком много времени на прогон сравнительно небольшого количества тестов (у нас на примерно сотню ручных тестов тестировщик тратит 1,5-2 недели :)), а это значит, что какие-то тесты будут вычеркиваться из тест-плана, а значит появится вероятность появления старой ошибки. Т.е. в общем случае тестировщик не может гарантировать выпуск стабильного продукта.
Кроме того, в общем случае, тестировщик не может проверять отказоустойчивость системы. Т.е. можно конечно запустить продукт и выдернуть сетевой кабель, но это не всегда можно (у нас например софт тестируется на виртуальных машинах через remote desktop), а отрубить жесткий диск или
перевести время на час назад в процессе обработки данных или просто инициировать виндоус апдейт просто невозможно. А ведь зачастую именно такие проблемы и всплывают.
Зачем же нужны тестировщики?
Тестировщики прогоняют существующий продукт по "зеленому" сценарию, т.е. задача тестировщика убедиться в том, что в идеальных условиях продукт работает и взаимодействует со внешним миром как надо. Также тестировщик может проводить deployment test'ы, т.е. сценарии апгрейда. Все это очень тягомотная, однообразная и вместе с тем нужная работа.
Если вы считаете, что тестировщики никак не влияют на качество кода
Есть код, а есть продукт. Тестировщики тестируют продукт. Код может быть ужасным, с кучей костылей, но если функционал работает корректно, то тестировщику пофиг, что там внутри. Другое дело, что в будущем при расширении функционала, к примеру, плохой код всегда наделает кучу проблем.
Работа тестировщика - СЛОМАТЬ - то, что программист считает надежно работающим. Только СЛОМАТЬ!!!
Это что еще за хрень? Какие сломать? Работа тестировщика - подтвердить, что продукт работает соответственно выдвинутым требованиям.
Но вообще не согласен - код после исправления ошибок, найденых тестером, становится качественнее, так как лучше соответствует требованиям.
Ну... если в спагетти коде пофиксить баг, то он все же останется спагетти кодом. А еще баг можно пофиксить посредством костыля.. который может чего в другом месте поломать
Работа тестировщика - подтвердить, что продукт работает соответственно выдвинутым требованиям.
------
Что работает согласно спекам - может подтвердить и прогер.
От тестировщика, по крайней мере Я, ожидают нахождение имеющихся и потенциальных проблем.
См. 
AlexNek и его упоминания об тестировщице догадавшейся выдернуть кабель...
Да, понятно изложено...
Просто я думала, что "качество кода" прямо пропорционально "качеству продукта".
Потом ребята из фирмы, куда я на практику пойду, сказали, что если я их смогу убедить в том, что им нужен тестер, то они меня оставят...Но вижу, что убеждать мне их особо нечем:)). Тем более что они сами свой софт юнит тестами покрывают. Люди пытались "склонить" меня на собеседовании к Mediengestalter и Фронтэнд, но я твёрдо стояла на тестировщике))).
Потом, я отдаю себе отчёт: нужно хорошо знать тестинг( быть минимум миддл), чтобы вводить это в фирму...Поэтому мне было интересно послушать мнение программистов.
Потом, я отдаю себе отчёт: нужно хорошо знать тестинг( быть минимум миддл), чтобы вводить это в фирму...
Это так.
Но вы не расстраивайтесь раньше времени, вы ещё даже не начали работать. Начните, а там осмотритесь по ситуации. В конце концов, если они вас позвали, значит решили, что им это зачем-то нужно.
Тем более что они сами свой софт юнит тестами покрывают.
Юнит-тесты - это вообще не гарантия того, что у них все работает).
Но вы не расстраивайтесь раньше времени, вы ещё даже не начали работать
нет,нет....нисколько. Я считаю, что мне крупно повезло! Сертификат плюс первый опыт (даже 2 месяца), повышают мой шанс найти работу как минимум на 30%. Жаль, что не будет именно тестера, от которого можно было бы быстрее научиться, но ничего страшного. Моё первое впечатление от людей там, очень положительное....
Что работает согласно спекам - может подтвердить и прогер.
Чушь городите. Во-первых, в силу психологических причин разработчик недостаточно критичен к собственной работе. Во-вторых, мир не идеален и формулировка спецификации в том числе. Были у меня случаи, когда программеры интерпретировали реки совсем не так, как я. В итоге получалось, что моя интерпретация верная 
В-третьих, программеры не в состоянии взглянуть целостно на продукт, всегда в подкорке мозга потоки данных бегают, я это из личного опыта знаю. Ваши рассуждения о работе тестировщика - дилетанство, сбиваете только ТС с толку.
От тестировщика, по крайней мере Я, ожидают нахождение имеющихся и потенциальных проблем.
А кто вы такой, что вы что-то ожидаете что-то от тестировщика? Что такое проблема в вашей точки зрения? На чем основываться, определяя проблема это или нет? На здравом смысле конкретного человека? Тогда это вообще жесть
См.
По вашему тестирование должно быть только негативным? Есть и другие виды тестирования, которые отнюдь не менее важные.
ем более что они сами свой софт юнит тестами покрывают.
Спросите у них, какой у них процент code coverage и branch coverage. Еще можете спросить про цикломатическую сложность Раз у них есть юнит тесты, надо пробовать искать ошибки на уровне интеграции.
Mediengestalter
Это что такое? Оформление какое-то?
Юнит-тесты - это вообще не гарантия того, что у них все работает).
https://tenor.com/view/unittest-unit-test-gif-10813141
Вооо, классный пример
По вашему тестирование должно быть только негативным?
остальное просто не запомнилось. Да и мне лично какой интерес от того что получен отчет, всё работает как и раньше. Хорошо, замечательно, полезно.
Зато вот когда что то не так это уже интересней, можно и рассказать и запоминается.
С другой стороны, зачем нужен тестер которой будет проверять работу исключительно в правильных "режимах"?
Данная профессия в русском языке называется тестировщик. Я не придираюсь за неимением аргументов, просто режет слух)
Нет универсального ответа, зачем нужны тестировщики. Но давно уже пришли к мнению, что тестировщики проверяет систему на предмет соответствия треьованиям. Цели и приоритеты тестирования в каждом проекте свои. Где-то важна стрессоустойчивость системы (в автопроме бывает такое), где-то это не совсем важно. Негативное тестирование - это одна из методик наряду с позитивным тестированием, тестированием пограничных значений, классами эквивалентности. Если позитивное тестирование не выявило багов, то можно заняться негативным тестированием. А так.. толку от того, что сферический калькулятор не вылетает, если ему вводят буквеннные символы, но не может правильно вычислить 2+3.
Ответа однозначного нет, креативность - это неплохо, но работа тестировщика - это часто рутина, особенно если разработчики башковитые.
ЗЫ вспомнила тут.. во времена разработки мой шеф тыкал в кнопку что питцот раз, чтобы приложение зависло или вылетело. Идиотизъм ж.
просто режет слух
могу вас понять, только русским мы на работе как то не пользуемся.
бота тестировщика - это часто рутина
Вот за что их и уважаю, я бы на их месте давно бы уже повесился
мой шеф тыкал в кнопку сто питцот раз, чтобы приложение зависло или вылетело
А чем не нравится? Нормальный способ, на десктопе может и не сильно нужно, но бывают и там подобные глюки
Во-первых, в силу психологических причин разработчик недостаточно критичен к собственной работе.
------
Это - да. И тем не менее именно прогер изначально утверждеает, что сдаваемый код работает согласно спекам.
В итоге получалось, что моя интерпретация верная
-----
Т.е. ты таки СЛОМАЛА то. что наваяли прогеры...
программеры не в состоянии взглянуть целостно на продукт
------
Это - тоже почти ДА.
Дело в том, что при современных объемах ПО вообще никто не в состоянии ЭТО сделать.
Вот свеженький пример:
- прожу. В какой-то момент получю тайм-оут на базе. Спрашиваю - что с базой? - ответ - Все нормально, работает, задержек нет.
- не верю, создаю мини-проект и проверяю подключение - работает.
- возвращаюсь к старому солюшнику - тайм-оут.
Вот теперь взгляни целостно на продукт и ответь на вопрос - где и что не дает законнектится на базу?
По вашему тестирование должно быть только негативным?
-----
В первую очередь - ДА.
Сделать код рабочим согласно спекам - это доступно прогеру.
А вот найти условия при которых он становится нерабочим - это не совсем прогерская задача.
Как-то обсчитывали обработку звука. Там - фурье и куча формул с синусами и косинусами... тестировщика - не было - пришлось самим выяснять где синус становится 1.е+304... Так, кстати, и не нашли - пришлось костылить проверкой, а это - дополнительное время в рассчетаx...
А так.. толку от того, что сферический калькулятор не вылетает, если ему вводят буквеннные символы, но не может правильно вычислить 2+3.
-----
Да-да...
Кстати, а кто должен искать где и как синус становится 1.е+304?
Если прогер - так у него НАПИСАНО ПРАВИЛЬНО - именно так как в документации, все аргументы в допустимых границах, получаемые результаты - заданной точности. Кроме синуса. Он, кстати, не повторим...
И, кстати, тесты в 99.9% случаев будут выполнены корректно.
Кто и как будет искать где и как синус становится 1.е+304?
И, кстати, какое было задание у прогера? Чтобы калькулятор не вылетал когда ему вводят буквенные символы? Ну так он это и делает. Не вылетает. А правильно посчитать 2+3 - другая задача...
но работа тестировщика -
это часто рутина, особенно если разработчики башковитые
-----
Просто башковитым разработчикам нужны башковитые тестеры...
А зачем?
-----
Это меня, прогера, тестер спрашивает зачем тестировать?
Или непонятно что именно будет происходить после двух, при котором первый еще не диспатчирован, кликов по кнопке?
Ну так там не сложно - если нет специальных требований - будут два запроса или две записи - где-то...
Последствия? Да кто же их предскажет...
Проблема: в тестировщики часто идут те, кто не тянет в прожении - квалификация ниже и не позволяет понять где, что и как можно СЛОМАТЬ...
В реальном мире время (=деньги) это ограниченный ресурс, и тратить его на поиск и починку багов типа «тупая секретарша нажала 500 раз на одну и ту же кнопку» - экономически нецелесообразно. С точки зрения бизнеса для 99% приложений (за исключением тех, где надежность суперкритична и нужна защита от дурака всех видов) разумнее инвестировать эти средства в починку более приоритетных багов и разработку новых киллер-фич.
В реальном мире
-----
В реальном прогерском мире код обрабатывающий данную ситуацию пишется ОДИН раз.
В реальном тестерском мире требуется лишь удостоверится, что написанный код используется...
Т.е. обе части надо написать один раз.
разумнее инвестировать эти средства в починку более приоритетных багов
-----
Я сейчас как раз вожусь с кодом в котором чинили более приоритетные баги.
Чтобы понять:
- основой рассчетов является квадратный... местами - линейный вместо квадратного... метр.
- в метрах считать не удобно - перешли к количеству листов (минимальный объем доставки к станку) - там проще - вместо 0.267, 2.763, 1.987 будет 1, 3, 2.
- из листов зачем-то перешли в проценты - видимо менеджеру требовалась обобщенная картинка...
- из процентов - надо было суммировать - снова пересчитали в листы
- а из листов, через метры, - снова в проценты...
Где "сшивали" Я вижу... а вот починить, даже зная что надо считать - все еще не могу - всего в наличии листов - 9, а вот у станка лежит... 1170... толи в выборке не то, толи в процессе пересчета проценты остались...
Чего "стоило" вот такое "починение" - известно - чел слетел с катушек и слег в дурку... Я, похоже, уже тоже на пути туда...
Будем дальше гнать "починку приоритетных багов"? 
вам и так нелегко.
-----
Именно по-этому у меня требования к тестеру... хммм... "несколько завышенные" - мне нужно чтобы он не только делал рутину - для этого можно взять мартышку, но и мог сказать больше, чем чем Я написал в процессе разработки...
Блин... с количеством листов - вообще труба... считается как количество записанных в логе батчей... ну это возможно... но вот вторая часть - там "полный Пе" - вместо рассчета количества - оно просто подставляется... количеством посчитанных из лога... т.е. автоматически завышаем в разы по количеству выбранных строк... работало... блин... он всегда использовал только первую строку... Блин, как не хочется снова возвращаться к метрам...
починку багов типа «тупая секретарша нажала 500 раз на одну и ту же кнопку»
Вы не правильно понимаете ситуацию. проверяется то совсем не это.
Просто это простейший способ проверить "клиента на вшивость".
Кстати, сегодня столкнулся с двумя интересными явлениями на почве тестирования.
Два разработчика проверили одну задачу - все работает точно согласно описанию. Дают тестирам на подтверждение.
Они довольно быстро находят целый список проблемок, которые нигде не описаны точно, не влияют на описание задачи, но работа продукта при определенных алгоритмах использования будет несколько другой.
Теперь начинаем уточнять задачу, как именно должно быть во всех возможных случаях.
2. Тестировщики постоянно поддерживали таблицу с данными о быстродействии одной части проги при различных алгоритмах использования в зависимости от версии ПО.
Как они это делали было без разницы пока не получил возврат задачи оптимизации с пометкой "разницы в быстродействии не выявлено".
Выяснились интересные вещи.
Быстродействие проверялось с помощью таймера на смартфоне, при этом результаты в таблице были начиная от 300 мс (3 раза мол измеряли и после делили)
Данные были такого размера, что визуальной деградации быстродействия было незаметно.
Измерение с помощью встроенного софт таймера показало время до 100 мс.
Вы сдавали тест на Istqb на немецком или на английском? Получили дополнительные 15 мин, т.к. сдавали на не родном языке? Наш преподаватель говорит, что не положено(для тех, кто прожил больше 1,5 года в Германии). На официальном сайте, однако, говорят что положено тем, кто сдаёт на не родном языке.
Просто, если на 40 вопросов положено 60 мин, то 15 мин не будут лишними (если учесть сложность вопросов и немецкого языка).
я сдавал и рекомендую сдавать только на немецком. Хотя бы потому, что ради вас одного никто не будет дополнительно заморачиваться с английским. Подготовка будет вестись только на немецком и многие термины вы будете знать только на немецком. Кроме того сами вопросы и ответы на подготовке будут только на немецком.
Дополнительные 15 минут брать обязательно, они очень важны.
Достаточно принести и показать российский загран паспорт.
Зы. Я провалил мок на русском, но сдал реальный на немецком. Что как бе намекает на качество перевода на русский.
Понятно.На нашем курсе проблем со сдачей на английском как раз нет, а вот с 15 доп.мин есть)))). Что за бред и из какого пальца он высосал правило про 1,5 года....Это говорит многое о его профессионализме....
Про силлабус на русском - вы правы, читаю оба и отличия заметны (особенно тонкости в формулировках ,что очень важно).
Интересно, как вы находите, Моки в сравнении с реальным экзаменом?
Сам экзамен был сложнее или тот же уровень? Есть платформа с более чем 500 вопросами- симуляторами. Есть ли смысл уделять ей много времени, если времени в обрез...
Вернулся из отпуска и подниму тему :D
Да и мне лично какой интерес от того что получен отчет, всё работает как и раньше.
В этом суть тестирования. Тестирование дает гарантию того, что продукт (фича) работает также, как и раньше. Ручное тестирование штука трудоемкая и дорогая, поэтому придумали тест-планы, кучу различных видов тестирования и методик.
Зато вот когда что то не так это уже интересней, можно и рассказать и запоминается.
Возможно, но скорее всего это просто неэффективно.
Предположим у тебя массовый продукт и примерно 1млн человек использует твой софт. При этом у 90% пользователей проблем нет. Зато у 100 человек хреновая сетевая карта и иногда вываливается сетевой кабель. По опыту могу сказать, что если ошибка регистрируется редко, то ей присвоят минимальный приоритет и руки до нее скорее всего никогда не дойдут. Так стоит ли тратить на это дорогой ресурс? Ведь тестировщик должен убедиться, что 90% пользователей будут довольны.
Есть и другая ниша - штучный продукт, но в таком случае разработчики, как правило, имеют прямой контакт с потребителем. Тут все тоже самое, что и в 1-ом случае - есть некий функционал, который важен для заказчика и есть миллион факторов, которые влияют на работоспособность. Есть проблемы, которые появляются часто и есть редкие проблемы. Так вот тестировщик должен убедиться, что система не стала работать хуже, чем работала до того.
А проблему с выдернутым сетевым кабелем тестировщик зачастую и не может воспроизвести :) Да и юнит-тест тут подходит лучше.
С другой стороны, зачем нужен тестер которой будет проверять работу исключительно в правильных "режимах"?
Зачем нужен тестировщик, который делает случайные тесты? :)
А проблему с выдернутым сетевым кабелем тестировщик зачастую и не может воспроизвести :)
-----
Если бы это была единственная проблема которую тестер никак не осознает...
Вот еще одна.
Прибежал техник со стороны для обслуживания чего-то там.
Пока делал - прописал себе под что-то ему одному нужное статический ИП.
Сделал - убежал.
А ИП - остался прописанным.
По случаю - совпал с ИПом сервера базы.
Маршрутизатор - умный - обрабатывает ОБА одинаковых ИПа.
Т.е. один пакет кидает на сервер, второй - на хрен знает куда...
Может тестер ЭТО придумать? Какие познания в сетях у него должны быть?
Так тестеру это и не надо осознавать ;)
-----
Правда что ли?
Ну и каким же образом тестера вообще могут дойти до необходимости проверять работоспособность в этих условиях?
Ну а если уж отавать нетещеное - так нах тогда тестера держать?
На уровне "не-е, не работает" - мне не интересно. Т.е. Я это увижу БЕЗ тестера - уведомление об сбое придет.
Мне интересно на уровне - "не работает при потере более 10% пакетов", "не обрабатывается ошибка наличия второго ИП в сети" и т.п.
Ну и каким же образом тестера вообще могут дойти до необходимости проверять работоспособность в этих условиях?
Так это от тестера никто и не ожидает :D
так нах тогда тестера держать?
Задача тестера - убедиться в том, что продукт работает также, как и в прошлый раз. Собственно говоря это задача любого тестирования. Тестер нужен там, где нельзя (ну или слишком трудоемко) выполнить тест автоматически. Тестер - это дорогой ресурс и если рассматривать тестера как "человека для поиска багов", то ресурс этот не только очень дорогой, но еще и с крайне низким КПД.
Тесты делаются для того, чтобы убедиться в том, что система все еще "зеленая". И не важно ручные это тесты, автоматические, юнит-тесты, системные, нагрузочные или еще какие.
Ни один здравомыслящий менеджер не поставит тестировщика "искать баги" :) А если кто-то ставит такую задачу, то этот менеджер просто некомпетентен и должен быть уволен как минимум за растрату денег :)
Я это увижу БЕЗ тестера - уведомление об сбое придет.
После этого уведомления ты должен:
1) создать тест-кейс, в котором будет приходить уведомление о сбое
2) пофиксить баг
3) убедиться, что уведомление о сбое больше не приходит
4) выполнять этот тест всегда
Все должно быть быть проделано именно в таком порядке. При этом тестировщик будет принимать участие на этапах 1, 3 и 4.
Мне интересно на уровне - "не работает при потере более 10% пакетов", "не обрабатывается ошибка наличия второго ИП в сети" и т.п.
Формулируешь то, что тебе интересно в ТЗ, тестировщик делает тест-кейс и прогоняет
его всегда.
По моему вы как-то недооцениваете работу тестировщика. Я сейчас на курсах по тестированию.Со мной здесь почти все из программистов.
Тестировщик, например может сделать следущее:
Äkvivalenzklassentest
Grenzwertanalyse
Entscheidungstabellentest
Zustandbasiertertest
Anwendungsbasierte
Anweisungstest
Zweigtest
Pfadtest
Dynamisch-Statischtest
Funktional-nichtfunktionaltest
Это ли не в помощь программисту....и это ещё далеко не половина того, что он может...
Со мной здесь почти все из программистов.Очень может быть. Программистам тоже полезно понимать зачем нужно тестирование :)
Опять же, тестирование бывает не только ручным (ручное тестирование - это совсем дорого и совсем мало эффективно), но автоматизированным. Более того, именно в сторону автоматизированного тестирования и идет развитие.
Тестировщик, например может сделать следущее:
Можно расшифровки всех этих терминов? :) А то мы будем говорить каждый о своем.
Многие из перечисленных тестов здесь:
https://de.m.wikipedia.org/wiki/Kontrollflussorientierte_T...
на графике показано, что стоимость проектов без тестера и с тестером одинакова, т.к. затраты на исправление багов(без тестировщика)= зарплата тестировщика.
Ни один здравомыслящий менеджер не поставит тестировщика "искать баги"
-----
Ну а кодера - легко поставит писать тесты...
Ну или искать проблему типа описанной выше...
Кстати, а кого он поставит на поиск указанного "бага"? Просто интересно - какой специалист должен этим заниматься...
И... это... Я не здравомыслящий менеджер - т.е. менеджер, который работает с тем набором людей какой ему дают, а всего лишь прогер, которому тестер нужен как расширение фукнционала или на съем части нагрузки. Потому Я буду искать тестера с квалификацией позволяющей выполнить 1) самостоятельно и ко мне прийти уже с достаточно четкой формулировкой проблемы.
1) создать тест-кейс, в котором будет приходить уведомление о сбое
-----
Вот оно самое и есть - создать ситуацию воспроизводящую уведомление об сбое.
Вот и расскажи мне как он это сделает в своей сетке в описанном случае.
И, пойми, меня НЕ интересует факт сбоя или его отсутствия (у тестера) - Я уже имею уведомление и оно достаточно детализированное.
Меня интересует чтобы Я не тратил свое время на поиск того что вызвало данное уведомление. Бо, задавить его Я могу и без тестера.
И - ДА - на вопрос тестера - Что изменилось? - будет дан 100% точный ответ - НИ-ЧЕ-ГО.
В смысле - в софте - ничего. Ничего не инсталилось, ничего не менялось в соурсах, в текущей сети (мною) и на сервере... ни-че-го...
Если ты пишешь юнит-тесты, то то, что описано по ссылке, возможно, тебе и пригодится. Хотя Visual Studio отлично умеет считать coverege и подкрашивать зелениньким "протестированное" и красненьким "не тестированное" :) Есть также статические анализаторы кода, которые показывают в том числи в цикломатическую сложность. Нужно ли все это тестеру? Если ты собираешься писать юнит-тесты, то да. Если программисты будут писать тестируемый код, то это даже улучшит надежность и качество кода.
Занимаются ли тестеры написанием юнит-тестов? Скорее нет :)
на графике показано, что стоимость проектов без тестера и с тестером одинакова, т.к. затраты на исправление багов(без тестировщика)= зарплата тестировщика.
лично у меня этот график вызывает сомнения :) я бы даже сказал, что это полная глупость, т.к. тестировщик не исправляет баги, он вылавливает "отклонения" на ранней фазе. Т.е. наличие тестировщика никак не влияет на стоимость исправления бага.
Опять же, если мы говорим о юнит-тестировании, которое требует задумываться об архитертуре приложения, то тут уже другая история и в долгосрочной перспективе использозование юнит-тестов удешевляет разработку.
как раз так: чем ранее тестировщик заметит отклонения, тем меньше стоимость исправления этой ошибки, т.к.ошибка найденная на поздней стадии может стоить очень дорого или вообще подвергнуть риску продукт.
Методы тестирования, что я описала относятся не только к White-box testing a также и к Black-box тестингу.А это намного шире Unit или Modul тестирования.Вы не находите?
Мне рано с вами спорить- у меня пока одна теория)))...практики нет...
Но мне кажется, наличие тестировщика по любому повышает процент качества самого продукта...Ведь каждый регрессионный тест (после исправления ошибок) это по сути ухудшение качества софта.Или я не правильно понимаю?
И еще, интересно, есть ли такой автоматизированный тест, который проверит, что переменной дано правильное значение?
В этом суть тестирования.
В этом суть регресионного тестирования, безусловно важного которое и стремятся обычно автоматизировать.
Речь же шла несколько о другом. Зачем мне в единственном экземпляре тестировщик, который кроме регресионного тестирования ничего больше не умеет?
Предположим у тебя....
А не надо ничего предполагать, это довольно хорошо известно, как и предполагаемая среда использования.
Я вот помню нас начальник отдела поддержки хорошо проучил. Писали мы ему письма, расскажите, что плохо, как сделать лучше? А он один раз говорит приходите ко мне с новой версией, я вам все покажу.
Он нам в руки лэптоп, вон говорит стоит устройство делайте, что нужно. Мы ему, а там же стол закрывает половину, может отодвинуть - а он, не так наши клиенты и работают. Каждый попробовал и сразу стало понятно где проблемы.
Да и юнит-тест тут подходит лучше.
Да, интересно, хотел бы глянуть как он воспроизведет туже самую ошибку от винды и это не эксепшион внутри проги.
Зачем нужен тестировщик, который делает случайные тесты?
Может вам и не нужен, да и тесты были не случайные как может показаться.
И еще, интересно, есть ли такой автоматизированный тест, который проверит, что переменной дано правильное значение?
Зависит от того что конкретно вы подразумеваете. И на каком уровне работаете? Если на уровне кода, то проблем, не вижу если есть доступ к значению переменной, и если четко определено "правильное значение"
чем ранее тестировщик заметит отклонения, тем меньше стоимость исправления этой ошибки, т.к.ошибка найденная на поздней стадии может стоить очень дорого или вообще подвергнуть риску продукт.
Это очень спорное утверждение :) Стоимость исправления ошибки зависит скорее от слоя, в котором была найдена ошибка. Т.е. если ошибка в компоненте низкого уровня, то изменение этой компоненты может повлечь изменения в компонентах более высокого уровня.
Есть конечно еще случай, когда один костыль подпирается другим костылем и так штук 10-20-100 (в зависимости от сложности) костылей. В этом случае исправление самого "нижнего" костыля также может повлечь большие изменения, но в этом случае время обнаружения проблемы также играет слабую роль :) Ну если только за это время еще штук 200 костылей не добавили :) Но тут уж сами себе злобные Буратино и никакое тестирование эту коллекцию костылей уже не спасет :D
Методы тестирования, что я описала относятся не только к White-box testing a также и к Black-box тестингу.А это намного шире Unit или Modul тестирования.Вы не находите?
Я нахожу, что софт должен соответствовать спецификации :) Ну и я не вижу никакого смысла в разделении на white-box-testing и black-box-testing. Собственно говоря, unit-тестирование - это black-box-тестирование ;) А всякие метрики (всевозможные типы покрытия) высчитывает Visual Studio. Кстати "Modul" переводится на англиский как "unit" :)
Но мне кажется, наличие тестировщика по любому повышает процент качества самого продукта...
Я с этим и не спорю :)
Ведь каждый регрессионный тест (после исправления ошибок) это по сути ухудшение качества софта.Или я не правильно понимаю?
Неправильно. Каждый регрессионный тест - это улучшение качества софта, т.к. тестом подтверждается, что проблемы больше нет.
И еще, интересно, есть ли такой автоматизированный тест, который проверит, что переменной дано правильное значение?
Я не совсем понимаю, что ты хочешь спросить :)
Если речь о какой-то внутренней (приватной) переменной, то ее значение никого не интересует и проверять ее в принципе не надо.
Если речь идет о каком-то состоянии объекта, которое видимо для других объектов, то да, такой тест сделать можно.
Зачем мне в единственном экземпляре тестировщик, который кроме регресионного тестирования ничего больше не умеет?
А что за тестировщик тебе нужен? И, самое главное, зачем тебе нужен именно такой тестировщик? Как измерять эффективность работы такого тестировщика и какой она (эффективность) должна быть?
Я вот помню нас начальник отдела поддержки хорошо проучил. Писали мы ему письма, расскажите, что плохо, как сделать лучше? А он один раз говорит приходите ко мне с новой версией, я вам все покажу.Он нам в руки лэптоп, вон говорит стоит устройство делайте, что нужно. Мы ему, а там же стол закрывает половину, может отодвинуть - а он, не так наши клиенты и работают. Каждый попробовал и сразу стало понятно где проблемы.
Ну ОК, нету грамотных ПМов, которые знают что нужно клиенту и умеют поставить задачу. И что? В чем тут учение?
Да, интересно, хотел бы глянуть как он воспроизведет туже самую ошибку от винды и это не эксепшион внутри проги.
Делаешь враппер и генерируешь через него любую ошибку. В чем проблема? У нас, была проблема, что при перечислении всех имеющихся в системе дисков мы выбирали один и пытались на него писать. Все было хорошо до тех пор, пока у одного клиента не было установлено ограничение в правах. При этом выглядело все так - диск в списке появлялся, но при получении информации о нем вылетало исключение. Я просто сделал враппер над DriveInfo и никаких гвоздей :)
Делаешь враппер и генерируешь через него любую ошибку. В чем проблема?
-----
Проблема в том, что ты требуешь делать очередной костыль вместо выяснения реальной причины вызывающей проблему.
И, кстати, костыль совершенно лишний - условия возникновения ошибки соответствуют неработоспособности сети как таковой и в прикладе это не лечаt...
Проблема в том, что ты требуешь делать очередной костыль вместо выяснения реальной причины вызывающей проблему.
:) Как можно выяснить то, что лежит за пределами доступности? :)
И, кстати, костыль совершенно лишний - условия возникновения ошибки соответствуют неработоспособности сети как таковой и в прикладе это не лечаt...
Так проблему и не надо лечить, надо чтобы мой софт корректно обработал возникшую проблему. Для того, чтобы корректно обработать, нужно поместить систему и условия, когда эта проблема возникла. Враппером можно симулировать любую ситуацию и таким образом можно проверить корректную работу системы.
А причины возникновения ошибки интересны только для того, чтобы не говорить "никогда такого не было и вот опять" :) Ну что тебе даст знание, того, что "какой-то техник поменял IP" или "полиси концерна требуют, чтобы диск D был защищен от чтения и записи" или "уборщица Клава махнула шваброй и выдернула сетевой кабель"? Толку от знания этих причин никакого. Более того, софт не может эти причины "пофиксить", а вот реагировать на них он должен правильно.
Так что это не костыль,
это методология, которая позволяет абстрагироваться от окружения и тестировать то, что нужно тестировать (а метаться между тестовой и живой БД).
Как можно выяснить то, что лежит за пределами доступности?
-----
Ну вопрос об том кого мудрый менеджер поставит определять причину Я уже задал. А вот ответа пока не слышал...
Враппером можно симулировать любую ситуацию и таким образом можно проверить корректную работу системы.
-----
Нет проблем - пиши враппер второго ИПшника в сети.
Проверять будешь совершенно стандартное дело:
OracleConnection oraCN = new OracleConnection();
try
{
oraCN.ConnectionString = ConnectionString;
oraCN.Open();
}
catch(OracleException oex)
{
тут будет все что тебе надо - раз - правильно, другой - ошибка...
}
софт не может
-----
Ошибаешься.
У меня - софт продолжает работать, включая ситуацию когда сеть не может нормально работать из-за второго ИПа. Медленно только...
Просто когда причина установлена - есть возможность обрабатывать именно причину, а не бороться со следствиями...
Ну вопрос об том кого мудрый менеджер поставит определять причину Я уже задал. А вот ответа пока не слышал...
Ответ в том, что причина никого не интересует. Тестировщик ли Петя вбил статический ИП или админ Коля перепутал маску подсети - разработчика софта это не интересует. Разработчика интересует может быть такая ситуация или нет.
Нет проблем - пиши враппер второго ИПшника в сети.
Ты сам понял, что спросил?
Ну а враппер будет прост как мычание:
public interface IOracleConnection, IDispocable
{
string ConnectionString { get; set; }
void Open ();
}
public class OracleConnectionWrapper : IOracleConnection
{
private OracleConnection oracleConn = new OracleConnection();
public string ConnectionString
{
get { return oracleConn.ConnectionString; }
set { oracleConn.ConnectionString = value; }
}
public void Open ()
{
oracleConn.Open ();
}
public void Dispose ()
{
oracleConn.Dispose ();
}
}
public class SomeCoolClass ()
{
// Инекцию можно сделать так, либо через конструктор, либо можно через конструктор передать фабрику...
protected virtual IOracleConnection OracleConnection { get { return new OracleConnectionWrapper (); } }
public void DoSomething ()
{
using (IOracleConnection oraCN = OracleConnection)
{
try
{
oraCN.ConnectionString = ConnectionString;
oraCN.Open();
}
catch(OracleException oex)
{
тут будет все что тебе надо - раз - правильно, другой - ошибка...
}
}
}
}
Таким образом при вызове Open () или сеттера ConnectionString я в тесте смогу сгенерировать любое исключение и таким образом проверить стабильность кода.
А что за тестировщик тебе нужен?
Ну если рассматривать ту ситуацию что была, то можно сказать хороший.
Который сам читает все что есть из доков, делает сводные таблицы в экзеле, и даже на этом этапе уже находит нестыковки.
Да многое еще было чего, не делала она ничего не шару и привносила много нового от себя
Ну ОК, нету грамотных ПМов, которые знают что нужно клиенту и умеют поставить задачу.
Какой бы грамотный не был ПМ, он никогда не сможет знать всех ньюансов.
И что? В чем тут учение?
В том, что когда сам на своей шкуре почувствуешь как это в одной руке держать лэптоп и сенсор, а другой еще что то набирать, то сразу забудешь какой замечательный и удобный контрол мы сделали.
Тут кстати и шнур выдергивается на раз.
Делаешь враппер и генерируешь через него любую ошибку.
Что то я не понимаю как изнутри программы сделать ошибку которая в обычном случае до программы просто не доходит. Можешь мне враппер сделать на выключение питания компа?
Жалко я уже всех подробностей не помню. Помню только что довольно долго с этим разбирались.
смогу сгенерировать любое исключение
------
А толку то c этого?
Ты хоть примерно представляешь как будет вести себя оракловский коннектион при указанных условиях ?
Подскажу - исключения вида "обнаружен дубликатный ИП в сети" у него нету. Просто нету.
А про то, что есть Я немного раньше, когда проблема была, спрашивал.
Ты сам понял, что спросил?
------
Разумеется. Я так думал, что сейчас нам продемонстрируют именно решение... ну хотя бы на уровне подмены сокета и реальной эмуляции сети с парой одинаковых ИПов...
Задача то именно так определена.
причина никого не интересует
------
Недавно отвечал на вопрос - Вот мы тут написали и у нас все работает. А у клиента - не работает. Как сделать чтобы у клиента работало?
Код - простой как три рубля - открывается сокет в него пишется и из него читается.
Все пашет идеально. Кинули - получили, ответили - получили. Любые тайминги для обработки. Все тесты - зеленые.
Но у клиента - упадет непременно - причину Я знаю и обойти ее нельзя. Т.е. упадет гарантированно.
И что бы ты посоветовал в этой ситуации с учетом "причина никого не интересует"?
Да, добавлю.
Если тесты прогнать на системе клиента - они останутся зелеными.
Мало того - можно сертифицировать прогу - никаких ошибок в работе с сокетом не сделано - исключения обрабатываются и все аспекты поправляются.
Остальное тоже имплементировано вполне приемлемо, хотя и не влияет на ситуацию.
Но!!! работающая софтина - упадет неприменно.
Ну если рассматривать ту ситуацию что была, то можно сказать хороший.Который сам читает все что есть из доков, делает сводные таблицы в экзеле, и даже на этом этапе уже находит нестыковки.Да многое еще было чего, не делала она ничего не шару и привносила много нового от себя
Ну это ты замечательно описал сферического коня в вакууме :) И вообще "мы за все хорошее и против всего плохого" :) Однако ответа на поставленный вопрос нет.
Какой бы грамотный не был ПМ, он никогда не сможет знать всех ньюансов.
И что? Никому и не надо знать всех ньюансов. Тот начальник тоже не знает всех ньюансов.
В том, что когда сам на своей шкуре почувствуешь как это в одной руке держать лэптоп и сенсор, а другой еще что то набирать, то сразу забудешь какой замечательный и удобный контрол мы сделали.Тут кстати и шнур выдергивается на раз.
Все это мило, но я тут вижу проблему в постановке задачи.
Что то я не понимаю как изнутри программы сделать ошибку которая в обычном случае до программы просто не доходит.
Если ошибка до программы не доходит, значит твоя программа работает корректно и, соответственно, никакой ошибки нет.
Можешь мне враппер сделать на выключение питания компа?
Конечно могу. Как только ты приведешь мне код программы, которая будет работать на выключенном компе.
Ты хоть примерно представляешь как будет вести себя оракловский коннектион при указанных условиях ?
Без понятия. Полагаю, что он либо сконнектится, либо отвалится с таймаутом, в зависимости от везения.
Подскажу - исключения вида "обнаружен дубликатный ИП в сети" у него нету. Просто нету.А про то, что есть Я немного раньше, когда проблема была, спрашивал.
Ты полагаешь, что я должен начать искать описание того, что у тебя там было? :)
Я так думал, что сейчас нам продемонстрируют именно решение... ну хотя бы на уровне подмены сокета и реальной эмуляции сети с парой одинаковых ИПов...Задача то именно так определена.
Зачем подменять сокеты или определять одинаковые ИП? При разработке софта исходить надо из того, что окружение работает без ошибок (сообщения о возникающих проблемах - это тоже безошибочная работа). Это значит, что сокет работает правильно. Это значит, что рутер работает правильно. И это значит, что в используемых протоколах (TCP, UDP) нет ошибок. Сетевая карта работает без сбоев. итд. Нет никакого смысла подменять сокеты, если ты не работаешь напрямую с сокетами. В твоем примере ты работаешь с внешней компонентой (OracleConnection), а значит именно ее и нужно заменять фейком.
И что бы ты посоветовал в этой ситуации с учетом "причина никого не интересует"?
Ты мешаешь мух с котлетами. Если у клиента что-то не работает, то это безусловно проблема. Однако это может быть как проблема твоего софта (тогда это твоя проблема), а может быть проблема конфигурации окружения у клиента (тогда это проблема клиента).
Я не собираюсь гадать и придумывать разные варианты решения возникшей у тебя проблемы.
Когда у клиента возникает какая-то проблема, то он (клиент) эту проблему репортит и разработчик должен проанализировать проблему и найти ее причину. А дальше идет уже следующий этап - надо принять решение, чья это проблема - разработчика (т.е. ошибка в коде, отсутствие какой-то фичи что-то еще) или клиента (конфигурация софта, окружения или еще что-то).
Вот у меня буквально вчера была такая ситуация: пришел баг-репорт о том, что не работает одна фича. Стал смотреть, оказалось, что клиент сконфигурировать систему так, что данные писались в несуществующую папку на несуществующем диске. Вывод - клиент должен правильно конфигурировать систему. Результаты были отправлены клиенту и досвидос. Я, как разработчик, не могу решить эту проблему в run time, но я могу правильно обработать ошибку (что и было сделано :D)
А причины, почему у клиента не было доступа к сконфигурированной папке меня совершенно не интересуют.
Без понятия.
-----
Ну и как же ты это - без понятия - собираешься эмулировать?
должен начать искать
------
Нее - ты, по твоему собственному заявлению, все сделаешь сразу даже не зная что за оно там было...
либо сконнектится, либо отвалится
-----
Если бы оно было так просто...
В некоторых случаях будет получена полуоткрытая коннекция, которую, к тому же, никак не закрыть без обрыва сети...
ты работаешь с внешней компонентой (OracleConnection), а значит именно ее и нужно заменять фейком.
-----
Двумя строками выше ты указал, что не имеешь предстявления об том, что будет ответом этой компоненты на указанную ситуацию, Т.е. не можешь заменить ее фейком. Просто по незнанию внешних проявлений сторонней проблемы.
Зачем подменять сокеты
-----
Ну так поставлення задача - симулировать обнаруженную ошибку, Ошибка - описана - второй ИП в сети.
должен проанализировать проблему и найти ее причину
-----
Как ты ее будешь искать в условиях - "причина никого не интересует"?
Ну повторю еще раз - в написанном коде проблемы НЕТ.
На всякий случай - у клиента - тоже все без ошибок.
но я могу правильно обработать ошибку
-----
Проблема в том, что не зная причины ты не можешь правильно обработать ошибку.
Ты можешь подавить часть (не все - в силу незнания причины и всех вариантов) последствий.
Не более.
Назвать тебе причину по которой не работало и не могло работать то что было описано
или ты сможешь ее обработать без этой информации?
Повторюсь - ошибок - нет. В коде (и конфигурации) 100% нет никаких ошибок.
А причины, почему у клиента не было доступа к сконфигурированной папке меня совершенно не интересуют.
-----
Меня - тоже.
Тем более, что ситуация с отсутствием доступа - решаемая.
Правда только после того как станет понятно, что это именно эта ситуация.
Ну и как же ты это - без понятия - собираешься эмулировать?
Ну во-первых, я ничего не собираюсь эмулировать. Это был твой пример и я не собираюсь разбираться в том, как работают твои компоненты.
Во-вторых, никому не надо эмулировать работу компоненты, достаточно эмулировать ответы. Т.е. сеттер для ConnectionString ничего не будет устанавливать, а функция Open не будет открывать никакие сокеты, она либо просто вернется (таким образом эмулируется успешное соединение), либо кинет исключение (эмуляция ошибки). Никаких других вызовов в твоем примере не было.
В-третьих, для тестирования OracleConnection - это черный ящик и мне глубоко фиолетово как он там работает.
Нее - ты, по твоему собственному заявлению, все сделаешь сразу даже не зная что за оно там было...
Ты либо не понял
того, что я сказал, либо умышленно перевираешь мои слова.
В некоторых случаях будет получена полуоткрытая коннекция, которую, к тому же, никак не закрыть без обрыва сети...
Да и ради бога. Если ты это может узнать обращаяь к своему объекту, значит это поведение можно эмулировать.
Двумя строками выше ты указал, что не имеешь предстявления об том, что будет ответом этой компоненты на указанную ситуацию, Т.е. не можешь заменить ее фейком. Просто по незнанию внешних проявлений сторонней проблемы.
Поведение системы в указанных условиях известно тебе (ты это уже изучил), мне же совершенно до лампочки как ведет себя OracleConnection в описанных тобой условиях, я с этим компонентом никогда не работал. Ты сам привел код, который попросил обернуть во враппер, чтобы эмулировать поведение OracleConnection. Я показал тебе как это можно сделать. Только и всего.
Ну так поставлення задача - симулировать обнаруженную ошибку, Ошибка - описана - второй ИП в сети.
Это не ошибка в поведении твоей компоненты. Симулировать надо внешнюю среду, в приведенном тобой привере внешняя среда - это OracleConnection. Как работает OracleConnection (через сеть ли, или передает открывает БД напрямую с диска или соеденяется с БД через COM-порт или работается через пайпы или шаред мемори
или еще как) - не важно. Если в сети есть 2 одинаковых ИП, то задача съэмулировать поведение OracleConnection в данных условиях. Делать сеть с двумя ИП имеет смысл только для того, чтобы выяснить поведение OracleConnection в таких условиях. Для теста же, который должен работать после каждой сборки, настраивать сеть с 2 ИП - тупость.
Как ты ее будешь искать в условиях - "причина никого не интересует"?
Очень просто. Причина сбоя программы и причина возникновения проблемы - это две большие разницы. В твоем примере, причина сбоя - это 2 одинаковых ИП в одной сети. Причина возникновения проблемы - монтер Вася, который забыл вернуть измененную конфигурацию. Так вот причина позникновения проблемы никого не волнует, т.к. сегодня это может быть монтер,
а завтра админы объеденят две подсети в одну или сотрудник со воим ноутом со статическим ИП придет в переговорку в соседний корпус.
Назвать тебе причину по которой не работало и не могло работать то что было описано или ты сможешь ее обработать без этой информации?
Я не собираюсь играть с тобой в угадайку. Хочешь называй, не хочешь не называй.
Тем более, что ситуация с отсутствием доступа - решаемая.
А вот это совсем не факт. И уж тем более, с вероятностью 99,99% эта проблема не решается софтом, который должен эту проблему корректно обработать.
либо кинет исключение (эмуляция ошибки)
-----
Ну ладно - не буду тебя мучать - там не будет одного только исключения.
Там будет группа исключений выбрасываемых в зависимости от состояния а:) самого коннекта, б) состояния сокетов, в) того куда уйдет очередной пакет на маршрутизаторе.
Пока ты этого не поймешь - ты можешь делать что угодно в коде (и тестах) но проблему - не решишь.
это черный ящик и мне глубоко фиолетово как он там работает
-----
Ну так проблема в том что именно оно там в этих условиях и не работает.
А починить - надо.
Можно в прикладе. Можно в системе. Можно просто устранить причину.
Но для любого из этих решений надо знать в чем причина и чем ее дрючить...
может узнать обращаяь к своему объекту
-----
Сокет не является моим объектом.
который попросил обернуть во враппер
-----
Я не просил оборачивать компонент во вреппер. Я привел код (свой) в котором
происходит ошибка и попросил тебя проэмулировать именно ошибку.
Почему так? Да потому что у меня рядом с Ораклом стоит Порстгрее и оно
в этой ситуации будет иметь те же самые проблемы.
то задача съэмулировать поведение OracleConnection в данных условиях
-----
Ну не можешь ты эмулировать это поведение. Просто не знаешь что именно происходит.
Я не собираюсь играть с тобой в угадайку.
-----
В угадайку - не играем и понять почему не работает - тоже не можем.
Ладушки - проблема в том, что у клиента не вся сеть TCP/IP-UDP.
В ней есть участки работающие по совершенно другим протоколам со всеми их ограничениями.
Пока не изучишь что именно там есть и как с ним работать - все будет идеально написано и нефига не будет работать...
с вероятностью 99,99%
-----
Файловый менеджер отследит возникновение проблемы доступа и сбросит информацию в биефкасе в директории юзверя.
По крайней мере у меня все работает именно так - упала/недоступна база - все сейчас пишем локально, потом будем синхронизировать.
Ну а файл у себя юзверь всегда создает.
Там будет группа исключений выбрасываемых в зависимости от состояния а:) самого коннекта, б) состояния сокетов, в) того куда уйдет очередной пакет на маршрутизаторе.
Там могут быть исключения любой сложности и вложенности и с любыми параметрами. Как только ты знаешь что там происходит, ты сразу можешь рапилить тест и убедиться, что твой софт работает правильно и правильно отрабатывает внештатную ситуацию. И тест этот работать будет всегда и предельно быстро. И для этого теста не надо будет добавлять дубликатный ИП.
Сокет не является моим объектом.
Так на кой хрен ты могда заговорил о том, чтобы эмулировать сокет?
Я не просил оборачивать компонент во вреппер.
Ну да, ты попросил какую-то дичь: Нет проблем - пиши враппер второго ИПшника в сети. И привел при этом код, который к ИП вообще никак не относится.
Я привел код (свой) в котором происходит ошибка
и попросил тебя проэмулировать именно ошибку.
Тебе было показано как можно абстрагироваться от OracleConnection, а обработку ошибки можешь тестировать бросая все эти "группы исключений" так, как тебе надо.
Ну не можешь ты эмулировать это поведение. Просто не знаешь что именно происходит.
Ну значит сначала выясняешь, а потом, в тесте, эмулируешь. В чем проблема?
Ладушки - проблема в том, что у клиента не вся сеть TCP/IP-UDP.В ней есть участки работающие по совершенно другим протоколам со всеми их ограничениями. Пока не изучишь что именно там есть и как с ним работать - все будет идеально написано и нефига не будет работать...
Я понятия не имею, что тут имеется в виду. В любом случае, данную проблему, если она вообще есть, нельзя исправить софтверно. А значит, после того, как ты все это выяснил, ты просто описываешь клиенту проблему и он решает ее сам для себя.
Как только ты знаешь что там происходит
-----
Так об этём и речь - когда знаешь причину - можно ее купировать, а не бороться с последствиями.
Но для этого надо установить именно причину.
Работая с ОраклеКоннектион указанную причину выяснить невозможно - не его уровень.
любой сложности и вложенности
-----
Ты все еще не понимаешь - там нет сложности и вложенности.
Там есть разные исключения для одной и той же операции.
Один раз тебе скажут - не коннектится, другой раз - ошибка записи, третий раз - потеря соединения.
Это из тех, до которых Я смог докопаться. Кроме этого есть еще куча разных других, в том числе и тех об которых Я не знаю.
ты попросил какую-то дичь
-----
Разумеется - Я просил эмулировать проблему, которую ты взялся законопатить враппером.
Причем указал что именно надо подменить. Правда умолчал об том, что этот враппер надо
будет скормить Коннектиону.
как можно абстрагироваться от OracleConnection
-----
Но оно не решает поблему. Оно позволяет сделать костыль для Коннектиона, но и только.
можешь тестировать бросая все эти "группы исключений" так, как тебе надо
-----
А кто будет выяснять какие именно будут "группы исключений"? Источником то черный ящик выступает.
А в доках нет никаких описаний "ехцептиона двойного ИП в сети".
Т.е. либо нужно разбираться с тем что и где, либо... хммм... никак.
В чем проблема?
-----
Эээ... гхммм...
А с какой стати Я должен разбираться в том, почему не работает написанный в соответствии со спецификацией
и многократно проверенный код?
Вот скажет мне тестер что он воспроизвел ситуацию возникновения проблемы и что проблема вот такая и при
этом оно не работает, а выдает "вот такое исключение" - я исключение обработаю без проблем.
Ну а если тестера берем подешевле - только чтобы не путал какие тесты запускать - то и вообще чинить нечего.
В любом случае, данную проблему, если она вообще есть, нельзя исправить софтверно.
-----
Ошибаешься - решается именно софтово. Но только после того как в деталях ознакомишься с тем
что там может быть, как это выяснить и как с этим работать.
он решает ее сам для себя.
-----
Он, вообще-то, даже не подозревает, что у него есть какие-то сети...
И сделать он с этим ничего не может - часть устройств сети, включая рутеры, вообще являются носимыми
устройствами.
Так об этём и речь - когда знаешь причину - можно ее купировать, а не бороться с последствиями.
Тесты делаются не для того, чтобы что-то там купировать. Они делаются для того, чтобы гарантировать, что твой софт работает так как надо и что это надо не изменилось со времени последнего билда.
Там есть разные исключения для одной и той же операции.Один раз тебе скажут - не коннектится, другой раз - ошибка записи, третий раз - потеря соединения.
Это ты не понимаешь. В описанном тобой случает делается просто три теста - один когда не коннектится, другой при ошибке записи и третий при потери соединения. Различия между этими тестами - выбрасываесое исключение. А дальше просто убеждаешься, что при одном, другом или третьем исключении программа ведет себя так, как надо. Например, при потере соеденения твоя программа принудительно высывает функцию Close. Для такого теста не надо ни регистрировать 2 одинаковых ИП, ни выдергивать кабель, ни отключать рубильник.
Разумеется - Я просил эмулировать проблему, которую ты взялся законопатить враппером.Причем указал что именно надо подменить. Правда умолчал об том, что этот враппер надо будет скормить Коннектиону.
Не надо мне указывать, что именно надо подменять. Тем более, что ты не понимаешь как работают юнит-тесты, зачем они нужны и почему они эффективны :)
Но оно не решает поблему. Оно позволяет сделать костыль для Коннектиона, но и только.
Оно позволяет абстрагироваться от чужой компоненты и протестировать свой код. Никаких костылей там нет.
А кто будет выяснять какие именно будут "группы исключений"?
Группы исключений будут перечислены в логе.
А с какой стати Я должен разбираться в том, почему не работает написанный в соответствии со спецификациейи многократно проверенный код?
С той, что ты не можешь гарантировать, что твой код рабочий. У тебя же нет тестов, которые проверяют, что ты правильно реагируешь на внештатные ситуации.
Ошибаешься - решается именно софтово. Но только после того как в деталях ознакомишься с тем что там может быть, как это выяснить и как с этим работать.
Я даже не представляю, что это могут быть за протоколы такие, которые гробят использующие TCP/IP - UDP приложения :) Все это попахивает лапшой :)
Он, вообще-то, даже не подозревает, что у него есть какие-то сети... И сделать он с этим ничего не может - часть устройств сети, включая рутеры, вообще являются носимыми устройствами.
Все интереснее и интереснее :)
Клиент не знает, что у него есть сети, при этом там куча рутеров и куча подсоедененных (по WLAN?) носимых устройств. Очевидно, что подсоедениться к этому может каждый, каждый же может определить любой IP адрес, да еще используя какой-то неведомый протокол обвалить софт. И ты хочешь сказать, что это все правда?
Ну это ты замечательно описал сферического коня в вакууме
Чтобы описать как может понравиться нужно море времени и громадное желание что мне обязательно нужен тестировщик.
Все это мило, но я тут вижу проблему в постановке задачи.
Как ни странно постановка задачи был корректной. И все были довольны, в том числе и заказчик. Не были бы довольны только конечные пользователи и то те которые не в офисе.
Если ошибка до программы не доходит
имелось в виду до исполняемого кода который можно контролировать. Вроде нужно было еще какую-то фигню от мелкософта установить и что-то при сборке проги подшаманить.
значит твоя программа работает корректно
Если приложение работает корректно это еще не значит что пользователь не будет видеть там ошибок.
Как только ты приведешь мне код программы, которая будет работать на выключенном компе.
Да нет проблем - printf("Hello world") - если не видишь результата, это не означает что она не работает
Да и это состояние не волнует, волнует именно немедленно как...
имелось в виду до исполняемого кода который можно контролировать.
У исполняемого кода нет хрустального шара. Если он (исполняемый код) не получает сообщение об ошибке, значит ошибки нет. Именно поэтому "проглатывание" ошибок catch'ем - зло.
Вроде нужно было еще какую-то фигню от мелкософта установить и что-то при сборке проги подшаманить.
Что-то все слишком сложно и запутано ;)
Если приложение работает корректно это еще не значит что пользователь не будет видеть там ошибок.
Тут надо определиться с терминологией. Что ты в данном случае понимаешь под "приложение работает корректно" и что ты понимаешь под "пользователь не будет видеть там ошибок"?
Если под "пользователь не будет видеть там ошибок" ты имеешь в виду сообщения об ошибках, то вывод сообщений об ошибках является корректной работой приложения (т.е. приложение корректно обработало ошибку). Если же под "пользователь не будет видеть там ошибок" ты имеешь в виду, что пользователь будет видеть надпись "Отменить" вместо "Подтвердить", то это не является "корректной работой приложения".
Да нет проблем - printf("Hello world") - если не видишь результата, это не означает что она не работает
Ну в таком случае я могу тебя поздравить, теперь ты самый богатый человек в мире, а если ты не видишь 150млрд долларов на своем счете, то это не значит, что у тебя их нет :D
Различия между этими тестами - выбрасываесое исключение.
------
Перечисли, плс, ВСЕ, выбрасываемые в данных условиях, исключения.
Я знаю наиболее часто выбрасываемые, но не знаю все ли знаю.
На всякий случай - там будут не только оракловские - есть пара дыр куда провалятся
некоторые из системных. Но это будет крайне редко. Мне все получить не удалось.
Ждем список - он определит какие тесты надо написать.
Группы исключений будут перечислены в логе.
-----
Ну и замечательно - тестер будет читать логи. А откуда лог то появится?
Ну и остается вопрос - что делать с теми исключениями, которые не попали в логи.
Ну просто в процессе работы/тестов не случилась комбинация условий при которых
оно выпадет.
программа принудительно высывает функцию Close.
-----
Могу повесить закрытие в финалли. Только это без толку - вроде оракловский Клосе
не закрывает коннект, а лишь возвращает его во внутренний пулл.
Это, однако, не решает проблему - коннект - закроется, пусть по таймауту пулла,
а сокет в данной ситуации - не освободится. При этом хандле сокета будет потерян.
Просто потому, что Оракловский Коннецтион НЕ обрабатывает данную ситуацию.
Так что через время система элементарно подвиснет из-за отсутствия возможности
получить новый сокет для коннекта.
Какими тестами ты собираешься гарантированно выяснить данную проблему?
Напомню - Оракловский код - черный ящик и проблема - за пределами твоего кода/тестов.
Просто не могу гарантированно получить все комбинации условий и реакцию системы
и коннектиона...
У тебя же нет тестов, которые проверяют, что ты правильно реагируешь на внештатные ситуации
------
У тебя, однако, их тоже нет.
В силу того, что ты не знаешь какая именно будет ситуация.
Разница - Я все же пытаюсь выяснить реальную причину и обработать источник проблемы,
ну а ты - проверяешь реакцию своей системы на внештатную ситуацию.
Т.е. у меня кое-как, медленно, но будет работать в указанных условиях,
ну а у тебя будет единственная доступная реакция на нештатную ситуацию - ничего не делаем.
Не надо мне указывать, что именно надо подменять.
-----
Ну здрасте...
Я говорю что именно мне надо проэмулировать, а ты подменяешь задачу совершенно другой.
Причем и в подмененной задаче не можешь гарантировать полное покрытие тестами,
но настаиваешь на том что это единственно правильное решение.
протестировать свой код
-----
Ну хорошо - пусть ты нашел 99% выбрасываемых исключений и даже написал какой-то
функционал по тестированию.
Тебе это как-то поможет:
- определить что ситуация имеет место быть?
- вылечить данную проблему для всех (ора, мс, пост, мускул) коннектинов?
По поводу своего кода Я уже писал - могу задавить проблему у себя в коде. Там - не сложно.
Но вот гарантировать что оно будет 100% работать - нет, не могу. Хоть с тестами, хоть без.
по WLAN?
------
Не-а... Там отдельный, но сертифицированный под местные требования, протокол.
Об этом Я тебе уже говорил - неоднородная там, однако, сеть.
И ты хочешь сказать, что это все правда?
-----
Смотри - ZigBee.
Перечисли, плс, ВСЕ, выбрасываемые в данных условиях, исключения.
Ты на старости лет заболел максимолизмом?
А откуда лог то появится?
Лог появится от клиента. Это не очевидно?
Ну и остается вопрос - что делать с теми исключениями, которые не попали в логи.
В логи не попали те исключения, которые не были выброшены, с ними ничего делать не надо, т.к. их нет.
Ну просто в процессе работы/тестов не случилась комбинация условий при которых оно выпадет.
Тесты не предназначены для того, чтобы создавать какие-то там новые комбинации условий. Тесты нужны для того, чтобы убедиться, что существующий функционал не изменен.
Это, однако, не решает проблему - коннект - закроется, пусть по таймауту пулла, а сокет в данной ситуации - не освободится. При этом хандле сокета будет потерян. Просто потому, что Оракловский Коннецтион НЕ обрабатывает данную ситуацию.
Ну да, и твое решение - это залезть рефлекшенами в OracleConnection и ручками закрыть сокет? :D
Какими тестами ты собираешься гарантированно выяснить данную проблему?
Для танкистов: ТЕСТИРОВАНИЕ ПРОВОДИТСЯ НЕ ДЛЯ ТОГО, ЧТОБЫ НАЙТИ НОВЫЕ ПРОБЛЕМЫ. Я не знаю, сколько еще раз тебе это надо повторить.
У тебя, однако, их тоже нет.
Мне и не надо. Это твоя проблема :)
Я говорю что именно мне надо проэмулировать, а ты подменяешь задачу совершенно другой.
Ты пытаешься натянуть сову на глобус. OracleConnection намеренно скрывает от тебя то, как он работает. Для тебя, как пользователя данного класса никаких сокетов не существует. Хочешь работать с сокетами - делай свою реализацию. Если используешь класс OracleConnection, то исходишь из того, что OracleConnection работает правильно (ну или можешь запостить баг репорт в MS, может быть они его когда-нибудь пофиксят).
- определить что ситуация имеет место быть?
Не понял вопроса.
- вылечить данную проблему для всех (ора, мс, пост, мускул) коннектинов?
С ними все тоже самое, что и с ораклом - никто из этих коннектионов не дает тебе доступа к сокетам. Нравится тебе это или нет. Значит либо ты делаешь все сам на сокетах (одинаково для всех), либо принимаешь чужую компоненту и исходить из того, что она работает правильно.
Смотри - ZigBee.
ZigBee не в IP стеке, каким образом наличие ZigBee может повлиять на IP стэк? Может быть у вас там рукожопые админы?
Это не очевидно?
-----
Нет.
В случае с дублированным ИП - да будет лог с полной галиматьей из которой невозможно выловить причину.
Во втором случае - не будет никакого лога с ошибками - все операции пройдут штатно.
т.к. их нет.
-----
Кто это определил? Каким методом это сдеано? Есть основания утверждать что применный метод гарантирует их отсутствие?
это залезть рефлекшенами в OracleConnection и ручками закрыть сокет?
-----
Ты умеешь закрывать сокет к которому потерян хандле?
И это... оракловский коннецтион - не обязательно позволит лазить по нему рефлектионом... ну это так, для общего сведения...
OracleConnection намеренно скрывает от тебя то, как он работает.
-----
Мне абсолютно все равно как он работает до тех пор пока он работает.
В данной ситуации - он НЕ работает - не обрабатывает возникшую ситуацию,
Ну а моя задача - несмотря на сбои в коннектионе продолжить то что делал.
Сделаю Я это в прикладухе ловя ехцептионы и не гарантируя работоспособность или "починю" что-то еще - это уже моя забота.
исходить из того, что она работает правильно.
-----
Она работает правильно при определенных условиях. По задаче - данные условия - нарушены.
Дальше есть два возможных решения:
- устранить последствия неработоспособности компонента
- устранить причину неработоспособности компонента
Ты пытаешься сделать первое, ну а меня интересует второе.
Один из вариантов для второго - прописать в маршрутизаторе что запросы на определенный порт нужно директить не по ИП, а по МАКу... Но это можно сделать если установлена причина сбоев и есть понимание проблемы. Если чего то из этого нет - а у тестера с твоими требованиями ничего и близко нет - остается бороться со следствиями.
ZigBee не в IP стеке
-----
Ну так Я тебе изначально сказал что сеть неоднородная.
каким образом наличие ZigBee может повлиять на IP стэк?
-----
А зачем ему влиять на ИП-стек? Оно никоим образом не влияет на ИП-стек.
Может быть у вас там рукожопые админы?
-----
Может. Но что бы это утверждать с полной уверенностью надо назвать другую радио-систему, сертифицированную для применения в тех частях госпиталей, где не разрешают пользоватья мобильными телефонами.
А вот прогеры точно были никакие.
И работали они точно по описываемой тобою методике.
Но свой код они вылизали на 100%.
И не работает.
Чтобы тебя больше не мучать - понять почему не работает без точных знаний по функционированию ZigBee
все одно не получится - объясню совершенно неочевидную для прогера вещь: переход с ИП-сети на ZigBee
делается через... аналог КОМ-порта. Ограничения - стандартные... для КОМ-порта - буффер и скорость.
На переполнение буфера ZigBee никак внешне не реагирует - никакого ехцептиона к инициатору не уходит.
Ну это из простых и понятных вещей.
Из более сложных - в мире ZigBee существует несколько версий протоколов и несколько наборов команд.
То, что юзверь отправил - пойдет по цепочке ZigBee-устройств, характеристики каждого из которых
могут отличатся. Набор операций, которое способно выполнить первое в цепочке - не есть гарантия
что все остальные будут способны делать тоже самое. Чтобы там гарантировать работоспособность
надо ЗНАТЬ через устройство с каким набором команд и протоколом будет идти обмен. Добавь к этому
носибельность рутеров...
то ты в данном случае понимаешь под "приложение работает корректно" и что ты понимаешь под "пользователь не будет видеть там ошибок"?
Ну например так, чисто чтобы понятия объяснить. Загружаем приложение, работаем без проблем, подключаем усб диск, выскакивает окно - приложение будет закрыто, не то, что у вас в приложении произошло ххх.
Пользователь то считает, что ошибка в приложении.
Намекаю - вы пока ещё не поняли что такое юнит-тест.
Возможно никакой, возможно какой-нибудь проверяющий использование только тех функций, которые доступны в андроиде версии x.y
По хорошему вам нужен "деплоймент тест". И да, если хотите чтобы выше приложение работало на андроиде 6.0, 6.1, ... 9.12345 вам надо иметь устройства со всеми этими андроидами, чтобы быть на 95% уверенным что будет работать. Не благодарите, ваш КО.
Намекаю - вы пока ещё не поняли что такое юнит-тест.
Вообще то речь шла совершенно о другом. А конкретно о том что для подобных целей мне НУЖНО использовать юнит тесты.
чтобы быть на 95% уверенным что будет работать.
Да для себя я прогу делаю, мне нужно что бы эта скотина хоть на одном единственном устройстве кроме эмулятора запустилась. Раньше вообще даже и не думал про андроид, но с Xamarin можно и поиграться.
...
Потому как без камеры ничего нельзя попробовать. И есть большое подозрение, что дело из-за ZXing библиотек.
А конкретно о том что для подобных целей мне НУЖНО использовать юнит тесты.
Ну, я ж и говорю. Пока что не поняли что это такое. Потому что для "подобных целей" (проверить что продукт будет работать в определёном окружении) юнит-тест использовать НЕВОЗМОЖНО. По определению. Юнит-тесты проверяют только ваш код. На уровне функции/метода/класса. Они проверяют функциональность кода, действително ли он делает то что должен (действительно ли bubble_sort() отсортирует переданный список), как код реагирует на исключительные ситуации (вместо списка передали null или пустой список или слишком длинный список, получил exception при попытке считать следующий элемент из списка).
А вот дальше начинаются интеграционные тесты, деплоймент тесты и те пе.
P.S. Юнит-тестом можно проверить, например, что в коде не используется определенная функция какой-нить библиотеки, про которую известно что она приводит к проблемам. Но никак не "проверить что моя аппликуха заработает под андроид x.y".
То программы, которые при отключенном питании у вас "работают" то прочая ересь.
Похоже аналогию "не схватили", типо того, что на ересь отвечают ересью.
Ну не знаю я как я еще можно аргументировать, что в той ситуации как было юнит тест не лезет ни в какую дырку.
скорее при отключенном зарядном устройстве и выключенном экране.
-----
Я тоже когда-то считал, что Power Off есть режим Выключено.
Тем не менее таблет в этом режиме продолжает довольно активно сосать акку, если не озаботится убиванием нескольких прог.
Я не помню,
Вроде тут началось плюс еще мурка...
https://foren.germany.ru/showmessage.pl?Number=35504473&Bo...
Ты умеешь закрывать сокет к которому потерян хандле? И это... оракловский коннецтион - не обязательно позволит лазить по нему рефлектионом... ну это так, для общего сведения...
Ну в таком случае расскажи мне, каким образом ты из своего софта исправляешь ошибку с двумя IP?
Дальше есть два возможных решения:
- устранить последствия неработоспособности компонента
- устранить причину неработоспособности компонента
Ты пытаешься сделать первое, ну а меня интересует второе.
Похоже, что ты просто не понимаешь то, что я вытаюсь донести до тебя. Перефразируя старый анекдот можно сказать, что есть 10 типов людей - те, кто понимают как работают и зачем нужны юнит-тесты и те, кто это не понимают :) Ты не понимаешь.
Один из вариантов для второго - прописать в маршрутизаторе что запросы на определенный порт нужно директить не по ИП, а по МАКу...
И это делает твой софт, которой работает на клиенской машине? :) Ну-ну :)
Но это можно сделать если установлена причина сбоев и есть понимание проблемы. Если чего то из этого нет - а у тестера с твоими требованиями ничего и близко нет - остается бороться со следствиями.
Тестер такой хренью вообще заниматься не будет. Тестер не должен докапываться до причин проблемы. Задача тестера - запустить тест и убедиться, что тест "зеленый". Если тест "красный", то зарепортить баг и описать сделанные шаги, чтобы разработчик мог этот баг воспроизвести. Кстати, если баг по какой-либо причине нельзя воспроизвести, то и пофиксить его нельзя.
переход с ИП-сети на ZigBeeделается через... аналог КОМ-порта.
У тебя там еще и переход добавился? :) ZigBee никак не пересекается с IP, о каком переходе речь?
Добавь к этомуносибельность рутеров...
И умножь на рукожопость админов.
Ну, котика я отфильтровываю, а в сообщении по ссылке никаких затыканий дырок не вижу.
Узнал (из опыта) что от библиотеки Х может прилететь исключение, добавляем в код разумную обработку такого исключения и юнит-тест с моком/стабом/фейком библиотечного вызова, который бросает эксепшен, а тест проверяет что наш код его правильно обработает. Что не так?
разу не заметил. но все же спрошу - А когда это мелкомягкие подвязались багтрекить и багфиксить оракловские либы?
Я хз чьи это либы, описано оно на MSDN: OracleConnection Class
:)
Загружаем приложение, работаем без проблем, подключаем усб диск, выскакивает окно - приложение будет закрыто, не то, что у вас в приложении произошло ххх.
Я не понял выделеную фразу.
Пользователь то считает, что ошибка в приложении.
Т.е. приложение отреагировало на ошибку закрытием себя? Ну произошла какая-то внештатная ситуация, после которой приложение не смогло восстановиться и продолжить работу. И что?
Играюсь я с Анроидом и Xamarin Forms, пару дней назад прога устанавливалась на смартфон, вчера уже нет. И какой мне юнит тест для этого написать?
Я правильно понимаю, что ты хочешь добавить тест к написанному тобой исталлеру, которым ты устанавливаешь программу на смартфон? В таком случе ты можешь найти место в котором происходит сбой, добавить туда юнит-тест и после этого сделать фикс. Ну или вывести более информацивное сообщение.
Не а - система хочет его закрыть
Ну значит получается, что твое приложение не справилось с возникшей нештатной ситуацией. Значит ошибка в твоем приложении. Ищи ошибку, делай юнит-тест, исправляй ошибку и ты больше никогда не увидишь данного сообщения при таких условиях. Профит :)
нельзя воспроизвести
-----
Ну по этому Я тебя и спрашивал - что именно ты собираешься делать когда из коннектиона полезет разная , почти невоспроизводимая, хрень.
каким образом
-----
Да элементарно - задавил Я ее на клиенте.
Получил ошибку - повторяю запрос. Пока не получу все что нужно.
Но это - не решение. Это - времянка, потому как надо было быстро заставить все работать...
Тестер не должен докапываться до причин проблемы.
-----
Это твой не должен. Моему - надо уметь несколько по-больше, чем умеет бесплатный СИ.
никак не пересекается
-----
Не влияет. Но - гейтируется. И туда, и обратно.
на рукожопость
------
Без проблем - другую сертифицированную систему назови.
Я - ничего.
Как это "ничего"?
Играюсь я с Анроидом и Xamarin Forms, пару дней назад прога устанавливалась на смартфон, вчера уже нет. И какой мне юнит тест для этого написать?
Я просто хочу понять как он мне поможет в подобной ситуации
До тех пор, пока ты не поймешь, зачем нужны юнит-тесты, написание юнит-тестов тебе вообще никак не поможет.
А если после замены/переинсталляции драйверов, приложение работает правильно. Где была ошибка в приложении?
Все равно в твоем приложении. Оно же обрабатывает... точнее говоря не обрабатывает некорректную работу драйверов.
Нужно ли такие ошибки исправлять - это уже другой вопрос, но ошибка однозначно у тебя (возможно, что и драйверах, но это не делает твой код безошибочным).
Ну по этому Я тебя и спрашивал - что именно ты собираешься делать когда из коннектиона полезет разная , почти невоспроизводимая, хрень.
Во-первых, я тебе уже отвечал на этот вопрос. Отвечу еще раз, я буду реагировать на эту хрень и свою реакцию протестирую юнит-тестами.
Во-вторых, то, что какую-то ситуацию нельзя воспроизвести на реальном железе не означает, что ее нельзя смоделировать моками.
Но это - не решение.
Так, а решение-то какое?
Это твой не должен. Моему - надо уметь несколько по-больше, чем умеет бесплатный СИ.
Где же ты найдешь дебила, который обладая скилами СИ (это ведь "сеньор инженер"?) пойдет работать тестером?
Не влияет. Но - гейтируется. И туда, и обратно.
Ну значит проблема в том, как оно у тебя там гейтируется. Потому что IP, как и ZigBee живет на сетевом уровне, т.е. работает на Ethernet протоколе.
А то, как ты это все гейтируешь - это уже рукожопость твоих админов.
Насколько я знаю, на ZigBee построены системы "умный дом" и у людей все работает без проблем, в том числе вместе с WiFi'ем дома. При это все гейтируется как надо и на смартфоне можно видеть статус оборудования и даже управлять этим оборудованием.
Без проблем - другую сертифицированную систему назови.
Я не админ и во всех этих штуках не разбираюсь. А ты лучше оставь поиски поиски тестера, которому "надо уметь несколько по-больше, чем умеет бесплатный СИ", а найди себе толкового админа.
Ну значит проблема в том, как оно у тебя там гейтируется.
-----
Разумеется.
Но там поменять ничего нельзя - прошитая железяка в корпусе.
Но по твоему утверждению тебе это знать НЕ надо - с клиента работаем через сокет и ошибки сокета обрабатываем.
Все, что тебе надо - аккуратно обработать ехцептионы на клиенте.
И тебе пофиг что их не будет...
Я не админ и во всех этих штуках не разбираюсь.
-----
Нее - ты тот прогер, который говорит - админы - мудаки.
И в случае с ZigBee это единственное твое положительное качество.
и у людей все работает без проблем
-----
Ну не все же делают как ты... некоторые дают себе труд разобраться в специфике...
это
ведь "сеньор инженер"?
-----
CI - Continues Integration...
Делаешь враппер и генерируешь через него любую ошибку
И? Любую ошибку, которую может вернуть "обёрнутый" враппером метод. Что не так?
Как быть с ошибками которые код просто не обрабатывает?
Начать их обрабатывать. Ваш КО.
P.S. И написать юнит-тест, который не даст нам позже сломать эту обработку. Ваш адмирал Ясен Хрен.
Но по твоему утверждению тебе это знать НЕ надо - с клиента работаем через сокет и ошибки сокета обрабатываем.
Совершенно верно. Если моя программа работает по IP протоколу, то мне глубоко наплевать, что там еще в сети еще работает. Мне дан стандарт и я с ним работаю.
Все, что тебе надо - аккуратно обработать ехцептионы на клиенте.
Именно так.
И тебе пофиг что их не будет...
Если их нет, значит все работает так, как описано в спецификации IP протокола. Софт, работающий на клиенте, не может пойти и покрутить настройки рутера, он также не может определить, что проблемы именно из-за ZigBee.
Нее - ты тот прогер, который говорит - админы - мудаки.
Неее, я прогер, который умеет определять свою зону ответственности и не пытается наводить порядок там, где зона ответственности других специалистов.
Ну не все же делают как ты... некоторые дают себе труд разобраться в специфике...
Ага, самое забавное, что у этих некоторых получается разобраться, а у тебя нет ;)
CI - Continues Integration...
Ты еще к тому же не знаешь, что такое Continues Integration
Если их нет, значит все работает так, как описано в спецификации IP протокола.
-----
Именно. Как описан в спецификации TCP/IP. Никаких отклонений, никаких ошибок.
Кроме этого - все описанные ошибки TCP/IP протокола аккуратно обрабатываются.
Готов поклястся на Библии, что там сделано все что возможно в этом плане.
он также не может определить, что проблемы именно из-за ZigBee.
-----
Ну и как же ты тогда будешь решать проблему обмена данными между двумя точнками?
Ведь у людей - работает. У меня, черт его дери, в сильно упрощенном виде - работает.
А у тебя - нет, не работает и нет никаких ошибок. И просто не работает и все.
И когда тебе говорят об проблеме - ты проверяешь ехцептионы в своем коде.
А их, ехцептионов - нет - все работает штатно, как должно.
Точнее - не работает именно так как должно.
В силу непонимания неоднородности сети и имеющихся ограничений.
По поводу - определить - ты существенно не прав.
Причем не прав аж со времен телетайпов - даже тогда существовала возможность нажать кнопарики "Кто Там?". Это только на уровне сокета открыл/закрыл по ИП+ПОРТ.
Ну да не будем о грустном - не твоя работа определить что используемый рутер вышел из зоны уверенного приема и надо либо увеличивать мощность передатчика ближайшего устройства, либо искать новый маршрут, либо сажать сеть шировещательным запросом видимости устройств - твой код идеально корректно и совершенно бесполезно работает с сокетом - ничего другого ты просто не хочешь знать.
и не пытается наводить порядок
там, где зона ответственности других специалистов.
-----
Данная стейтмента имеет сильное противоречие с заявкой об том, что админы мудаки. Особенно в виду неподкрепленности ссылкой на другую сертифицированную возможность.
Особливо это подчеркивается тем, что в своей зоне ответственности ты не можешь справится с задачей, требующей знаний вне ее и не готов изучать внешие аспекты проблемы.
а у тебя нет
-----
К несчастью - у меня - работает.
И с дубликатом ИП, и с ZigBee - все, зараза такая, пашет... хотя и не быстро.
По ZigBee, кстати, есть еще одна смешная штука.
Тоже может использоваться для демонстрации порочности замыкания в собственном коде.
Протокол, точнее - известные мне имплементации, является "грязным" - ты можешь, как на клиенте, так и на сервере получать недостоверную информацию.
Определить что именно получено - инфа или туфта - можно... почти всегда. Ну то есть за исключением тех случаев когда нельзя. Вот эти нельзя и интересуют.
Вот теперь нарисуй мне примитивный тестик - заглушка выдает константную строку в ZigBee-формате.
Тест должен определить корректно ли обрабатывается полученное.
Тут именно как ты настаиваешь, без отклонений - чисто твой код.
Напомню - там всегда возвращается константа, но в одном случае это инфо, а в другом - туфта...
Поборешься? В смысле - без изучения всяких внешних глупостей, чисто в своем коде...
к тому же не знаешь
-----
Я знаю, что Я много чего еще не знаю.
Но Я, все же, имею шанс что-то самостоятельно узнать хотя бы часть, а не сидеть и ждать ехцептиона,которого не будет...
пока ты не поймешь, зачем нужны юнит-тесты
пока что особых проблем с ними не было, пока кто-то не стал меня убеждать, что только юнит тесты мне и помогут в данных ситуациях и все проблемы исключительно в моих хреновых приложениях.
Может Вы с адмиралом на пару, приведете мне пример юнит теста для моего xamarin кода который будет проверять смогу ли я установить мой код на моем смартфоне, а то я такой тупой что никак не догоняю как это все связать вместе. Я даже согласен на пример любого теста который сможет это действительно проверить.
Именно. Как описан в спецификации TCP/IP. Никаких отклонений, никаких ошибок. Кроме этого - все описанные ошибки TCP/IP протокола аккуратно обрабатываются.Готов поклястся на Библии, что там сделано все что возможно в этом плане.
Если в твоем коде ошибок нет и он работает в соответствии с заданной спецификацией, значит все ОК.
А у тебя - нет, не работает и нет никаких ошибок.
Это у тебя не работает.
не твоя работа определить что используемый рутер вышел из зоны уверенного приема и надо либо увеличивать мощность передатчика ближайшего устройства, либо искать новый маршрут, либо сажать сеть шировещательным запросом видимости устройств - твой код идеально корректно и совершенно бесполезно работает с сокетом - ничего другого ты просто не хочешь знать.
Еще раз повторюсь: ты смешиваешь разные вещи в одну проблему. В твоем примере есть две области: 1) твой софт, который работает на железке у клиента и 2) окружение, т.е. сеть, в которой работает железка, на которой работает твой софт.
Так вот, по твоему описанию, проблема не в софте, а в окружении. И тут есть 2 способа решения возникшей проблемы:
1) ты говоришь, что твоя часть сделана (т.е. твой софт удовлетворяет спецификации) и клиент сам должен настроить окружение так, чтобы не было конфликтов
2) ты договариваешься с клиентом и наличие ZigBee устройств в сети становится частью спецификации, т.е. изменяются требования к твоему софту в результате чего софт перестает удовлетворять спецификации. После этого можно начинать думать, как обойти проблему. Т.е. надо погружаться в имеющуюся проблему и пытаться решить ее программным способом. Однако, факт в том, что если есть понимание проблемы и понимание того, как эту проблему можно программно решить, значить ее можно и протестировать. И тестирование нужно не для того, чтобы найти ту или иную проблему, а для того, чтобы убедиться, что софт соответствует спецификации.
Особливо это подчеркивается тем, что в своей зоне ответственности ты не можешь справится с задачей, требующей знаний вне ее и не готов изучать внешие аспекты проблемы.
Моя зона ответственности ограничивается спецификацией на софт.
У меня шеф такой же как ты. Считает, что любые проблемы он должен решить сам. Это просто пипец какой-то. Сейчас вот был "баг", программа выкидывает исключение, что мол "нет папки R:\Backup". Смотрю, говорю, сетевой диск не замаплен, поэтому диска R нет, от сюда исключение. Ошибки нет. Все работает так, как должно. Чтобы доказать это, добавляю диск R - все работает. Через полчаса опять приходит шеф и говорит "Ты зашел под своим аккаунтом, а надо было под доменным". Твою мать! Софт работает! Говорю ему, что значит под доменным аккаунтом этого маппинга нет. Он утверждает, что есть. Смотрим - маппинг есть. Смотрим как он это
дело запускает. И оказывается, что он запускает это на класторе с SYSTEM правами. Значит, говорю, у SYSTEM'a нет маппинга на R. И знаешь что он мне заявляет? Говорит, что он не хочет подключать админов и выяснять можно ли добавить маппинг диска для SYSTEM.
Т.е. что мы тут видим? Есть рабочий софт и есть окружение, которое блокирует работу софта. Причины, по которой работа заблокирована известна, устранить программно эту причину нельзя. Зато устранить ее могут (и должны) админы. Так какого хера ты не идешь к админам? Пусть они делают свою работу.
Протокол, точнее - известные мне имплементации, является "грязным" - ты можешь, как на клиенте, так и на сервере получать недостоверную информацию.Определить что именно получено - инфа или туфта - можно... почти всегда. Ну то есть за исключением тех случаев когда нельзя. Вот эти нельзя и интересуют.Вот теперь нарисуй мне примитивный тестик - заглушка выдает константную строку в ZigBee-формате.Тест должен определить корректно ли обрабатывается полученное. Тут именно как ты настаиваешь, без отклонений - чисто твой код.
Давай спецификацию и мое время стоит 100Евро/час.
Может Вы с адмиралом на пару, приведете мне пример юнит теста для моего xamarin кода который будет проверять смогу ли я установить мой код на моем смартфоне, а то я такой тупой что никак не догоняю как это все связать вместе.
Никто не будет тратить свое время на написание юнит-тестов за тебя :) Это во-первых.
Во-вторых, помочь с юнит-тестами можно будет только после того, как ты определишься, а) какую фичу в своем коде ты хочешь протестировать и б) что именно ты хочешь протестировать.
Юнит-тесты исключают взаимодействие с окружением.
Это у тебя не работает.
-----
Ну Я же тебе написал где именно у тебя "не работает" и даже написал почему.
Но у тебя по-прежнему упор на обработку ошибок TCP/IP... без учета специфики сети.
Поверь - не работает - именно при твоем подходе.
Если точнее - ты можешь вылизать код на 100% код обмена по TCP/IP - работать не будет.
Т.е. надо погружаться в имеющуюся проблему
если есть понимание проблемы и понимание того
-----
Ну слава богу - наконец то дошло, что надо знать и проблемы окружения, а не упираться только в свой код.
Ошибки нет.
------
Ошибка... есть исключение => уже есть ошибка... (Ну Я надеюсь, что ты не пользуешься исключениями как способом управления работой прожки).
устранить программно эту причину
нельзя.
------
Господи, какие глупости... один запрос к контроллеру домена и все твои права у тебя на блюдечке.
У меня более одного домена. У меня проги работают с подмапленными дисками из разных доменов.
Никаких проблем ни с проверкой/созданием учетки для прог, ни с подмапливанием дисков не возникает.
Единственная проблема - удаленная машина/сеть физически в дауне - тогда все пишется локально.
И не надо говорить что это сложно - это ничуть не сложнее всего остального... если понимаешь с чем работаешь.
Так какого хера ты не идешь к админам? Пусть они делают свою работу.
------
Да потому что от тебя ожидают выполнение прогерской работы - корректную запись данных.
На подмапленные диски значит на подмапленные - корректно, а не в соответствии с ошибками в спецификации.
Ну а тебе "лениво" изучить пробемы окружения и ты все спихиваешь на админов.
Давай спецификацию
-----
Даю.
У тебя есть два числа - 10 (левое) и... 10 (правое).
Одно из них - правильное, другое - неправильное.
Тебе нужно их протестировать и сказать какое из них правильное, а какое - нет.
В точном соответствии с твоими требованиями - полностью опущены вопросы окружения.
Да, достаточно указать алгоритм определения.
стоит 100Евро/час.
------
Ок.
Время определяется по минимально необходимому количеству нажатых кнопок.
Неустойка на первые 1000 часов - 100евро/час, далее - 1000евро в день.
Время пошло.
Поверь - не работает - именно при твоем подходе.
Если точнее - ты можешь вылизать код на 100% код обмена по TCP/IP - работать не будет.
Код, в котором нет ошибок работает без ошибок. Я даже не понимаю, как с этим можно спорить.
Вот если тебе дать книжку на японском языке, при этом мы точно знаем, что в книжке нет ни одной ошибки, то хрен ты сможешь понять, что там написано. Но это не проблема книжки. Книжка идеальна. Это ты не знаешь японского и это твоя проблема, а не издателя книжки.
Ну слава богу - наконец то дошло, что надо знать и проблемы окружения, а не упираться только в свой код.
Я не понимаю, зачем ты вырываешь слова из контекста. Все это было ксазано к этому:
2) ты договариваешься с клиентом и наличие ZigBee устройств в сети становится частью спецификации, т.е. изменяются требования к твоему софту в результате чего софт перестает удовлетворять спецификации.
Ты же утверждал, что имеющийся код спецификации удовлетворяет.
Ошибка... есть исключение => уже есть ошибка... (Ну Я надеюсь, что ты не пользуешься исключениями как способом управления работой прожки).
Что ты понимаешь под "способом управления"?
Что-то такое:
public void BindNodes (INode node1, INode node2)
{
if (node1 == null || node2 == null)
throw new ArgumentNullException ("Nodes can't be null");
if (node1.BindedNode.Equal(node2))
throw new BindingException ("You can't bind nodes twice.");
if (node2.IsBindable == false)
throw new BindingRestrictionException ("Node2 can't be binded at all");
node1.BindedNode = node2;
}
это способ управления? или это генерация ошибок?
Господи, какие глупости... один запрос к контроллеру домена и все твои права у тебя на блюдечке.
У меня клиенты - казино, там не то, чтобы права на блюдечке не дадут, там через службу безопасности надо каждый порт открывать.
У меня более одного домена. У меня проги работают с подмапленными дисками из разных доменов.
Никаких проблем ни с проверкой/созданием учетки для прог, ни с подмапливанием дисков не возникает.
Конечно, потому что занимается всем этим не твой код, а админ создал тебе все условия. Ну может быть ты на локальной машине вызываешь "net use ..."
Единственная проблема - удаленная машина/сеть физически в дауне - тогда все пишется локально.
Это требование к софту (которое,
кстати, можно протестировать юнит-тестами :D :D :D)
Да потому что от тебя ожидают выполнение прогерской работы - корректную запись данных.
Вот я свою работу и выполнил - данные записываются. И багов нет.
На подмапленные диски значит на подмапленные - корректно, а не в соответствии с ошибками в спецификации.
А это совершенно не важно, подмаплен диск или нет. Есть некий путь, это может быть локальный диск, подмапленый или любой другой UNC путь. И этот путь либо есть, либо его нет. И если его нет, то проге совершенно наплевать почему этого пути нет. Что делать дальше описано в спецификации. Это может быть просто запись в логе и игнор (в моем случае), это может быть запись в локальную папку
и последующая синхронизация (в твоем случае) (кстати, интересно, что ты будешь делать, если локальный диск забит и возможности записать нет. корректтное поведение программы в этом случае легко проверяется юнит-тестом), это может быть также ручной вызов "net use ..." или просто показать мессадж бокс и ждать реакции юзера.
В спецификации тоже могут быть ошибки, но это не повод отходить от спецификации. В конце концов, даже конституцию можно менять, так что и спецификация тоже может меняться. Ничего страшного в этом нет. Но софт должен соответствовать спекам.
Давай спецификацию
-----
Даю.
У тебя есть два числа - 10 (левое) и... 10 (правое).
Одно из них - правильное, другое - неправильное.
Тебе нужно их протестировать и сказать какое из них правильное, а какое - нет.
Теперь понятно, от куда у тебя берутся "пятничные вопросы" и почему тебе все время хочется какой-нибудь хрени :)
Время определяется по минимально необходимому количеству нажатых кнопок.
Неустойка на первые 1000 часов - 100евро/час, далее - 1000евро в день.
Ты что сказать-то хотел?
Код, в котором нет ошибок работает без ошибок.
-----
Хи-хи...
Код, достигающий заданных результатов в возможных условиях является работающим кодом.
Ты же утверждал, что имеющийся код спецификации удовлетворяет.
-----
Я утверждал, что код корректно работает с TCP/IP. Не более.
Кроме этого Я утверждал, что код, несмотря на отсутствие ошибок, не выполняет необходимую работу.
При этом ты доказывал, что все что за пределами кода не представляет интереса для прогера/тестера.
Тебе просто была дана ситуация когда проблема ВНЕ твоего кода и у тебя не оказалось решения для проблемы.
В спеку, кстати, добавлять ничего не требуется - в спеке есть упоминание об том, что будут пересылаться
именно ZigBee-команды. Остальное надо было либо знать, либо досконально изучать.
Что ты понимаешь под "способом управления"?
------
Ну ты же, например, не используешь исключение для выхода из вложенных циклов?
Ну или из рекурсии...
там через службу безопасности надо каждый порт открывать.
-----
Угу - т.е. к админам - не надо...
потому что занимается всем этим не твой код
-----
Угу... будет админ бегать по предприятию (а это - километры) и переподмапливать слетевшие диски на станочной программе.
Все делается программно. И даже не удаленно, а просто локально.
данные записываются.
-----
Ну и куда ты записал данные?
Я не имею в виду информацию об ошибке, а именно - данные.
Откуда Я их прочитаю после перезагрузки станции?
Но софт должен соответствовать спекам.
-----
Мы опять вернемся к вопросу об дублировании ИП в сети и неоднозначном результате операций в такой сети.
Толку от того, что софт соответствует спекам
(не учитывающим этот вариант), но не определяет наличие этих условий и не работает (т.е. не получает заданный результат) в этих условиях?
Что делать дальше описано в спецификации.
-----
Родной, у меня в спеках написано как должен выглядеть АРМ.
Внешний вид ящика, положение в нем компа, куда нельзя ставить монитор.
Из остального - частично описано содержимое файла конфигурации.
Частично. Потому как полный набор - надо выковыривать из кода.
Даже то, как получить доступ к форме с настройками - тоже надо искать в спагетти-коде.
Все - в точном соответствии с квалификацией исполнителей делавших спеку.
понятно, от куда
------
Ну да - именно из твоего утверждения, что можешь решить данную проблему локально, не заморачиваясь окружением...
это способ управления? или
это генерация ошибок?
-----
Непонимание задачи.
При понимании задачи у тебя не должно создаваться необходимости данных проверок.
Ты что сказать-то хотел?
-----
Что вернемся к этому позднее, когда под лимон натикает...
Код, достигающий заданных результатов в возможных условиях является работающим кодом.
Пример с книжкой я тебе привел.
Я утверждал, что код, несмотря на отсутствие ошибок, не выполняет необходимую работу.
Это не из-за ошибок в коде, а из-за проблем в окружении. Код на окружение влиять не может.
В спеку, кстати, добавлять ничего не требуется - в спеке есть упоминание об том, что будут пересылаться именно ZigBee-команды. Остальное надо было либо знать, либо досконально изучать.
Все чудесатее и чудесатее :) Т.е. ты выкатил клиенту софт, который не соответствует заданным условиям :) Красавец, чо? :)
Ну ты же, например, не используешь исключение для выхода из вложенных циклов?Ну или из рекурсии...
Почему нет? Зависит от контекста. Например, рекурсивно удалять папки и прекратить удаление, если одну из папок (по какой-либо причине) удалить нельзя. В этом случае выход из рекурсии будет по исключению.
Угу - т.е. к админам - не надо...
Сначала к безопасникам, потом админы включат порт. Меня эта процедура вообще не волнует.
Угу... будет админ бегать по предприятию (а это - километры) и переподмапливать слетевшие диски на станочной программе.Все делается программно. И даже не удаленно, а просто локально.
Ну если ему не в падлу бегать, то пусть бегает. Но вообще есть удаленный доступ. Или же можно расширить спек и описать, каким образом софт должен определять какой путь куда мапить.
Откуда Я их прочитаю после перезагрузки станции?
Да, мне вот тоже интересно, от куда ты их прочитаешь, если у тебя диск переполнен?
Мы опять вернемся к вопросу об дублировании ИП в сети и неоднозначном результате операций в такой сети.
Дублирование ИП в сети - это не проблема софта. Сколько раз тебе это надо повторять?
Толку от того, что софт соответствует спекам
Ясен хер, от соответствующего спекам софта нет никакого толку :)
у меня в спеках написано как должен выглядеть АРМ.
Внешний вид ящика, положение в нем компа, куда нельзя ставить монитор.
Ну т.е. в спеках у тебя всякая хренотень, которая не имеет отношения к продукту.
Непонимание задачи.
При понимании задачи у тебя не должно создаваться необходимости данных проверок.
:) Я так понимаю, что проверки эти надо делать до того, как вызывать указанную функцию. Или их вообще не надо делать?
Может Вы с адмиралом на пару, приведете мне пример юнит теста для моего xamarin кода который будет проверять смогу ли я установить мой код на моем смартфоне
Тут и адмирал не справится. Тут маршала Яжговорил звать надо. Сформулированую в этом предложении задачу решить юнит тестом невозможно.
P.S. И никто не говорил что можно.
Щас попробуем так.
1. Вася пишет программку.
2. Вася ставит программку на телефон.
3. Программка не работает.
4. Вася ищет причины, по которой она не работает.
5. (предположим) Вася находит что причина - в использовании в классе "понты" метода "фигня()" из библиотеки "мелкософт_утилз".
(до сих пор никаких следов юнит тестов, заметили?)
6. Вася убирает из кода вызовы "фигни"
7. Везде, где видит что используется "мелкософт_утилз" пишет юнит тесты, в которых подменяет "фигню" моком / фейком, который при вызове ломает тест.
(ура! появились юнит тесты!)
Что это даст Васе? Что ситуация из п. 3 не повторится. Стоит ему поменять тестируемый код и (случайно) вызвать "фигню", как его тест станет красненьким. И он увидит что надо править.
Может ли случится новая ошибка? Например, из-за несовпадений версий библиотеки "бздыщь" в Васином IDE и на его телефоне?
Может.
А из-за того что на телефоне помяти не хватает?
Может.
Поможет тут тест на "фигню"?
Нет.
А зачем его писать?
Чтобы сэкономить время на деплоймент и убедиться что не повторил уже известную ошибку.
Это не из-за ошибок в коде, а из-за проблем в окружении.
-----
Ну и какая мне или менеджеру, не имеющему представленя об всей внутренней кухне, разница из-за чего не получен результат?
Я потому и говорю тебе - не работает - т.е. не дает ожидаемого. А чтобы давало - надо очень аккуратно изучать окружение.
Т.е. ты выкатил
------
Я ничего не выкатывал. Я за пару минут понял, что оно:
а) на 100% соответствует спеке
б) не будет работать.
Вот тебе уже третий день не могу объяснить почему оно не будет работать - у тебя недостаток знаний по ZigBee и заявленная ненужность изучения окружения не позволяет понять в чем неработоспособность идеально написанного кода.
Меня эта процедура вообще не волнует.
-----
Меня, однако, тоже. Только причина - другая - эта проблема не у меня - вот она меня и не волнует.
Дублирование ИП в сети - это не проблема софта.
------
Нее, не проблема... если, конечно, можно остановится и подождать... вот только поставленная задача - продолжать работать...
от куда ты их прочитаешь, если у тебя диск переполнен?
-----
Оттуда, откуда ты прочитаешь лог в этих же условиях.
Ты просто не понимаешь как оно организовывается на производстве - остановка производства - это уже ЧП, так что будем крутить-вертеть-обманывать - но сохраним данные. Особенно - критичные... если знаем где и как можно...
есть удаленный доступ.
------
Угу,,, который прекрасно работает на Вин98... ВинНТ, ДОСе...
И, кстати, не просвятишь по поводу того, почему с ВинХП на Вин98 можно зайти, а с Семерки - уже нет? Сеть - та же... Я пробовал найти что-то внятное из объяснений - не получилось. А это, кстати, реальная машинка, к которой надо регулярно наведываться и чистить диск локально... а по спекам - должно работать как и остальное...
в спеках у тебя всякая хренотень
------
Ну что у меня - хрень - это понятно.
Вопрос - надо код приводить в соответствие этой спеке?
Или их вообще не надо делать?
-----
А как писали до появления ехцептионов?
Т.е. если у тебя есть гарантия того, что проверяемые условия выполняются - эти проверки - лишние.
А как именно и чем будет гарантироваться соответствие - это уже отдельный вопрос.
Вот - текучка.
Добавил к сайтику несколько ВБ-файликов.
Ничего сложного - взял с работающего сервака и засунул в проект сайта для отладки.
Теперь имею устойчивое падение Студии с криком - не могу далее справится со своими окнами...
Ну и каким образом вбшный файл компилируемый и запускаемый ИИСом приводит к падению Студии?
Что об этом говорят спеки мелкомягких? Что они там не допроверили настолько, что все падает от добавления файлика к сайту?
В этом случае выход из рекурсии будет по исключению.
------
Замечательно.
Ну а кто будет освобождать ресурсы задействованные на каждой итерации?
Особенно те, которые были аллоцированы не фреймворком...
Я потому и говорю тебе - не работает - т.е. не дает ожидаемого. А чтобы давало - надо очень аккуратно изучать окружение.
Это последний раз, когда я повторяю тебе одну и туже мысль: Проблемы окружения не решаются программным способом. Изучать окружение можно сколько угодно подробно и находить причины проблем тоже. Но есть вещи которые нельзя изменить из кода. Например, появление в сети второго ИП. Ну нельзя это изменить. Хоть ты тресни.
продолжать работать...
ну так и продолжает.
будем крутить-вертеть-обманывать
вместо того, чтобы действовать строго по инструкции :)
Я пробовал найти что-то внятное из объяснений - не получилось.
Я бы напряг тех, кто в этом разбирается, т.е. дал бы админам заработать их деньги :)
надо код приводить в соответствие этой спеке?
Одно из двух - либо код приводить к спеке, либо спеку к коду. А вот писать отсебятину не надо :)
А как писали до появления ехцептионов?
Очевидно, что тогда использовали перфокарты.
если у тебя есть гарантия того, что проверяемые условия выполняются - эти проверки - лишние.
Какие гарантии в публичном методе? Да даже в приватном методе таких гарантий никто не даст. Завтра придет новый сотрудник и забудет проверить.
Что об этом говорят спеки мелкомягких?
Очевидно, что у тебя есть к ним доступ - возьми и почитай.
Ну а кто будет освобождать ресурсы задействованные на каждой итерации?
Примерчик плиз, а там будет видно как освобождать ресурсы.
ну так и продолжает.
-----
Продолжает - это не отсутствие падения в связи с не обработанным ехцептионом.
Продолжает - это выполняет весь набор операционистики.
Ну нельзя это изменить.
-----
Ни и чего? Ну нельзя - пусть админы бегают и ищут где и чего там продублировалось.
Ну и продолжение работы, из-за такой мелочи как нарушение в функционирования сети, никто не отменял...
вместо того, чтобы действовать строго по инструкции :)
-----
И че? Если в инструкции написано - застрелится - будешь стреляться или сначала сломаешь стрелялку, потом из нее застрелишьсйa?
Какие гарантии в публичном методе?
-----
Да обычные, чернобелые в цветной горошек...
Завтра придет новый сотрудник и забудет
-----
Не забудет, а не будет знать какие условия и каким образом гарантировались.
Ибо для него это тоже "окружение", в котором он не должен разбираться...
И то, что ты выбросишь и как-то обработаешь исключение не сделает систему рабочей с смысле получения нужного результата.
Я бы напряг тех, кто в этом разбирается
-----
Ты полагаешь Я один ковырялся? Ну не нашлось в сети описания этой проблемы и ее решения.
Никто не понимает в чем именно состоит проблема.
Как прогер Я могу слепить что-нибудь на базе, но в обход существующей системы, но сказали - не надо.
И подобных проблем - много.
Одно из двух
-----
Из трех.
Третье - делай что должен и будет так как будет.
Лично Я не выдержу написание документации к 2 Гб спагетти-кода... даже на русском...
у тебя есть к ним доступ
-----
У тебя
- тоже. И даже оперативная помощь экспертов имеется... => social.msdn.microsoft.com
Примерчик плиз
-----
Ну что-нибудь из вот этой группы:
https://docs.microsoft.com/en-us/windows/win32/memory/about-memory-management
Ну и в принципе все остальное за пределами среды ДотНета...
https://support.microsoft.com/en-us/help/982734/you-cannot...
В сторону отключения SMB2 на семёрке тоже можно посмотреть.
пусть админы бегают и ищут где и чего там продублировалось.
Именно так. Тем более, что у них и инструментарий для этого есть.
Если в инструкции написано - застрелится
Ты как школьная училка :D Задаешь такие же тупые вопросы :)
Не забудет, а не будет знать какие условия и каким образом гарантировались.
Ибо для него это тоже "окружение", в котором он не должен разбираться...
А потом ты удивляешься, что у тебя 2Гб спагетти кода. Ясен хрен у тебя ж там половина - мусор... ээээ, пардон, необходимые проверки параметров перед вызовом методов
И то, что ты выбросишь и как-то обработаешь исключение не сделает систему рабочей с смысле получения нужного результата.
Сделает.
Никто не понимает в чем именно состоит проблема.
Еще раз, ZigBee используется в "умных домах", эти системы продаются миллионами, а проблемы только у тебя. Я все таки склоняюсь к тому, что проблемы не в ZigBee....
И подобных проблем - много.
Конечно много. И чем больше будешь лезть туда, где ты ничего не понимаешь, тем больше будет проблем.
Ну что-нибудь из вот этой группы
Ну т.е. примерчик ты предоставить не можешь.
Именно так.
------
Ты вторую часть опустил - пока они бегают - прожка должна продолжать работать.
А потом ты удивляешься, что у тебя 2Гб спагетти кода.
------
А чего мне удивлятся - это твои требования.
Ясен хрен у тебя ж там половина - мусор
-----
У меня, увы, мусор не половина, а порядка 94%...
По крайней мере пока получается из 60-70К оставить 2-3К на страницу...
Но данный вопрос - не ко мне - оно устраивает заказчика/владельцa и пусть так и будет...
Сделает.
-----
Увы. С точки зрения полученного результата - не сделает.
У меня куча кода, результат работы которого зависит от того, в какой момент времени произойдет, а она происходит гарантированно, ошибка обработки данных.
Ну а момент выброса исключения определяется тем, в каком порядке оракл выдаст строки в выборке.
Причем написано все "аккуратно" - ехцептион катчится и давится - пользователь хлопает глазами и спрашивает - Где мои Данные?
Можно, конечно, слегка это дело подчистить, но, увы, построение имени поля по данным из выборки гарантирует появление ошибки при введении новых данных...
Еще раз, ZigBee используется в "умных домах", эти системы продаются миллионами, а проблемы только у тебя.
------
А откуда у меня проблемы? У меня как раз проблем нет. У меня есть необходимые знания, проверенные практикой.
Проблемы у того, кто ждет и обрабатывает ехцептион с сокета, не желая разобраться в проблеме...
Я все таки склоняюсь к тому, что проблемы не в ZigBee....
-----
Не надо склонятся - склонение ведет к ожиданию и обработке ехцептиона сокета,
Надо - знать.
Ну а чтобы знать - надо лезть туда где не знаешь и довольно глубоко там копать.
примерчик ты предоставить не можешь
------
Ну раз уж тебе так надо - открой стредствами винды (не ДотНета) на каждом уровне по сокету - будешь писать туда отчет об удаленных файликах... и папочках...
Как обычно - открытие при входе и закрытие на выходе. И не забудь проскочить мимо закрытия по ехцепшену - ты же его используешь для управления...
Задаешь такие же тупые вопросы
-----
Ну так кроме полностью абсурдных ты никакие другие не воспринимаешь...
приведете мне пример юнит теста для моего xamarin кода который будет проверять смогу ли я установить мой код на моем смартфоне,
Юнит-тесты не проверяют поведение программы. Они тестируют код. Причем конкретный кусок кода. И это большая разница. Допустим я написал прогу-оболочку, запускающую другую прогу, которая в свою очередь что то должна писать. Если ничего не пишется, то моя прога не работает. А вот код в моей проге может быть абсолютно правильный, ибо она просто вызывает. И вызов работает.
Так вот юнит-тесты не проверяют "пишет-не пишет". Ибо мой кусок кода НЕ должен писать. А проверяют "вызывает-не вызывает". А вот другую прогу НУЖНО заменять в тесте моком, который будет работу симулировать только для теста.
Основная философия - проверяем только код и
только то, что код сам конкретно делает. А не результаты, которые приходят после того, как метод вызвал цепочку другого кода, в котором что то произошло.
пока они бегают - прожка должна продолжать работать.
С двумя-то одинаковыми ИП в сети?
А чего мне удивлятся - это твои требования.
Опять придумываешь.
ехцептион катчится и давится
мда...
У меня как раз проблем нет.
Так что же ты тогда тут заливаешь об ошибках каких-то?
открой стредствами винды (не ДотНета) на каждом уровне по сокету
опять на ходу требования уточняем? :)
В любом случае, есть IDisposable и using ими можео гарантировать освобождение ресурсов.
С двумя-то одинаковыми ИП в сети?
------
И что такого? Ну сбоит сеть... фига... завод должен продолжать работать... пока не устранят...
Или до тебя только сейчас начинает доходить, что в этой ситуации вообще можно продолжать работать?
Так что же ты
-----
Ну Я вообще-то тебя спросил и ты ответил - будешь вылизывать сокет и клиентский код.
Ну а в ZigBee на возможность доставить команду на устройство сокет, конечно, влияет, но вот не гарантирует что доставленное будет принято.
Ну да ладно - для тебя, сидящего на сокете и не интересующегося окружением, это слишком сложно...
опять на ходу требования уточняем? :)
-----
Ну а что делать - ты же всегда закладываешься на самый благоприятный вариант, а в жизни оно немного по-другому...
есть IDisposable и using ими можео гарантировать освобождение ресурсов.
-----
Правда? У сокетного (не ДотНет, а ВинАпи) хендла есть IDisposable?
Может у него еще и IUnknown для комплекта в наличии? Тогда и до диспозабла добраться не проблема...
Нее, лучше уж отправить тебя сравнивать 10(левое и 10(правое) - там ты хоть понимаешь с чем рабоатешь...
Или до тебя только сейчас начинает доходить, что в этой ситуации вообще можно продолжать работать?
Так завод и работает. В чем проблема?
Ну а в ZigBee на возможность доставить команду на устройство сокет, конечно, влияет, но вот не гарантирует что доставленное будет принято.
Насколько я помню, сокет - это пара из IP адреса и порта, т.е. сокет - это понятие из IP-протокола. Таким образом, фраза "доставить что-то на сокет по протоколу ZigBee" не имеет смысла.
Ну да ладно - для тебя, сидящего на сокете и не интересующегося окружением, это слишком сложно...
Ага, зато если послушать тебя, съевшего собаку на ZigBee, то получается, что устройства ZigBee несут в себе опасность для всего мира. И хакеры должны выстраиваться в очередь за этим волшебным железом :) А что? Подключился к сети и трындец - все программы (кроме твоей конечно) сдохли. Кррррасота :)
У сокетного (не ДотНет, а ВинАпи) хендла есть IDisposable?
У .Net'ого есть. Если по какой-то причине .Net'й сокет использовать нельзя, а можно только ВинАпи, то всегда можно обернуть сокет ВинАпи враппером и реализовать IDisposable.
Враппер, кстати, сделает использование ВинАпишного сокета тестируемым :) Так что одни сплошные плюсы.
Насколько я помню, сокет - это пара из IP адреса и порта
-----
Плоховато у тебя с сокетами.
Точнее - у тебя с сокетами ровно так как ты их видишь из программы. И не более.
Если тебе задать вопрос - как на одной паре ИП+порт будут работать несколько подключений - ответа у тебя не будет.
Может все же надо внимательно изучать окружение?
фраза "доставить что-то на сокет по протоколу ZigBee" не имеет смысла.
------
Ну, во-первых, фразу ты синтезировл самостоятельно.
А во-вторых - фраза таки имеет смысл, если смотреть на систему в целом, а не только на сокет.
ZigBee несут в себе опасность для всего мира
------
И не просто опасность, а сертифицированную опасность. Очень страшно....
можно обернуть
------
Да-да... особенно - в чужем коде и особенно для нелюбителей изучать окиружение...
Если тебе задать вопрос - как на одной паре ИП+порт будут работать несколько подключений - ответа у тебя не будет.
От сюда следует, что ответ будет у тебя :D Ну давай, рассказывай.
Может все же надо внимательно изучать окружение?
Нафига мне твое окружение? :)
Ну, во-первых, фразу ты синтезировл самостоятельно.
Твоя фраза:
Ну а в ZigBee на возможность доставить команду на устройство сокет
Сокет - это термин из мира IP, ZigBee - с IP никак не пересекается. Соответственно переслать что-то по протоколу ZigBee на сокет нельзя. При этом наверняка есть устройства, которые работают "мостами"/"шлюзами" между ZigBee и IP, но это уже другая тема. И если у тебя эти устройства глючат, то это проблема этих устройств, но никак не клиентского софта.
А во-вторых - фраза таки имеет смысл, если смотреть на систему в целом, а не только на сокет.
На колу мочало, начинай сначала.
Да-да... особенно - в чужем коде и особенно для нелюбителей изучать окиружение...
:) Красота! Каждый раз что-то новенькое :) То нельзя использовать .Нет, теперь вот код еще чужой :)
Ладно, открою тебе великую тайну - сокеты в ВинАпи - это тоже "чужой код" и, как нетрудно догадаться, любой "чужой код" можно обернуть враппером.
Ну давай, рассказывай.
----
Ох, ты-жжж...
Никак просишь рассказать тебе об том, что для тебя явлается окружением которое изучать не нужно и вредно...
Неее, не буду тебе вредить... просто скажу что внутренний идентификатор сокета гораздо длиннее ИП+порт.
И если у тебя эти устройства глючат, то это проблема этих устройств, но никак не клиентского софта.
------
Ну вот и будешь это рассказывать заказчику на предмет - Какого Хрена Оно Не Работает?
любой "чужой код" можно обернуть враппером
-----
Делай. Чужой код - класс А. Если не нравится - могу его статиком сделать.
internal class A
{
public delegate Boolean CheckRecursionCondition();
public event CheckRecursionCondition Condition;
public void Recursion()
{
AllocateResouce();
if (Condition())
{
Recursion();
}
DeallocateResouce();
}
private void AllocateResouce() { }
private void DeallocateResouce() { }
}
internal class B
{
A a;
public B()
{
a = new A();
a.Condition += ConditionChecker;
}
static int count = 0;
private static Boolean ConditionChecker()
{
if (count > 20)
throw new Exception("Dummy");
++count;return true;
}
public static void Runner()
{
B b = new B();
b.a.Recursion();
}
}
это уже другая тема.
-----
А заказчику как-то до лампочки какая этё тема - не работает - это он видит...
И когда в следующий раз упомянешь другую тему, то, плс, упомяни и другое сертифицированное оборудование... а то как-то смурно - тема - другая, а железяки - те же...
Никак просишь рассказать тебе об том, что для тебя явлается окружением которое изучать не нужно и вредно...
На кой фиг мне сдалось твое окружение? :)
просто скажу что внутренний идентификатор сокета гораздо длиннее ИП+порт.
Какой нахрен "внутренний идентификатор" сокета? Ты вообще о чем?
Ну вот и будешь это рассказывать заказчику на предмет - Какого Хрена Оно Не Работает?
Нет, не буду. Я просто скажу ему, что проблема не в моем софте. А уже после этого можно будет начать разговоры о возможных путях решения проблемы.
Чужой код - класс А.
Это интернал-то? :)
public interface IA
{
public event CheckRecursionCondition Condition;
public void Recursion();
}
public class Wrapper_A : IA
{
private A a = null;
public Wrapper_A ()
{
a = new A ();
a.Condition += ConditionChecker;
}
private Boolean ConditionChecker()
{
try
{
if (Condition != null)
return Condition ();
return false;
}
catch
{
return false;
}
}
public event CheckRecursionCondition Condition;
public void Recursion()
{
A.Recursion ();
}
}
Ну и использование:
internal class B
{
public IA a {get; private set; }
public B(IA a)
{
this.a = a;
a.Condition += ConditionChecker;
}
static int count = 0;
private static Boolean ConditionChecker()
{
if (count > 20)
throw new Exception("Dummy");
++count;
return true;
}
}
public static void Runner()
{
B b = new B(new Wrapper_A());
b.a.Recursion();
}
Как-то так.
А заказчику как-то до лампочки какая этё тема - не работает - это он видит...
С таким же успехом от заказчик может требовать работы твоего софта от производителя железок. Я не могу отвечать за работу других компонентов. И при выполнении своей работы я исхожу из того, что другие компоненты работают без ошибок.
А уже после этого можно будет начать разговоры о...
-----
...где найти другого дурака готового расстаться с деньгами на разработку.
Как-то так.
-----
Ну да - осталось выполнить то, об чем был разговор изначально - выход из рекурсии посредством эхцептиона...
Я не могу отвечать за работу других компонентов.
-----
Тебе не за это надо отвечать, а за работоспособность системы в целом, со всеми железками и деревяшками.
И для того чтобы заставить ее работать - придется изучить и изучить в деталях что и как надо делать не только на сокете, но и в каждом девайсе.
Не можешь, не умеешь, не хочешь - свободен...
будешь ли ты использовать ехцептион для выхода из вложенных циклов или рекурсии...
Выход из цикла или из рекурсии по исключению - это вполне себе нормальный способ. Однако, это не значит, что из всех циклов и рекурсий надо выходить по исключению.
Исключение - это способ сообщить об ошибке или о какой-то специальном состоянии и если эта ошибка или специальное состояние должны заканчивать цикл или рекурсию, то логично и правильно выходить из цикла или рекурсии по исключению.
-----
Ну а с этим кто-то спорит?
Повторюсь - был задана вопрос - А? - на что было отвечено - Да.
По факту было сделано - Нет.
Об нормальности и ненормальнности методики сейчас не говорим.
Мне ведь ничего не стоит запихать выброс исключения во внутрь рекурсивного метода.
Ну а с этим кто-то спорит?
Ну Я надеюсь, что ты не пользуешься исключениями как способом управления работой прожки
Ну т.е. вызодить из цикла и/или рекурсии по исключению - это нормально и никаких проблем с этим нет. Или как?
Повторюсь - был задана вопрос - А? - на что было отвечено - Да.
По факту было сделано - Нет.
Что за фигня? Ты прогнал какую-то дичь, что мол нельзя выходить исключениями из циклов и рекурсий, т.к. не будут освобождены ресурсы. Привел какой-то говно код, который не освобождает ресурсы в случае исключения.
Я обернул твой говно код в оболочку и решил все проблемы, показав тем самым, что даже имея такой говно код можно обойти все проблемы и мало того, что освободить ресурсы в случае исключения, так еще и сделать код тестируемым.
На вопрос "можно ли управлять работой программы исключениями" ответ да.
Мне ведь ничего не стоит запихать выброс исключения во внутрь рекурсивного метода.
Конечно! Писать говно код вообще не очень трудно :)
Получить исключение в нормально работающей программе - это нормально?
А что такое "нормально работающая прога"? Или по-твоему исключение - это только NullPointerException, деление на 0, переполнение стека, AccessViolation и прочее?
Сгенерировать исключение в случае, если нет доступа к БД или к файлу - это вполне себе "нормально работающая программа".
В старые времена ошибка возвращалась в виде целочисленного значения - 0 - нет ошибки, все остальное - код ошибки. Сейчас вместо возврата значения ошибки кидают исключение и да это "нормально работающая программа".
Безусловно, а вот если исключение генерится, но никакой ошибки нет.
Что значит нет никакой ошибки? Ты же понимаешь, что надо определить, что ты называешь ошибкой? :)
Вот например, при итерации кидается исключение, если коллекция каким-либо образом изменена. Это ошибка?
Или например кинуть исключение, если не удалось соедениться с удаленным хостом. Это ошибка?
Ну т.е. вызодить из цикла и/или рекурсии по исключению
-----
Никогда не считал подобное нормальным.
Хотя пару раз - пользовался и даже объяснял молодой девахе что с точки зрения управления так можно, но есть куча вопросов.
Я обернул твой говно код в оболочку и...
-----
...нарушил начальное утверждение - выход из рекурсии посредством ехцептиона.
На вопрос "можно ли управлять работой программы исключениями" ответ да.
-----
Посредством генерации ошибок? Да, разумеется можно...
Блин... вот почти как сейчас - в бэкграунде прожка тянет данные по запросу с сервака...
уже 38 минут... еще даже первую секцию не вытянула... а секций - с десяток...
Как хочется ее ехцептировать... и это будет исключительно правильное решение...
К сожалению деньги платят за другое...
Сгенерировать исключение в случае, если нет доступа к БД или к файлу - это вполне себе "нормально работающая программа".
------
Для тебя - да.
Для меня - нормальным будет логирование события - "потеряна связь с сервером" и переход на чуточку другой протокол работы с тем же сервером. Ну нельзя мне мне останавливаться из-за мелких сбоев в сети. Тем более что сбои в сети - явление обычное.
Сейчас вместо возврата значения ошибки кидают исключение и да это "нормально работающая программа".
-----
Это - ужас - после выброса исключения никто не гарантирует определенного состояние системы - место выброса жестко не определено.
Особенно, если не смотреть что там окружении шебуршится...
При "коде возврата" хоть что-то гарантировалось.
так может рецептом поделишься?
-----
Берется юниорный прогер вульгариус одна штука.
Сажается на проект. Медленно, чтобы не заметил проблем и не соскочил.
Потом начинается готовка. Многие практикуют начинание с запарки.
Вот когда он уже достаточно запарен, можно начинать повышать накал
- сделать юниора скажем миддлом и добавить жару.
Потом, когда устаканится и перекипятится миддле - можно еще поднять
градус - сделать сениором и если на проекте сидит плотно - варить на
полном огне до готовности проекта.
Когда проект дойдет до готовности... сениор прогер все еще не будет
готов - можно подсадить на два и более проекта... но - осторожно - чтобы
не сорвался с криком "что Я вам лошадь ломовая что ли?"...
Дальше количество проектов доводится до уровня когда прогер уже не
понимает что происходит, но устойчиво сидит на множестве проектов
и варится, варится, варится...
Признаком дохождения до крутого состояния является готовность взять
еще несколько проектов... тут главное не дать сорваться в свободное
плавание или собственный бизнес...
Для меня - нормальным будет логирование события - "потеряна связь с сервером" и переход на чуточку другой протокол работы с тем же сервером. Ну нельзя мне мне останавливаться из-за мелких сбоев в сети. Тем более что сбои в сети - явление обычное.
Да ты просто не знаешь чем отличается генерация ошибки от обработки ошибки :)
Это - ужас - после выброса исключения никто не гарантирует определенного состояние системы - место выброса жестко не определено.
Тебя просто нельзя допускать к современным проектам. Вот кодить на ANSI C где-нибудь в 70х годах - это твое :)
При "коде возврата" хоть что-то гарантировалось.
Ничерта там не гарантировалось. Говно-код можно писать используя любой язык программирования и любой способ возврата ошибки. Будь то исключение или "код возврата"
Ну нет ошибки - просто пакет ушел на другой хост. Ответ от него, кстати, на уровне TCP/IP можно получить, но там на оговоренном порту нет нужного сервиса...
И опять пошла морока про коварный зарубеж (с) Высоцкий
Надоело переливать из пустого в порожнее.
что надо определить, что ты называешь ошибкой?
Хм оказывается точного определения и нет.
https://studopedia.ru/15_119158_opredelenie-ponyatiya-oshi...
Можно сказать так, что если программа работает как ожидается, то ошибок нет.
Если цикл должен крутиться 5 раз и он все 5 раз крутится, то ошибок нет. Если же он на 5-й раз выходит по эксептион, то это непорядок.
Вот как раз свежий примерчик, до пятницы при старте программы мне нужно было нажать один раз ф5 и всё было нормально.
Теперь приходится делать раз 10 потому как вываливаются исключения которые в принципе не влияют на работу программы, но являются неприятными для меня.
твоем говно-коде иначе нельзя было
------
Однако мой говнокод для тебя есть говнокод внешний, из окружения, которое, по твоему изначальному утверждению, знать не требуется.
Но даже это не меняет сути - выход по эхцетиону из рекурсии илии вложеных циклов - это большой геморой, как и вся эхцептионская срань...
Можно сказать так, что если программа работает как ожидается, то ошибок нет.
Если цикл должен крутиться 5 раз и он все 5 раз крутится, то ошибок нет. Если же он на 5-й раз выходит по эксептион, то это непорядок.
Ну ОК, а если цикл крутится 4 раза, после этого вылетает исключение. Исключение это обрабатывается и цикл запускается еще раз. И так до тех пор, пока он (цикл) не прокрутится 5 раз. В этом случае ошибка есть или еще таки нет?
Вот как раз свежий примерчик, до пятницы при старте программы мне нужно было нажать один раз ф5 и всё было нормально.
Теперь приходится делать раз 10 потому как вываливаются исключения которые в принципе не влияют на работу программы, но являются неприятными для меня.
И что? Это неисправленные ошибки или нет?
Однако мой говнокод для тебя есть говнокод внешний, из окружения, которое, по твоему изначальному утверждению, знать не требуется.
Я также говорил, что исходить надо из того, что окружение работает без ошибок. Если ошибки там все таки есть, значит их надо нивелировать (если это возможно). В данном случае мы имеем дело с банальным багом.
Но даже это не меняет сути - выход по эхцетиону из рекурсии илии вложеных циклов - это большой геморой, как и вся эхцептионская срань...
Вот только эта хрень делает код читабельным, сопровождаемым и тестируемым, а также упрощает отладку (если конечно не попадаются мудаки, которые "проглатывают" исключения)
------
Сегодняшний выхлоп:
Exception thrown: 'Oracle.DataAccess.Client.OracleException' in Oracle.DataAccess.dll
Exception thrown: 'System.Net.Sockets.SocketException' in System.dll
Exception thrown: 'System.Net.WebException' in System.dll
Exception thrown: 'System.Net.WebException' in System.dll
Exception thrown: 'System.Net.WebException' in System.dll
Exception thrown: 'System.Net.Mail.SmtpException' in System.dll
Это вся информация.
Эээ... добавлю - данные - получены. 45К строк...
Ну и что будем нивелировать? Чтобы повторить результат надо часов 6... может - 8+...
В случае с ZigBee - там нет ошибок. Там есть элементарное непонимание того с чем надо работать.
Это вся информация.
Эээ... добавлю - данные - получены. 45К строк...
Ну и что будем нивелировать? Чтобы повторить результат надо часов 6... может - 8+...
Ты так нихрена и не понял.
В случае с ZigBee - там нет ошибок.
Ну и отлично. Значит все работает как надо :)
Там есть элементарное непонимание того с чем надо работать.
Ну так топай своей проторенной дорожкой - разбирайся.
Хи-хи... Это Я про твое решение по рекурсии...
В моем промере исключение обрабатывается, а не проглатывается.
если вылетает, потому что допустим соединение прервалось,то это ошибка и правильно
А если сам выбрасываешь исключение чтобы цикл по новому запустить, то это уже непорядок.
Почему не порядок? Вот предположим, ты отправляешь сообщение и ответом на это сообщение является 5 сообщений от удаленного сервиса. Ты принял 4 сообщения, а вместо 5-ого сообщения ты принял нечто, чего ты не ожидал. Т.е. соединение не рвалось и о возникшей ошибке знаешь только ты. Выход - сгенерировать исключение. Почему же это непорядок?
Я уже представляю себе картину : когда в спор между двумя программистами, встревает тестировщик, со словами: "У вас вот тут вот ошибочка..." ...и повисает тишина....
Вот интересно, что происходит потом....
a) программисты дружно рассмеются
б) програмисты не обратят никакого внимания и продолжат свою дискуссию.
с) прогрмммистам захочется как следует врезать тестировщику.
По окончании курса на тестировщика, нам отвели 8 часов на проект, в котором был дан веб сайт и доступ к интернету. Сдать каждый должен был 5 документов: Требования (!!!), Ревью на требования, Тест план и штоерунг, тест кейсы и баг репорт. Нужно было протестировать онлайновскими Tools'ами и описать ошибки. Я делала обычные, т.к мне достался веб-журнал: нагрузочный, HTML, CSS, кроссбраузерное, линки, робот, Ява скрипт. Кругом было найдено куча ошибок. Вернее их находили программы, мне их нужно было только описать. Но их было так много, что мама дорогая!
Вообще можно добавить, что эта работа не для всех... Скрупулезная и монотонная...
Потом, даже цель какая-то обратная: ты как бы не созидаешь а наоборот, пытаешься разрушить или найти изъян буквально во всем...и чем больше, тем лучше!!! )))
Но в общем вопрос сводится к тому, что будем ли мы использовать goto или нет
Ну в таком случае вызов любой функции сводится к использованию goto Так что надо забить на ООП и фигачить все в одной функции... впрочем, всякие там условные переходы и циклы - тоже сводятся к goto...
Цель: стать мануальным тестером, потом может и автоматизатором;
Ну так и не изменяйте своей цели. Изучение немецкого, тем более находясь на территории немецкоговорящей страны это повседневная обязанность и она никак не связана с профессией тестировщика.
Лично мой опыт был такой:
в 38 лет работая менеджером в управлении эмиссии и сопровождения банковских карт известного в России банка вечерами читал книгу Романа Савина - тестирование дот ком + Святослава Куликова - тестирование ПО. Базовый курс. Одновременно взял курсы по основам Java по месту своего жительства (чтение и курсы 2 месяца). После курсов начал рассылать резюме на вакансии. На поиск работы ушло месяцев 5. Да, подвинулся по ЗП в части достижения своей мечты в меньшую сторону, но не надолго. Через 4 месяца мануального тестирования меня уже позвали в подразделение автотестирования UI. Вот так и вошёл в QA.
Я может где-то не так выразилась...я совсем не жалуюсь на немецкий, тем более это не первый ин. язык в моей жизни...И совсем не хочу никуда "сворачивать" от информатики...для чего ж я училась? Если через тестирование я смогу зайти в IT , я буду только счастлива. А там будет видно...Но есть одно "но": Чем больше я углубляюсь в тестирование, тем больше я понимаю, что это не совсем мое...мне нужно больше креатива...
Я отлично сдала экзамены, пришла домой...и никакой удовлетворенности....(Что, такого ни у кого в жизни не бывало?) Потом села за компьютер...подумала...и купила себе весь пакет Аdobe creative...и начала заниматься по ю-тубу....и 2ю неделю уже не вылезая я там сижу и понимаю, что все это мне действительно в кайф! И что мне не надо себя заставлять этим заниматься...это идет натурально...само-собой...изнутри...и это то, что мне нравилось всегда и с детства...
Это заставило меня задуматься...Теперь можете бросаться в меня тапочками...мол не знает, чего хочет...А я очень даже рада, что смогла разобраться в себе...
А если у кого-то получается иметь свое хобби , как работу, то это счастливые люди по-моему. Я искренне рада, что у вас получилось..
ПС: Савина читала, да с юмором...но считаю, что книга имеет мало общего, например, с Syllabus или местной Basiswissen...или она уже просто устарела...