Может кто-то помогать объяснить Тестирование Соответствия мне? [закрытый]
Вы столкнулись с общей проблемой: выбор XML, который находится в пространстве имен. Когда вы выбираете /findToFileResponse, вы выбираете элемент с именем findToFileResponse, но поскольку префикс пространства имен не указан, предполагается, что вы хотите выбирать элементы без пространства имен, что является общим.
Однако вы можете видеть, что ваш XML-документ находится в пространстве имен, потому что он использует атрибут пространства имен по умолчанию , что приводит к тому, что все его потомки включаются в это пространство имен (если не указано иное):
xmlns="xmlapi_1.0"
Чтобы выбрать элемент в этом пространстве имен, сначала нужно объявить его и присвоить префиксу в прологе XQuery:
declare namespace api = "xmlapi_1.0";
Сейчас Вы можете выбрать элементы в этом пространстве имен, используя префикс:
/api:findToFileResponse
Вы также можете выбрать элементы в любом пространстве имен, используя префикс подстановочного знака:
/*:findToFileResponse
4 ответа
Различие между NUnit/MbUnit и FitNesse - то, что NUnit/MbUnit предназначаются, чтобы использоваться для модульных тестов, в то время как FitNesse для приемочных испытаний.
Модульные тесты тестируют единственную, небольшую единицу кода, такого как метод, чтобы гарантировать, что он выполняется, как программист предназначил. Например, Вы могли бы использовать модульный тест, чтобы гарантировать, что вычисляющий факториал метод возвращает корректные результаты для ряда чисел, включая некоторые пограничные случаи.
Приемочные испытания предназначаются, чтобы протестировать, встречены ли высокоуровневые конструктивные требования. Как пример, если Вы писали клон Pac-человека, и одно из требований было "Новым уровнем, начинается, когда последнюю точку предыдущего уровня едят", приемочное испытание протестировало бы, чтобы видеть, удовлетворено ли то требование в целом кодом - не определенные части кода, которые используют точку, проверяют конечные условия и загружают новые уровни (хотя тот код был бы осуществлен в процессе выполнения приемочного испытания). Приемочные испытания обычно пишутся без учета в определенную реализацию требования.
Много отделов QA выполняет длинные списки приемочных испытаний вручную, которые могут быть очень трудоемкими. Соответствие и FitNesse являются инструментами, которые помогают в автоматизации приемочных испытаний, которые могут сэкономить много времени.
Существует большая хорошая информация о приемочных испытаниях в Wiki Ward Cunningham.
Последняя компания я работал с используемым FitNesse с определенной степенью успеха. Не означал использоваться таким же образом в качестве NUnit, в котором степень тестирования очень детализирована. FitNesse используется больше для "приемочных испытаний", включая меньше детализированных, "крупномасштабных" тестов. Для сравнения этих двух, позволяет, говорят, что мы писали приложение для обработки проверок в банке:
Если бы мы пишем модульные тесты с NUnit, мы протестировали бы каждый отдельный метод наших объектов Проверки, объектов Транзакции, фабрик TransactionProcessor, протестировали бы каждый метод нашего Уровня доступа к данным и т.д. Вы - тесты, очень близко к исходному коду.
Если мы пишем приемочные испытания, мы могли бы настроить дневную ценность транзакций, запросить приложение обрабатывать транзакцию и удостоверяться, что код производит корректные положения счета и отчеты. Вы в намного более высоком уровне, чем модульные тесты, обычно в точке наблюдения, где можно протестировать все бизнес-правила приложений сразу.
Модульные тесты говорят программистам, содержит ли код какие-либо дефекты, и приемочные испытания говорят бизнес-аналитикам, что приложения оправдывают пользовательские надежды.
Тестовые сценарии FitNesse разработаны, чтобы быть записанными людьми без технических знаний. Вам все еще нужны программисты для записи DLLs для представления внутренностей приложения к FitNesse, но иначе варианты использования, как предполагается, записаны нетехническими людьми, которые ничего не знают об исходном коде (т.е. бизнес-аналитики и QA).
Моя компания использовала FitNesse для тестирования одного из наших "базовых" приложений, которые, оказалось, были записаны в течение 20 лет с помощью мертвого подобного КОБОЛУ языка. Базовое приложение не имело модульных тестов, и было почти невозможно создать платформу поблочного тестирования на языке оригинала. Forturnately, язык имел привязку COM, которая выставила несколько открытых методов для.NET и Java, позволив нам записать автоматизированные тестовые сценарии для этого приложения впервые за 20 лет. Это не было симпатично, но деловым людям понравился он.
С моей точки зрения: это едва зависит от сцепления с приложением, которое будет протестировано. Если это не делает разрабатывает хороший API, это почти бесполезно. И не пробуйте его за тестирование GUI.
Может использоваться для выполнения комплектов регрессионного теста. Это может использоваться для проверки выпуска базы данных после выпуска. Это может использоваться для тестирования сохраненного procs. Это может использоваться для сравнения различных сред.