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

дефектные факторы

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

1. Программное обеспечение не соответствует функциям и производительности, требуемым клиентами;
2. Программное обеспечение превосходит требования клиентов;
3. Программное обеспечение содержит ошибки, которые недопустимы по требованиям заказчика;
4. Использование программного обеспечения не соответствует привычкам и рабочей среде клиента.

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

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

Проверьте общие базовые знания

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

Тест неполный (тест неполный)

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

Тестирование невосприимчиво (невосприимчивость к дефектам программного обеспечения)

Дефекты программного обеспечения имеют такой же ужасный «иммунитет», как и вирусы. Чем больше тестов к ним применяют тестировщики, тем сильнее становится их иммунитет, и обнаружить больше дефектов программного обеспечения становится сложнее. Мы можем сделать этот вывод из математической теории вероятностей. Если предположить, что в программе объемом 50 000 строк имеется 500 дефектов программного обеспечения и ошибки программного обеспечения распределены равномерно, то один дефект программного обеспечения можно обнаружить на каждые 100 строк. Предположим, что тестировщик тратит X часов/100 усилий на поиск дефектов программного обеспечения с помощью какого-либо метода. Согласно этому расчету, когда программное обеспечение имеет 500 дефектов, нам требуется X часов, чтобы найти один программный дефект. Когда программное обеспечение имеет только 5 ошибок, нам требуется 100X часов, чтобы найти каждый программный дефект. Практика доказала, что реальный процесс тестирования более сложен, чем приведенные выше предположения, поэтому мы должны изменить различные методы тестирования и данные тестирования. Этот пример также показывает, что использование одного метода тестирования программного обеспечения не может эффективно и полностью устранить все дефекты программного обеспечения, поэтому при тестировании программного обеспечения следует использовать как можно больше методов тестирования.

Тестирование — это «общая концепция» (полный тест).

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

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

принцип 80-20

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

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

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

Тест на эффективность

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

Неизбежность дефектов

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

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

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

Значение тестирования программного обеспечения – посмертный анализ

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

в заключение

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