В гибком как разработка, кто должен случаи теста записи? [закрытый]
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
12 ответов
Команда.
, Если дефект добирается до клиента, это команда отказ, поэтому , команда должна писать тестовые сценарии, чтобы гарантировать, что дефекты не достигают клиента.
-
Менеджер проектов (PM) должен понять домен лучше, чем кто-либо в команде. Их знания проблемной области жизненно важны к наличию тестовых сценариев, которые имеют смысл относительно домена. Они должны будут обеспечить исходные данные в качестве примера и ответить на вопросы об ожиданиях по недопустимым исходным данным. Они должны обеспечить, по крайней мере, 'счастливый путь' тестовый сценарий.
-
Разработчик (разработчики) будет знать код. Вы предполагаете, что разработчик может быть лучшим для задачи, но что Вы ищете случаи функционального тестирования. Любые тесты, которые придумывает разработчик, являются белыми тестами поля. Это - преимущество наличия разработчиков, создают тестовые сценарии – они знают, где швы в коде.
Хорошие разработчики будут также приезжать к премьер-министру с вопросами, "Что должно произойти когда...?" – каждый из них является тестовым сценарием. Если ответ сложен "Если тогда x , но если b тогда y, за исключением четвергов" – существует несколько тестовых сценариев.
-
Тестеры (QA) знают, как протестировать программное обеспечение. Тестеры, вероятно, придумают тестовые сценарии, что премьер-министр и разработчики не думали бы о – именно поэтому у Вас есть тестеры.
Гибкий канон - то, что у Вас должно быть (по крайней мере) два слоя тестов: тесты разработчика и клиентские тесты.
Тесты разработчика записаны теми же людьми, которые пишут производственный код, предпочтительно с помощью разработки через тестирование. Они помогают придумывающий хорошо отделенный дизайн и удостоверяются, что код делает то, что разработчики думают, что он делает - даже после рефакторинга.
Клиентские тесты указаны клиентским или клиентским прокси. Они - на самом деле, спецификация системы, и должны быть записаны способом, что они - оба исполняемый файл (полностью автоматизированный) и понятный деловыми людьми. Достаточно часто команды находят способы, чтобы клиент даже записал им, с помощью людей QA. Это должно произойти, в то время как - или даже прежде - функциональность разрабатывается.
Идеально, единственные задачи для QA, чтобы сделать незадолго до слияния, нажимает кнопку, чтобы запустить все автоматизированные тесты и сделать немного дополнительные исследовательский (=unscripted) тестирование. Вы захотите запустить те тесты снова после слияния также, чтобы удостовериться, что интеграция изменений не повредила что-то.
причина мне не нравится иметь моих людей QA, делают это, то, потому что мне не нравится идея того, что они создавали их собственную работу. Например, они могли бы не учесть вещи, которые являются просто слишком большой работой для тестирования, и они не могут знать техническую деталь, которая необходима.
Yikes, у Вас должно быть больше доверия Вашему отделу QA или лучшее. Я имею в виду, воображаю Вас, сказал, что "Мне не нравится иметь моих разработчиков, разрабатывают программное обеспечение. Мне не нравится идея того, что они создавали их собственную работу".
Как разработчик, я Знаю, что существуют риски, включенные в письменной форме мои собственные тесты. Но это вовсе не значит я не делаю этого (я делаю, особенно если я делаю TDD), но у меня нет иллюзий о тестовом покрытии. Разработчики идут в тесты записи, которые показывают, что их код делает то, что они думают, что он делает. Не слишком многие идут в тесты записи, которые относятся к фактической экономической модели под рукой.
Тестирование является навыком, и надо надеяться Ваш отдел QA, или по крайней мере, лидеры в том отделе, является хорошо сведущим в том навыке.
Мое предложение было бы к наличию, кто-то еще просматривает тестовые сценарии, прежде чем код будет объединен для обеспечения качества. Предоставленный это может означать, что разработчик пропускает работу другого разработчика, но что вторая пара глаз может поймать что-то, что не было первоначально поймано. Начальные тестовые сценарии могут быть сделаны любым разработчиком, аналитиком или менеджером, не тестером.
QA не должен писать тестовые сценарии, поскольку они могут быть ситуациями, где ожидаемый результат не был определен и этой точкой, может быть трудно иметь кого-то рефери между QA и разработкой, если каждая сторона думает, что их интерпретация является правильной. Это - что-то, что я много раз видел многих и жаль, что этого не происходило так часто, как это делает.
люди QA, в сочетании с "клиентом", должны определять тестовые сценарии для каждой задачи [мы действительно смешиваем терминологию здесь], и разработчик должен записать им. сначала!
Я свободно разламываю свои тесты на тесты "разработчика" и "потребительские" тесты, последний которых был бы "приемочными испытаниями". Первый - тесты, которые разработчики пишут, чтобы проверить, что их код работает правильно. Позже тесты, которые кто-то другой , чем разработчики пишет, чтобы гарантировать, что поведение соответствует спецификации. Разработчики должны никогда , пишут тесты accepatance, потому что их создание программного обеспечения, которое они тестируют, предполагает, что они сделали правильную вещь. Таким образом их приемочные испытания, вероятно, собираются утверждать то, что разработчик уже знал, чтобы быть верным.
приемочные испытания должны управляться спецификацией и если они будут записаны разработчиком, то они будут управляться кодом и таким образом текущим поведением, не желаемым поведением.
"разработчики, которые думают, что это - пустая трата их времени, или что им просто не нравится делать его" Тогда, вознаграждают их за него. Какая социальная инженерия необходима, чтобы заставить их создавать тестовые сценарии?
Может QA просматривать код и тестовые сценарии и объявлять "Недостаточно Покрытия - Потребность Больше Случаев". Если так, тогда программист, который имеет "достаточно" покрытие сразу же, будет Большой Кахуной.
Так, мой вопрос: Как только задача сделана, кто должен определить цель "достаточно" тестовые сценарии для этой задачи? Как только Вы знаете "достаточно", можно сделать программистов ответственными за то, что заполнили "достаточно" и QA, ответственный за уверение, что "достаточно" тестирование сделано.
Слишком трудно для определения "достаточно"? Интересный. Вероятно, это - первопричина конфликта с программистами во-первых. Они могли бы чувствовать, что это - пустая трата их времени, потому что они уже сделали "достаточно", и теперь кто-то говорит, что это не "достаточно".
От прошлого опыта нам везло, довольно определяя тесты на разных уровнях для тестирования немного отличающихся вещей:
1-й уровень: На уровне кода/класса разработчики должны писать атомарные модульные тесты. Цель состоит в том, чтобы протестировать отдельные классы и методы как можно больше. Эти тесты должны быть запущены разработчиками, как они кодируют, по-видимому, прежде, чем заархивировать код в управление исходным кодом, и непрерывным сервером интеграции (автоматизированным), если Вы используетесь.
2-й уровень: На уровне интеграции компонентов снова имейте разработчиков, создающих модульные тесты, но тот тест интеграция между компонентами. Цель не состоит в том, чтобы протестировать отдельные классы и компоненты, но протестировать, как они взаимодействуют друг с другом. Эти тесты должны быть запущены вручную инженером интеграции или автоматизированы сервером непрерывной интеграции, если Вы используетесь.
3-й уровень: На прикладном уровне имейте команду QA, выполняющую их тестирование системы. Эти тестовые сценарии должны базироваться от бизнес-предположений или документов требований, предоставленных менеджером по продукции. В основном протестируйте, как будто Вы были конечным пользователем, делая вещи, которые конечные пользователи должны быть в состоянии сделать как зарегистрированный интервал а требования. Эти тестовые сценарии должны быть записаны командой QA и менеджерами по продукции, которые (по-видимому), знают то, что хочет клиент и как они, как ожидают, будут использовать приложение.
я чувствую, что это обеспечивает довольно хороший уровень покрытия. Конечно, уровни 1 и 2 выше должны идеально быть выполнены прежде, чем послать созданное приложение команде QA. Конечно, можно адаптировать это к любым соответствиям бизнес-модель, но это работало вполне прилично в моем последнем задании. Наш continous-сервер-интеграции выгнал бы электронное письмо группе разработчиков, если один из модульных тестов, отказавших во время сборки/процесса интеграции также, упакуйте кого-то, забыл запускать их тесты и фиксировал взломанный код в исходный архив.
Мы экспериментировали с соединением разработчика с человеком QA с довольно хорошими результатами. Они обычно 'сохраняли друг друга честным' и так как у разработчика были модульные тесты для обработки кода, он или она уже был довольно близким с изменениями. Человек QA не был, всего лишь прибыл в него со стороны черного квадрата. Оба считались ответственные за полноту. Часть продолжающегося процесса рассмотрения помогла поймать недостатки модульного теста и таким образом, не было слишком многих инцидентов, о которых я знал, где любой намеренно старался не писать X тестов, потому что, вероятно, окажется, что была проблема.
я люблю соединяющуюся идею в некоторых случаях и думаю, что она работала вполне прилично. Не мог бы всегда работать, но имеющий те плееры из различных областей взаимодействуют, помог избежать 'броска это по стене' менталитет, который часто происходит.
Во всяком случае, надейтесь, что это так или иначе полезно Вам.
Я думаю Менеджер проектов, или Бизнес-аналитик должен записать те тестовые сценарии.
Они должны тогда передать их человеку QA, чтобы изложить в деталях и протестировать.
Тот способ, которым Вы не гарантируете недостающих разрывов между спецификацией, и что на самом деле тестируется и поставляется.
разработчик не должен определенно делать этого, поскольку они будут тестировать свои модульные тесты. Таким образом, это - пустая трата времени.
, Кроме того, эти тесты найдут ошибки, которые никогда не будет находить разработчик, поскольку они происходят, вероятно, из-за недоразумения в спецификации, или функции или маршрута через код, не продуманный и реализованы правильно.
, Если Вы находите, Вы не имеете достаточного количества времени для этого, нанимаете кого-то еще или способствуете кого-то этой роли, поскольку это является ключевым для поставки превосходного продукта.
Выберите (не, только выбирают случайным образом), один или два тестера, и позвольте им записать тестовые сценарии. Обзор. Могло также быть полезно, если разработчик, работающий с задачей, смотрит на тестовые сценарии для задачи. Поощрите тестеры предлагать улучшения и дополнения к наборам тестов - иногда, люди боятся зафиксировать то, что сделал босс. Таким образом, Вы могли бы найти кого-то, кто способен к тестовому дизайну.
Сообщенный тестеры о технических деталях - я думаю, что у всех в гибкой команде должен быть доступ для чтения к коду, и независимо от того, что документация доступна. Большинство тестеров, которые я знаю, может прочитать (и запись) код, таким образом, они могли бы найти модульные тесты полезными, возможно даже расширить их. Удостоверьтесь, что тестовые разработчики получают полезные ответы от разработчиков, если они должны знать что-то.
Тестовый пример начинается первым в карточке истории.
Цель тестирования - отодвинуть дефекты влево (раньше в процессе разработки программного обеспечения, когда их дешевле и быстрее исправить) ,
Каждая карточка-рассказ должна включать критерии приемки. Владелец продукта объединяется с аналитиком решений, чтобы определить критерии приемки для каждой истории. Этот критерий используется, чтобы определить, достигнута ли цель карты истории.
Критерии приемлемости карт-историй будут определять, какие автоматизированные модульные тесты должны быть закодированы разработчиками, как они делают разработку через тестирование. Он также будет управлять автоматическим функциональным тестом, реализованным тестировщиками с автоматическим введением (и, возможно, с поддержкой разработчика при использовании таких инструментов, как FIT).
Не менее важно, критерии приемки будут определять автоматизированные тесты производительности и могут использоваться разработчиками при анализе профилирования приложения.
Наконец, приемочный тест пользователя будет определяться критериями приемлемости в карточках-историях и должен быть разработан деловым партнером или пользователями. Следуйте этому процессу, и вы, скорее всего, выпустите выпуск без дефектов.