Где найти хорошие шаблоны/примеры тестового сценария? [закрытый]
Это даст вам результат, но медленно.
import re
import pandas as pd
a = pd.DataFrame({"strings_to_search" : ["AA1 BB2 CVC GF2","AR1 KP1","PL3 4OR 91K GZ3"]})
b = pd.DataFrame({"regex_search" : ["^(?=.*AA1).*$", "^(?=.*AR1)(?=.*PL3).*$", "^(?=.*4OR)(?=.*GZ3).*$"]})
a.insert(1,'regex','')
for item in b.regex_search:
for s in a.strings_to_search:
if(re.match(item,s)):
a.regex.loc[a.strings_to_search == s] = item
print(a)
5 ответов
Я разработал два документа, которые использую.
один предназначен для ваших более «стандартных веб-сайтов» (например, бизнес-присутствие в Интернете):
http://pm4web.blogspot.com/2008 /07/quality-test-plan[1143090 visible.html
- другой, который я использую для веб-приложений:
http://pm4web.blogspot.com/2008/07/ Writing-system-test-plan .html
надеюсь, что это поможет.
Во-первых, я думаю, что объединение документа требований с документом тестового примера имеет наибольший смысл, поскольку большая часть информации одинакова для обоих и наличие требований перед тестировщиками и тестовыми примерами перед пользователями и разработчиками усиливает требование и предлагает различные точки зрения на них. Вот хорошая отправная точка для макета документа: http://www.volere.co.uk/template.htm#anchor326763 - если вы добавите: шаги для тестирования, в результате чего ожидания теста, край / связанные случаи - у вас должны быть довольно солидная спецификация требований и спецификация тестирования в одном.
Что касается шагов, не забудьте включить шаг оценки, где вы, тестировщики, разработчики и т. д.
Веб-сайт Дэвида Петерсона Concordion имеет очень хорошая страница о технике написания хороших спецификаций (а также о структуре для выполнения упомянутых спецификаций). Его совет прост и лаконичен.
Вы также можете почитать классическую запись в блоге Дэна Норта о поведении, управляемом разработкой (BDD). Очень полезно!
Перед началом работы вам обязательно нужна подробная спецификация; иначе ваши разработчики не знают, что писать и когда они закончат. Джоэл Спольски написал хорошее эссе на эту тему с примерами. Однако не ожидайте, что спецификация останется неизменной во время разработки: внесите изменения в план.
Meade, выше, рекомендовал объединить спецификацию с тестами. Это известно как Разработка через тестирование и является очень хорошей идеей. Он фиксирует вещи так, как это часто бывает с естественным языком, и сокращает объем работы.
Вам также необходимо подумать о модульных тестах и автоматизации. Это большая экономия времени и качественный ускоритель. Тесты уровня GUI может быть сложно автоматизировать, но вы должны сделать уровень GUI как можно тоньше, и есть автоматизированные тесты для функций ниже. Это значительно сэкономит время на поздних этапах разработки, потому что вы можете тщательно тестировать все приложение сколь угодно часто. Ручные тесты дороги и медленны, поэтому есть сильный соблазн срезать углы: «мы изменили только модуль Foo, поэтому нам нужно только повторить тесты 7, 8 и 9». Затем клиент звонит и жалуется, что что-то в модуле Bar сломано, и оказывается, что Foo имеет неясный побочный эффект на Bar, который разработчики упустили. Автоматические тесты поймают это, потому что автоматические тесты дешевы в выполнении. Правдивую историю о такой ошибке см. здесь .
Если ваше приложение достаточно велико, чтобы в нем нуждаться, укажите модули с помощью TDD и превратите эти тесты модулей в автоматизированные тесты.
Час на выполнение всех ручных тестов звучит немного оптимистично, если только это не очень простое приложение. Не забывайте, что вам нужно проверить все случаи ошибок, а также основной путь.
Просмотрите старые отчеты об ошибках и создайте свой тест футляры от них. Вы можете проверить конкретные старые ошибки, а также сделать больше обобщений. Поскольку одни и те же типы ошибок, как правило, возникают снова и снова, это даст вам набор тестов, который больше посвящен обнаружению реальных ошибок, а не невыполнимой (или очень дорогой) задаче полного охвата.
Используйте графический интерфейс и веб-автоматизация. Селен , например. Многое можно автоматизировать, гораздо больше, чем вы думаете. Например, ваш сценарий регистрации пользователя легко автоматизировать. Даже если они должны быть проверены человеком, например, кроссбраузерное тестирование, чтобы убедиться, что все выглядит правильно, тест можно записать и воспроизвести позже, пока инженер QA наблюдает. Разработчики могут даже записывать шаги для воспроизведения трудно автоматизируемых ошибок и передавать их QA вместо того, чтобы тратить время на написание инструкций и часто с ошибками. Сохраните их как часть проекта. Дайте им хорошее описание цели теста. Свяжите их с билетом. Если графический интерфейс изменится так, что тест больше не будет работать, а это произойдет, вы можете переписать тест, чтобы охватить его намерения.
Я уточню то, что Пол Джонсон сказал о том, чтобы сделать слой графического интерфейса как можно более тонким. Отделите форму (графический интерфейс, HTML или форматирование) от функциональности (того, что она делает) и автоматизируйте тестирование функциональности. Имейте функции, которые генерируют список стран, проверьте это тщательно. Затем функция, которая использует это для генерации HTML или AJAX или чего-то еще, и вам нужно только проверить, что он выглядит правильно, потому что функция, выполняющая реальную работу, хорошо протестирована. Логин пользователя. Проверка пароля. Сообщения электронной почты. Все они могут быть написаны для работы без графического интерфейса. Это резко сократит количество медленных, дорогих и некорректных ручных тестов, которые необходимо проводить.