The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Это может показаться странным, но я это докажу: несмотря на то, насколько большим или стабильным является программное обеспечение, у него есть неограниченное количество ошибок, которые еще не были обнаружены. Не важно, сколько из них мы уже успели найти и исправить, остается слишком много, чтобы их пересчитать.
Давайте возьмем в качестве примера этот простой Java-метод, который вычисляет сумму двух целых чисел:
Эта простая программа имеет неограниченное количество ошибок.
Чтобы подтвердить это утверждение, нам всего лишь нужно объединить две мысли:
- Во-вторых, требования и ожидания могут быть функциональными и нефункциональными. Последние включают производительность, устойчивость, надежность, поддерживаемость и еще десятки других NFR.
Очевидно, что в этом уравнении есть как минимум две неоднозначные переменные: ожидания пользователей и поддерживаемость. Мы не можем быть точными относительно них, и поэтому количество ошибок, которые они могут вызвать, не ограничено.
Конечно, только очень ограниченное подмножество всех ошибок имеет реальное деловое значение. Большинство ошибок, которые существуют в программе, могут оставаться там даже после ее отправки пользователям — никто их никогда не найдет, или же ущерб, который они вызывают для пользовательского опыта, будет незначительным.
Наконец, давайте еще раз взглянем на метод sum()
. А что насчет этих ошибок:
У него нет никакой документации для пользователей.
Его дизайн не является объектно-ориентированным.
Он не суммирует три или более чисел.
Он не суммирует числа типа
double
.Он не преобразует
long
вint
автоматически.Он не пропускает выполнение, если один аргумент равен нулю.
Он не кэширует результаты предыдущих вычислений.
“Здесь нет журналирования”
Checkstyle будет жаловаться, так как аргументы не являются
final
.
Я уверен, что вы сможете найти еще много примеров.
Кстати, Гленфорд Дж. Майерс сказал нечто очень похожее в своей книге “The Art of Software Testing”, которую я рассмотрел ранее.
Билл Хетцел, The Complete Guide to Software Testing (1993): “Некоторые теоретические ограничения тестирования: ‘Мы никогда не можем быть уверены, что спецификации верны’, ‘Ни одна система тестирования не может идентифицировать каждую правильную программу’, ‘Мы никогда не можем быть уверены, что система тестирования правильна.’ Эти теоретические ограничения говорят нам о том, что никогда не будет способа быть уверенными, что у нас есть идеальное понимание того, что программа должна делать (ожидаемые или требуемые результаты), и что любая система тестирования, которую мы можем создать, всегда будет иметь некоторую вероятность сбоя. Вкратце, мы не можем достичь 100-процентной уверенности, независимо от того, сколько времени и энергии мы вкладываем в это!”
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 05:18