Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Задание 2.7.b: какие ещё группы свойств вы бы добавили в этот список и как бы вы выделили подгруппы у уже имеющихся в списке свойств? Очевидно, что отмеченные группы свойств оказывают взаимное влияние. Графически его можно отобразить в виде концепт-карты 350 (рисунок 2.7.e). Рисунок 2.7.e — Концепт-карта взаимовлияния групп свойств каталога 350 «Concept map», Wikipedia [ http://en.wikipedia.org/wiki/Concept_map ] Локальный SOURCE_DIR Сетевой Права доступа Существование Изначально Во время работы Особенности работы сети Существует Не существует Права есть Прав нет Имя Длина Допустимая Недопустимая Символы Допустимые Недопустимые Комбинации символов Допустимые Недопустимые Зарезервированное Свободное Особенности работы ОС Кодировки Классы эквивалентности и граничные условия Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 238/298 Чтобы иметь возможность применить стандартную технику классов эквива- лентности и граничных условий, нам нужно по рисунку 2.7.e дойти от центрального элемента («SOURCE_DIR») до любого конечного, однозначно относящегося к пози- тивному или негативному тестированию. Один из таких путей на рисунке 2.7.e отмечен кружками. Словесно его можно выразить так: SOURCE_DIR → Windows → Локальный каталог → Имя → Свободное → Длина → В кодировке UTF16 → Допустимая или недопустимая. Максимальная длина пути для Windows в общем случае равна 256 байтам: [ диск][:\][путь][null] = 1 + 2 + 256 + 1 = 260. Минимальная длина равна 1 байту (точка обозначает «текущий каталог»). Казалось бы, всё очевидно и может быть представ- лено рисунком 2.7.f. Рисунок 2.7.f — Классы эквивалентности и граничные условия для длины пути Но если почитать внимательно спецификацию 351 , выясняется, что «физиче- ски» путь может быть длиной до 32’767 символов, а ограничение в 260 символов распространяется лишь на т.н. «полное имя». Потому возможна, например, ситуа- ция, когда в каталог с полным именем длиной 200 символов помещается файл с именем длиной 200 символов, и длина полного имени файла получается равной 400 символам (что очевидно больше 260). Так мы подошли к ситуации, в которой для проведения тестирования нужно либо знать внутреннюю реализацию поведения приложения, либо вносить правки в требования, вводя искусственные ограничения (например, длина имени SOURCE_DIR не может быть более 100 символов, а длина имени любого файла в SOURCE_DIR не может быть более 160 символов, что в сумме может дать макси- мальную длину в 260 символов). Ввод искусственных ограничений — плохая идея, потому с точки зрения ка- чества мы вполне вправе считать представленное на рисунке 2.7.f разбиение кор- ректным, а сбои в работе приложения (если таковые будут), вызванные описанной выше ситуацией вида «200 символов + 200 символов», — дефектом. Таблица 2.7.c — Значения всех входных данных для тест-кейсов по проверке вы- бранного на рисунке 2.7.e пути Позитивные тест-кейсы Негативные тест-кейсы Зна- чение (точка) C:\ 256 байт Пустая строка C:\ 257 байт Пояс- нение Имя с мини- мальной допу- стимой длиной Имя с максимальной допустимой длиной Имя с недопустимой длиной, учтено для надёжности Имя с недопустимой длиной Итак, с одним путём на рисунке 2.7.e мы разобрались. Но их там значительно больше, и потому в следующей главе мы рассмотрим, как быть в ситуации, когда приходится учитывать влияние на работу приложения большого количества пара- метров. 351 «Naming Files, Paths, and Namespaces», MSDN [ https://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath ] 0 1 256 257 Допустимо Недопустимо Недопустимо Доменное тестирование и комбинации параметров Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 239/298 2.7.3. Доменное тестирование и комбинации параметров Уточним данное ранее {92} определение: Доменное тестирование (domain testing, domain analysis 352 ) — техника со- здания эффективных и результативных тест-кейсов в случае, когда не- сколько переменных могут или должны быть протестированы одновре- менно. В качестве инструментов доменного тестирования активно используются техники определения классов эквивалентности и граничных условий, которые были рассмотрены в соответствующей {234} главе. Потому мы сразу перейдём к практиче- скому примеру. На рисунке 2.7.e кружками отмечен путь, один из вариантов которого мы рас- смотрели в предыдущей главе, но вариантов может быть много: • Семейство ОС o Windows o Linux • Расположение каталога o Локальный o Сетевой • Доступность имени o Зарезервированное o Свободное • Длина o Допустимая o Недопустимая Чтобы не усложнять пример, остановимся на этом наборе. Графически ком- бинации вариантов можно представить в виде иерархии (см. рисунок 2.7.g). Исклю- чив совсем нетипичную для нашего приложения экзотику (всё же мы не разрабаты- ваем сетевую утилиту), вычеркнем из списка случаи зарезервированных сетевых имён (отмечены на рисунке 2.7.g серым). Легко заметить, что при всей своей наглядности графическое представление не всегда удобно в обработке (к тому же мы пока ограничились только общими иде- ями, не отметив конкретные классы эквивалентности и интересующие нас значения граничных условий). Альтернативным подходом является представление комбинаций в виде таб- лицы, которое можно получать последовательно за несколько шагов. Сначала учтём комбинации значений первых двух параметров — семейства ОС и расположения каталога. Получается таблица 2.7.d. Таблица 2.7.d — Комбинации значений первых двух параметров Windows Linux Локальный путь + + Сетевой путь + + На пересечении строк и столбцов можно отмечать необходимость выполне- ния проверки (в нашем случае таковая есть, потому там стоит «+») или её отсут- ствие, приоритет проверки, отдельные значения параметров, ссылки и т.д. 352 Domain analysis is a technique that can be used to identify efficient and effective test cases when multiple variables can or should be tested together. [Lee Copeland, «A practitioner’s guide to software test design»] Доменное тестирование и комбинации параметров Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 240/298 Рисунок 2.7.g — Графическое представление комбинаций параметров SOURCE_DIR Windows Linux Локальный Сетевой Локальный Сетевой Зарезерви- рованное Свободное Зарезерви- рованное Свободное Зарезерви- рованное Свободное Зарезерви- рованное Свободное Недопус- тимая Допустимая Недопус- тимая Допустимая Недопус- тимая Допустимая Недопус- тимая Допустимая Недопус- тимая Допустимая Недопус- тимая Допустимая Недопус- тимая Допустимая Недопус- тимая Допустимая Доменное тестирование и комбинации параметров Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 241/298 Добавим третий параметр (признак зарезервированного имени) и получим таблицу 2.7.e. Таблица 2.7.e — Комбинации значений трёх параметров Windows Linux Зарезервирован- ное имя Локальный путь + + Сетевой путь - - Свободное имя Локальный путь + + Сетевой путь + + Добавим четвёртый параметр (признак допустимости длины) и получим таб- лицу 2.7.f. Чтобы таблица равномерно увеличивалась по высоте и ширине, удобно до- бавлять каждый последующий параметр попеременно — то как строку, то как стол- бец (при формировании таблиц 2.7.e и 2.7.f третий параметр мы добавили как строку, четвёртый – как столбец). Таблица 2.7.f — Комбинации значений четырёх параметров Недопустимая длина Допустимая длина Windows Linux Windows Linux Зарезервиро- ванное имя Локальный путь - - + + Сетевой путь - - - - Свободное имя Локальный путь + + + + Сетевой путь + + + + Такое представление по сравнению с графическим оказывается более ком- пактным и позволяет очень легко увидеть комбинации значений параметров, кото- рые необходимо подвергнуть тестированию. Вместо знаков «+» в ячейки можно по- ставить ссылки на другие таблицы (хотя иногда все данные совмещают в одной таблице), в которых будут представлены классы эквивалентности и граничные условия для каждого выбранного случая. Как несложно догадаться, при наличии большого количества параметров, каждый из которых может принимать много значений, таблица наподобие 2.7.f бу- дет состоять из сотен строк и столбцов. Даже её построение займёт много времени, а выполнение всех соответствующих проверок и вовсе может оказаться невозмож- ным в силу нехватки времени. В следующей главе мы рассмотрим ещё одну технику тестирования, призванную решить проблему чрезмерно большого количества ком- бинаций. Попарное тестирование и поиск комбинаций Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 242/298 2.7.4. Попарное тестирование и поиск комбинаций Уточним данное ранее {92} определение: Попарное тестирование (pairwise testing 353 ) — техника тестирования, в которой вместо проверки всех возможных комбинаций значений всех па- раметров проверяются только комбинации значений каждой пары пара- метров. Выбрать и проверить пары значений — звучит вроде бы просто. Но как вы- бирать такие пары? Существует несколько тесно взаимосвязанных математических методов создания комбинаций всех пар: • на основе ортогональных массивов 354 , 358 ; • на основе латинских квадратов 355 ; • IPO (in parameter order) метод 356 ; • на основе генетических алгоритмов 357 ; • на основе рекурсивных алгоритмов 358 Глубоко в основе этих методов лежит серьёзная математическая тео- рия 358 В упрощённом виде на примерах суть и преимущества этого под- хода показаны в книге Ли Коупленда 359 и статье Майкла Болтона 354 , а спра- ведливая критика — в статье Джеймса Баха 360 Итак, суть проблемы: если мы попытаемся проверить все сочетания всех значений всех параметров для более-менее сложного случая тестирования, мы по- лучим количество тест-кейсов, превышающее все разумные пределы. Если представить изображённую на рисунке 2.7.e схему в виде набора пара- метров и количества их значений, получается ситуация, представленная таблицей 2.7.g. Минимальное количество значений получено по принципу «расположение: локально или в сети», «существование: да или нет», «семейство ОС: Windows или Linux » и т.д. Вероятное количество значений оценено исходя из необходимости учитывать несколько классов эквивалентности. Количество значений с учётом пол- ного перебора получено исходя из технических спецификаций операционных си- стем, файловых систем и т.д. Значение нижней строки получено перемножением значений в соответствующей колонке. 353 The answer is not to attempt to test all the combinations for all the values for all the variables but to test all pairs of variables. [Lee Copeland, «A practitioner’s guide to software test design»] 354 «Pairwise Testing», Michael Bolton [ http://www.developsense.com/pairwiseTesting.html ] 355 «An Improved Test Generation Algorithm for Pair-Wise Testing», Soumen Maity and oth. [ https://citeseerx.ist.psu.edu/view- doc/download?doi=10.1.1.147.2164&rep=rep1&type=pdf ] 356 «A Test Generation Strategy for Pairwise Testing», Kuo-Chung Tai, Yu Lei [ https:// citeseerx.ist.psu.edu/viewdoc/down- load?doi=10.1.1.106.8350&rep=rep1&type=pdf ] 357 «Evolutionary Algorithm for Prioritized Pairwise Test Data Generation», Javier Ferrer and oth. [ https://neo.lcc.uma.es/staff/javi/files/gecco12.pdf ] 358 «On the Construction of Orthogonal Arrays and Covering Arrays Using Permutation Groups», George Sherwood [ http://testcover.com/pub/background/cover.htm ] 359 «A Practitioner's Guide to Software Test Design», Lee Copeland. 360 «Pairwise Testing: A Best Practice That Isn’t», James Bach [ http://citeseerx.ist.psu.edu/viewdoc/down- load?doi=10.1.1.105.3811&rep=rep1&type=pdf ]. Попарное тестирование и поиск комбинаций Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 243/298 Таблица 2.7.g — Список параметров, влияющих на работу приложения Параметр Минимальное количество значений Вероятное количество значений Количество значе- ний с учётом пол- ного перебора Расположение 2 25 32 Существование 2 2 2 Наличие прав доступа 2 3 155 Семейство ОС 2 4 28 Зарезервированное или свободное имя 2 7 23 Кодировки 2 3 16 Длина 2 4 4096 Комбинации символов 2 4 82 ИТОГО тест-кейсов 256 201 ’600 34 ’331’384’872’960 Конечно, мы не будем перебирать все возможные значения (для того нам и нужны классы эквивалентности), но даже 256 тест-кейсов для проверки всего лишь одного параметра командной строки — это много. И куда вероятнее, что придётся выполнять около 200 тысяч тест-кейсов. Если делать это вручную и выполнять по одному тесту в пять секунд круглосуточно, понадобится около 11 суток. Но мы можем применить технику попарного тестирования для генерации оп- тимального набора тест-кейсов, учитывающего сочетание пар каждого значения каждого параметра. Опишем сами значения. Обратите внимание, что уже на этой стадии мы провели оптимизацию, собрав в один набор информацию о расположе- нии, длине, значении, комбинации символов и признаке зарезервированного имени. Это сделано потому, что сочетания вида «длина 0, зарезервированное имя com1» не имеют смысла. Также мы усилили часть проверок, добавив русскоязычные названия каталогов. Таблица 2.7.h — Список параметров и их значений Параметр Значения Расположение / длина / зна- чение / комбинация симво- лов / зарезервированное или свободное 1. X:\ 2. X:\dir 3. “X:\пробелы и русский” 4. .\dir 5. ..\dir 6. \\host\dir 7. [256 байт только для Windows] + Пункты 2-6 с “\” в конце пути. 8. / 9. /dir 10. “/пробелы и русский” 11. host:/dir 12. smb://host/dir 13. ./dir 14. ../dir 15. [4096 байт только для Linux] + Пункты 9-14 с “/” в конце пути. Недопустимое имя. 16. [0 символов] 17. [4097 байт только для Linux] 18. [257 байт только для Windows] 19. " 20. // 21. \\ Попарное тестирование и поиск комбинаций Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 244/298 22. .. 23. com1-com9 24. lpt1-lpt9 25. con 26. nul 27. prn Существование 1. Да 2. Нет Наличие прав доступа 1. К каталогу и его содержимому 2. Только к каталогу 3. Ни к каталогу, ни к его содержимому Семейство ОС 1. Windows 32 bit 2. Windows 64 bit 3. Linux 32 bit 4. Linux 64 bit Кодировки 1. UTF8 2. UTF16 3. OEM Количество потенциальных тест-кейсов уменьшилось до 2736 (38*2*3*4*3), что уже много меньше 200 тысяч, но всё равно нерационально. Теперь воспользуемся любым из представленных в огромном количестве ин- струментальных средств 361 ( например, PICT) и сгенерируем набор комбинаций на основе попарного сочетания всех значений всех параметров. Пример первых де- сяти строк результата представлен в таблице 2.7.i. Всего получилось 152 комбина- ции, т.е. в 1326 раз меньше (201’600 / 152) исходной оценки или в 18 раз меньше (2736 / 152) оптимизированного варианта. Таблица 2.7.i — Наборы значений, полученные методом попарных комбинаций № Расположение / длина / значение / комбинация символов / зарезерви- рованное или свобод- ное Существо- вание Наличие прав до- ступа Семейство ОС Кодировки 1 X:\ Да К каталогу и его со- держимому Windows 64 bit UTF8 2 smb://host/dir/ Нет Ни к каталогу, ни к его содержимому Windows 64 bit UTF16 3 / Нет Только к каталогу Windows 32 bit OEM 4 [0 символов] Да Только к каталогу Linux 32 bit UTF8 5 smb://host/dir Нет К каталогу и его со- держимому Linux 32 bit UTF16 6 ../dir Да Ни к каталогу, ни к его содержимому Linux 64 bit OEM 7 [257 байт только для Windows] Да Только к каталогу Windows 64 bit OEM 8 [4096 байт только для Linux] Нет Ни к каталогу, ни к его содержимому Windows 32 bit UTF8 9 [256 байт только для Windows] Нет Ни к каталогу, ни к его содержимому Linux 32 bit OEM 10 /dir/ Да Только к каталогу Windows 32 bit UTF16 Если исследовать набор полученных комбинаций, можно исключить из них те, которые не имеют смысла (например, существование каталога с именем нуле- вой длины или проверку под Windows характерных только для Linux случаев — см. 361 «Pairwise Testing, Available Tools» [ https://jaccz.github.io/pairwise/tools.html ] Попарное тестирование и поиск комбинаций Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 245/298 строки 4 и 8). Завершив такую операцию, мы получаем 124 комбинации. По сооб- ражениям экономии места эта таблица не будет приведена, но в приложении «При- мер данных для попарного тестирования» {290} представлен конечный итог оптимиза- ции (из таблицы убраны ещё некоторые комбинации, например, проверка под Linux имён, являющихся зарезервированными для Windows). Получилось 85 тест-кейсов, что даже немного меньше минимальной оценки в 256 тест-кейсов, и при этом мы учли куда больше опасных для приложения сочетаний значений параметров. Задание 2.7.c: в представленной в приложении «Пример данных для по- парного тестирования» {290} в колонке «Наличие прав доступа» иногда от- сутствуют значения. Как вы думаете, почему? Также в этой таблице всё ещё есть «лишние» тесты, выполнение которых не имеет смысла или представляет собой крайне маловероятный вариант стечения событий. Найдите их. Итак, на протяжении последних четырёх глав мы рассмотрели несколько тех- ник тестирования, позволяющих определить наборы данных и идей для написания эффективных тест-кейсов. Следующая глава будет посвящена ситуации, когда вре- мени на столь вдумчивое тестирование нет. Исследовательское тестирование Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 246/298 2.7.5. Исследовательское тестирование Исследовательское {82} и свободное {82} тестирование уже было упомянуто ра- нее на уровне определения. Для начала ещё раз подчеркнём, что это разные виды тестирования, пусть в каждом из них степень формализации процесса значительно меньше, чем в тестировании на основе тест-кейсов {81} Сейчас мы будем рассмат- ривать применение именно исследовательского тестирования. Сэм Канер определяет 362 исследовательское тестирование как стиль, осно- ванный на свободе и ответственности тестировщика в непрерывной оптимизации своей работы за счёт выполняемых параллельно на протяжении всего проекта и взаимодополняющих изучения, планирования, выполнения проверок и оценки их результатов. Если сказать короче, исследовательское тестирование — это одно- временное изучение, планирование и тестирование. Кроме очевидной проблемы с тестированием на основе тест-кейсов, состоя- щей в высоких затратах времени, существует ещё одна — существующие техники оптимизации направлены на то, чтобы максимально исследовать приложение во всех учтённых ситуациях, которые мы можем контролировать — но невозможно учесть и проконтролировать всё. Эта идея визуально представлена на рисунке 2.7.h. Рисунок 2.7.h — Факторы, которые могут быть пропущены тестированием на ос- нове тест-кейсов 362 Исследовательское же тестирование часто позволяет обнаружить дефекты, вызванные этими неучтёнными факторами. К тому же оно прекрасно показывает себя в следующих ситуациях: • Отсутствие или низкое качество необходимой документации. • Необходимость быстрой оценки качества при нехватке времени. • Подозрение на неэффективность имеющихся тест-кейсов. • Необходимость проверить компоненты, разработанные «третьими сторо- нами». • Верификация устранения дефекта (для проверки, что он не проявляется при незначительном отступлении от шагов воспроизведения). 362 «A Tutorial in Exploratory Testing», Cem Kaner [ http://www.kaner.com/pdfs/QAIExploring.pdf ] Приложение Подготовленные данные и команды Контролируемое поведение Неучтённые состояния компонентов приложения Неучтённые состояния ОС и среды выполнения Неучтённые состояния конфигураций и ресурсов Неучтённые воздействия других приложений Неучтённые состояния компонентов приложения Неучтённые состояния ОС и среды выполнения Неучтённые воздействия на разнообразные ресурсы Неучтённые воздействия на другие приложения Исследовательское тестирование Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 247/298 В своей работе 362 Сэм Канер подробно показывает способы проведения ис- следовательского тестирования с использованием базовых методов, моделей, при- меров, частичных изменений сценариев, вмешательства в работу приложения, про- верки обработки ошибок, командного тестирования, сравнения продукта с требова- ниями, дополнительного исследования проблемных областей и т.д. Вернёмся к нашему «Конвертеру файлов» {57} . Представим следующую ситу- ацию: разработчики очень уж быстро выпустили первый билд, тест-кейсов (и всех тех наработок, что были рассмотрены ранее в этой книге) у нас пока нет, а прове- рить билд нужно. Допустим, в уведомлении о выходе билда сказано: «Реализованы и готовы к тестированию требования: СХ-1 , СХ-2 , СХ-3 , ПТ-1.1 , ПТ-1.2 , ПТ-2.1 , ПТ- 3.1 , ПТ-3.2 , БП-1.1 , БП-1.2 , ДС-1.1 , ДС-2.1 , ДС-2.2 , ДС-2.3 , ДС-2.4 , ДС-3.1 , ДС-3.2 (текст сообщений приведён к информативному виду), ДС-4.1 , ДС-4.2 , ДС-4.3 ». Ранее мы отметили, что исследовательское тестирование — это тесно взаи- мосвязанные изучение, планирование и тестирование. Применим эту идею. Изучение Представим полученную от разработчиков информацию в виде таблицы 2.7.j и проанализируем соответствующие требования, чтобы понять, что нам нужно бу- дет сделать. Таблица 2.7.j — Подготовка к исследовательскому тестированию Требование Что и как будем делать СХ-1 Не требует отдельной проверки, т.к. вся работа с приложением будет выпол- няться в консоли. СХ-2 Не требует отдельной проверки, видно по коду. СХ-3 Провести тестирование под Windows и Linux. ПТ-1.1 Стандартная проверка реакции консольного приложения на различные вари- анты указания параметров. Учесть, что обязательными являются первые два параметра из трёх (третий принимает значение по умолчанию, если не задан). См. «Идеи», пункт 1. ДС-2.1 ДС-2.2 ДС-2.3 ДС-2.4 ПТ-1.2 См. «Идеи», пункт 2. ПТ-2.1 Не требует отдельной проверки, покрывается другими тестами. ПТ-3.1 На текущий момент можно только проверить факт ведения лога и формат за- писей, т.к. основная функциональность ещё не реализована. См. «Идеи», пункт 4. ПТ-3.2 ДС-4.1 ДС-4.2 ДС-4.3 БП-1.1 См. «Идеи», пункт 3. БП-1.2 ДС-1.1 Тестирование проводить на PHP 5.5. ДС-3.1 Проверять выводимые сообщения в процессе выполнения пунктов 1-2 (см. «Идеи»). ДС-3.2 Планирование Частично планированием можно считать колонку «Что и как будем делать» таблицы 2.7.j, но для большей ясности представим эту информацию в виде обоб- щённого списка, который для простоты назовём «идеи» (да, это — вполне класси- ческий чек-лист). Исследовательское тестирование Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 248/298 Идеи: 1. Проверить сообщения в ситуациях запуска: a. Без параметров. b. С верно указанными одним, двумя, тремя параметрами. c. С неверно указанными первым, вторым, третьим, одним, двумя, тремя параметрами. 2. Остановить приложение по Ctrl+C. 3. Проверить сообщения в ситуациях запуска: a. Каталог-приёмник и каталог-источник в разных ветках ФС. b. Каталог-приёмник внутри каталога-источника. c. Каталог-приёмник, совпадающий с каталогом-источником. 4. Проверить содержимое лога. 5. Посмотреть в код классов, отвечающих за анализ параметров командной строки и ведение лога. Задание 2.7.d: сравните представленный набор идей с ранее рассмотрен- ными подходами {149} , {231} , {234} , {239} , {242} — какой вариант вам кажется более про- стым в разработке, а какой в выполнении и почему? Итак, список идей есть. Фактически, это почти готовый сценарий, если пункт 2 (про остановку приложения) повторять в конце проверок из пунктов 1 и 3). Тестирование Можно приступать к тестированию, но стоит отметить, что для его проведе- ния нужно привлекать специалиста, имеющего богатый опыт работы с консольными приложениями, иначе тестирование будет проведено крайне формально и ока- жется неэффективным. Что делать с обнаруженными дефектами? Для начала — фиксировать в та- ком же формате, т.е. как список идей: переключение между прохождением некоего сценария и написанием отчёта о дефекте сильно отвлекает. Если вы опасаетесь что-то забыть, включите запись происходящего на экране (отличный трюк — запи- сывать весь экран так, чтобы были видны часы, а в списках идей отмечать время, когда вы обнаружили дефект, чтобы потом в записи его было проще найти). Список «идей дефектов» можно для удобства оформлять в виде таблицы (см. таблицу 2.7.k). Таблица 2.7.k — Список «идей дефектов» № Что делали Что получили Что ожидали / Что не так 0 а) Во всех случаях сообщения приложения вполне корректны с точки зрения происходящего и информативны, но противоречат требованиям (обсудить с заказчиком изменения в требо- ваниях). б) Лог ведётся, формат даты-времени верный, но нужно уточнить, что в требованиях име- ется в виду под «имя_операции параметры_операции результат_операции», т.к. для разных операций единый формат не очень удобен — нужно ли приводить всё к одному формату или нет? 1 php converter.php Error: Too few command line parameters. USAGE: php converter.php SOURCE_DIR DESTINATION_DIR [LOG_FILE_NAME] Please note that DESTINATION_DIR may NOT be inside SOURCE_DIR. Сообщение совершенно не соответствует требованиям. 2 php converter.php zzz:/ c:/ Error: SOURCE_DIR name [zzz:] is not a valid directory. Странно, что от «zzz:/» оста- лось только «zzz:». Исследовательское тестирование Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 249/298 3 php converter.php "c:/non/exist- ing/directory/" c:/ Error: SOURCE_DIR name [c:\non\exist- ing\directory] is not a valid directory. Слеши заменены на бэк- слеши, конечный бэк-слеш удалён: так и надо? Глянуть в коде, пока не ясно, дефект это или так и задумано. 4 php converter.php c:/ d:/ 2015.06.12 13:37:56 Started with parame- ters: SOURCE_DIR=[C:\], DESTINA- TION_DIR=[D:\], LOG_FILE_NAME=[.\converter.log] Буквы дисков приведены к верхнему регистру, слеши за- менены на бэк-слеши. По- чему имя лог-файла относи- тельное? 5 php converter.php c:/ c:/ Error: DESTINATION_DIR [C:\] and SOURCE_DIR [C:\] mat NOT be the same dir. Опечатка в сообщении. Явно должно быть must или may. 6 php converter.php "c: /каталог с русским именем/" c:/ Error: SOURCE_DIR name [c:\ ърЄрыюу ё Ёєёёъшь шьхэхь] is not a valid directory. Дефект: проблема с кодиров- ками. 7 php converter.php / c:/Win- dows/Temp Error: SOURCE_DIR name [] is not a valid directory. Проверить под Linux: мало- вероятно, конечно, что кто-то прямо в / будет что-то рабо- чее хранить, но имя «/» уре- зано до пустой строки, что до- пустимо для Windows, но не для Linux. 8 Примечание: «e:» -- DVD- привод. php converter.php c:/ e:/ file_put_con- tents(e:f41c7142310c5910e2cfb57993b4d 004620aa3b8): failed to open stream: Per- mission denied in \classes\CLPAna- lyser.class.php at line 70 Error: DESTINA- TION_DIR [e] is not writeable. Дефект: сообщение от PHP не перехвачено. 9 php converter.php /var/www /var/www/1 Error: SOURCE_DIR name [var/www] is not a valid directory. Дефект: в Linux обрезается начальный «/» в имени ката- лога, т.е. можно смело счи- тать, что под Linux приложе- ние неработоспособно (можно задавать только отно- сительные пути, начинающи- еся с «.» или «..»). Выводы по итогам тестирования (которое, к слову, заняло около получаса): • Нужно подробно обсудить с заказчиком форматы и содержание сообщений об использовании приложения и об ошибках, а также формат записей лог- файла. Разработчики предложили идеи, выглядящие куда более адекватно, чем изначально описано в требованиях, но всё равно нужно согласование. • Под Windows серьёзных дефектов не обнаружено, приложение вполне рабо- тоспособно. • Под Linux есть критическая проблема с исчезновением «/» в начале пути, что не позволяет указывать абсолютные пути к каталогам. • Если обобщить вышенаписанное, то можно констатировать, что дымовой тест успешно пройден под Windows и провален под Linux. Цикл «изучение, планирование, тестирование» можно многократно повто- рить, дополняя и рассматривая список обнаруженных проблем (таблица 2.7.k) как новую информацию для изучения, ведь каждая такая проблема даёт пищу для раз- мышлений и придумывания дополнительных тест-кейсов. Задание 2.7.e: опишите дефекты, представленные в таблице 2.7.k в виде полноценных отчётов о дефектах. Поиск причин возникновения дефектов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 250/298 В данной главе в таблице 2.7.k некоторые пункты представляют собой оче- видные дефекты. Но что их вызывает? Почему они возникают, как могут прояв- ляться и на что влиять? Как описать их максимально подробно и правильно в отчё- тах о дефектах? Ответам на эти вопросы посвящена следующая глава, в которой мы поговорим о поиске и исследовании причин возникновения дефектов. 2.7.6. Поиск причин возникновения дефектов Ранее мы отмечали {165} , что используем слово «дефект» для обозначения проблемы потому, что описание конечного симптома несёт мало пользы, а выясне- ние исходной причины может быть достаточно сложным. И всё же наибольший эф- фект приносит как раз определение и устранение первопричины, что позволяет снизить риск появления новых дефектов, обусловленных той же самой (ненайден- ной и неустранённой) недоработкой. Анализ первопричин (root cause analysis 363 ) — процесс исследования и классификации первопричин возникновения событий, негативно влияю- щих на безопасность, здоровье, окружающую среду, качество, надёжность и производственный процесс. Как видно из определения, анализ первопричин не ограничивается разработ- кой программ, но нас он будет интересовать всё же в ИТ-контексте. Часто ситуация, в которой тестировщик пишет отчёт о дефекте, может быть отражена рисунком 2.7.i. Рисунок 2.7.i — Проявление и причины дефекта В самом худшем случае проблема вообще будет пропущена (не замечена), и отчёт о дефекте не будет написан. Чуть лучше выглядит ситуация, когда отчёт описывает исключительно внешние проявления проблемы. Приемлемым может считаться описание лежащих на поверхности причин. Но в идеале нужно стре- миться добраться до двух самых нижних уровней — первопричины и условий, спо- 363 Root cause analysis (RCA) is a process designed for use in investigating and categorizing the root causes of events with safety, health, environmental, quality, reliability and production impacts. [James Rooney and Lee Vanden Heuvel, «Root Cause Analysi s for Beginners», https://www.abs-group.com/content/documents/rca_for_begineers.pdf ] Наблюдаемое проявление проблемы Симптом Причина N Причина N-1 Первопричина Условия, способствовавшие возникновению первопричины Поиск причин возникновения дефектов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 251/298 собствовавших её возникновению (хоть последнее часто и лежит в области управ- ления проектом, а не тестирования как такового). Вкратце вся эта идея выражается тремя простыми пунктами. Нам нужно по- нять: • Что произошло. • Почему это произошло (найти первопричину). • Как снизить вероятность повторения такой ситуации. Сразу же рассмотрим практический пример. В таблице 2.7.k в строке с номе- ром 9 {249} есть упоминание крайне опасного поведения приложения под Linux — из путей, переданных приложению из командной строки, удаляется начальный символ «/», что для Linux приводит к некорректности любого абсолютного пути. Пройдём по цепочке, представленной рисунком 2.7.i, и отразим этот путь таб- лицей 2.7.l: Таблица 2.7.l — Пример поиска первопричины Уровень анализа Наблюдаемая ситуация Рассуждения и выводы Наблюдаемое проявление про- блемы Тестировщик выполнил команду «php converter.php /var/www /var/www/1 » и по- лучил такой ответ приложения: «Error: SOURCE_DIR name [ var/www ] is not a valid directory. » в ситуации, когда указанный ка- талог существует и доступен для чтения. Сразу же бросается в глаза, что в сообщении об ошибке имя каталога отличается от заданного — отсутствует начальный «/». Несколько кон- трольных проверок подтвер- ждают догадку — во всех па- раметрах командной строки начальный «/» удаляется из полного пути. На этом этапе очень часто начинающие тестировщики описывают дефект как «неверно распознаётся имя каталога», «приложение не обнаруживает доступные каталоги» и тому подобными словами. Это плохо как минимум по двум причинам: а) описание дефекта некорректно; б) программисту придётся самому проводить всё исследование. Таблица 2.7.l [продолжение] Уровень анализа Наблюдаемая ситуация Рассуждения и выводы Причина N Факт: во всех параметрах командной строки начальный «/» удаляется из пол- ного пути. Проверка с относительными пу- тями («php converter.php . .») и проверка под Windows («php converter.php c:\ d:\») показывает, что в таких ситуациях прило- жение работает. Дело явно в обработке вве- дённых имён: в некоторых случаях имя обрабатывается корректно, в некоторых — нет. Гипотеза: убираются началь- ные и концевые «/» (может быть, ещё и «\»). Причина N-1 Проверки «php converter.php \\\\\c:\\\\\ \\\\\d:\\\\\ » и «php converter.php /////c:///// /////d:///// » показывают, что приложение под Windows запускается, корректно распо- знав правильные пути: «Started with parameters: SOURCE_DIR=[C:\], DESTINATION_DIR=[D:\] » Гипотеза подтвердилась: из имён каталогов приложение убирает все «/» и «\», в любом количестве присутствующие в начале или конце имени. В принципе, на этой стадии уже можно писать отчёт о дефекте с кратким опи- санием в стиле «Удаление краевых “/” и “\” из параметров запуска повреждает аб- солютные пути в Linux ФС». Но что нам мешает пойти ещё дальше? Таблица 2.7.l [продолжение] Поиск причин возникновения дефектов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 252/298 Уровень анализа Наблюдаемая ситуация Рассуждения и выводы Причина N-2 Гипотеза: где-то в коде есть первичный фильтр полученных значений путей, кото- рый обрабатывает их до начала проверки каталога на существование. Этот фильтр работает некорректно. Откроем код класса, отвечающего за анализ парамет- ров командной строки. Очень быстро мы обнаруживаем метод, который виновен в происходящем: private function getCanonicalName($name) { $name = str_replace('\\', '/', $name); $arr = explode('/', $name); $name = trim(implode(DIRECTORY_SEPARATOR, $arr), DIRECTORY_SEPARATOR); return $name; } Мы нашли конкретное место в коде приложения, которое яв- ляется первопричиной обна- руженного дефекта. Информа- цию об имени файла, номере строки и выдержку самого кода с пояснениями, что в нём неверно, можно приложить в комментарии к отчёту о де- фекте. Теперь программисту намного проще устранить про- блему. Задание 2.7.f: представьте, что программист исправил проблему сменой удаления краевых «/» и «\» на концевые (т.е. теперь они удаляются только в конце имени, но не в начале). Хорошее ли это решение? Обобщённый алгоритм поиска первопричин можно сформулировать следую- щим образом (см. рисунок 2.7.j): • Определить проявление проблемы o Что именно происходит? o Почему это плохо? • Собрать необходимую информацию o Происходит ли то же самое в других ситуациях? o Всегда ли оно происходит одинаковым образом? o От чего зависит возникновение или исчезновение проблемы? • Выдвинуть гипотезу о причине проблемы o Что может являться причиной? o Какие действия или условия могут приводить к проявлению про- блемы? o Какие другие проблемы могут быть причинами наблюдаемой про- блемы? • Проверить гипотезу o Провести дополнительное исследование. o Если гипотеза не подтвердилась, проработать другие гипотезы. • Убедиться, что обнаружена именно первопричина, а не очередная причина в длинной цепи событий o Если обнаружена первопричина — сформировать рекомендации по её устранению. o Если обнаружена промежуточная причина, повторить алгоритм для неё. Здесь мы рассмотрели очень узкое применение поиска первопричин. Но представленный алгоритм универсален: он работает и в разных предмет- ных областях, и в управлении проектами, и в работе программистов (как часть процесса отладки). Поиск причин возникновения дефектов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 253/298 Рисунок 2.7.j — Алгоритм поиска первопричины дефекта На этом мы завершаем основную часть данной книги, посвящённую «тести- рованию в принципе». Далее будет рассмотрена автоматизация тестирования как совокупность техник, повышающих эффективность работы тестировщика по мно- гим показателям. Определить проявление проблемы Собрать необходимую информацию Выдвинуть гипотезу о причине проблемы Проверить выдвинутую гипотезу Гипотеза подтвердилась? Сформировать рекомендации по устранению Это первопричина? Да Да Нет Нет |