Тестирование программного обеспечения на предыдущих этапах разработки цикла

Question

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

1) Написание программных тестов ранее на основе требований и критериев приемки помогает разработчикам s/w идентифицировать проблемы интеграции с любыми чужими компонентами (например, сторонние исполняемые файлы и исполняемые файлы и т. Д.),

2) Улучшает работу s/w разработчиков в конечном продукте, принятии и самом проблемном домене.

3) Легче предсказать, как конечный продукт будет соответствовать требованиям к качеству.

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

UPDATE Я foundt this и они быть хорошие материалы для чтения.

Благодарим за помощь.

Answer 1

Один пункт, сделанный в первой статье, должен быть расширен с учетом следующей управленческой пословицы: менеджмент получает то, что контролирует управление.

«Качество встроено, не добавлено». из статьи. То же самое можно сказать о безопасности, производительности, надежности, возможности повторного использования и переносимости, но, в отличие от качества, можно протестировать. Если какой-либо из этих атрибутов проекта важен для управления, то их следует отслеживать с самого начала.

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

Parentheical note about performance testing: Важно не оптимизировать слишком рано. Однако, если вы не знаете, какова ваша базовая линия, или даже если эта базовая линия приемлема, тогда трудно принять правильные решения. Эстафетная проверка производительности позволит вам определить, что у вас есть.

Отвечая на первый комментарий.?

Я "м до сих пор не ясно, что вы имеете в виду о данных третьих сторон Вы имеете в виду что-то вроде отображения данных, где кто-то поставляет карты внутри библиотек Другим примером является выпуск почтовых Код данных в Канаде

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

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

Answer 2

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

Разнообразные процессы и задачи разработки могут быть использованы для проверки того, что дизайн был функционально протестирован и проверен на ранней стадии с использованием моделей и симуляций. К ним относятся проверка правильности требований (т. Е. Неконфликтных, полных и т. Д.), Подтверждающих соответствие модели дизайна требованиям, проверка того, что дизайн проходит все функциональные тесты, и различные дополнительные проверки, чтобы подтвердить, что дизайн не имеет ошибок (как с точки зрения функциональности, так и с точки зрения устойчивости). Эта ссылка на verification, validation, and test содержит дополнительную информацию.