Недавно я прочитал несколько статей о некоторых сомнениях в преимуществах приемочных испытаний, потому что он довольно дорог по сравнению с тем, что он приносит. Чтобы сформировать собственное мнение, я хотел бы получить как можно больше преимуществ автоматических приемочных испытаний. Вы можете мне помочь?В чем преимущества автоматизации приемочных испытаний?
В целом, автоматическое тестирование имеет смысл при условии, что общие инвестиции в настройку и поддержание автоматизированного теста на срок службы продукта ниже, чем общие инвестиции при проведении ручного испытания, когда это необходимо для жизни продукт.
Поэтому автоматическое тестирование становится более привлекательным, если очень дешево создавать тест по сравнению с его запуском вручную (например, приспосабливать тестирование, где вы по существу создаете электронные таблицы), или если будет достаточно большое количество исполнений теста, чтобы компенсировать разницу в стоимости.
Модульное тестирование работает хорошо, потому что имеется достаточно большое количество исполнений - с любыми незначительными изменениями или рефакторингом вы хотите убедиться, что новый сбой отсутствует.
Приемочные испытания более уместны, поскольку вероятность повторного выполнения значительно меняется от проекта к проекту, а бизнес-потребности влияют на долгосрочную поддержку и проблемы обслуживания.
Если проект доставляется после прохождения приемочных испытаний и дополнительной поддержки или изменений нет, то автоматическое приемочное тестирование может не иметь смысла, если только очень дешево производить автоматизированные тесты.
Если, с другой стороны, ожидаются будущие выпуски (даже для одного клиента) или долгосрочный контракт на поддержку, тогда первоначальные инвестиции могут со временем стать достойными.
Наша компания производит торговые системы и алгоритмы для самых разных клиентов, а новые функции и продукты построены поверх старых. Стоимость выполнения всех наших тестов вручную настолько высока, что мы работаем над добавлением автоматических приемочных испытаний для многих сценариев, которые ранее были протестированы вручную.
Развейте:
ИМХО важно сначала очень четко и полный шаг за шагом планов тестирования (Хороший QA человек или команда имеет решающее значение здесь). В случае приемочных испытаний клиенты могут предоставить свои собственные или QA должны будут предоставлять своим клиентам. Я считаю, что план тестирования часто должен быть частью контракта.
Как только у вас есть это, легче оценить, сколько времени потребуется человеку для его запуска (и вы можете поэкспериментировать с человеком, чтобы узнать). Важно обратить внимание на то, какие шаги требуют «ворчания», и какие шаги требуют реального человеческого вклада или усмотрения.
Это важное различие. Например, предположим, что вы создаете программу рисования. если вы говорите человеку, что рисовать линии в определенных координатах, это может быть легко автоматизировано. Однако, если ваш шаг говорит: «Убедитесь, что форма - цветок», человек может сделать это легко, но автоматизировать это почти невозможно. Многие тестовые примеры могут быть полуавтоматизированы. Вы оставляете «крючки» для ввода пользователем и фокусируете внимание на них.Кнопка запускает серию операций, и пользователю предлагается «вывести правильный выход?».
Мой опыт в том, что стоимость автоматизации довольно интуитивно понятна. Однако часто необходимо изменить существующую программу, чтобы сделать ее более проверяемой. Например, в приведенном выше примере, если у вас есть API, позволяющий добавлять строки к холсту, все отлично. Если вам нужно написать робот-мышь, который переводит логические координаты на экран и все это, это намного дольше.
Каковы преимущества автоматизации приемочных испытаний?
Я часто являюсь магазином одного человека, поэтому с моей точки зрения основное преимущество заключается в том, что машины делают это вместо меня.
Как учебная среда тестирования, написания библиотеки тестирования и написания автоматизированных тестов точно проще, чем ручное тестирование? Я думаю, что самая большая проблема заключается в том, что приемочные тесты часто запускаются только один раз, я прав? –
@Gabriel, Um ... обучение - это трудная часть, и если у вас нет резиновых бамперов между ушами, нужно только один раз сделать это. остальное - академическое. И у вас есть верный момент, если у вас есть и будет только один выпуск одного продукта. Если бы мне было так повезло. –
@ Gabriel - также мое определение приемочного тестирования несколько включает в себя тестирование дыма и края в функциональное тестирование, поэтому я могу быть слабым моим определением. что я знаю, во всяком случае? ;-) –
Написание автоматических приемочных испытаний может похвастать большими преимуществами. В частности, он будет:
Пока вы можете быть на 100% знакомы с приложением, попробуйте положить его на несколько месяцев или лет и вернуться к нему, чтобы внести изменения. Поверьте мне, гораздо проще выполнить набор тестов, чтобы доказать, что ваши новые изменения ничего не сломали.
Наконец, подумайте о том, чтобы написать свои приемочные испытания, прежде чем писать код, а также тест, разработанный на основе тестирования. Это не только даст вам лучший код, но вы получите полный охват набора тестов, когда закончите.
Не забывайте о расходах. Да, для написания и сопровождения набора автоматических приемочных испытаний требуется время, обязательства и энергия. Но это дешевле, чем альтернатива, которая не является никаким тестом и не знает, что произойдет, если вы что-то измените и какой эффект knockon у нее будет. Какова ценность вашего клиента? Какова реальная стоимость исправления ошибки после ее отправки?
Как мой клиент более уверен в стабильности системы? Как насчет автоматических тестов, моя стойка стабильна? Какие расходы на обслуживание будут возмещены? Автоматизированные тесты можно рассматривать как больше кода для поддержки, что совершенно противоположно. Я предоставляю риск изменения ниже, потому что я вижу, какие сценарии затронуты изменением. Я не думаю, что изменение будет дешевле - часто приходится менять тесты. Написание приемочных испытаний заранее может быть затруднительным, если нет поддержки для тестирования всех взаимодействий. Стоимость не проблема для меня, но как насчет платежного клиента? –
В моей компании клиент - это бизнес, который платит за приложение, которое будет построено, но дело в том, что, если конечный клиент постоянно видит стабильную систему, они более счастливы, что является ценным. Автоматизация тестов делает систему стабильной, выявляя ошибки на раннем этапе, тем самым помогая предотвратить непредвиденные проблемы в обрезке в ваших сборках или позволяя раннее выявление, когда они это делают. Изменения дешевле, потому что вы менее склонны вводить ошибки, которые могут быть дорогостоящими для исправления, и после внесения изменений требуется меньшее ручное регрессионное тестирование. Наконец, хорошо написанные тесты не позволяют поддерживать высокий уровень тестирования. –
Платный клиент всегда заботится о стоимости. Важно то, что, платя больше авансом, они избегают дорогостоящих неожиданных сценариев в будущем (будь то простои из-за ошибок или пропущенных крайних сроков, потому что ручное регрессионное тестирование занимает больше времени). Подумайте об этом, как регулярно получать ваш автомобиль. Поступая таким образом, вы выявляете проблемы раньше, позволяя вам тратить время и деньги на решение любых проблем раньше, а не неожиданное разрушение, которое стоит гораздо больше времени и денег, и кто знает, что еще (может быть, вы ездили на свадьбу, например.). –
Спасибо, именно мои мысли :) Однако я не думал о реальном сценарии, где было бы полезно начать прием больше тестов. У меня еще мало вопросов: как определить стоимость автоматических тестов и ручных тестов? Вы думали в своем сценарии о тестировании на основе моделей? –
Габриэль, ИМХО, важно сначала иметь очень четкие и полные пошаговые тестовые планы (здесь хороший человек с QA). Как только у вас есть это, легче оценить, сколько времени потребуется человеку для его запуска (и вы можете экспериментировать с человеком). Если время очень велико, то вы выполняете технический анализ затрат на автоматизацию. Это часто довольно интуитивно, хотя может потребоваться некоторые изменения в инфраструктуре, чтобы сделать вещи более проверяемыми. – Uri
действительно, я думаю, что тестируемость должна быть архитектурным требованием с самого начала, спасибо, что последний абзац сделал мой тест на сдачу экзамена :). –