Тактика тестирования программного обеспечения - Software testing tactics

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Тестирование установки

Основная статья: Тестирование установки

Проверка установки гарантирует, что система установлена ​​правильно и работает на реальном оборудовании заказчика.

Коробочный подход

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

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

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

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

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

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

Инструменты покрытия кода могут оценивать полноту набора тестов, созданного с помощью любого метода, включая тестирование методом черного ящика. Это позволяет команде разработчиков программного обеспечения исследовать части системы, которые редко тестируются, и гарантирует, что наиболее важные функциональные точки были протестированы.[1] Покрытие кода как метрика программного обеспечения можно указать в процентах для:

  • Охват функций, который сообщает о выполненных функциях
  • Покрытие заявления, который сообщает о количестве строк, выполненных для завершения теста
  • Охват решения, который сообщает, была ли выполнена ветвь True и False данного теста.

100% покрытие операторов гарантирует, что все пути или ветви кода (с точки зрения поток управления ) выполняются хотя бы один раз. Это помогает обеспечить правильную функциональность, но этого недостаточно, поскольку один и тот же код может обрабатывать разные входные данные правильно или неправильно.

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

Основная статья: Тестирование черного ящика
Схема черного ящика

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

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

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

Одним из преимуществ метода черного ящика является то, что не требуется никаких знаний в области программирования. Какие бы предубеждения ни были у программистов, тестировщик, вероятно, имеет другой набор и может делать упор на разные области функциональности. С другой стороны, тестирование методом черного ящика было названо «походом на прогулку по темному лабиринту без фонарика».[5] Поскольку они не исследуют исходный код, бывают ситуации, когда тестировщик пишет множество тестовых примеров, чтобы проверить что-то, что могло быть протестировано только одним тестом, или оставляет некоторые части программы непроверенными.

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

Визуальное тестирование

Цель визуального тестирования - предоставить разработчикам возможность изучить, что происходило в момент сбоя программного обеспечения, путем представления данных таким образом, чтобы разработчик мог легко найти информацию, которая ему или ему нужна, и информация была четко выражена. .[6][7]

В основе визуального тестирования лежит идея о том, что показать кому-то проблему (или провал теста), а не просто ее описать, значительно увеличивает ясность и понимание. Поэтому визуальное тестирование требует записи всего процесса тестирования - записи всего, что происходит в тестовой системе, в видеоформате. Выходные видео дополняются вводом тестера в реальном времени через веб-камеру «картинка в картинке» и аудиокомментариями с микрофонов.

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

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

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

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

Дальнейшая информация: Тестирование графического пользовательского интерфейса

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

Основная статья: Тестирование серого ящика

Тестирование серого ящика (американское написание: тестирование серого ящика) включает в себя знание внутренних структур данных и алгоритмов для целей разработки тестов при выполнении этих тестов на уровне пользователя или на уровне черного ящика. От тестировщика не требуется иметь полный доступ к исходному коду программного обеспечения.[2] Манипулирование входными данными и форматирование выходных данных не квалифицируются как серый ящик, потому что входные и выходные данные явно находятся за пределами «черного ящика», который мы называем тестируемой системой. Это различие особенно важно при проведении интеграционное тестирование между двумя модулями кода, написанными двумя разными разработчиками, где для тестирования доступны только интерфейсы.

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

Зная основные концепции того, как работает программное обеспечение, тестировщик делает более информированный выбор при тестировании программного обеспечения извне. Обычно тестировщику серого ящика разрешается настроить изолированную среду тестирования с такими действиями, как заполнение база данных. Тестировщик может наблюдать за состоянием тестируемого продукта после выполнения определенных действий, таких как выполнение SQL операторы для базы данных, а затем выполнение запросов, чтобы убедиться, что ожидаемые изменения были отражены. Тестирование методом серого ящика реализует сценарии интеллектуального тестирования, основанные на ограниченной информации. Это особенно относится к обработке типов данных, Обработка исключений, и так далее.[8]

Автоматизированное тестирование

Основная статья: Автоматизация тестирования

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

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

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

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

  • Программные мониторы, позволяющие полный или частичный мониторинг программного кода, включая:
  • Отформатированный дамп или символическая отладка, инструменты, позволяющие проверять программные переменные на ошибки или в выбранных точках
  • Инструменты тестирования автоматизированного функционального графического интерфейса пользователя (GUI) используются для повторения тестов на уровне системы через графический интерфейс.
  • Контрольные точки, позволяя сравнивать производительность во время выполнения
  • Анализ производительности (или инструменты профилирования), которые могут помочь выделить горячие точки и использование ресурсов

Некоторые из этих функций могут быть включены в один составной инструмент или Интегрированная среда развития (IDE).

Абстракция уровней приложения применительно к автоматизированному тестированию

Обычно существует четыре признанных уровня тестов: модульное тестирование, интеграционное тестирование, тестирование интерфейса компонентов и системное тестирование. Тесты часто группируются по месту их добавления в процессе разработки программного обеспечения или по уровню специфичности теста. Основные уровни в процессе разработки, определенные SWEBOK Guide - это модульное, интеграционное и системное тестирование, которые различаются целью тестирования, не подразумевая конкретной модели процесса.[9] Другие уровни тестирования классифицируются в зависимости от цели тестирования.[9]

С точки зрения клиентов, существует два разных уровня тестирования: тестирование низкого уровня (LLT) и тестирование высокого уровня (HLT). LLT - это группа тестов для компонентов различного уровня программного приложения или продукта. HLT - это группа тестов для всего программного приложения или продукта.[нужна цитата ]

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

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

Модульное тестирование относится к тестам, которые проверяют функциональность определенного раздела кода, обычно на функциональном уровне. В объектно-ориентированной среде это обычно на уровне класса, а минимальные модульные тесты включают конструкторы и деструкторы.[10]

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

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

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

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

Основная статья: Интеграционное тестирование

Интеграционное тестирование - это любой тип тестирования программного обеспечения, целью которого является проверка интерфейсов между компонентами на соответствие дизайну программного обеспечения. Программные компоненты могут быть интегрированы итеративно или все вместе («большой взрыв»). Обычно первое считается лучшим методом, поскольку он позволяет быстрее обнаруживать и устранять проблемы интерфейса.

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

Тестирование интерфейса компонентов

Практика тестирования интерфейса компонентов может использоваться для проверки обработки данных, передаваемых между различными модулями или компонентами подсистем, помимо тестирования полной интеграции между этими модулями.[12][13] Передаваемые данные могут рассматриваться как «пакеты сообщений», а диапазон или типы данных могут быть проверены на предмет данных, сгенерированных из одного блока, и проверены на достоверность перед передачей в другой блок. Одним из вариантов тестирования интерфейса является ведение отдельного файла журнала передаваемых элементов данных, часто с фиксированной временной меткой, что позволяет анализировать тысячи случаев передачи данных между модулями в течение дней или недель. Тесты могут включать проверку обработки некоторых экстремальных значений данных, в то время как другие переменные интерфейса передаются как нормальные значения.[12] Необычные значения данных в интерфейсе могут помочь объяснить неожиданную производительность в следующем блоке. Тестирование интерфейса компонентов - это разновидность черный ящик,[13] с упором на значения данных, помимо связанных действий компонента подсистемы.

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

Основная статья: Системное тестирование

Системное тестирование тестирует полностью интегрированную систему, чтобы убедиться, что система соответствует ее требованиям.[14] Например, системный тест может включать в себя тестирование интерфейса входа в систему, затем создание и редактирование записи, а также отправку или печать результатов с последующей суммарной обработкой или удалением (или архивированием) записей, а затем выходом из системы.

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

Основная статья: Операционные приемочные испытания

Оперативная приемка используется для обеспечения операционной готовности (предварительного выпуска) продукта, услуги или системы как части система менеджмента качества. OAT - это распространенный тип нефункционального тестирования программного обеспечения, используемый в основном в разработка программного обеспечения и обслуживание программного обеспечения проекты. Этот тип тестирования фокусируется на оперативная готовность системы, которую необходимо поддерживать, и / или стать частью производственной среды. Следовательно, это также известно как тестирование оперативной готовности (ORT) или Готовность к эксплуатации и гарантия (OR&A) тестирование. Функциональное тестирование в рамках OAT ограничивается теми тестами, которые необходимы для проверки нефункциональный аспекты системы.

Кроме того, тестирование программного обеспечения должно гарантировать, что переносимость системы, а также ее правильная работа не повреждают или частично повреждают ее операционную среду или не приводят к тому, что другие процессы в этой среде становятся неработоспособными.[15]

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

Основная статья: Тестирование совместимости

Распространенной причиной сбоя программного обеспечения (реального или предполагаемого) является его отсутствие. совместимость с другим программное обеспечение, операционные системы (или операционная система версии, старые или новые) или целевые среды, которые сильно отличаются от оригинала (например, Терминал или же GUI приложение, предназначенное для запуска на рабочий стол теперь требуется, чтобы стать веб приложение, который должен отображаться в веб-браузер ). Например, в случае отсутствия Обратная совместимость, это может произойти из-за того, что программисты разрабатывают и тестируют программное обеспечение только в последней версии целевой среды, которую могут использовать не все пользователи. Это приводит к непредвиденным последствиям, заключающимся в том, что последняя работа может не работать в более ранних версиях целевой среды или на более старом оборудовании, которое могли использовать более ранние версии целевой среды. Иногда такие проблемы можно решить заранее. абстрагирование функциональность операционной системы в отдельную программу модуль или же библиотека.

Дым и проверка на вменяемость

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

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

Регрессионное тестирование

Основная статья: Регрессионное тестирование

Регрессионное тестирование направлено на поиск дефектов после того, как произошло серьезное изменение кода. В частности, он стремится раскрыть регрессия программного обеспечения, как деградированные или утерянные функции, включая возвращенные старые ошибки. Такие регрессии возникают, когда функциональные возможности программного обеспечения, которые ранее работали правильно, перестают работать должным образом. Обычно регрессия происходит в виде непредвиденные последствия изменений программы, когда вновь разработанная часть программного обеспечения сталкивается с ранее существовавшим кодом. Общие методы регрессионного тестирования включают повторный запуск предыдущих наборов тестовых примеров и проверку того, возникли ли повторно ранее исправленные ошибки. Глубина тестирования зависит от фазы процесса выпуска и рисковать добавленных функций. Они могут быть полными для изменений, добавленных в конце выпуска или считающихся рискованными, или очень неглубокими, состоящими из положительных тестов каждой функции, если изменения находятся на ранней стадии выпуска или считаются неопасными. Регрессионное тестирование, как правило, является самым крупным тестированием при разработке коммерческого программного обеспечения.[16] из-за проверки многочисленных деталей в предыдущих функциях программного обеспечения, и даже новое программное обеспечение может быть разработано с использованием некоторых старых тестовых примеров для тестирования частей нового дизайна, чтобы гарантировать, что предыдущие функции все еще поддерживаются.

Приемочное тестирование

Основная статья: Приемочное тестирование

Приемочное тестирование может означать одно из двух:

  1. А дымовой тест используется в качестве приемочного теста перед введением новой сборки в основной процесс тестирования, т. е. перед интеграция или же регресс.
  2. Приемочные испытания, проводимые заказчиком, часто в лабораторных условиях на собственном оборудовании, известны как приемочное тестирование пользователей (UAT). Приемочное тестирование может выполняться как часть процесса передачи между любыми двумя фазами разработки.[нужна цитата ]

Альфа-тестирование

Альфа-тестирование - это смоделированные или фактические эксплуатационные испытания, проводимые потенциальными пользователями / клиентами или независимой группой тестирования на сайте разработчиков. Альфа-тестирование часто используется для готового программного обеспечения как форма внутреннего приемочного тестирования, прежде чем программное обеспечение перейдет на бета-тестирование.[17]

Бета-тестирование

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

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

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

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

Непрерывное тестирование

Основная статья: Непрерывное тестирование

Непрерывное тестирование - это процесс выполнения автоматизированные тесты как часть конвейера поставки программного обеспечения, чтобы получить немедленную обратную связь о бизнес-рисках, связанных с кандидатом на выпуск программного обеспечения.[18][19] Непрерывное тестирование включает в себя проверку обоих функциональные требования и нефункциональные требования; Объем тестирования простирается от проверки восходящих требований или пользовательских историй до оценки системных требований, связанных с общими бизнес-целями.[20][21][22]

Разрушительное тестирование

Основная статья: Разрушительное тестирование

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

Дальнейшая информация: Обработка исключений и Тестирование восстановления

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

Основная статья: Тестирование производительности программного обеспечения

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

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

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

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

Юзабилити-тестирование

Юзабилити-тестирование заключается в проверке простоты использования и понимания пользовательского интерфейса. В основном это касается использования приложения.

Тестирование доступности

Доступность тестирование может включать соответствие таким стандартам, как:

Тестирование безопасности

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

Международная организация по стандартизации (ISO) определяет это как «тип тестирования, проводимого для оценки степени защиты объекта тестирования, связанных с ним данных и информации, чтобы неавторизованные лица или системы не могли использовать, читать или изменять их, и уполномоченным лицам или системам не отказано в доступе к ним ".[23]

Тестирование интернационализации и локализации

Общая способность программного обеспечения быть интернационализированный и локализованный может быть автоматически протестирован без фактического перевода, используя псевдолокализация. Он проверит, что приложение по-прежнему работает, даже после того, как оно было переведено на новый язык или адаптировано для новой культуры (например, для других валют или часовых поясов).[24]

Фактический перевод на человеческие языки тоже должен быть протестирован. Возможные ошибки локализации включают:

  • Программное обеспечение часто локализуют путем перевода списка струны вне контекста, и переводчик может выбрать неправильный перевод для неоднозначной исходной строки.
  • Техническая терминология может стать непоследовательной, если проект переводят несколько человек без должной координации или если переводчик проявляет неосмотрительность.
  • Дословный дословный перевод может показаться неуместным, искусственным или слишком техническим для целевого языка.
  • Непереведенные сообщения на языке оригинала могут быть оставлены жестко закодированный в исходном коде.
  • Некоторые сообщения могут создаваться автоматически на время выполнения и результирующая строка может быть грамматически неверной, функционально неверной, вводящей в заблуждение или сбивающей с толку.
  • Программное обеспечение может использовать Сочетание клавиш который не работает на исходном языке раскладка клавиатуры, но используется для набора символов в раскладке целевого языка.
  • Программное обеспечение может не поддерживать кодировка символов целевого языка.
  • Шрифты и размеры шрифтов, подходящие для исходного языка, могут не подходить для целевого языка; Например, CJK персонажи может стать нечитаемым, если шрифт слишком мелкий.
  • Строка на целевом языке может быть длиннее, чем может обработать программа. Это может сделать строку частично невидимой для пользователя или вызвать сбой или сбой программного обеспечения.
  • В программном обеспечении может отсутствовать надлежащая поддержка чтения или записи. двунаправленный текст.
  • Программное обеспечение может отображать изображения с нелокализованным текстом.
  • Локализованные операционные системы могут иметь другое название system файлы конфигурации и переменные среды и разные форматы даты и валюта.

Тестирование разработки

Основная статья: Тестирование разработки

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

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

A / B тестирование

Основная статья: A / B тестирование

A / B-тестирование - это в основном сравнение двух выходных данных, обычно когда изменилась только одна переменная: запустить тест, изменить что-то одно, снова запустить тест, сравнить результаты. Это более полезно в более мелких ситуациях, но очень полезно для тонкой настройки любой программы. В более сложных проектах можно проводить многовариантное тестирование.

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

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

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

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

Основная статья: Тестирование на соответствие

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

Рекомендации

  1. ^ Вступление, Анализ покрытия кода, Стив Корнетт[ненадежный источник? ]
  2. ^ а б Паттон, Рон (26 июля 2005 г.). Тестирование программного обеспечения (2-е изд.). Самс Паблишинг. ISBN  978-0672327988.[страница нужна ]
  3. ^ Лэйкок, Г. Т. (1993). «Теория и практика тестирования программного обеспечения на основе спецификаций». Кафедра компьютерных наук, Шеффилдский университет, Великобритания. Архивировано из оригинал (PostScript ) на 2007-02-14. Получено 2008-02-13. Цитировать журнал требует | журнал = (помощь)
  4. ^ Бах, Джеймс (Июнь 1999 г.). «Тестирование на основе рисков и требований» (PDF). Компьютер. 32 (6): 113–114. Получено 2008-08-19.
  5. ^ Савенков, Роман (2008). Как стать тестировщиком программного обеспечения. Роман Савенков Консультации. п. 159. ISBN  978-0-615-23372-7.
  6. ^ «Визуальное тестирование программного обеспечения - Хельсинкский технологический университет» (PDF). Получено 2012-01-13.
  7. ^ «Статья о визуальном тестировании в Test Magazine». Testmagazine.co.uk. Архивировано из оригинал на 2012-07-24. Получено 2012-01-13.
  8. ^ "Инструменты тестирования SOA для методов тестирования SOA черного, белого и серого ящиков". Crosschecknet.com. Получено 2012-12-10.
  9. ^ а б "Руководство SWEBOK - Глава 5". Computer.org. Получено 2012-01-13.
  10. ^ Биндер, Роберт В. (1999). Тестирование объектно-ориентированных систем: объекты, шаблоны и инструменты. Эддисон-Уэсли Профессионал. п.45. ISBN  0-201-80938-9.
  11. ^ Бейзер, Борис (1990). Методы тестирования программного обеспечения (Второе изд.). Нью-Йорк: Ван Ностранд Рейнхольд. С. 21, 430. ISBN  0-442-20672-0.
  12. ^ а б Клапп, Джудит А. (1995). Контроль качества программного обеспечения, анализ ошибок и тестирование. п. 313. ISBN  0815513631.
  13. ^ а б Матур, Адитья П. (2008). Основы тестирования программного обеспечения. Университет Пердью. п. 18. ISBN  978-8131716601.
  14. ^ IEEE (1990). Стандартный компьютерный словарь IEEE: Сборник стандартных компьютерных глоссариев IEEE. Нью-Йорк: IEEE. ISBN  1-55937-079-3.
  15. ^ Технический документ: Оперативная приемка - приложение стандарта тестирования программного обеспечения ISO 29119. Май 2015 Энтони Вудс, Capgemini
  16. ^ Пауль Амманн; Джефф Оффатт (2008). Введение в тестирование программного обеспечения. п. 215 из 322 страниц.
  17. ^ ван Венендал, Эрик. «Стандартный глоссарий терминов, используемых при тестировании программного обеспечения». Получено 4 января 2013.
  18. ^ Часть конвейера: почему так важно непрерывное тестирование, Адам Ауэрбах, TechWell Insights, август 2015 г.
  19. ^ Взаимосвязь между риском и непрерывным тестированием: интервью с Уэйном Ариолой, Кэмерон Филипп-Эдмондс, Stickyminds, декабрь 2015 г.
  20. ^ DevOps: вы быстрее сообщаете клиентам ошибки, Уэйн Ариола и Синтия Данлоп, PNSQC, октябрь 2015 г.
  21. ^ DevOps и QA: какова реальная цена качества?, Эрика Чиковски, DevOps.com, июнь 2015 г.
  22. ^ Сдвиг влево и поставь качество на первое место, Адам Ауэрбах, TechWell Insights, октябрь 2014 г.
  23. ^ ISO / IEC / IEEE 29119-1: 2013 - Разработка программного обеспечения и систем - Тестирование программного обеспечения - Часть 1 - Понятия и определения; Раздел 4.38
  24. ^ «Пошаговая глобализация: готовый к использованию подход к тестированию. Сеть разработчиков Microsoft». Msdn.microsoft.com. Получено 2012-01-13.

внешняя ссылка