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

Комментарии к заданиям
Тестирование программного обеспечения. Базовый курс. 
© 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/». Конечно, при проверке суще-
ствования такой каталог не будет найден, но фильтрация данных всё 
равно нарушена. А вот имя «/» всё равно превратится в пустую 
строку. 

жүктеу/скачать 5,03 Mb.

Достарыңызбен бөлісу: