Тестирование программного обеспечения

Question

На моем рабочем месте мы используем тестирование на основе сценариев. Однако всякий раз, когда что-то исправлено или добавлен новый патч, добавляются новые сценарии, в результате список становится все длиннее и длиннее, и на тестирование приложения уходит 3 дня и более Есть ли способ сделать правильное тестирование, не занимая много времени? Что вы используете?

Спасибо

Answer 1

Только 3 дня, чтобы протестировать вашу заявку! У нас есть тестовые задания, которые могут быть выполнены в течение 15 дней. И я думаю, что другие затаившиеся здесь люди могут сказать вам, что у них есть еще большие тестовые задания; Вы знаете тренировку - когда я был мальчиком, у нас даже не было дыры в дороге, чтобы жить.

А если серьезно, 3 дня на полное тестирование кандидата на выпуск с потоком выгод стоимостью O (10 ^ 7 долларов США) мне не кажутся возмутительными. С другой стороны, если вам требуется 3 дня, чтобы протестировать изменение одного поля в графическом интерфейсе с 12 до 24 символов, тогда это кажется слишком большим. Я думаю, что ваш вопрос лучше сформулировать так: «Сколько времени мы должны потратить на тестирование?» и ответ может быть любым от 10% до 50% (возможно, выше для систем, критичных для безопасности). Если вы тратите 2 дня на разработку патча, тогда тестирование должно занять не более 1/2 дня.

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

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

Answer 2

CI может помочь вам достичь этого, ключевым словом является автоматизация. Для процесса тестирования вам нужно сделать автоматизированное тестирование, UT, тестирование интерфейса, тестирование на основе UI и тестирование производительности. Но есть корневая концепция должна быть принята, качество не равно тестированию. UT может быть создан RD до завершения кодирования; Тестирование на основе UI и тестирование интерфейса разрабатываются QA во всем процессе кодирования. Когда новое перо закончено, есть набор тестов для обеспечения качества. Единственное, что вам нужно сделать, - это функциональное тестирование, которое не может быть покрыто автоматизированным тестированием.

Answer 3

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

Answer 4

Почему вы не автоматизируете свое приложение? Тестовый костюм? Всякий раз, когда существует разрыв между текущим и следующим выпуском, вы можете тем временем автоматизировать существующие тестовые случаи. Это не только сэкономит время цикла тестирования, но и регрессионное тестирование будет более точным, не пропуская и не пропуская ни одного сценария тестирования.
Вы можете автоматизировать не менее 60-70% всех тестовых случаев, что сэкономит время выполнения теста с хорошим запасом и может быть выполнено в одночасье.

Answer 5

Я тоже верю, что ты должен пойти на Agile.Поскольку Agile является комбинацией итеративного и инкрементного процесса, следовательно, основные моменты разделяются клиентом, то есть требованиями и обновлениями.Вы можете отсортировать Требование в порядке приоритета и можете планировать спринты, т.е. все требования должны быть упорядочены в порядке от высокого до низкого, так как отставание продукта и спринты могут быть подготовлены из очереди продукта.Поэтому к тому времени, когда идет разработка спринта 1, вы можете подготовить сценарии для тестирования спринта 1 в этом промежутке.после доставки спринта, если есть какой-либо запрос на изменение в каком-либо процессе, последующим можно легко управлять, и с помощью ретроспективных встреч scrum & sprint процесс может быть улучшен в будущих проектах. Таким образом, проект может быть легко доставлен в спринтах иза короткий промежуток времени.