Petrov.Sergey

Не очень понимаю, как могут впарить господа работодатели составить тест-план начинающему тетсировщику...

Господа работодатели не понимают, что такое тестирование.

Но знают про существование такого документа как "Тест-план", который суперкрутой и решает много проблем.

"Надо бы и нам сделать такой! Кто будет делать? Конечно же, тестировщик! Он у нас один - ничО, справится!"

Только вот на второй вопрос из трёх главных "Что (делаем)? Зачем (делаем)? Как (делаем)?" они не ответили. А именно в нём и кроется суть - тест-план им не нужен, потому что они сами не понимают, зачем он им.

 

Ну ладно вам, не набрасывайтесь так сразу все на человека.

 

Это вопросы с собеседования, да? Судя по формулировкам они рассчитаны не совсем на новичка.

Какие знания у вас уже есть? Может на часть вопросов вы сможете ответить сами?

Пишите свои рассуждения, а мы направим вас в  нужное русло.

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

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

1. Когда необходимо приступить к тестированию программного модуля?

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

д) После того, как разработчик закончил регрессионное тестирование (точно нет, разработчики его не проводят).

Юнит-тестирование необходимо выполнять до написания кода

Правда, многие этого правила не придерживаются.

 

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

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

Пример: дорога расчитана на 4 автомобиля в ряд (4 полосы в одну сторону).

Вы запускаете 1, 2, 3, 4 автомобиля - всё ОК.

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

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

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

Я бы ответил "б"
 

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

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

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

6. Вы разрабатываете план тестирования информационного портала крупной компании. Портал предоставляет доступ к внутренним информационным ресурсам как сотрудникам компании, так и внешним потребителям товаров и услуг компании. Разработка портала завершена в полном объеме. Тестирование проводилось на каждой итерации в ходе разработки. Какой набор видов тестирования необходимо включить в план?
Мне не понятна фраза "Тестирование проводилось на каждой итерации в ходе разработки", но предполагаю, что модульное тестирование уже проведено.

Именно модульное тестирование и означает эта фраза.

 

7. Вы тестируете техническое задание на разработку системы электронного документооборота для дошкольного учреждения (ДОУ). Основные цели разработки и развертывания системы сформулированы так: 

 - автоматизировать процесс постановки ребенка на учет в ДОУ; 

-  обеспечить быстрый обмен данными с министерством образования; 

 - хранить исторические данные о каждом ребенке. 

Какое из перечисленных требований ТЗ не соответствует целям системы?
Сложный вопрос. Но хочется ответить:
д) Реализовать контроль прохождения документа между сотрудниками подразделений

Вот именно "д" я бы оставил, но присмотрелся бы к пункту "а". Какой архив, если база пустая на момент старта?

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

WINDOWS:

net start = список всех запущенных сервисов

Чтобы перенаправить поток из консоли в файл, нужно использовать знак "больше".

Пример:

C:\>net start > c:\<fullpath>\services.txt

На выходе файл services.txt по указанному пути в кодировке CP866

Удачи!

Спасибо большое за ответ)! .  ISTQB планирую в конце этого года сдавать, в Варшаве появилась специальность " Тестер ПО"  и сдача этого сертификата входит в обучение. 

"Тестер ПО" - это официальное название?

В некоторых московских и питерских ВУЗах есть специальность "Специалист по тестированию ПО". В прошлом году со мной работала девушка с дипломом по этой специальности.

ISTQB - сертификат тестировщика. Сдаётся экзамен ТОЛЬКО на английском языке.

Там Вам и термины, и знания, и сертификат, которым будете махать перед носом HR-ов при приёме на работу.

Это не просьба о помощи, а просьба "сделайте мне".

Не стыдно быть взрослым мальчиком и просить о таком?

В моем случает "потребитель сервисов" - это Ваш генератор запроса.

Сергей, что такое и как должен по Вашему работать генератор эталонного ответа в случае, если сервис возвращает, скажем, только номер договора?

1) послал запрос.

2) получил ответ (просто получил, пока ещё не знаю, что в нём. Главное, что не ERROR - на это проверку делаю). Факт получения ответа гарантирует, что сервис уже отработал.

3) полез в БД. По своим посланным данным ищу, что в БД изменилось. Если должен был быть создан договор, то ищу, какой договор был создан по моему запросу. Если не создан => сразу фейл (на этом тест можно завершить, независимо от того, что вернул в ответе сервис). Если создан, беру его номер (от сервиса же ожидается номер договора).

4) на основании данных, взятых из БД, формирую эталонный ответ.

5) сравниваю эталонный ответ с вернувшимся от сервиса (пункт 2). Все поля должны быть идентичны.

Если вернувшийся номер договора не совпадает с моим, который я достал из базы, => фейл.

Таким образом проверяю не только факт возвращения номера договора, но и то, что номер договора вернулся правильный, соответствующий параметрам запроса, а не наобум сгенерённый/выбранный из БД.

Эталонный ответ = объект того же класса, что и ответ сервиса.

Только ответ сервиса = client.getResponse().

А эталонный ответ генерится мной отдельно: Response etalon_resp = new Response();

Генератор эталонного ответа - это метод, принимающий на вход объект "запрос" и возвращающий объект "ответ". Внутренность этого метода = пункты 3+4 из списка в этом посте.

Сергей, что Вы имеете в виду?

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

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

Я делал так:

На основе WSDL через утилиту wsimport генерировал JAVA-модель.

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

Потом клепал сами тесты: вызывал генератор запроса, через CXF отправлял запрос и получал ответ. Генерил эталонный ответ. Сравнивал с тем, что пришло.

Генератор запроса использовал статические данные только в параметризованных полях. Остальное рандомизировалось.

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

Параметров было порядка 5-7 (уже не помню).

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

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

Используйте два инстанса WebDriver.

В контексте каждого из них будет жить своя сессия.

 

Кстати, насчёт моего кода.

Конкретно ганимедовская либа не даёт открыть сессию и держать её столько, сколько нужно, работая как в "шелл-режиме".

Она позволяет открыть коннект, выполнить команду, которая возвращает результат (или несколько через ";"), а потом закрывает сессию.

Вот дока по этой либе: http://www.ganymed.e...sessioncommands

спасибо! это важная информация. 

Для меня это тоже было проблемой. Но сейчас навострился. Все тяжёлые скрипты запихал в баш-файлы на удалённом серваке и через SSH-connect вызываю эти скрипты и забираю результат либо в виде файла (ганимедовская либа позволяет осуществлять также SCP-connect = Secure Copy Protocol для обмена файлами с SSH-сервером), либо в виде консольного потока вывода в формате data и в формате error:

		try {
			sess.execCommand(command);

			BufferedReader stdoutReader = new BufferedReader(new InputStreamReader(new StreamGobbler(sess.getStdout())));
			BufferedReader stderrReader = new BufferedReader(new InputStreamReader(new StreamGobbler(sess.getStderr())));

			String data = new String(), errors = new String();
			while (true) {
				String line = stdoutReader.readLine();
				if (line == null)
					break;
				data += line + "\n";
			}
			stdoutReader.close();
			output.setData(data);

			while (true) {
				String line = stderrReader.readLine();
				if (line == null)
					break;
				errors += line + "\n";
			}
			stderrReader.close();
			output.setErrors(errors);
		} catch (IOException e) {
			e.printStackTrace();
		}

Кстати, насчёт моего кода.

Конкретно ганимедовская либа не даёт открыть сессию и держать её столько, сколько нужно, работая как в "шелл-режиме".

Она позволяет открыть коннект, выполнить команду, которая возвращает результат (или несколько через ";"), а потом закрывает сессию.

Вот дока по этой либе: http://www.ganymed.e...sessioncommands

 

Правильные варианты ответов:
Нубский:
1. 1+1    2. 10+10    3. 10+1
1. 2+9    2. 1+10      3. 10+1
Нормальный:
1. 1+2    2. 9+10      3. 10+1

А распишите, пожалуйста, почему так? У меня есть предположения, но я не уверен, что правильные.

 

Я не автор предлагаемого варианта, но в принципе понимаю ход мыслей при построении указанных множеств.

Все они преследуют следующие цели:

1) хотя бы в одном тесте первое слагаемое должно быть = 1

2) хотя бы в одном тесте второе слагаемое должно быть = 1

3) хотя бы в одном тесте первое слагаемое должно быть = 10

4) хотя бы в одном тесте второе слагаемое должно быть = 10

5) плюс надо проверить значения, близкие к границе (2 и 9)

6) надо проверить хотя бы одним тестом переполнение.

С чем я не согласен в приведённых вариантах - так это с некорректным определением границ и проверки данных вблизи границ.

Возьмём абстрактную задачу, в которой только один параметр Х, имеющий множество допустимых значений [A, B]. Какие числа надо проверять, подставляя в Х?

Очевидно, надо обязательно проверить А и В. Также надо обязательно проверить (А-1) и (В+1), чтобы убедиться, что числа А и В являются границами допустимого множества. Плюс обязательно нужно проверить хотя бы одно значение внутри отрезка. Любое, если все числа внутри отрезка принадлежат одному классу эквивалентности. Говорить однозначно, что надо проверить число Х = (А+В)/2, нельзя, потому что, проверяя каждый раз одно и то же значение, можно в будущем нарваться на "эффект пестицида". Поэтому Х = "любое число из промежутка (А,В)", меняющееся в каждом регресс-тесте.

Итого, надо проверить 5 чисел: (А-1), А, любое в промежутке (А,В), В, (В+1).

Собственно, сравнивая предложенную чуть выше абстрактную задачу и предложенное пользователем vmaximv решение, у меня возникает вопрос: зачем в тестах проверяются числа (А+1) и (В-1) ? Причём проверяются жёстко и безапелляционно. Они не являются граничными + они не являются "любыми внутри отрезка".

Я этого не понимаю и был бы рад прочитать объяснение автора - глядишь, может, чему-нибудь и научусь толковому.

 

 

2 пример не соответствует условия.
Целое число может быть отрицательным, где пример вида -7+3. Вполне соответствует заявленным условиям
 

целых чисел от одного до десяти

 

Коллега, извините, но нет
Вот пруф http://ru.math.wikia...iki/Целое_число
 Оно состоит из положительных натуральных чисел (1, 2, 3), чисел вида -n (n) и числа нуль.

Вы будете мне рассказывать, какие множества чисел бывают в математике? 

Натуральный ряд = 0,1,2,3,4,5,... до бесконечности. (иногда натуральным рядом считают целые положительные числа. Тут двоякое понимание)

Целые числа = натуральный ряд + отрицательный натуральный ряд

Рациональные числа = множество чисел вида "целое число, делённое на натуральное число, не являющееся 0".

Иррациональные числа - числа, не представимые в виде рациональной дроби.

Трансцендентные числа - числа, не являющиеся корнями никаких уравнений с рациональными коэффициентами.

Продолжить?

В условии явно сказано: "при условии ввода только целых чисел от одного до десяти".

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

возможности сложить только 3 пары чисел.

1) Что означает эта фраза?

Можно только 3 теста провести (каждый суммирует 2 числа)? Бредовое условие.

2) По условию ввести можно только целые от 1 до 10. (калькулятор принимает только однозначные числа)

Каким образом Вы собираетесь вводить число 11?

А почему именно 11, а не 15 или 23 или 10?

3) Проверку на то, что первое число не может быть = 0, Вы написали. А Вы гарантируете, что второе число не может быть = 0?

4) Вы привели только негативные тесты (калькулятор должен выдать ошибку в каждом из этих тестов). И ни одного позитивного (что калькулятор вообще суммирует и суммирует правильно).

3 тестов тут явно недостаточно.

Имхо, задание бредовое.

Мой минимальный набор тестирования данного калькулятора содержит в себе 4 теста: 2 негативных 0+9, 9+0, один позитивный 3+5 и переполнение 4+8. Вычёркивание хотя бы одного теста из моего набора сразу снимает гарантию на то или иное => гарантию, что ТЗ выполнено в полном объёме и 100% правильно.

Правда, я сразу предполагаю, что калькулятор физически не может принимать на вход двузначные числа. Иначе нужно 6 тестов: 0+9, 9+0, 3+5, 4+8, 1+10, 10+1

Если же требуется точная локализация дефекта, то минимальный набор увеличивается: 0+8, 8+0, 9+1, 1+9, 3+5 (переполнение уже на 9 сидит)

Итого, 4 (мин), 5 (точная локализация), 6 (двузначные) или 8 (с двузначными и точной локализацией) тестов в зависимости от начальных условий, не озвученных в задании.

Как-то так...

В любом случае 3 теста - мало.

Множество тесткейсов является проверяемой документацией.

1) её может просмотреть более опытный коллега, который может указать на:

а) неполноту набора тесткейсов

б) неоднозначность входных данных

в) неактуальность

г) излишество (когда два тесткейса легко объединяются в группу по классу эквивалентности)

д) ...

2) её будете смотреть Вы сами, чтобы провести регрессионное тестирование (неоднократно, хочу заметить!).

3) её может (и должен) просмотреть тест-менеджер, чтобы выделить из множества тесткейсов те, которые пойдут в набор "verification tests" , "smoke tests" и другие группы.

Это те причины, которые мне пришли в голову сходу.

А, ну и самое главное, что важно будет конкретно Вам.

Набор тесткейсов является доказательством того, что Вы проверили функционал.

По этому набору можно будет судить, насколько полно проверен функционал, а также можно оценить, сколько времени потребуется для дальнейшего ретеста (этот момент важен для тестменеджера при планировании).