Я студент, работающий над моим BE (CS), и мой вопрос заключается в следующем:

1. Нужно ли тестирование в области программного обеспечения?
2. Если мы создаем программное обеспечение с большой осторожностью, то зачем нам тестировать?
3. После тестирования мы можем быть уверены, что достигли этой цели (продукт / программное обеспечение работает как задумано), потому что мы провели тестирование для нее? Является ли это возможным?

Мой вопрос: нужно ли тестирование программного обеспечения ?

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

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

да

По той же причине, что повар готовит еду во время приготовления.

Я работаю с кем-то, кто так думает, он думает, что, поскольку он старший программист, ему больше не нужно тестировать свой код. Компания не понимает, насколько опасно такое отношение, и вместо того, чтобы увольнять его, они наняли больше программистов для решения проблемы с ошибками. Не зная, откуда возникает это отставание, они думают, что это является частью программирования. По сути, у нас есть 3 программиста, которые работают в этом режиме, и команда из 20 человек, которые не делают ничего, кроме как проверяют и исправляют ошибки, создаваемые этими тремя.

ОТСУТСТВИЕ ИЗ ПРАВИЛЬНОГО ИСПЫТАНИЙ УБИВАЕТ .

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

Программное обеспечение написано людьми.

Люди несовершенны и делают ошибки.

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

Так что да, тестирование необходимо. Это приносит баланс и перспективу.

Вы полетите на самолете с операционной системой, которую, как вы знаете, использовали на своем ноутбуке, и вы увидите экран смерти в своем любимом цвете? Думаю об этом.

Ни один кодер не идеален. Далеко, далеко, далеко от этого действительно. Вы нуждаетесь в тестировании, и тестировщики часто приводят в перспективе (также известный как сценарии использования), который пропустили разработчики.

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

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

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

В дополнение к тому, что уже было опубликовано, наличие полного набора автоматических модульных тестов для любого конкретного приложения сделает вас более уверенным в будущих изменениях кода. Эта более высокая достоверность (поскольку модульные тесты обеспечивают БОЛЬШУЮ сеть безопасности) приведет к более быстрым изменениям кода в существующих приложениях (из-за меньшего количества обратных проверок / двойной проверки)

Errare humanum est

Нет такого понятия, как программное обеспечение без ошибок.

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

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

Идеальный разработчик - это только часть всего этого. И идеальных разработчиков не существует.

Большинство реальных программ:

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

Таким образом, если вы не будете проверять, как программа работает в реальной ситуации, вероятность того, что она вообще не будет работать, будет близка к 100%.

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

ДА.

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

Никогда не стоит недооценивать необходимость «независимой проверки» . По той же причине хорошо, когда несколько независимых редакторов просматривают вашу работу, прежде чем отправлять большой текст для публикации. Неважно, насколько вы хороший писатель, вы будете время от времени делать выводы - и писать что-то вроде «in» вместо «it» или что-то в этом роде. Если вы перечитаете его сами, даже довольно осторожно, вы все равно будете его упускать, потому что ваш мозг автоматически воспринимает ваш мыслительный процесс как корректный и закрывает ошибку Для свежего взгляда такая ошибка обычно довольно очевидна.

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

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

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

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

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

Как вы думаете, что придало ему уверенности в этом?

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

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

Пахнет домашним заданием.

Нужно ли тестирование в области программного обеспечения?

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

Если мы создаем программное обеспечение с большой осторожностью, то зачем нам тестировать?

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

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

После тестирования мы можем быть уверены, что достигли этой цели (продукт / программное обеспечение работает как задумано), потому что мы провели тестирование для нее? Является ли это возможным?

Нет, не до 100%. Мы не можем протестировать каждую мыслимую комбинацию входных данных или путей выполнения в любом, кроме самого простого кода. Мы не можем объяснить все факторы окружающей среды. Мы не можем представить все возможные способы отказа.

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

Реальный сценарий - я работал над серверной системой, которая периодически отправляла обновления в службу графического интерфейса для отображения в таблице на экране. Во время проекта было добавлено требование добавить фильтрацию к дисплею (например, оператор мог выбрать отображение подмножества записей в таблице). Ошибка проектирования № 1 - фильтрация должна была выполняться службой графического интерфейса пользователя (у меня есть странное, антикварное представление о том, что функции управления дисплеем должны быть обязанностью программного обеспечения для управления дисплеем), но из-за политики и моей неспособности распознавать проблемы до того, как они станут проблемы , это требование было наложено на серверное обслуживание. Ну, ладно, нет проблем, я могу это сделать. Фильтровать изменения состояния, я получаю сообщение, а затем отправляю сообщение о создании или удалениикаждая строка в таблице , потому что именно так работает интерфейс (ошибка проектирования № 2 - невозможно отправить обновления для нескольких строк в одном сообщении; мы даже не могли отправить одно сообщение «очистить» или «удалить», чтобы очистить вся таблица).

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

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

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

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

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

1.) Устранить как можно больше сбоев с помощью проектирования и правильной реализации. 2.) Устранить непредвиденные сбои на этапе проектирования и неправильной реализации с помощью различных форм тестирования (единичное, интеграционное, случайное). 3.) Устранить любые оставшиеся сбои с помощью избыточности ( temporal => пересчитать, повторить или spacial => сохранить копии, четность)

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

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

Все программы имеют ошибки, по крайней мере, для начала.

Были некоторые исследования, которые сходятся примерно на 1 баг на каждые пять строк непроверенного кода.

Урок истории:

Еще в 1960-х годах IBM нуждалась в программе «NOP», чтобы они могли выполнять некоторые функции в JCL, фактически не запуская программу. Разработчики придумали однострочную программу на ассемблере, в которой весь код содержался в ее названии «IEFBR14», а реальный код:

       BR 14 * brach to return address in register 14

За время своей долгой работы эта однострочная программа была подвержена 2 сообщениям об ошибках и пяти изменениям.

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

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

Чтобы ответить № 3 на ваш вопрос:

Будучи программистом и тестером программного обеспечения, да, вы можете быть уверены, что вы соответствуете требованиям программного обеспечения во время тестирования.

{надевая шляпу QA}

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

{QA hat off}

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

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

НО это не так. ++++++++

Часто случаются ошибки, некоторые из которых имеют решающее значение для работы проекта. Существует также межбраузерное тестирование (что означает тестирование в различных существующих браузерах, таких как SAFARI, FIREFOX, CHROME и Internet Explorer), и я работал над проектом, где простые интерфейсные кнопки, такие как YES и NO, в окне опроса, где не работают только во всех браузерах. некоторые из них.

Я работал над тестированием интернет-страниц, тестировал простые ТЕКСТОВЫЕ ИЗМЕНЕНИЯ и подумал про себя, что нигде на свете не может быть дефектов в этой простой работе, но этого не происходит.

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

ДА

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

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

(продолжение следует)