Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Раздел 4: приложения 4.1. Карьера тестировщика 371 371 Полноразмерный вариант рисунка [ http://svyatoslav.biz/wp-pics/testing_career_path.png ] Автоматизация тестирования Функциональное тестирование Базовая самоподготовка Английский язык Основы тестирования Чтение специальной литературы Тестирование документации и требований Разработка тестов Поиск и документирование дефектов Отчётность о результатах тестирования Функциональное и доменное тестирование Оценка трудозатрат Основы планирования в тестировании Планирование своего рабочего времени Виды тестирования Методы и методологии тестирования Коммуникативные навыки Работа с системами управления требованиями Работа с системами управления тестами Работа с багтрекинговыми системами Интернет- технологии Базы данных и язык SQL Использование различных ОС Тестирование веб- приложений Основы программирования Основы автоматизации тестирования Программирование на Java/C#/etc. Программирование Бизнес-анализ Опыт проектной работы Тестирование производитель- ности Инструменты автоматизирован- ного тестирования Дальнейшее развитие и/или специализация Опытный специалист Менеджер Управление ресурсами Управление проектами Эксперт Разработка решений TestNG Модульное тестирование Тестирование настольных приложений Специальные технологии TDD BDD DDT Разработка и адаптация инструментов Работа с офисными программами Формирование представления об IT- специализации Базовая самоподготовка может занимать разное время. В общем случае ей рекомендуется посвятить первые 2-3 курса университета. Успешная базовая самоподготовка позволяет пройти отбор на тренинг и усвоить программу тренинга. Изучение функционального тестирования занимает от полугода до года. За это время необходимо приобрести полный набор технических и специализированных навыков, необходимых специалисту для начала работы тестировщиком. Поскольку в тестирование приходит много людей без достаточной технической подготовки, соответствующим темам следует уделять особое внимание. Изучение автоматизации тестирования занимает от полугода до года. Предполагается, что к этому моменту соискатель уже изучил функциональное тестирование, а также обладает как минимум уверенными базовыми знаниями в области программирования. Автоматизация тестирования подразумевает программирование как часть повседневной деятельности. Особое внимание на этом этапе подготовки уделяется инструментальным средствам и специфическим технологиям. После успешного трудоустройства специалист в течение нескольких лет повышает свою квалификацию, приобретает всё более глубокий и обширный опыт, позволяющий как более эффективно выполнять свои прямые обязанности, так и рассматривать дальнейшие перспективы карьерного роста. Дальнейший карьерный рост предполагает либо углубление в техническое направление и становление экспертом в некоторой области, либо переключение в область управления проектами или ресурсами. Наступает момент выбора: приступить к работе в качестве специалиста по функциональному тестированию, переключиться на изучение бизнес-анализа или продолжить изучение тестирования (в области автоматизации). Знания и умения: 1. Свободное владение Word, Excel. 2. Свободное владение компьютером на уровне уверенного пользователя (умение устанавливать и настраивать ОС, сеть, необходимое ПО). 3. Сформированное представление о работе тестировщика, желание заниматься именно этой работой. 4. Знание английского на уровне беглого чтения англоязычной документации. Основные навыки: 1. Анализ технической документации. 2. Создание чек-листов. 3. Разработка тестов и тестовых сценариев. 4. Поиск и эффективное документирование обнаруженных дефектов. 5. Формирование отдельных фрагментов отчётов о результатах тестирования. 6. Использование вспомогательных инструментальных средств. 7. Понимание методов и видов тестирования, умение применять их адекватно ситуации. Дополнительные навыки: 1. Умение вести деловое общение – «вживую», и использованием почты и иных средств коммуникации . 2. Умение планировать рабочее время и оценивать трудозатраты. 3. Понимание принципов работы компьютерных сетей. 4. Понимание основ баз данных, умение писать тривиальные запросы. 5. Умение работать с различными версиями ОС семейства Windows и *nix. Основные навыки: 1. Умение программировать на уровне, достаточном для создания автоматизированных тестов. 2. Понимание специфических технологий и инструментальных средств, умение выбрать и применить их для решения поставленной задачи. 3. Глубокое понимание принципов работы программных средств. Дополнительные навыки: 1. Умение планировать, реализовывать и оценивать результаты экспериментов. 2. Умение оптимизировать тесты и тестовые сценарии. 3. Умение использовать вспомогательные программные средства, используемые проектной командой для автоматизации повседневных задач. 4. Понимание и умение использовать несколько высокоуровневых языков программирования, языков и технологий вёрстки. Тестирование веб- приложений и веб- сервисов Тестирование мобильных приложений JUnit JMock NUnit SilkTest TestComplete QTP AutoIt Selenium RC & Grid HtmlUnit Selenium IDE Selenium Web Driver Soap IU Jaxb & Jax-ws Selenium iOS Driver Selenium Android Driver Java C# Python JavaScript VBScript Ruby Scala 4Test JScript XML HTML WSDL SOAP SQL Cucumber jBehave Комментарии к заданиям Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 278/298 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 {31} Учли ли вы при составлении списка не только возможность ваших собственных недоработок, но и объективные факторы риска? Напри- мер, цена на некоторый товар выросла, товара не оказалось в нали- чии. Продумали ли вы, кто уполномочен принимать решение в ситуа- ции, когда «посовещаться со всеми» невозможно или слишком долго? 2.2.b {51} При составлении списка вопросов рекомендуется опираться на две мысли: а) Как сделать продукт, максимально удовлетворяющий по- требности заказчика. б) Как реализовать и протестировать то, что требует заказчик. Игнорирование любого из этих пунктов может привести либо к созда- нию бесполезного продукта, либо к работе в ситуации неопределён- ности, когда по-прежнему не до конца ясно, что же разрабатывать и как это тестировать. 2.2.c {54} После того как вы выполнили это задание, проверьте себя с помо- щью материала главы «Типичные ошибки при анализе и тестирова- нии требований» {60} . Если вы обнаружили в своей работе какие-то из перечисленных там ошибок, исправьте их. 2.2.d {59} В продолжение теста на внимательность: заметили ли вы в тексте этой книги сколько-нибудь опечаток? Поверьте, они здесь есть. 2.2.e {59} По мере детализации набора требований ваши вопросы могут стано- виться всё более и более конкретными. Также помните, что стоит по- стоянно держать в голове всю общую картину требований, т.к. на низком уровне может проявиться проблема, затрагивающая обшир- ную часть требований и влияющая на весь проект. Комментарии к заданиям Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 279/298 2.3.a {74} После того, как у вас закончатся собственные идеи, вы можете при- бегнуть к небольшой хитрости: поищите в Интернете (и книгах, на ко- торые приведено множество ссылок) описание различных видов те- стирования, изучите области их применимости и дополните свой спи- сок на основе полученных знаний. 2.4.a {113} После того, как вы составите список свойств качественных требова- ний, характерных для чек-листов, подумайте, какими свойствами должен обладать чек-лист, чтобы быть универсальным (т.е. чтобы его можно было использовать повторно на другом проекте). 2.4.b {116} На чём базировались ваши правки существующего чек-листа? Мо- жете ли вы аргументированно доказать преимущества предложен- ного вами варианта? 2.4.c {132} Возможно, кто-то из ваших знакомых тестировщиков может рекомен- довать вам то или иное инструментальное средство, исходя из соб- ственного опыта. Если такого источника информации у вас нет, возь- мите список соответствующего ПО из Википедии и/или многочислен- ных обзоров в Интернете. 2.4.d {136} Насколько приоритетным будет данный тест-кейс? Если он обнару- жит ошибку в приложении, какое значение важности вы ей присво- ите? (Примечание: сама идея «повторной конвертации» бессмыс- ленна, т.к. повторная конвертация файла, кодировка которого была приведена к UTF8, ничем по сути не отличается от просто первичной конвертации файла, изначально находящегося в этой кодировке. По- тому весь этот тест-кейс можно удалить, добавив в один из других тест-кейсов файл в кодировке UTF8 на вход конвертации.) 2.4.e {151} Заметили ли вы отличия в рекомендациях по написанию тест-кейсов и вообще по проведению тестирования в проектах, реализуемых по «классическим» и гибким методологиям? 2.4.f {153} Если вы хорошо знаете какой-то язык программирования, можете написать программу, автоматизирующую представленные в данных командных файлах проверки. 2.4.g {156} Можно ли сделать ваши автоматизированные проверки более уни- версальными? Можно ли вынести за пределы командных файлов наборы данных? А логику обработки данных? 2.5.a {171} Ответ: в отчёте приведена ссылка на требование ДС-2.1 , в котором сказано, что обработанные файлы помещаются в каталог-приёмник, а не перемещаются туда. Конечно, это дефект требований, но если подходить строго формально, то в требованиях нигде не сказано о перемещении обработанного файла, а потому отчёт о дефекте при- ложения может быть закрыт, хотя повторная обработка одного и того же файла явно противоречит здравому смыслу. Однако! Может выяс- ниться, что заказчик имел в виду, что приложение должно создавать в каталоге-приёмнике обработанные копии всех файлов из каталога- источника… и тут придётся многое переписывать, т.к. между «обра- ботать и переместить все файлы» и «обработать и скопировать все новые файлы, не затрагивая повторно никакие ранее обработанные файлы» есть существенная разница (вплоть до того, что придётся вычислять и хранить контрольные суммы всех файлов, т.к. нет ника- кой гарантии, что в каталоге-приёмнике какой-то файл не был заме- нён одноимённым). Комментарии к заданиям Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 280/298 2.5.b {189} Возможно, кто-то из ваших знакомых тестировщиков может рекомен- довать вам то или иное инструментальное средство, исходя из соб- ственного опыта. Если такого источника информации у вас нет, возь- мите список соответствующего ПО из Википедии и/или многочислен- ных обзоров в Интернете. 2.6.a {217} Для начала можно ознакомиться с этим примером: http://www.softwaretestingclass.com/wp- content/uploads/2013/01/Sample-Test-Plan-Template.pdf 2.6.c {230} Какие отвлекающие факторы снижали вашу производительность? Что у вас занимало больше всего времени (обдумывание тест-кей- сов, оформление или что-то иное)? Как вы считаете, повысилась или понизилась бы ваша производительность, если бы вы провели за изучением требований к проекту несколько часов или даже дней? 2.7.a {233} Ответ: потому, что здесь мы бы уже проверяли фактически взаимо- действие двух параметров. Это хорошая идея, но она выходит за рамки тестирования отдельной изолированной функциональности. 2.7.b {237} Самым эффективным способом доработки представленного списка является… программирование. Если вы достаточно хорошо знаете какой-нибудь язык программирования, напишите небольшую про- грамму, которая всего лишь будет получать из командной строки имя каталога и проверять его наличие и доступность для чтения. А затем протестируйте вашу программу и дополните представленный в за- даче список идеями, которые придут к вам в процессе тестирования. 2.7.c {245} В колонке «Наличие прав доступа» иногда отсутствуют значения, т.к. если каталог отсутствует, к нему неприменимо понятие «права до- ступа». Что касается лишних проверок, то, например, в строках 18 и 22 пути приведены с «/» в качестве разделителя имён каталогов, что характерно для Linux, но не для Windows (хотя и сработает в боль- шинстве случаев). Такие проверки можно оставлять, но можно и уби- рать как низкоприоритетные. 2.7.d {248} А если, кроме сложности, оценить также время на разработку тест- кейсов и проведение тестирования? А потом учесть необходимость повторять те же проверки многократно? 2.7.e {249} Можно использовать приведённый на рисунке 2.5.e {171} пример описа- ния дефекта как шаблон для решения этого задания. 2.7.f {252} Ответ: это плохое решение, т.к. теперь приложение будет пропускать имена каталогов вида «/////C:/dir/name/». Конечно, при проверке суще- ствования такой каталог не будет найден, но фильтрация данных всё равно нарушена. А вот имя «/» всё равно превратится в пустую строку. Командные файлы для Windows и Linux Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 281/298 4.3. Командные файлы для Windows и Linux, автоматизирую- щие выполнение дымового тестирования CMD- скрипт для Windows rem Переключение кодовой таблицы консоли rem (чтобы корректно обрабатывались спецсимволы в командах): chcp 65001 rem Удаление файла журнала от прошлого запуска: del smoke_test.log /Q rem Очистка входного каталога приложения: del IN\*.* /Q rem Запуск приложения: start php converter.php IN OUT converter.log rem Размещение тестовых файлов во входном каталоге приложения: copy Test_IN\*.* IN > nul rem Таймаут в 10 секунд, чтобы приложение успело обработать файлы: timeout 10 rem Остановка приложения: taskkill /IM php.exe rem ========================================================================= rem Проверка появления в выходном каталоге файлов, rem которые должны быть обработаны, rem и непоявления файлов, которые не должны быть обработаны: echo Processing test: >> smoke_test.log IF EXIST "OUT\«Мелкий» файл в WIN1251.txt" ( echo OK! '«Мелкий» файл в WIN1251.txt' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Мелкий» файл в WIN1251.txt' file was NOT processed! >> smoke_test.log ) IF EXIST "OUT\«Средний» файл в CP866.txt" ( echo OK! '«Средний» файл в CP866.txt' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Средний» файл в CP866.txt' file was NOT processed! >> smoke_test.log ) IF EXIST "OUT\«Крупный» файл в KOI8R.txt" ( echo OK! '«Крупный» файл в KOI8R.txt' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Крупный» файл в KOI8R.txt' file was NOT processed! >> smoke_test.log ) IF EXIST "OUT\«Крупный» файл в win-1251.html" ( echo OK! '«Крупный» файл в win-1251.html' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Крупный» файл в win-1251.html' file was NOT processed! >> smoke_test.log ) IF EXIST "OUT\«Мелкий» файл в cp-866.html" ( echo OK! '«Мелкий» файл в cp-866.html' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Мелкий» файл в cp-866.html' file was NOT processed! >> smoke_test.log ) IF EXIST "OUT\«Средний» файл в koi8-r.html" ( echo OK! '«Средний» файл в koi8-r.html' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Средний» файл в koi8-r.html' file was NOT processed! >> smoke_test.log ) IF EXIST "OUT\«Средний» файл в WIN_1251.md" ( echo OK! '«Средний» файл в WIN_1251.md' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Средний» файл в WIN_1251.md' file was NOT processed! >> smoke_test.log ) Командные файлы для Windows и Linux Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 282/298 IF EXIST "OUT\«Крупный» файл в CP_866.md" ( echo OK! '«Крупный» файл в CP_866.md' file was processed! >> smoke_test.log ) ELSE ( echo ERROR! '«Крупный» файл в CP_866.md' file was NOT processed! >> smoke_test.log |