Какой софт нужен, чтобы стать тестировщиком

Kiwi TCMS

Kiwi TCMS – бесплатная система управления тестовыми сценариями, написанные на Python и Django. У данной системы достаточно мощных и полезных функций, к примеру интеграция с Bugzilla и JIRA, быстрый план тестирования и выполнения умного поиска, настраиваемый контроль доступа для каждого тест-плана, выполнения теста и прочих артефактов, а также API-интерфейсы и XML-RPC.

Kiwi TCMS

Система отлично подходит под небольшие команды\продукты и предназначена помочь тестировщикам сделать их работу более организованной, прозрачной и подотчётной для всех членов команды.

Kiwi TCMS

Возможности:

• Линкование тестовых сценариев и issue не выходя из JIRA

• Работа с автоматизированными тестами

• Внутренний баг-трекер

• Понятная система отчетов

• Использование общего шага

• Фактическое время прохождения теста

• Экспорт данных в Excel

 Цена: Бесплатная система с открытым исходным кодом, но есть платные планы за донейшен или подписку

Понравился пост? Не забудьте поделиться им!

И помните, только тестировщик стоит между багами и клиентом! 🙂

Документация для тестирования

Как уже было указано выше, тестирование проводится в соответствии с программой и методикой испытаний, которая разрабатывается в соответствии с ГОСТ 34.603-92.

Для проведения тестирования разрабатывается контрольный пример, который должен содержать достаточно данных для проверки всех режимов работы программного продукта. Обычно, контрольный пример создается совместно заказчиком и исполнителем на основе реальных данных.

Для проведения всех видов тестирования производительности чаще всего создается так называемый генератор данных, который позволяет в автоматическом режиме создать достаточное количество данных, для достижения объективного результата при оценке производительности.

В ходе проведения тестирования составляется протокол тестирования, куда заносится информация о прохождении всех этапов и шагов тестирования и замечаниях полученных на испытаниях.

Если результат тестирования отрицательный, проводится устранение недостатков и повторное тестирование.

Уровень

Этот пункт определяет объект тестирования.

• Модульное / юнит-тестирование – проверка корректной работы отдельных единиц ПО, модулей. Этот вид тестирования могут выполнять сами разработчики.
• Интеграционное тестирование – проверка взаимодействия между несколькими единицами ПО.
• Системное – проверка работы приложения целиком.
• Приёмочное – оценка соответствия заявленным требованиям к программному продукту.

Переход на каждую новую ступень – движение от микроуровня к макро. Это важный этап тестирования, ведь безошибочно написанные модули могут просто не работать вместе. Узнать больше об особенностях каждого из уровней тестирования вы сможете на базовом курсе Академии, а закрепить навыки – на продвинутом курсе.

Какие типы или виды тестирования используются в QA процессе?

Теперь, когда мы понимаем, что представляет собой процесс QA, давайте поговорим о различных типах тестов, используемых при тестировании программного обеспечения. Да, их очень много. Но волноваться не стоит. Как только вы поймёте, по каким принципам тесты делятся на группы, вы легко сможете в них ориентироваться.  

Функциональные и нефункциональные тесты

Основные категории тестов — это функциональные и нефункциональные тесты.

При функциональном тестировании мы проверяем, работает ли приложение должным образом. Другими словами, мы проверяем, соответствует ли фактический результат ожидаемому результату.

В нефункциональном тестировании мы проверяем, как наше приложение работает в различных условиях. Нагрузочные тесты, тесты безопасности, стрессовые тесты и тесты удобства пользования — все они попадают в эту категорию.

Знание исходного кода

Если тестировщики знают исходный код до тестирования, речь идет о тестировании “белого ящика” (white box testing). В противном случае мы имеем дело с тестированием “черного ящика” (black box testing), когда тестировщики оценивают только поведение приложения, не зная его внутреннего устройства. Тестирование “серого ящика” (grey box testing) представляет собой комбинацию этих двух подходов. Тестировщикам предоставляется ограниченная информация о внутренней структуре системы.

Подход к выполнению тестов

Некоторые тесты выполняются людьми, и мы говорим о ручном тестировании. При этом подходе тестировщики выполняют тестовые сценарии и создают отчеты о результатах.

Другие тесты выполняются компьютерами. Инженеры по автоматизации тестирования создают сценарии автоматического тестирования и пишут код, который многократно проверяет программное обеспечение на наличие ошибок. Здесь мы имеем дело с автоматическим тестированием.

У каждого из этих подходов есть свои плюсы и минусы. Они дополняют друг друга. Например, ручное тестирование лучше подходит для проверки небольших изменений. Во время ручного тестирования тестировщики часто могут найти такие проблемы, которые остались бы незамеченными, если бы они полагались только на автоматизированные тесты. Ручное тестирование не требует глубоких знаний языков программирования и его достаточно легко освоить. 

В то же время, при работе над большими приложениями, тестирование без использования автоматических тестов может занять слишком много времени. Мы также не можем исключить вероятность человеческих ошибок.

Для каждого отдельно взятого проекта QA специалисты определяют идеальный баланс между ручным и автоматическим тестированием.

Фаза разработки программного обеспечения

Мы разделяем тесты на модульные, интеграционные, системные — в зависимости от того, на каком этапе цикла разработки программного обеспечения находится команда.

Вот еще несколько типов тестов, с которыми вы часто будете сталкиваться в публикациях:

Дымовые тесты (smoke tests) предназначены для проверки базовой функциональности приложения. Это быстро выполнимые тесты, с помощью которых тестировщики следят за тем, чтобы основные функции системы работали правильно.

Регрессионные тесты (regression tests)  помогают проверить, работает ли приложение так, как оно должно работать, после внесения каких-либо изменений, например исправления дефектов.

Нагрузочные тесты (load tests) необходимы для проверки приложения как при средней, так и при пиковой нагрузке.

Кроссбраузерное / кроссплатформенное тестирование помогает анализировать поведение приложения в различных браузерах и системах.

Конечно, это не все типы тестов, которые используются в процессе разработки программного обеспечения. Но знание этих основных категорий поможет вам лучше ориентироваться в теме QA.

Когда разработчик должен прекратить тестировать и поставить продукт?

Решение может основываться на измерении коэффициентов ошибок. Однако ключевое решение будет всегда основываться на доступных ресурсах. Если до релиза продукта имеется определенный объем времени, можно было бы расширить тестирование на каждом этапе. Однако, если бы программное обеспечение было обещано 6 месяцев назад, тестировщик мог бы  рискнуть и сказать о том, что программа работает без серьезных багов, даже если он или она знает о некоторых незначительных ошибках. Все это сводится к оценке степени риска и способности определить, когда более или менее безопасно отослать продукт заказчику.  Если дефектный продукт отослан, новая версия его все же может быть выпущена, однако это подразумевает совершенно новый набор оценок степени риска.

Qase

Qase достаточно удобен для небольших и средних размеров команд. Продукт отличается широкими возможностями кастомизациии при аскетичностьи интерфейса. Удобная система отчётов и выполнения тестовых артефактов в совокупности с настройками интерфейса позволяют достаточно быстро и точно настроить свои рабочие процессы.

QaseQase

Возможности:

• Тестовый репозиторий: выстраивание тестов в логические группы

• Оповещения во внешние сервисы об изменениях в тестах

• Удобный интерфейс и расширенной кастомизацией

• Хранение документации по проекту

• Автотрекинг дефектов в интегрированные TTS

• Удобный и простой REST API

• Расширенные возможности интеграций с внешними системами

• Гибкая ролевая политика

Цены: до 3 юзеров бесплатно, далее от $24 в месяц

Бесплатная пробная версия: 30 дней

Тестирование масштабируемости

Тестирование на вашем ноутбуке – это хорошо, но недостаточно, когда вы создаете социальную сеть, систему электронной почты или программное обеспечение для суперкомпьютера. Если ваше программное обеспечение предназначено для развертывания на 1000 серверов, все они будут функционировать в унисон, то тестирование, которое вы проводите локально в одной системе, не обнаружит ошибок, которые возникают, когда программное обеспечение развертывается «в масштабе» на сотнях тысяч экземпляров. На самом деле, ваше тестирование, скорее всего, никогда не сможет быть запущено в полном масштабе до выпуска в производство, потому что было бы слишком дорого и непрактично построить тестовую систему с 1000 серверами стоимостью в миллионы долларов. Следовательно, тестирование масштабируемости проводится на нескольких серверах, но обычно не на полном количестве рабочих серверов, чтобы попытаться выявить некоторые из дефектов, которые могут быть обнаружены при использовании ваших систем в более крупной инфраструктуре.

Тестирование черного и белого ящиков

«Черный ящик» и «белый ящик» – это менее конкретные методики тестирования и больше категорий типов тестирования. По сути, тестирование методом черного ящика, которое предполагает, что тестировщик ничего не знает о внутренней работе программного обеспечения, и создает план тестирования и тестовые примеры, которые просто смотрят на систему извне, чтобы проверить ее работу. Тестирование методом «белого ящика» выполняется архитекторами программного обеспечения, которые понимают внутреннюю работу программной системы и разрабатывают кейсы со знанием того, что может, будет, должно и может сломаться. Тестирование как в черном, так и в белом ящике может выявить различные типы дефектов.

Тестирование видеокарты. Программа FurMark

Видеокарту необходимо регулярно тестировать на наличие неисправностей, особенно если вы владелец игрового компьютера или ноутбука.Протестировать видеокарту поможет бесплатная утилита под названием FurMark.

Внешний вид приложения FurMark

Чтобы начать тестирование видеокарты, нажмите на клавишу «GPU-Z», как показано на рисунке выше.

Результат тестирования видеокарты компьютера

Тематические видеоролики:

AIDA64 универсальная программа для диагностики компьютера или ноутбука.

AIDA64 позволяет произвести: тест на стабильности системы, тест температуры видеокарты, процессора и других основных узлов компьютера.

Инструменты тестирования

Теперь, когда мы знаем, что такое процесс QA и какие существуют методы, подходы и типы тестов, давайте поговорим о том, какие инструменты тестировщики используют в своей работе. Инструмент тестирования — это любой продукт, который помогает оптимизировать различные действия: сбор требований, планирование, выполнение тестов, создание отчётов и анализ результатов.

Существует огромное количество таких сервисов и приложений. Никто не будет ожидать от начинающего тестировщика знание всех этих продуктов. Но будет полезно ознакомиться с некоторыми из наиболее популярных, такими как Selenium, Jira или BrowserStack.

Selenium — самый популярный инструмент тестирования. Он не требует глубоких знаний языков программирования и удобен для новичков.

Jira  — это распространённый инструмент для отслеживания ошибок и дефектов. Он также используется для управления проектами.

BrowserStack позволяет разработчикам тестировать свои приложения в разных браузерах, устройствах или операционных системах.

Основные тесты

Есть несколько основных методов тестирования, которые формируют часть режима тестирования программного обеспечения. Эти тесты обычно считаются самодостаточными в поиске ошибок и багов во всей системе.

 

Тестирование методом черного ящика

Тестирование методом черного ящика осуществляется без каких-либо знаний внутренней работы системы. Тестер будет стимулировать программное обеспечение для пользовательской среды, предоставляя различные входы и тестируя сгенерированные выходы. Этот тест также известен как Black-box, closed-box тестирование или функциональное тестирование.

Тестирование методом белого ящика

Тестирование методом «Белого ящика», в отличие от «черного ящика», учитывает внутреннее функционирование и логику работы кода. Для выполнения этого теста, тестер должен иметь знания кода, чтобы узнать точную часть кода, имеющую ошибки. Этот тест также известен как White-box, Open-Box или Glass box тестирование.

Тестирование методом серого ящика

Тестирование методом серого ящика или Gray box тестирование, это что-то среднее между White Box и Black Box тестированием, где тестер обладает лишь общими знаниями данного продукта, необходимыми для выполнения теста. Эта проверка осуществляется посредством документации и схемы информационных потоков. Тестирование проводится конечным пользователем, или пользователям, которые представляются как конечные.

Методика тестирования

Широко используемыми методами тестирования являются модульное тестирование, интеграционное тестирование, приемочное тестирование, и тестирование системы. Программное обеспечение подвергается этим испытаниям в определенном порядке.

1) Модульное тестирование

2) Интеграционное тестирование

3) Системное тестирование

4) Приемочные испытания

Модульное тестирование

В первую очередь проводится модульный тест. Как подсказывает название, это метод испытания на объектном уровне. Отдельные программные компоненты тестируются на наличие ошибок. Для этого теста требуется точное знание программы и каждого установленного модуля. Таким образом, эта проверка осуществляется программистами, а не тестерами. Для этого создаются тест-коды, которые проверяют, ведет ли программное обеспечение себя так, как задумывалось.

Интеграционное тестирование

Отдельные модули, которые уже были подвергнуты модульному тестированию, интегрируются друг с другом, и проверяются на наличие неисправностей. Такой тип тестирования в первую очередь выявляет ошибки интерфейса. Интеграционное тестирование можно осуществлять с помощью подхода «сверху вниз», следуя архитектурному сооружению системы. Другим подходом является подход «снизу вверх», который осуществляется из нижней части потока управления.

Системное тестирование

В этом тестировании, вся система проверяется на наличие ошибок и багов. Этот тест осуществляется путем сопряжения аппаратных и программных компонентов всей системы, и затем выполняется ее проверка. Это тестирование числится под методом тестирования «черного ящика», где проверяются ожидаемые для пользователя условия работы программного обеспечения.

Приемочные испытания

Это последний тест, который проводится перед передачей программного обеспечения клиенту. Он проводится, чтобы гарантировать, что программное обеспечение, которое было разработано отвечает всем требованиям заказчика. Существует два типа приемо-сдаточных испытаний — то, которое осуществляется членами команды разработчиков, известно, как внутреннее приемочное тестирования (Альфа-тестирование), а другое, которое проводится заказчиком, известно, как внешнее приемочное тестирования.

Если тестирование проводится с помощью предполагаемых клиентов, оно называется приемочными испытаниями клиента. В случае если тестирование проводится конечным пользователем программного обеспечения, оно известно, как приемочное тестирование (бета-тестирование).

Что тестируют на разных этапах разработки

Есть несколько уровней тестирования. Их проводят в разное время:

1. Модульное тестирование делается в самом начале, когда готовы те куски кода, которые можно проверить по отдельности: объекты, классы, функции, программные модули. Тесты пишутся отдельно для каждой функции или метода. На этом этапе проверяют работоспособность части кода, нет ли регрессии — не появились ли после изменения кода ошибки там, где раньше всё работало нормально. Это самый нижний уровень тестирования, часто это делают те, кто пишет код.
2. К интеграционному тестированию переходят после модульной проверки. Здесь тестируют связи между проверенными элементами и то, как программа взаимодействует с операционной системой, оборудованием.
3. Системное тестирование показывает, соответствует ли готовая система функциональным и нефункциональным требованиям.
4. Приёмочное тестирование проходит, когда заказчик принимает приложения от разработчиков. Его цель — убедиться, что продукт удовлетворяет требованиям клиента. На основании этого покупатель решает, готова ли программа или её нужно дорабатывать.

В зависимости от этапа разработки перед тестировщиками стоят разные цели:

• Когда пишется код, нужно найти как можно больше сбоев и дефектов, чтобы их исправить.
• Во время приёмочного тестирования нужно показать заказчику, что система работает без ошибок.
• На этапе сопровождения программы тестирование помогает исправить баги, которые появились в коде после изменения.

Нагрузочное тестирование

Нагрузочное тестирование — процесс анализа производительности тестируемой системы под воздействием нагрузок. Цель нагрузочного тестирования- определить способность приложения к внешним нагрузкам. Обычно испытания проводятся в несколько этапов.

1. Генерация тестовых сценариев

Для эффективного анализа сценарии должны быть наиболее близки к реальным сценариям использования

Важно понимать, что всегда возможны исключения, и даже самый подробный план тестирования может не покрыть отдельно взятого случая.. 2

Разработка тестовой конфигурации

2. Разработка тестовой конфигурации

Имея сценарии тестирования, важно распределить порядок возрастания нагрузки. Для успешного анализа необходимо выделить критерии оценки производительности (скорость отклика, время обработки запроса и т.д.).. 3

Проведение тестового испытания

3. Проведение тестового испытания

При проведении тестов важно своевременно следить за исполнением сценариев и откликом тестируемой системы. Для эмуляции высоких нагрузок требуется серьезная аппаратная и программная инфраструктура

В некоторых случаях для удешевления работ применяются методы математического моделирования. За основу берутся данные, полученные при низких нагрузках, и аппроксимируются. Чем выше уровень моделируемой нагрузки, тем ниже точность оценки. Однако подобный способ существенно сокращает расходы.

Статический анализ тестирования

Статический анализ – это тестирование, которое выполняется путем проверки программного кода без его фактического запуска. Для проведения статического анализа, как правило, вы должны использовать инструмент, их много, один известный инструмент – это Coverity. Статический анализ легко запустить перед выпуском программного обеспечения, и он может найти множество проблем с качеством в вашем коде, которые можно исправить до выпуска. Могут быть обнаружены ошибки памяти, ошибки обработки типов данных, разыменование нулевого указателя, неинициализированные переменные и многие другие дефекты. Такие языки, как C и C ++, значительно выигрывают от статического анализа, потому что языки предоставляют большую свободу программистам в обмен на большую мощность, но это также может создавать большие ошибки и ошибки, которые можно найти с помощью тестирования статического анализа.

Почему ручное тестирование не вымерло?

Да, автоматизация значительно сокращает время на тестирование определенных фич. Плюс есть вещи, которые просто невозможно проверить вручную. Но не стоит забывать и о ее стоимости. Не все продукты финансово могут потянуть автоматизацию. Да и не всегда требуется что-то автоматизировать.

Также вручную можно протестировать практически любое приложение, в то время как автоматизировать стоит только стабильные системы. То есть мы не можем, по крайней мере на сегодняшний день, автоматизировать все проверки.

Автоматизированное тестирование используется главным образом для регрессии. Кроме того, некоторые виды тестирования, например, исследовательское тестирование, могут быть выполнены только вручную.

Автоматизация начинается с ручного тестирования. То есть для того, чтобы начать процесс автоматизации тестирования, нужно точно знать, что и как вы собираетесь делать. Идеальный автотест базируется на ручном тест-кейсе с должным уровнем детализации.

________________________________

Ручное тестирование существует, так как невозможно автоматизировать все проверки и автоматизация не всегда финансово выгодна.

________________________________

На реальных проектах часто используется комбинация ручного и автоматизированного тестирования. Уровень автоматизации зависит от многих факторов: тип проекта, особенности постановки производственных процессов в компании, финансовых возможностей и т.п.

Тестирование встроенного ПО и соблюдение стандартов в эру Agile

Соблюдение отраслевых стандартов – это не то, чем вы можете пренебречь или заняться позже; это неотъемлемая часть процесса разработки встроенного программного обеспечения (ПО). Для некоторых индустрий, — таких как авионика, автомобилестроение и здравоохранение, — строгое следование стандартам качества при разработке сложных и безотказных встроенных систем становится жизненно необходимым условием выпуска продукта на рынок. Традиционно, тестирование играет важную роль в разработке встраиваемых систем для регулируемых стандартами отраслей. Однако за последние годы устоявшиеся практики и процессы тестирования, их место и роль в подобных проектах значительно преобразились. Это резко изменило все правила игры, а когда правила игры меняются, необходимо меняться вместе с ними, чтобы выиграть.

В условиях постоянного развития новых, ультрасовременных технологий компаниям необходимо быстро предлагать рынку надежные, безопасные, простые в использовании и совместимые с другими системами продукты – просто чтобы не потеряться в быстро меняющемся технологическом мире. В такой ситуации традиционная каскадная модель, где процесс разработки ПО строго последователен и тестирование выполняется в самом его конце, уходит в прошлое. Большую популярность приобретают методы DevOps и Agile, поскольку они позволяют инженерам выполнять задачи, которые раньше следовали друг за другом, одновременно.

Исследование, проведенное Ауригой при поддержке независимой исследовательской компании LTM Research, показывает, что эта эволюция роли тестирования в цикле разработки ПО имеет огромное значение. При постоянном дефиците времени производители по-прежнему не могут пожертвовать качеством, надежностью и безопасностью своего продукта. К примеру, широко обсуждаемые сегодня беспилотные автомобили являются источником повышенной опасности, а значит, требуют неукоснительного соблюдения стандартов. Нельзя обойтись и без тестирования встроенного ПО, поскольку практически все решения в области IoT и Connectivity основаны на встроенных технологиях.

Все отрасли стремятся к инновациям, быстрому развитию и распараллеливанию процессов, и это делает тестирование встроенного ПО еще более важным. Здравоохранение, где стандарты традиционно очень высоки, отличает огромный спрос на сложные и сверхточные алгоритмы – такие как, например, алгоритм автоматического распознавания сердечных ритмов для инновационного дефибриллятора, над которым сейчас трудятся инженеры Ауриги. Новые интеллектуальные больничные системы, «умное» медицинское оборудование и носимые устройства, которые появляются почти каждый день, должны быть безопасными и надежными.

Говоря о безопасности, нельзя не упомянуть сферу финансов и растущий интерес к биометрии. Сканирование отпечатков пальцев и сетчатки глаз, распознавание голоса и лица – вот что будет использоваться для идентификации пользователей вместо обычных паролей, к которым мы так привыкли. Но прежде чем позволить встроенному ПО сканировать вашу сетчатку, производители должны убедиться, что оно соответствует всем стандартами и устойчиво к киберугрозам, которые сегодня становятся все масштабнее и изощреннее.

Agile

Методология гибкой (Agile) разработки и тестирование ПО может быть описана как набор подходов, ориентированных на использование интерактивной разработки, динамического формирования требований и обеспечения их осуществления как результата постоянного взаимодействия внутри самоорганизующейся рабочей группы. Большинство гибких методологий разработки ПО нацелены на минимизацию рисков посредством разработки в рамках коротких итераций. Одним из главных принципов этой гибкой стратегии является возможность быстрого реагирования на возможные изменения, нежели стремление положиться на долгосрочное планирование.

Узнайте больше об Agile (прим. — статья на английском языке).

Правила составления тестов

Когда студент проходит тестирование, он остается один на один с заданиями. Если ему что-то непонятно — спросить не у кого. Приходится отвечать наугад, а это снижает объективность результата. Ниже мы подготовили правила составления тестов, следуя которым вы сможете существенно повысить качество своих тестов.

Как составлять вопросы для теста

Ключевые мыслиВопросы нужно ставить к основным логическим заключениям, передача которых являлась целью данного обучения. Тестовые задания должны проверять какую-то существенную часть пройденной теории. Заведомо глупые и бесполезные вопросы стоит исключать.

НедвусмысленностьЧеловек после прочтения вопроса сразу должен понять, что именно от него хотят. Тестовые задания не должен содержать двусмысленности. Нужно исключать из текста неопределенные слова, которые могут трактоваться студентом субъективно.

Простой языкФормулировка вопроса должна быть четкой, ясной, простой и понятной. Использование сложных текстовых конструкций необходимо минимизировать. Не перегружайте текст вопроса ненужной информацией. Исключайте из текста обороты, не несущие в себе смысловой нагрузки. Например, фразы “Как вы думаете”, “на ваш взгляд”, “по желанию”. Не используете в формулировке непонятные термины или сокращения.

Без подсказокОдни тестовые задания не должны содержать подсказки к другим. Испытуемый не должен использовать знание, полученное им из предыдущего задания, для решения следующего.

Сократите отрицанияИзбегайте использования негативных суждений в формулировке задания. При использовании отрицания четко обозначьте его — например, выделите строчными буквами «НЕ», «НЕТ», «НАИМЕНЬШЕЕ», «КРОМЕ».

Как составлять ответы для теста

К каждому сформулированному вопросу нужно подобрать правдоподобные дистракторы — варианты ответа, призванные сбить с толку и отвлечь внимание. Составление хороших дистракторов порой является самой трудоемкой частью создания теста. Делимся с вами правилами, которые помогут в составлении неправильных ответов

Внешний видПравильные и неправильные ответы должны быть однозначны по содержанию и структуре. Желательно, чтобы все ответы были краткими и одинаковыми по своей длине. Старайтесь максимум текста выносить в тело вопроса. Длинный вопрос и короткие ответы предпочтительнее, чем короткий вопрос и развернутые ответы.

В пределах знанийОтвет на вопрос должен находиться в пределах переданных уроком знаний. То есть, нужно убедиться, что в пройденном студентом уроке действительно и однозначно дается ответ на вопрос теста.

АдекватностьНеверные варианты ответа должны выглядеть адекватно, чтобы их нельзя было отбросить только лишь на основании общих логических рассуждений. Один или несколько могут быть точно правильными, а остальные должны выглядеть правильными, то есть быть условно правильными. Варианты ответов не должны содержать спорных моментов и непроверенных данных. В профессиональном тесте недопустимы шуточные варианты ответа.

ОбоснованностьНельзя включать дистракторы, неправильность которых на момент тестирования не может быть обоснована учащимися. Неправильные ответы должны конструироваться на основе типичных ошибок и должны быть правдоподобными. Неправильные ответы должны быть основаны на фактах.

Случайный порядокПравильные ответы должны располагаться среди всех предлагаемых ответов в случайном порядке.

Количество ответовРекомендуемое количество вариантов ответа для теста с одиночным выбором — 4, для теста с множественным выбором 5-6.

Нет подсказокПравильный ответ не должен содержать грамматической подсказки (выделения, однокоренные слова). Все варианты ответов должны грамматически верно сочетаться с вопросом. Каждый вариант ответа должен логично продолжать изначальное предложение. То есть, если их склеить, то должно каждый раз получаться нормальное предложение без пропущенных слов.

Нет обобщенийНе используйте варианты ответов: «все вышеперечисленное верно», «все указанные ответы неверны», «ни одного». Это вводит ученика в заблуждение. Если вы хотите, чтобы студент выбрал все варианты ответа в задании, то используйте вид теста с множественным выбором (чек-бокс).

Нет одинаковых фразОтветы на вопрос не должны начинаться или заканчиваться одинаковыми словами или фразами. Если такое произошло, то нужно переформулировать вопрос так, чтобы перенести эти слова или фразы в тело самого вопроса.

Когда составлены вопросы и ответы, нужно поместить их в уроки электронного курса.

Качество программного обеспечения

Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием «качество ПО» и если задать вопрос тестировщику или программисту «что такое качество?», то у каждого найдется своё толкование. Рассмотрим определение «качества ПО» в контексте международных стандартов:

Качество программного обеспечения — это степень, в которой ПО обладает требуемой комбинацией свойств.

Качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Характеристики качества ПО

Функциональность (Functionality) — определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает то, что ПО работает исправно и точно, функционально совместимо соответствует стандартам отрасли и защищено от несанкционированного доступа.

Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.

Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.

Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности, в соответствии с выделенными ресурсами, временем и другими обозначенными условиями.

Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов для реализации новых требований, для облегчения дальнейшего обслуживания и адаптирования к имеющемуся окружению.

Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/ hardware) в другое.

Модель качества программного обеспечения

На данный момент, наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.Рис.1. Модель качества программного обеспечения (ISO 9126-1)

Тестирование переполнения памяти

При использовании таких языков, как C или C ++, программист несет большую ответственность за прямую адресацию памяти, и это может вызвать фатальные ошибки в программном обеспечении, если будут сделаны ошибки. Например, если указатель равен нулю и разыменован, программное обеспечение выйдет из строя. Если для объекта выделяется память, а затем строка копируется в пространство памяти объекта, обращение к объекту может вызвать сбой или даже неопределенное неправильное поведение. Поэтому очень важно использовать инструмент, чтобы попытаться обнаружить ошибки доступа к памяти в программном обеспечении, использующем такие языки, как C или C ++, которые могут иметь эти потенциальные проблемы. Инструменты, которые могут выполнять этот тип тестирования, включают Valgrind с открытым исходным кодом или проприетарные инструменты, такие как PurifyPlus.. Эти инструменты могут спасти ситуацию, когда непонятно, почему программное обеспечение дает сбой или работает неправильно, и напрямую указывают на то место в коде, где есть ошибка. Классно, правда?