Тестирование программного обеспечения. Базовый курс. 3-е издание



Pdf көрінісі
бет301/307
Дата03.07.2023
өлшемі5,03 Mb.
#179304
1   ...   297   298   299   300   301   302   303   304   ...   307
Байланысты:
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU

 
Стр: 281/301 
4.2. 
Комментарии к заданиям 
Задание 
Комментарий 
1.1.a
{6}
 
Ответ: около 2e+42 лет, т.е. примерно в 1.66e+32 раза больше, чем 
текущий возраст Вселенной.
Решение: (2
64 
* 2
64 
* 2
64
) / (100’000’000 * 31536000
примерно секунд в году
) = 
1.9904559029003934436313386045179e
+42 лет. 
1.1.b
{8}
 
Для знакомства с широчайшим спектром терминологии тестирования 
рекомендуется внимательно изучить ISQB Glossary: 
http://www.istqb.org/downloads/glossary.html
 
1.2.a
{10}
 
Для очень примерной оценки своего уровня владения английским 
языком можно воспользоваться представленными в широком ассор-
тименте онлайн-тестами, например вот этим: 
http://www.cambridgeenglish.org/test-your-english/
 
1.3.a
{12}
 
Пожалуйста, записывайте свои вопросы. Это не шутка. Сотнями ис-
числяются случаи, когда на тренинге звучит что-то в стиле «Я ж та-
кое (!!!) хотел(а) спросить и забыл(а) 

». 
2.1.a
{26}
 
Если есть ощущение, что многое непонятно или забылось, исполь-
зуйте как источник данные отсюда 
http://istqbexamcertification.com/what-are-the-software-development-
models 
и попытайтесь сделать что-то наподобие собственного кон-
спекта. 
2.2.a
{34}
 
Учли ли вы при составлении списка не только возможность ваших 
собственных недоработок, но и объективные факторы риска? Напри-
мер, цена на некоторый товар выросла, товара не оказалось в нали-
чии. Продумали ли вы, кто уполномочен принимать решение в ситуа-
ции, когда «посовещаться со всеми» невозможно или слишком 
долго? 
2.2.b
{54}
 
При составлении списка вопросов рекомендуется опираться на две 
мысли: а) Как сделать продукт, максимально удовлетворяющий по-
требности заказчика. б) Как реализовать и протестировать то, что 
требует заказчик. 
Игнорирование любого из этих пунктов может привести либо к созда-
нию бесполезного продукта, либо к работе в ситуации неопределён-
ности, когда по-прежнему не до конца ясно, что же разрабатывать и 
как это тестировать. 
2.2.c
{57}
 
После того как вы выполнили это задание, проверьте себя с помо-
щью материала главы «Типичные ошибки при анализе и тестирова-
нии требований»
{63}
. Если вы обнаружили в своей работе какие-то из 
перечисленных там ошибок, исправьте их. 
2.2.d
{62}
 
В продолжение теста на внимательность: заметили ли вы в тексте 
этой книги сколько-нибудь опечаток? Поверьте, они здесь есть. 
2.2.e
{62}
 
По мере детализации набора требований ваши вопросы могут стано-
виться всё более и более конкретными. Также помните, что стоит по-
стоянно держать в голове всю общую картину требований, т.к. на 
низком уровне может проявиться проблема, затрагивающая обшир-
ную часть требований и влияющая на весь проект. 


Комментарии к заданиям
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 282/301 
2.3.a
{77}
 
После того, как у вас закончатся собственные идеи, вы можете при-
бегнуть к небольшой хитрости: поищите в Интернете (и книгах, на ко-
торые приведено множество ссылок) описание различных видов те-
стирования, изучите области их применимости и дополните свой спи-
сок на основе полученных знаний. 
2.4.a
{116}
 
После того, как вы составите список свойств качественных требова-
ний, характерных для чек-листов, подумайте, какими свойствами 
должен обладать чек-лист, чтобы быть универсальным (т.е. чтобы 
его можно было использовать повторно на другом проекте). 
2.4.b
{119}
 
На чём базировались ваши правки существующего чек-листа? Мо-
жете ли вы аргументированно доказать преимущества предложен-
ного вами варианта? 
2.4.c
{135}
 
Возможно, кто-то из ваших знакомых тестировщиков может рекомен-
довать вам то или иное инструментальное средство, исходя из соб-
ственного опыта. Если такого источника информации у вас нет, возь-
мите список соответствующего ПО из Википедии и/или многочислен-
ных обзоров в Интернете. 
2.4.d
{139}
 
Насколько приоритетным будет данный тест-кейс? Если он обнару-
жит ошибку в приложении, какое значение важности вы ей присво-
ите? (Примечание: сама идея «повторной конвертации» бессмыс-
ленна, т.к. повторная конвертация файла, кодировка которого была 
приведена к UTF8, ничем по сути не отличается от просто первичной 
конвертации файла, изначально находящегося в этой кодировке. По-
тому весь этот тест-кейс можно удалить, добавив в один из других 
тест-кейсов файл в кодировке UTF8 на вход конвертации.) 
2.4.e
{154}
 
Заметили ли вы отличия в рекомендациях по написанию тест-кейсов 
и вообще по проведению тестирования в проектах, реализуемых по 
«классическим» и гибким методологиям? 
2.4.f
{156}
 
Если вы хорошо знаете какой-то язык программирования, можете 
написать программу, автоматизирующую представленные в данных 
командных файлах проверки. 
2.4.g
{159}
 
Можно ли сделать ваши автоматизированные проверки более уни-
версальными? Можно ли вынести за пределы командных файлов 
наборы данных? А логику обработки данных? 
2.5.a
{174}
 
Ответ: в отчёте приведена ссылка на требование 
ДС-2.1
, в котором 
сказано, что обработанные файлы помещаются в каталог-приёмник, 
а не перемещаются туда. Конечно, это дефект требований, но если 
подходить строго формально, то в требованиях нигде не сказано о 
перемещении обработанного файла, а потому отчёт о дефекте при-
ложения может быть закрыт, хотя повторная обработка одного и того 
же файла явно противоречит здравому смыслу. Однако! Может выяс-
ниться, что заказчик имел в виду, что приложение должно создавать 
в каталоге-приёмнике обработанные копии всех файлов из каталога-
источника… и тут придётся многое переписывать, т.к. между «обра-
ботать и переместить все файлы» и «обработать и скопировать все 
новые файлы, не затрагивая повторно никакие ранее обработанные 
файлы» есть существенная разница (вплоть до того, что придётся 
вычислять и хранить контрольные суммы всех файлов, т.к. нет ника-
кой гарантии, что в каталоге-приёмнике какой-то файл не был заме-
нён одноимённым). 


Комментарии к заданиям
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 283/301 
2.5.b
{192}
 
Возможно, кто-то из ваших знакомых тестировщиков может рекомен-
довать вам то или иное инструментальное средство, исходя из соб-
ственного опыта. Если такого источника информации у вас нет, возь-
мите список соответствующего ПО из Википедии и/или многочислен-
ных обзоров в Интернете. 
2.6.a
{220}
 
Для начала можно ознакомиться с этим примером:
http://www.softwaretestingclass.com/wp-
content/uploads/2013/01/Sample-Test-Plan-Template.pdf
  
2.6.c
{233}
 
Какие отвлекающие факторы снижали вашу производительность? 
Что у вас занимало больше всего времени (обдумывание тест-кей-
сов, оформление или что-то иное)? Как вы считаете, повысилась или 
понизилась бы ваша производительность, если бы вы провели за 
изучением требований к проекту несколько часов или даже дней? 
2.7.a
{236}
 
Ответ: потому, что здесь мы бы уже проверяли фактически взаимо-
действие двух параметров. Это хорошая идея, но она выходит за 
рамки тестирования отдельной изолированной функциональности. 
2.7.b
{240}
 
Самым эффективным способом доработки представленного списка 
является… программирование. Если вы достаточно хорошо знаете 
какой-нибудь язык программирования, напишите небольшую про-
грамму, которая всего лишь будет получать из командной строки имя 
каталога и проверять его наличие и доступность для чтения. А затем 
протестируйте вашу программу и дополните представленный в за-
даче список идеями, которые придут к вам в процессе тестирования. 
2.7.c
{248}
 
В колонке «Наличие прав доступа» иногда отсутствуют значения, т.к. 
если каталог отсутствует, к нему неприменимо понятие «права до-
ступа». Что касается лишних проверок, то, например, в строках 18 и 
22 пути приведены с «/» в качестве разделителя имён каталогов, что 
характерно для Linux, но не для Windows (хотя и сработает в боль-
шинстве случаев). Такие проверки можно оставлять, но можно и уби-
рать как низкоприоритетные. 
2.7.d
{251}
 
А если, кроме сложности, оценить также время на разработку тест-
кейсов и проведение тестирования? А потом учесть необходимость 
повторять те же проверки многократно? 
2.7.e
{252}
 
Можно использовать приведённый на рисунке 2.5.e
{174}
 
пример описа-
ния дефекта как шаблон для решения этого задания. 
2.7.f
{255}
 
Ответ: это плохое решение, т.к. теперь приложение будет пропускать 
имена каталогов вида «/////C:/dir/name/». Конечно, при проверке суще-
ствования такой каталог не будет найден, но фильтрация данных всё 
равно нарушена. А вот имя «/» всё равно превратится в пустую 
строку. 


Достарыңызбен бөлісу:
1   ...   297   298   299   300   301   302   303   304   ...   307




©engime.org 2024
әкімшілігінің қараңыз

    Басты бет