Тестирование программного обеспечения
История развития тестирования программного обеспечения и современные достижения в данной сфере. Системные и пользовательские требования, атрибуты качества. Виды тестирования по степени знания кода. Тестирование мобильных приложений на базе ОС Android.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 04.11.2015 |
| Размер файла | 5,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Введение
тестирование программный пользовательский приложение
Тестирование программного обеспечения является одной из важных стадий современной разработки ПО. На этом этапе проверяется соответствие разработанной системы заявленным требованиям и целям разработки. Без заключения отдела тестирования продукт не будет выпущен на рынок.
Рис 1. Стоимость исправления ошибок на различных этапах разработки ПО (источник- IBM Systems Sciences Institute)
Тестирование мобильных приложений имеет еще большее значение, так как рынок сейчас очень насыщен и если конечный пользователь увидит неполадки в вашей программе, он просто удалит ваше приложение и установит решение от конкурента.
Тестирование бывает автоматизированным и ручным. Моя работа посвящена ручному тестированию, так как данный вид тестирования является основным. Невозможно автоматизировать тестирование всего функционала приложения, а во многих случаях автоматизация не будет эффективным решением в плане денежных затрат. Поскольку при тестирований на Android инженеру - тестировщику часто приходится прибегать к инструмента Android SDK, а в частности - android debug bridge (adb), который имеет консольный интерфейс и поддерживает работу с консольными командами UNIX систем. Я решил разработать приложение, в котором благодаря простому графическому интерфейсу пользователь сможет получить доступ к самым распространенным командам adb, даже не знаю синтаксиса этого приложения, а так же увидеть результаты своей деятельности благодаря выводу на экран результатов выполнения этих команд. Это должно облегчить труд и увеличить производительность ручного тестирования, а так же его точность.
Объект исследования моей ВКР является процесс тестирования приложений на мобильных устройствах на платформе Android.
Предмет исследования - оптимизация процесса тестирования приложений на мобильных устройствах на платформе Android.
Целью работы является разработка системы информационного сопровождения процесса тестирования приложений на мобильных устройствах на платформе Android, которая позволит снизить время тестирования и порог вхождения для начинающих специалистов в этой области, еще слабо знакомых с функционалом Android sdk, а так же повысить качество и точность тестирования, что в целом повысит качество итогового продукта.
Задания работы:
- Изучить процесс тестирования
- Изучить особенности процесса тестирования на мобильных устройствах
- Выявить элементы процесса прохождения тестовых сценариев, которые следует включить в функционал разрабатываемого приложения.
- Разработать приложение.
- Проверить работоспособность приложения на конкретном примере.
Теоретической основой для написания ВКР послужили работы отечественных и зарубежных авторов в области тестирования программного обеспечения а так же материала коммерческой и технической направленности, размещенные на сайтах производителей рассматриваемого в дипломной работе программного обеспечения.
1. История развития тестирования программного обеспечения
Тестирование, как таковое, начало свое развитие еще в глубокой древности. Издревле люди проводили испытания своих способностей, знаний, навыков. Подобные состязания и испытания можно считать прародителями современных тестов, ведь им, по сути, так же были присуще все атрибуты современных процессов тестирования. Затем более широкое распространение тестирование получило в средних веках, когда начинали свою работу рабочие гильдии и цеха, выпускающие какую-либо продукцию, например, подковы в кузницах и мастерских. Эта продукция после создания проходила контроль у мастеров гильдии, которые обеспечивали постоянный контроль качества данной продукции. Такой порядок вещей просуществовал практически до 19 века, когда произошла индустриальная революция.
Индустриальная революция начала менять представление людей о тестировании. Ремесленника из гильдии на заменил рабочий на мануфактуре. Следуя этим изменениям, необходимо было и обновить систему контроля качества. Это и сделал Фредерик Уинслоу Тейлор, ставший основоположником научной организации труда. Он первым начал применять на производстве систему дифференциальной оплаты труда. Тейлор полагал, что любой квалифицированный рабочий может быть проанализирован так, чтобы его можно было передать в процессе обучению любому другому человеку, что шло в разрез с тогдашней структурой правсоюза, которая сохраняла подобие кастового порядка. Так же Тейлор считал, что власть на предприятии не должна единолично принадлежать владельцам, а управлять на местах должны специально обученные специалисты -нынешнее менеджеры.
Его идею подхватил Уолтер Шухарт (1891-1967) - всемирно известный ученый и консультант по управлению качеством. Он опубликовал книги «Экономическое управление качеством промышленной продукции» и «Статистический метод с точки зрения контроля качества». Шухарт ввел в обиход понятие о «контрольных картах» - графическое средство представление и принятия решений касательно стабильности и устойчивости процесса производства. Так же, Шухарт разработал процесс принятия решений, известный как PDCA(pian-do-check-act - планирования- действие - проверка - корректировка). Это элеменентарный алгоритм, который руководит действиями руководителя по управлению процессом производства.
Свое дальнейшие развитие этот алгоритм получил уже после второй мировой, когда генерал Дуглас МакАртур, работающий в Японии после ее поражения в войне совмести с Эдвардом Демингом над модернизацией японского производства. В процессе этого производства они искали способы улучшить качество труда на японских мануфактурах и фабриках, используя идею, что важнее фокусироваться на качестве продукта чем на итоговой цене продукта. Для достижения этой цели они работали на улучшенной версии PDSA модели, приспособленной для автоматизированной индустрии. В результате этой работы, покупатели стали отдавать предпочтение товарам из Японии, нежели из США ввиду их лучшего качества
Деминг сильно лоббировал дальнейшую разработку PDSA в начале ее существования. Важно понимать, что Деминг поднял конфликтный вопрос между темпами производства и качеством производства. Вместо того, чтобы бездумно наращивать темпы производства, Деминг предлагал в своим методах управления качеством обращать большее внимание на структурирования и дальнейшую экономию времени путем анализа документации во всех аспектах процесса разработки.
Вкратце, PDSA разрабатывался для обеспечения интегративной и инкрементной системы разработки, которые послужили основой той системы разработки, которой мы пользуемся сейчас. Первый из документированных примеров такой разработки был представлен командой из IBM.
Этот проект состоял из более чем миллиона строк кода. Это была система контроля и управления подводной лодкой США и проект требовал точности и очень сжатых сроков реализации. Приходилось уделять больше внимания пожеланиям заказчика, чем ведению надлежащей документации.
Команда успешно подошла к заданным срокам и сам проект был успешен. Этот проект был первым, когда при при меньшей итерации и пониженным документооборотом был достигнут положительный результат. Если конечно качество управления было бы недостаточно хорошим, мы бы могли сказать, что процесс разработки не был бы завершен в должные сроки.
Таким образом, сейчас существуют различные методологии разработки. Каскадная разработка подразумевает ведение документации и трату большего времени для того, чтобы добиться максимально хорошего кода, но при экстремальной разработке тратится меньшее время на выполнения более коротких итераций,которые могут быть оправданы при специфических условиях разработки, таких как проектирование систем управление подводным лодками. Каждая из методологий имеет свои плюсы и минусы, по этому наиболее важно понимать каждую идею, которая может вести разработку как к успеху так и к провалу.
Тестирование сегодня
Рис 2. Элементы контроля качества
Сегодня тестирование включает в себя большой комплекс процедур по обеспечению контроля качества над разрабатываемым программным обеспечением. Этот комплекс может варьироваться в зависимости от сложно разрабатываемого ПО, так и от конкретного объекта тестирования.
В общем, контроль качества осуществляется путем проведения следующих мероприятий:
1. Создания тестовых сценариев
2. Функционального тестирования
3. Тестирования безопасности и устойчивости
4. Тестирования соответствий
5. Тестирования масштабируемости
6. Тестирования производительности
7. Регрессионное тестирование
8. Обновление тестовых баз
2. Функциональное тестирование
Рис 3. Элементы функционального тестирования
Это вид тестирования является одним из основных. Его задача состоит в устранении различий в поведении программы между завяленными требованиями и фактическим результатом. В процессе функционального тестирования выявляются основные ошибки в реализации программы, которые влияют на ее качество.
Процесс функционального тестирования начинается с ознакомления с системными требованиями, разработанными для этого приложения.
Системные требования к разрабатываемому программному обеспечению - это строительные блоки, из которых разработчик воздвигает свою систему. Системные требования делятся на функциональные и дополнительные. Функциональные системные требования определяют то, как пользователь выполняет свои функции. Например, в систему необходимо ввести систему поиска устройства по данным gps - это требование будет является функциональным. Нефункциональными требования, как правило называют требования к качеству продукции.
Системные требования можно классифицировать по различным параметрам, таким как требования по уровням:
Рис 4. Классификация системных требований
Бизнес-требования - описывают то, как разрабатываемую систему видит компания-разработчик или заказчик. Эти требования так же содержат тот предполагаемый источник прибыли или выгоды, которые рассчитывают получить заинтересованные стороны. Они могут быть описаны в виде документов, кейсов либо в виденье проекта или в перечне функционала. Бизнес требования описывают виденья главы проекта или заинтересованных лиц на одном комплекте документации. Программное обеспечение не может быть написано исходя лишь из этой высокоуровневой информации. Бизнес-требования в первую очередь содержат информацию о:
1. Целях разрабатываемого проекта
2. Задачах разрабатываемого проекта
3. Области покрытия проекта
4. Ожидаемом результате разработки проекта
5. Приоритете и ожидаемых сроках завершения проекта
6. Целесообразности проекта, зачем нужно разрабатывать этот проект, как он будет приносить прибыл
7. Подразделениях и отделах компании, участвующие в разработке проекта.
Пользовательские требования описывают поведение системы со стороны пользователя, какие действия может использовать пользователь, чтобы взаимодействовать с системой. Пользовательские требования должны быть документированы в руководстве пользователя, написанном на естественном языке.
В разработке и дизайне программного обеспечения очень важно понимать, что хочет пользователь от взаимодействия с данной системой. Это вызвано тем, что пользователь часто бывает не в состоянии полностью взаимодействовать с системой из-за непродуманного интерфейса, который не обеспечивает должной функциональности или выдает пользователю неполную или неточную информацию о процессах и состоянии системы.
Как правило, такие требования описываются с помощью пользовательских сценариев (user cases). Пользовательские требования подчинены бизнес требованиям, а значит каждое требования должно быть связанное минимум с одним бизнес требованием. Задача разработать такой интерфейс лежит на отделе аналитике и дизайна. Бизнес-аналитики тщательно анализируют потребности пользователей и строит документированный набор требований к качеству продукта, который удовлетворял бы запросам пользователей. Пример пользовательского требования:
User case: Включить компьютер.
Актеры: Пользователь
Частота: Каждый день
Приоритет: 1 (высший)
Описание: пользователь включает выключенный ранее компьютер.
Предусловия: компьютер исправен и доступен пользователю, на компьютере задан пароль для учетной записи пользователя
Результат: пользователь видит рабочий стол своей операционной системы.
Поток нормальный.
1. Пользователь нажимает кнопку POWER на системном блоке
2. Загружается BIOS
3. BIOS инициализирует компоненты системы
4. Загружается OS
5. Система предлагает ввести пользователю пароль для доступа к его учетной записи
6. Пользователь вводит пароль
7. Пользователь попадает на рабочий столь
Сценарий завершен
Сценарий 1а.
1. А) Пользователь нажимает кнопку POWER на системном блоке
2. А) BIOS не загружается.
Конец сценария
Сценарий 1а 2
3. Б)Компьютер не включен в сеть
4. Б)Пользователь включает компьютер
5. Б)Назад к шагу 1
Сценарий 1а 3
2. В) Компьютер включен в сеть
3. В) Нужно проверить исправности материнской платы
Вторая группа требований - нефункциональные требования. Эти требования содержат требования к качеству работы системы, такие как работоспособность, масштабируемость, ремонтопригодность и удобство. Они так же важны, как и функциональные, так как они определяют, будет ли комфортно пользователю взаимодействовать с конечной системой. Невыполнение любого из этих пунктов может повлечь несоответствие системы с заявленными параметрами в плане использования и функционирования. Нефункциональные требования определяют качество и стабильность к системе и обычно не меняются от релиза к релизу и остаются постоянными на весь период разработки. Нефункциональные требования встречаются на всех трех уровнях разработки. Основное «место обитания» - программный уровень. Это такой уровень, на котором определяется качество программного обеспечения - уровень работы программы. Так же нефункциональные требования существуют на уровне команд разработок - важный для реализации таких требований уровень, на котором определяются то, как будут функционировать между собой команды разработчиков. Эти связи способствуют более гладкому и гибкому процессу разработки, который позволит избежать множества ошибок и тем самым повысить качество системы. Уровень документации так же может содержать в себе нефункциональные требования. Выделяют следующие виды нефункциональных требований:
Бизнес правила. Включают в себя какие-либо правила, по которым система должна быть описана так и никак иначе. Может содержать какие-либо правила и пожелания заказчика, отсылки на законодательство.
Внешние интерфейсы. Включают в себя макеты интерфейсов пользователя, способы и правила взаимодействия с другими системами и сторонними приложениями.
Атрибуты качества. К атрибутам качества обычно относят такие характеристики как:
1. легкость и простота использования
2. производительность
3. удобство эксплуатации
4. удобство технического обслуживания
5. надежность и устойчивость к сбоям
6. взаимодействие системы с пользователем
7. расширяемость и гибкость.
Для процесса тестирования важно в первую очередь ознакомится с функциональными требованиями и пользовательскими сценариями. Именно с ними в первую очередь отожествляется то, как будет выглядеть и функционировать конечный продукт.
Функциональная декомпозиция.
Функциональная декомпозиция применяется, когда необходимо разбить весь массив функционала приложения на более маленькие и детализированные части, над которыми будет удобнее проводить тестирование и строить специфические тест планы.
Анализ требований
Это процесс систематизации, анализа и выявления противоречий в написанных для разрабатываемого программного обеспечения требований. К таковому процессу тестирования он отношения не имеет и применяется аналитиками на стадии разработки и дизайна концепции приложения.
3. Планирование тестирования
Планирование тестирования это уже непосредственная задача отдела тестирования. Основная ее задача сводится к созданию тест планов чтобы в дальнейшим покрыть с помощью этих планов требования тестовыми сценариями.
Тест план - это документ, который детализирует цели, целевой рынок, состав команды бета-тестирования и процедуру проведения тестирования для программного продукта.
Существует стандарт IEEE 829 для написания тест планов. Согласно нему, тест план состоит из:
- Предметов тестирования.
Это вещи, которые необходимо протестировать в рамках данного тест плана. Как правило, содержит:
- Требования спецификации
- Дизайн и системные требования
- Пользовательские сценарии
- Руководства по эксплуатации и установки.
В тест плане определяются критические элементы, на которые необходимо обращать внимание перед началом тестирования. Так же, тест план может быть рассчитан на разные уровни программы- либо покрывать весь функционал, либо какую-либо одну его часть, блок или модуль.
Тестируемые особенности
Это список тех элементов программы, которые должны быть проверены с пользовательского сценария поведения. Это техническое описание функций программного обеспечения но через призму пользовательского поведения. Рекомендуется использовать данный подход для тестирования каждой особенности программы, с которой может взаимодействовать пользователь.
Для каждой функции полезно будет установить приоритет (достаточно самый простой - высокий, средний, низкий).Это будет очень полезным при самом процессе тестирования и обработке неисправностей.
Подход с составлению тест-плана.
Это общая стратегия, которая использует для построения плана тестирования. Готовый тест план должен отвечать на следующие вопросы:
- Существуют ли специальные инструменты, которые будут задействованы в процессе тестирования и что это за инструменты
- Требуют ли они специальной подготовки для их использования
- Какие метрики необходимо собрать по ходу выполнения тест плана
- Какого порядка должны быть собранные метрики?
- На каких конфигурациях должно быть проведено тестирование
- Как должно быть построено регрессионное тестирование?
- Будет ли регрессионное тестирования зависеть от тяжести найденных неполадок
- Какие элементы требований или дизайна не будут включенные в тестирование
- Существуют ли специальные требования для проведения тестирования
- Существую ли какие-либо ограничения для этого тест плана (время, ресурсы)
Критерии прохождения тест плана:
Когда тест план считается пройденным? Критерии прохождения должны быть подробно и четко описаны, чтобы не возникало двоякости в понимании того, когда тест план можно считать пройденным.
- На уровне модульного тестирования все тестовые сценарии должны быть пройдены и указан процент допустимых дефектов
- На уровне главного тестового плана должны быть пройдены все планы более низкого уровня и указан процент допустимых дефектов
Критерии приостановления выполнения тестового плана:
Порой продолжать прохождения тест плана является не целесообразным, намример, когда количество найденных багов становится через чур большим и они блокируют возможность прохождения остальных тестов.
Так же, нужно детализировать что будет получено на выходе после прохождения тест плана:
- техническое описание тестов
- техническое описание тестовых сценариев
- сопроводительные отчеты
- зафиксированные баги
Задачи тестирования (test tasks)
Эти задачи должны быть определены для каждого вида и результата прохождения тест плана. Если процесс тестирования является многоэтапным, и этот тест план охватывает только часть функционала, то цели должны быть прописаны только для этого функционала.
4. Матрица покрытия функциональных требований (traceability matrix)
Таблица 1. Пример матрицы функциональных требований
Матрица покрытия функциональных требований это документ, который обычно содержит перечень отношений, которые определены в проекте. Он содержит список особенностей, который подлежат разработке на той или иной итерации продукта. Она используется для проверки текущего статуса разработки программного продукта. Эта матрица применяется на любых стадиях разработки, вплоть до оставления пользовательских сценариев. Она служит для контроля целостности продукта, по ней легко отследить, что уже сделано и что предстоит реализовать в дальнейшим.
Разработка тестового сценария
Тестовые сценарии состоят из сущностей, которые описывают входные условия, действия, события а так же ожидаемое поведение программы для того, чтобы определить, корректно ли работает тестируемая особенность или приложение. Чтобы это выяснить, как правило, создать два тестовых сценария - положительный и отрицательный. Созданные тестовые сценарии должны содержать четкую последовательность шагов, по которым тестировщик может прийти к тому или иному результату.
Пример тестового сценария.
Test case 1. (идентификационный номер тестового сценария, что затем его можно было легко найти и использовать в других тестовых планах)
Author: Anikin Anton
Title: Включение компьютера
Preconditions: Компьютер исправен и подключен к сети. (состояние системы на момент начала прохождения тестового сценария. Обычно этот пункт опускают, если система находится в состоянии «по умолчанию», но формально начальное состояние все же следует описывать).
Таблица 2. Пример тестового сценария
|
Шаги |
Результат |
|
|
Нажать кнопку POWER на системном блоке |
Включение компьютера, инициализация BIOS |
|
|
Загрузка компонентов |
||
|
Загрузка ОС |
||
|
Выбрать учетную запись: Admin |
Появилось окно ввода пароля |
|
|
Ввести пароль учетной записи: Qwerty12 |
Пароль принят |
|
|
-конец тестового сценария- |
Шаги тестового сценария должны быть максимально детализированы, чтобы у инженера не возникло проблем с толкованием тех или иных шагов. Например, если на шаге «выбрать учетную запись» не указать, какую именно запись следует выбрать, инженер может выбрать запись «гость» или другую (если она есть) и, соответственно, следующий шаг(ввод пароля) будет возможно содержать себе дефект, так как условия для его введения могут быть невыполненными.
Выполнение тестовых планов(test execution)
Когда тест план составлен и весь базовый функционал покрыт тестами, можно приступать к непосредственно выполнению тестовых сценариев.
При выполнение тестовых сценариев, каждый шаг непосредственно отмечается пройден он или нет(в этом случае этот шаг автоматически помечается, как шаг, содержащий дефект и тестеру предлагается подробно описать данный дефект)
Если все шаги отмечены как пройденные, то и сам тестовый сценарий автоматически считается пройденным и тестер может приступать к выполнению следующего сценария.
Если какой-либо шаг невозможно выполнить из-за того, что его функционал заблокирован каким-либо ранее найденным дефектом, то такой шаг следует помечать как заблокированный.
5. Управление дефектами
После завершения процесса тестирования необходимо составить отчет, в котором описывают результаты тестирования, найденные дефекты.
Виды тестирования по степени знания кода
В Процессе тестирования можно выделить 3 основные стратегии тестирования: тестирование черного ящика, серого ящика и белого ящика.
Под тестированием методом белого ящика традиционно понимают использование исходного когда приложения в качестве основы для его отладки. Обычно такой вид тестирования выполняется непосредственно программистом, так как он подразумевает хорошее знание исходного кода. Такой вид тестирования может включать в себя отслеживание путей выполнения программы путем заранее известных входных значений на этих путях.
Тестирование методом белого ящика не поможет определить несоответствие работы программы с заявленными требованиями, но оно может помочь выявить некоторые ошибки проектирования в исходном коде, такие как проблема управления потоком данных(бесконечные циклы) или в самих данных (использование неопределенной переменой). Статический анализ кода (с помощью инструментариев) так же поможет найти проблемы в программе но не сможет помочь разработчику/тестеру код в той степени, в которой это делает тестирование белого ящика.
Как правило, тестирование белого ящика связано с тестированием компонентов системы на предмет полного покрытия всех требований кодом и что эти компоненты находятся в исправном состоянии. Но такие тесты не могу быть полными, так как тестовые примеры в таком виде тестирования являются искусственными и не могут выявить всех ошибок поведения программы в реальной среде.
Тестирование методом черного ящика применяется, когда тестер не имеет представления о внутреннем составе программы. Он может подавать какие-либо данные в качестве входных условий в тестируемое программное обеспечение и по полученным значениям определять, соответствует ли это обеспечение заявленным требованиям.
Основными стратегиями тестирования черного ящика являются:
1. Разбиение на классы эквивалентности (используются, когда необходимо проверить множество входных условий, которые можно разбить на некоторые группы по формальным признаками и затем протестировать эти группы, взяв из каждой из них по 1-2 значения)
2. Анализ граничных значений ( проверка работоспособности программы при работе с данными, выходящими за пределы допустимых для ввода значений или находящихся близко к этому рубежу)
3. Проверка причинно-следственных связей (проверка корректной работы пользовательских сценариев)
4. Свободный поиск ошибок (прохождение нетипичных сценариев которые могут выявить ошибки в функционале работы программы, как правило, не очень высокого приоритета)
Тестирование методом серого ящика объединяет в себе методы тестирования методом «черного» и «белого» ящика. По методу черного ящика обычно осуществляется ввод данных, например - запуска программы внутри отладчика.
Нагрузочное тестирование
Вид тестирования, в котором измеряется в первую очередь производительность и время отклика разрабатываемой системы в различных режимах работы в соответствии с заявленными требованиями. Производится посредством приближение работы приложения к его максимально допустимому. Оно происходит в контролируемых лабораторных условиях, для более точного снятия показателей.
Обычно исследуют отклик системы и ее производительность падают на пиковых нагрузках, которая сильно превышает заявленную пропускную мощность системы. Такой вид тестирования называется стресс-тестированием.
Основная цель нагрузочного тестирования состоит в создании запланированной нагрузки на систему с помощью технических или аппаратных и средств и последующим наблюдении за состоянием системы в этот момент.
Основные принципы нагрузочного тестирования.
1. Уникальность запросов -нужно стараться генерировать как можно более разные и уникальные запросы к системе, так как конечный пользователь всегда будет так или иначе использовать недокументированные или нелогичные формы запросов к системе
2. Время ответа системы - измерение того, как ведет себя система под воздействием повышенных нагрузок. Из этого можно сделать вывод, что если мы имеем достаточное количество испытаний, то по ним можно определить, будет ли снижаться время доступа к системе вместе с ростом запросов к ней.
3. Зависимость времени ответа системы от ее сложности - влияет ли количество узлов и общая сложность системы на увеличение время ответа системы вместе с повышением количества и интенсивности запросов к ней.
4. Разброс времени ответа системы на запрос - некоторые команды программы при увеличении времени ответа системы перестают удовлетворять требованиям к проектируемой системе.
Существуют различные инструменты для проведения нагрузочного и стресс тестирования. Но все эти инструменты работают с приложением как с совокупностью узлов, на которые следует оказывать давление. Всего выделяют следующие виды узлов, подверженные нагрузочному тестированию:
- база данных
- приложение
- сеть
- балансировка нагрузки
- клиентская часть приложения.
Основные решения в области нагрузочного и стресс тестирования OpenSTA
Рис 5. Пример интерфейса программы
Распространяется по свободной лицензии. Базируется на распределенной архитектуре приложений(CORBA). Основное предназначение - тестирование веб-серверов. В настоящее время работает только на Windows-операционных системах.
Тестирование осуществляется посредством скриптов, записанных на языке SCL, простом языке, который обеспечивает поддержку пользовательских функций, областей переменных и случайных, а так же последовательных списков команд.
Разработка и поддержка данного приложения прекращена
IBM Rational Performance Tester
Рис 6. Пример интерфейса программы
Данный пакет предназначен для нагрузочного и автоматизированного тестирования веб-приложений и серверов. Он позволяет пользователь писать тесты, которые могли бы имитировать обмен данными между пользователями и серверной частью тестируемого приложения. Во время тестирования эти операции многократно повторяются для создания дополнительной нагрузки на сервер. Программа собирает данные, которые позволяют понять, насколько изменилось время ответа приложения после получение дополнительной нагрузки.
Создание теста производится с помощью механизма записи, который фиксирует все операции, происходящие между клиентской и серверной частью разрабатываемой системы. Результат выводится в виде дерева, где каждая ветвь представляет с собой какой-либо клиентский запрос к серверной части.
Чтобы редактировать таким образом записанный скрипт, пользователь изменяет непосредственно эти ветви дерева, вставляю в них дополнительные операторы, триггеры и счетчики проверок ответов. Так же можно использовать модуль JAVA для более точной настройки. Программа поддерживает процесс корреляции данных, который обеспечивает непрерывность между тестовыми взаимодействиями с разрабатываемым приложением.
JMeter
Рис 7. Пример интерфейса программы
Система нагрузочного тестирования, разработанная компанией Apache, приспособленная к анализу и измерению стабильности функционирования различных сервисов, в частности, веб-приложений. Jmeter может быть использован как часть тестового окружения для JDBC,FTP,LDAP и многих других стандартов. Он поддерживает широкие возможности для параметризации, валидации и составление отчетов, а его работа основана на поддержке плагинов, в том числе и неофициальных.
HP LoadRunner
Утилита для автоматизированного нагрузочного тестирования. Помимо приложений, может тестировать сайты различных уровней сложности. Работает за счет подключения виртуальных пользователей, которые руководствуются созданными скриптами.
Приложение состоит из следующих модулей:
- Virtual user generation - разработка скриптов и управление виртуальными пользователям
- Load Generator - генерация нагрузки
- Controller - разработка скриптов
- Analysis - анализ результатов тестирования
Рис 7. Пример интерфейса программы
Рис 8. Пример интерфейса программы
Продукт компании Borland для автоматизации выполнения нагрузочного тестирования для веб-систем различного уровня сложности. Сейчас выкуплен компанией Micro Focus. Отличается простотой и высокой мощностью, что позволяет использовать его для тестирований корпоративных приложений самого разного спектра и разного уровня массштабируемости.
Основными преимуществами считается сниженное потребление ресурсов на обнаружение дефектов путем начала тестирования еще до начала основного цикла разработки, до получения конечных версий клиентского приложения.
Стандартный цикл тестирования в SilkPerformer строится следующим образом:
1. Настраиваются новые параметры для тестируемого приложения
2. Создается тестовый сценарий (обычно за счет встроенной функции записи)
3. Созданный тестовый скрипт обрабатывается и для текущей сессии
4. Устанавливается модель рабочей нагрузки
5. Запуск теста
6. Анализ результатов теста на стороне клиента
7. Создание и анализ дальнейшей отчетности
Siege
Рис 9. Пример интерфейса программы
Утилита, специализирующаяся на тестировании веб-серверов. Siege имитирует подключение к серверу большого числа пользователей. Имеет три основных режима работы -
1. Режим регрессионного тестирования - программа считывает ссылки из файла конфигурации и по очереди проходит по ним
2. Режим интернета - программа в случайном порядке проходит по ссылкам в конфигурационном файле.
3. Режим грубой силы - программа обращается на один адрес
Приложение является бесплатным и поддерживает почти все современные ОС
Visual Studio Team System
Рис 10. Пример интерфейса программы
Visual Studio Team System - пакет инструментов, которые упрощают совместную работу над проектами, обеспечивают ее тестовым окружением и средствами для построения отчетов.
В состав этого пакета входит Team Test Load Agent, который отвечает за проведения нагрузочного тестирования в веб- или windows приложениях. Продукт тесно интегрирован с Team Fundation Server, что позволяет проводит такого рода тестирование на всем жизненном пути программы, однако лицензируется отдельно от TFS.
QTest
Рис 11. Пример интерфейса программы
QTest поддерживает не только нагрузочные тесты, но и полный цикл ручного тестирования. Так же обладает простым и интуитивным интерфейсом, который позволяет гибко подготовить проект к тестированию. Так же, QTest располагает возможностью интеграции с большинством решений в области отслеживания дефектов, что позволяет легко синхронизировать свою деятельность между платформами.
Тестирование удобства пользования (usability testing)
Рис 12. Работа с фокус - группой
Данный вид тестирования относится к оценке качества разработанной системы с точки зрения поведения пользователя. Как правило, участники такого тестирования (как правило, это небольшая фокус - группа) выполняют типичные задачи, используя разработанное приложения а наблюдатели собирают данные и на их основе делают выводы о удобстве использования приложения.
Собираемые данные:
1. Легкость обучения - как быстро человек сможет освоить новый для себя интерфейс
2. Эффективность обучения - какова продуктивность человека после обучения
3. Усвояемость обучения - легко ли пользователь запоминает то, чему он научился
4. Ошибки - как много пользователь допускает ошибок после прохождения обучения
5. Удовлетворенность - складывается ли у пользователя положительное впечатление о работе с системой
Задача данного вида тестирования - измерить все эти параметры Сам процесс тестирования может включать в себя следующие этапы:
1. Исследовательское - проведение тестирования интерфейса на предмет того, позволяет ли он с достаточной эффективностью использовать программу.
2. Оценочное тестирование - производится после большей детализации интерфейса. На данном этапе измеряемыми метриками уже являются такие показатели как количество обращений к помощи относительно количества совершенных операций, количество допущенных ошибок и т д.
3. Валидационное тестирование - на этом этапе производится анализ соответствия полученного интерфейса с системными стандартами, регламентирующими вопросы удобства интерфейса.
Обычно оценка происходит с помощью эвристических критериев удобства. Примером таких критериев могут является критерии, выделенные Якобом Нильсеном:
- Наблюдаемость состояния системы - пользователь всегда может получить информации о текущем состоянии системы
- Соотнесение с реальными миром - терминология, использованная в интерфейсе должна быть понятна конечному пользователю
- Пользовательское управление и свобода действий - пользователь должен иметь возможность в случае ошибки вернуть систему в исходное положение
- Целостность - интерфейс должен использовать одинаковые обозначения и лексику для обозначения одних и тех же частей системы.
- Помощь пользователям в распознавании и устранении ошибок - сообщения об ошибках должны быть понятные пользователю и передавать суть возникшей проблемы.
- Предотвращение ошибок - дизайн интерфейса должен быть продуманным, чтобы у пользователя не возникала возможность допустить ошибку или совершить ложное нажатие
- Гибкость использования - интерфейс должен иметь возможность кастомизации под нужды конкретного пользователя, а так же содержать горячие клавиши.
- Эстетический и минимально необходимый дизайн - приложение не должно содержать лишних и отвлекающих пользователя от работы элементов, окна не должны быть назойливыми или рассеивать внимание.
- Документация - интерфейс должен содержать файл помощи, который поможет разобраться и освоить весь функционал пользователю.
Тестирование безопасности (security testing)
Рис 13.Тестирование безопасности
Главная задача данного вида тестирования состоит в выявлении недостатков безопасности разрабатываемого приложения и поддержки должного уровня безопасности как предполагается в требованиях. Приложение считается безопасным, если удовлетворяет следующим принципам безопасности:
1. Конфиденциальность - сокрытие ресурсов и информации от некоторой категории пользователей, например, для не авторизированных пользователей.
2. Целостность - включает в себя доверие (данные могут быть изменены только доверенной группой пользователей) и повреждение и восстановление (данные могут быть восстановлены в случае их повреждения)
3. Доступность - каким группам пользователей какие виды ресурсов могут быть доступны
Существующие виды уязвимостей
- XSS(Cross-Site Scripting) - актуален для веб приложений. На тестируемом сайте выполняются вредоносные скрипты, которые атакуют клиента.
- XSRF/CSRF - такой вид уязвимости использует брешь в HTTP протоколе, позволяющий установить на доверенном сайте ссылку на вредоносный сайт, при переходе на который активируется скрипт
- Code injections - добавление вредоносного кода к исполняемому коду программы, в следвии чего становится возможным запуск кода с целью получение доступа к защищенным ресурсам
- Server-Side Includes injection - использует вставку серверных команд в HTML код или запускает их напрямую с сервера
- Authorization Bypass - получение доступа к учетной записи пользователя
Тестирование локализации
Это процесс тестирование локализованной версии разрабатываемого продукта. Проверяется корректность перевода пользовательского интерфейса и сопутствующей документации. Цель такого тестирования - убедиться в том, что данное приложение поддерживает мультиязычный интерфейс и может, по необходимости, легко переключатся между языками.
Тестирование совместимости
Проверка работоспособности системы в каком-либо окружении, таком как аппаратная платформа, сетевая конфигурация, операционная система, базы данных, переферия и т.п
Тестирование стабильности
Данный вид тестирования проверят работу системы на длительном промежутке времени с средним уровнем нагрузки.
Основной задачей такого тестирования является поиск утечек памяти, следов увелечения потребления ресурсов.
6. Ручное и автоматизированное тестирование
Ручное тестирование
Рис 14. Ручное тестирование
Ручное тестирование - это процесс поиска дефектов в программе, когда тестировщик выступает в роли пользователя и проверяет все функции приложения на предмет их работоспособности. Ручное тестирования является базовым типом тестирования, так как автоматизированное тестирование не в состоянии покрыть весь функционал программы.
Основной целью ручного тестирования является необходимость удостоверится в том, что тестируемое приложение не содержит в себе ошибок и функционирует в соответствии с документированными требованиями.
Ручное тестирование применяют во время функционального и не функционального тестирования, такого как тестирования совместимости, интерфейса, удобства, локализации.
При тестировании крупных проектов используется методология, которая позволяет выявить максимальное количество дефектов. Такая методология,как правило, включает в себя:
1. Выбор методологии тестирования
2. Составление тест-планов и тестовых сценариев
3. Ручное прохождение созданных тестов
4. Передача результатов тестов разработчикам
Автоматизированное тестирование
Рис 15. Автоматизирование тестирование
Процесс тестирования подразумевает под собой процесс, когда тестовые сценарии прогоняются автоматически по заранее заданному сценарию и без участия тестера.
Сейчас существуют два основных подхода к автоматизированному тестированию: тестирование на уровне кода и тестирования пользовательского интерфейса.
К тестированию на уровне кода относят модульное тестирование, при котором разрабатываемое приложение проверяется по частям, часто по ходу ее разработки.
Наиболее распространенной же формой автоматизированного тестирования является именно тестирование приложений через графический интерфейс. По сути, это та же имитация действий пользователя что и при ручном тестировании, только выполнение происходит автоматически.
На сей день существует следующие техники обеспечения такого тестирования:
- Запись и воспроизведение. Данные утилиты записывают действия тестировщика во время ручного тестирования и затем воспроизводят их в заданные моменты. Такие тесты помогают оптимизировать время тестировщика, убрав из процесса монотонные действия. Но если тестируемое претерпит изменения - тесты придется переписывать с нуля.
- Сценарии. Является формой программирования на специализированных скриптовых языках. Обычно написанием таких скриптов занимаются сам программисты. Скрипты хорошо подходят для тестирования пользовательского интерфейса, но так же имеют недостаток, связанный с их устареванием вместе с изменением внутри самой программы.
- Data-driven testing. Вид скриптов, которые оперирует непосредственно потоками данных и сами тестовые скрипты верифицируются с помощью этих данных.
-Метод координат. В этом методе каждый элемент графического интерфейса ищется по координатам на экране. Минусом является большая зависимость от настроек платформы (разрешение, шрифт и тп) и невозможность отслеживать состояние объекта.
-Распознавание объектов. В основе этого метода лежит поиск элементов пользовательского интерфейса с использованием распознавание и взаимодействие с заданными образцами. Минусы такие же, как и в методе координат.
Основной проблемой автоматизированного тестирования является трудоемкость, которая не всегда оправдывается выигрышем в времени. Чаще всего автоматизированное тестирование используется при тестировании локализаций и а так же при тестировании интерфейса с точки зрения соответствия его требован
7. Виды тестирования по времени проведения тестов
1. Альфа тестирование. Тестирование, проводимое на самой ранней стадии разработки, как правило для показа готового функционала клиентам. Как правило состоит в систематическом использовании всех функций программы.
2. Приемочное тестирование. Этот вид тестирования применятся для тестирования модулей программы на предмет критических дефектов, которые блокируют сдачу или релиз текущей версии продукта. Если дефектов обнаружено не было, то такой релиз можно считать допущенным до распространения.
3. Тестирование нового функционала. Вид приемочного тестирования, в котором все внимание уделяется новому функционалу приложения.
4. Регрессионное тестирование. Вид тестирования, направленный на поиск ошибок в уже проверенных частях кода. Такие ошибки могу возникнуть с выходом новых версий программы или с фиксом старых багов. Как правило, регрессионное тестирование состоит из повторного прогона полного приемочного тест плана. Когда проводить регрессионное тестирование каждая команда тестеров решает сама, обычно его проводят раз в несколько релизов, чтобы убедиться, не «отвалился» ли кусок старого функционала после изменений, постигших программу за последние итерации. Так же регрессию желательно проводить после рефакторинга кода.
5. Бета тестирование. Проводится с целью выявление максимального количества ошибок и для проверки функциональности продукта в максимально приближенных к реальности условиях. Как правило, бета тестирование подразумевает привлечение штата добровольцев из числа будущих пользователей продукта. Так же бета-тестирование может быть использовано в качестве рекламы и продвижения продукта на рынок.
8. Тестирование мобильных приложений
Рис 16. Тестирование мобильных приложений
Тестирование мобильных приложений проводится по тем же принципам, что и тестирование десктопных систем. Оно так же состоит из функционального тестирования, нагрузочного, тестирования производительности и стабильности и прерывания, простоты использования. Однако, в тестировании мобильных приложений есть много нюансов, о которых мы поговорим ниже.
Особенности мобильного тестирования
Для пользователя любое мобильное приложение должно быть простым и интуитивно понятным, иначе такой пользователь выберет другие приложение, так как конкуренция на этом рынке очень высока. В меньшей степени это можно отнести к корпоративному сегменту, хотя и тут эргономика и стабильность работы имеют решающие значение. Таким образом, на ряду с функциональности крайне важно значение для успеха продукта имеют все виды юзабилити-тестирования.
С технической точки зрения, важными отличиям является специфичность мобильных платформ и широкий спектр устройств, которые необходимо поддерживать.
Частые обновления операционной системы вынуждают так же часто обновлять само приложение, ведь зачастую после обновления системы меняется не только часть функционала но и дизайн ОС и разработчики должны иметь возможность выпускать своевременные обновления для своего детища. Поскольку сейчас большинство операционных систем поддерживают функцию обновления через встроенный магазин приложений, проблем с дистрибьюцией таких обновлений вроде бы нет, но с другой стороны, встает вопрос о совместимости новой версии с предыдущей, ведь пользователю будет неудобно сначала удалять старую версию, теряя все свои настройки, и, затем, устанавливая обновленную версию приложения.
Так же, важным является поддержка мультиязычности. Она позволяет сравнительно легко и дешево значительно увеличить охват целевой аудитории программы. Однако, важно, чтобы продукт был локализован корректно, не содержал в себе «машинного» перевода. Некачественный перевод может сыграть с разработчиками еще более злую шутку, чем его отсутствие.
Удобство пользования. Тестирование и оптимизация интерфейса является одной из важнейших частей тестирования мобильного программного обеспечения, так как в условиях большой конкуренции именно удобный дизайн и безотказность во время работы может дать решающие преимущество над конкурентами.
Нагрузочное тестирование. Наблюдение за потребление системных ресурсов. Так же необходимо отслеживать утечки памяти и проверять работоспособность и устойчивость серверной части приложения. Следует принимать во внимание, что передача данных в мобильных сетях может идти с потерей пакетов а так же следует проверить механизмы шифрования трафика на предмет его перехвата и использования сторонними пользователями.
Тестирование обработки случайных событий - разрабатываемое приложение должно корректно вести себя во время случайных и непредсказуемых событий, так как телефон часто попадает в условия, кода происходит хаотичное нажатие клавиш.
Мультиплатформенное тестирование. Мобильный рынок обладает большим количеством типов устройств и конфигураций. Очевидно, что тем больше устройств будет поддерживать приложение, тем большей будет база его клиентов
Основные моменты, на которые стоит обращать внимание при тестировании:
1. Интерфейс
1.1 Элементы интерфейса должны быть легко доступны пользователю, он должен иметь возможность однозначно попасть по ним
1.2 Приложение не должно содержать пустых или ведущих в никуда экранов. Пользователь всегда должен иметь возможность вернуть приложение к предыдущему рабочему состоянию
1.3 Приложение должно стабильно обрабатывать многократное и быстрое нажатие одной кнопки
1.4 Если заявлена поддержка жестов, то следует проверить, применимы ли те или иные жесты в тех или иных рабочих областях приложения и как это согласуется с требованиями
2. Производительность:
2.1 Утечки памяти. Следует проверять потребление памяти при длительной работе или при появлении окон с большим количеством информации.
2.2 Обработка ситуации нехватки ресурсов. Проверка стабильности работы приложения в условиях нехватки системных ресурсов
2.3 Отсутствие поддержки устройством части функционала приложения
3. Работы с различными экранами и разрешениями:
3.1 Ретина и обычные экраны. На ретине элементы интерфейса отображаются мельче
3.2 Работа с портретной и альбомной ориентацией устройства
3.3 Приложение должно работать только на заявленных версиях операционной системы
3.4 Соответствие дизайна приложения общей концепции дизайна платформы.
4. Обработка внешних событий:
4.1 Звонки/СМС, оповещения других приложений
4.2 Выключение устройства
4.3 Отключение устройства от сети, режим «в самолете»
4.4 Подключение/отключение карты памяти
Так же в приложении обязательно должна присутствовать форма обратной связи с разработчиком.
Все эти пункты легко поддаются ручному тестированию и сейчас для проверки работоспособности приложений оно особенно актуально. Но так же существуют системы автоматизированного тестирования, разработанные специально для тестирования мобильных приложений под различные платформы.
Автоматизирование тестирование мобильных приложений
Для автоматизированного тестировании мобильных приложений справедливы те же подходы, что и актуальны для тестирования десктопных систем, а именно:
- Запись и воспроизведение. Данные утилиты записывают действия тестировщика во время ручного тестирования и затем воспроизводят их в заданные моменты. Такие тесты помогают оптимизировать время тестировщика, убрав из процесса монотонные действия. Но если тестируемое претерпит изменения - тесты придется переписывать с нуля.
- Сценарии. Является формой программирования на специализированных скриптовых языках. Обычно написанием таких скриптов занимаются сам программисты. Скрипты хорошо подходят для тестирования пользовательского интерфейса, но так же имеют недостаток, связанный с их устареванием вместе с изменением внутри самой программы.
- Data-driven testing. Вид скриптов, которые оперирует непосредственно потоками данных и сами тестовые скрипты верифицируются с помощью этих данных.
-Метод координат. В этом методе каждый элемент графического интерфейса ищется по координатам на экране. Минусом является большая зависимость от настроек платформы (разрешение, шрифт и тп) и невозможность отслеживать состояние объекта.
...Подобные документы
Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование.
курсовая работа [112,2 K], добавлен 22.03.2015Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем.
курсовая работа [3,0 M], добавлен 19.11.2009История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения.
курсовая работа [309,5 K], добавлен 16.12.2015История возникновения тестирования программного обеспечения, основные цели и особенности его проведения. Виды и типы тестирования, уровни его автоматизации. Использование и исследование необходимых технологий. Полный цикл прогона всей системы мониторинга.
дипломная работа [1,7 M], добавлен 03.05.2018Тестирование как составляющая часть процесса отладки программного обеспечения, его роль для обеспечения качества продукта. Обнаружение ошибок в программах, выявление причин их возникновения. Подходы к формулированию критериев полноты тестирования.
курсовая работа [1,6 M], добавлен 20.12.2012Описание исходных текстов программного продукта. Системные требования и установка программного продукта. Тестирование пользователя по двадцати вопросам указанной темы и сохранение результатов тестирования. Форма отображения результатов тестирования.
курсовая работа [2,8 M], добавлен 09.07.2013Комплексное функциональное и структурное тестирование программного продукта - граф-программа решения квадратного уравнения. Постановка задачи структурного тестирования маршрутов. Заключение о типе и причине ошибки, предложение по ее исправлению.
курсовая работа [2,8 M], добавлен 05.01.2013Развитие аппаратных компьютерных средств - задача первых трех десятилетий компьютерной эры. Процесс тестирования как составляющая процесса обеспечения качества разработки ПО. Принципы и критерии, предъявляемые к тестированию программного обеспечения.
курсовая работа [319,5 K], добавлен 25.05.2009Тестирование и отладка программного обеспечения: понятие, принципы, этапы, цели и задачи. Тестирование методом сандвича как компромисс между восходящим и нисходящим подходами. Сущность метода "белого и черного ящика", отладки программного обеспечения.
курсовая работа [36,9 K], добавлен 21.07.2012Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
отчет по практике [296,1 K], добавлен 19.04.2015Выбор инструментальной среды разработки программного обеспечения системы. Алгоритм создания теста и ввода его исходных данных. Анализ экономической эффективности применения программного обеспечения "Тестирования знаний обучающихся программированию".
дипломная работа [3,2 M], добавлен 11.09.2014Тестирование как деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Существующие техники, их сравнительная характеристика. Пример тестирования программы о том, является ли год високосным, нахождение корня уравнения.
контрольная работа [161,8 K], добавлен 25.12.2014Проектирование базы данных, информационной подсистемы PLC-Tester, модуля тестирования и web-приложения. Разработка логической структуры программного продукта и общие требования к техническому обеспечению. Запуск программы и описание тестовых прогонов.
дипломная работа [3,2 M], добавлен 30.06.2011Автоматизация регрессионного тестирования. Классификация по способу сопровождения. Построение потового графа. Набор модульных тестов. Покрытие тестами классов эквивалентности. Тестирование методом "черного ящика". Тесты регрессии на "закрытых" багах.
курсовая работа [1,8 M], добавлен 16.01.2017Общий обзор проблемы безопасности ОС Android. Развитие индустрии по борьбе с вредоносным и мошенническим ПО. Разработка Системы ранжирования уровней опасности Android приложений. Выбор производителя и типа СУБД. Тестирование программного обеспечения.
дипломная работа [2,7 M], добавлен 13.02.2016Сущность тестирования и отладки, методика выявления ошибок в программном обеспечении. Практика отладки приложений в среде Delphi, системы управления версиями приложения и отслеживания ошибок. Применение точек остановки и модификация локальных переменных.
курсовая работа [303,4 K], добавлен 19.01.2016Архитектура и история создания операционной системы Android. Язык программирования Java. Выбор средства для реализации Android приложения. Программная реализация Android приложения. Проведение тестирования разработанного программного обеспечения.
курсовая работа [167,8 K], добавлен 18.01.2017Схемы взаимодействия между заказчиком и разработчиком программного обеспечения. Качество программного обеспечения и определение основных критериев его оценка на современном этапе, особенности управления на стадиях жизненного цикла, анализ достаточности.
презентация [114,7 K], добавлен 14.08.2013Процессы тестирования: общее понятие, история, философия. Главные особенности интеграции модулей. Испытание программных продуктов: цель и особенности, технологическая схема, планирование и оценка завершенности. Кoмплeксный имитaциoннo-мoдeлирующий стeнд.
курсовая работа [37,2 K], добавлен 21.07.2012Описание среды разработки Microsoft Visual Studio. Поддерживаемые технологии и языки программирования. Возможности и особенности компьютеризированного тестирования человека. Проектирование программного обеспечения с использованием объектного подхода.
курсовая работа [3,0 M], добавлен 09.02.2013
