Классификация, в более широком смысле, подразумевает разделение объектов по признакам, критериям, для систематизации знаний об объектах. Для чего нужно классифицировать программное обеспечение? Что мы хотим узнать о программах при помощи классификации? Давайте подумаем вот над чем: обработка информации всегда подразумевает получение нового знания. Стандарт ГОСТ Р ИСО/МЭК ТО 12182-2002 классифицирует программное обеспечение по следующим категориям: по масштабам, стабильности, классам функций программных средств, режиму эксплуатации, требованиям защиты, надежности, критичности, представлению и использованию данных, требованиям к вычислительным ресурсам, к вычислительной системе и среде, к рабочим характеристикам и языку программирования. Например, приложение для банковского сектора будет характеризоваться следующими параметрами классификации: надежность, защищенность сеанса связи и данных, скорость вычислений; для приложения образовательной платформы важнее будут характеристики: качество звука и изображения, количество одновременно подключаемых пользователей.
Стандарт не ограничивается разделением программных средств на категории. Он также классифицирует программные продукты и данные, описывает схему классификации, включающую разные подходы к классификации и их характеристики. В результате применения международного стандарта мы получили только общие подходы к классификации, не учитывающие потребности пользователей и носящие рекомендательный характер.
Предлагается также возможность разработки собственных стандартов для больших программных комплексов. Предложенный в стандарте пример наглядно показывает, как использовать классификацию для документирования разработанного программного продукта.
Таким образом, стандарт позволяет классифицировать программный продукт, отнеся его к одному или нескольким классам, по соответствующим шкалам классификации, и отразить данный выбор в документации. Но документирование программных средств не может быть единственной целью создания классификации.
При разработке программного продукта необходимо определиться, на каком оборудовании будет работать программа, каково ее назначение и область применения, какие существуют ограничения по использованию данных и вычислительным мощностям. Следовательно, при разработке программного обеспечения будут приняты решения, соответствующие выбранным критериям. Поэтому, отнесение разрабатываемой программы к тому или иному классу определяет, какие типовые решения будут приняты для ее реализации.
Если задача уже неоднократно решалась различными производителями программного обеспечения, то существуют уже разработанные критерии и возможные варианты решений, которыми можно воспользоваться или попытаться сделать программный продукт лучше аналогов. Для того, чтобы сравнивать программный продукт с аналогами, необходимо его соотнести с другими, на основе классификации. Это вторая задача, которую выполняет данный стандарт.
После краткого рассмотрения классификации программного обеспечения, перейдем к классификации видов тестирования. Наряду с видами тестирования, существуют также типы и способы тестирования, подходы к тестированию, но в данном случае они являются синонимами.
Виды тестирования принято разделять по следующим признакам: по запуску кода на исполнение, по доступу к коду и архитектуре, по уровню детализации приложения, по степени автоматизации, в зависимости от целей тестирования, от исполнителей, от уровня функционального тестирования, по принципам работы с приложением, или по философии: позитивное или негативное.
Т.к. в тестировании нет четких определений, можно встретить разные названия категорий, хотя это также связано с выбранным уровнем детализации классификации для конкретной задачи. Пример такой классификации представлен на рисунках интеллект-карты, созданной в программе XMind. Просмотр отдельных блоков с помощью стрелочек вправо-влево:
Выбор видов тестирования программного продукта во многом зависит от требований - заданных характеристик системы или ее части, на основе конкретных целей. Само по себе тестирование предназначено для проверки на соответствие реального и ожидаемого поведения программной функции или модуля. Кроме того, конкуренция на рынке программного обеспечения сделала необходимым создавать интерфейсы, удобные для пользователя: выявлять потребности и ожидания пользователей, изучать опыт взаимодействия пользователя с программой на этапе бета-тестирования - UX/UI тестирование, что расшифровывается как User Experience и User Interface.
Борьба за пользователя, в части конкуренции в ценовом диапазоне программ, послужила причиной создания методов и методологий тестирования, позволяющих обнаруживать дефекты на ранних стадиях разработки программного обеспечения, тем самым снижая затраты на устранение обнаруженных дефектов.
Необходимость защиты данных от несанкционированного доступа послужила предпосылкой создания тестов, выявляющих недокументированное поведение программы, не предусмотренное требованиями, которое может привести к запуску вредоносного кода.
Благодаря тому, что методов тестирования появилось огромное множество, необходимо было их как-то упорядочить, что требовала исследовательская природа тестирования как процесса, для создания методологии тестирования и разработки отдельных сценариев. Например, при разработке небольшого проекта, могут проводиться тесты в следующей последовательности:
- "дымовое" тестирование, позволяющее определить, что программа работает стабильно, все основные функции запускаются;
- тестирование критического пути - для прохождения всего сценария работы пользователя, от регистрации или входа в программу, до получения желаемого результата за минимальное время и минимальное количество этапов работы с программой;
- расширенное тестирование - проводится для остальной части функционала программы, с целью выявления наибольшего количества ошибок до сдачи программы в эксплуатацию;
- приемочное тестирование - выполняется перед передачей программы непосредственно заказчику, и позволяет удостовериться, что все пожелания и требования заказчика выполнены.
Надеюсь, что представленный материал помог Вам вспомнить и упорядочить знания о программных продуктах и видах тестирования. Конечно, данный материал не претендует на полноту, ведь на курсах нам давали классификации целиком, не уточняя, что, зачем, почему. В итоге этот громоздкий материал не очень хорошо запоминается, вспоминается фрагментарно.
Если Вы учились в вузе в 80-90е годы, то наверно помните, что задавать такие вопросы раньше было обязательно, для каждой системы было необходимо самостоятельно определять назначение, область применения, ограничивающие факторы, технические и эксплуатационные, критерии подготовки пользователей для работы с программным продуктом.
Если Вы учились позже, то надеюсь, что помогла Вам хоть немного восполнить пробелы в соответствующей области знаний. Подписывайтесь и будем "вспоминать всё" вместе.
