기능 테스트에서 브라우저에서 렌더링 된 모든 테이블 데이터를 DB에서 온 것과 비교해야합니까?

Question

일부 테스트가 다음과 같은 경로를 찍는 웹 사이트 테스트 계획을 진행하고 있습니다.

1. 요청 된 URI를 누르고 데이터를 일부 테이블 (페이지 당 20 행) 내부로 렌더링하십시오.
2. 해당 테이블에서 렌더링 해야하는 데이터를 가져 오려면 데이터베이스 쿼리를 작성하십시오.
3. 2 행을 행으로 비교하면 일치해야합니다.

기능 테스트를 수행하는 올바른 방법입니까? 해당 요청이 Ajax 요청이라면 답변은 무엇입니까? 통합 테스트의 대답이 다를까요?

나는 이것이 어떻게 든 잘못되었다고 믿는 이유가 있습니다 .... 여전히 당신의 의견이 필요합니다!

Answer 1

예, 이것은 생산적인 테스트 일 수 있습니다. 고정 데이터 세트가 있거나 그렇지 않습니다.

고정 된 데이터 세트가있는 경우 테스트하기가 훨씬 쉽습니다. 수행하는 일은 고정 된 출력과 비교하는 것입니다.

고정 데이터 세트가없는 경우 비즈니스 로직을 복제하여 개발자가 이미 수행 한 작업을 효과적으로 복제해야합니다. 그런 다음 유지해야 할 두 가지 논리 세트가 있습니다.

두 번째는 동일한 작업을 수행하는 두 가지 방법, 즉 사양 및 코드에 대한 피어 리뷰를 얻기 때문에 최선의 방법입니다. 또한 시간과 리소스 측면에서 매우 비싸기 때문에 대부분의 사람들이 고정 데이터 세트를 선택하기로 선택합니다.

질문에 답하기 위해 쿼리의 비즈니스 로직이 간단한 경우 테스트를 매우 쉽게 얻을 수 있습니다. 그러나 테스트가 가져 오는 가치는 크지 않습니다. 테스트하지 않기 때문입니다.

비즈니스 로직이 복잡하다면 테스트에서 더 많은 가치를 얻고 있지만 장기적으로 유지하기가 더 어려울 것입니다.

저에게 테스트가 가져 오는 것은 시스템이 데이터베이스에서 올바르게 읽히고 데이터를 올바르게 표시 함을 입증하는 간단한 통합 테스트입니다. 이것은 자동화되면 좋은 테스트입니다.

Answer 2

이것은 기능 테스트에 괜찮은 것 같습니다. 내 마음의 통합 테스트는 일반적으로 기능 테스트보다 광범위한 다양한 기술이나 구성 요소의 테스트와 관련이 있습니다. 그러나 물론 이러한 종류의 테스트는 응용 프로그램을 구성하는 방식과 개발 수명주기에서 테스트가 발생하는 위치에 따라 통합 테스트로 간주 될 수 있습니다. 예를 들어이 사이트가 작동하기 위해서는 독립적으로 개발 된 몇 가지 구성 요소를 구성해야 할 수도 있습니다. 이것은 통합이 작동하는지 확인하기위한 테스트 중 하나 일 수 있습니다.

이것이 ajax인지 아닌지에 대한 답을 다르게 만드는 것과 어떤 관련이 있는지 보지 마십시오.

Answer 3

나는 여기서 반대 의견이 될 것이지만, 나는 이것이 생산적인 테스트라고 생각하지 않습니다. 당신이하는 일은 단순히 페이지를 생성하는 코드를 복제하는 것입니다. 또한 복제 된 코드를 소개 할 때마다 (부서 전체에도) 장기적으로 자른 결함을 살펴볼 것입니다.

알려진 데이터 (앱을 통해 또는 직접)로 DB를로드 한 다음 출력이 기대하는 것과 일치하는지 확인하는 것이 훨씬 좋습니다. 또한 DB 계층 또는 DB 자체가 예상치 못한 방식으로 데이터를 수정하지 않도록합니다.

그건:

1. 알려진 데이터로드 (바람직하게는 앱 자체를 통해)
2. 요청 된 URI를로드하십시오
3. 표시된 데이터가 알려진 데이터와 일치하는지 확인하십시오

Answer 4

이러한 종류의 테스트는 데이터베이스와 최종 사용자에 대한 디스플레이간에 개발자 논리가 많지 않으면 비교적 적은 테스터 노력으로 대규모 데이터 세트를 테스트하는 데 좋습니다. 우리 팀은 여러 차례에 걸쳐이 작업을 수행했으며 실제 시나리오가 예상대로 처리되도록 테스트를 통해 대량의 실제 생산 데이터를 실행하는 데 특히 유용합니다. DB와 웹 페이지 (Null 값, 특수 문자 및 기타 이상)에서 다르게 처리 될 수있는 드문 시나리오에 대한 약간의 고정 입력 테스트를 수행해야합니다.

개인적으로, 나는 당신이 "기능 테스트"가 아닌 DB와 웹 사이트의 통합을 테스트하고 있기 때문에 이것을 "통합 테스트"라고 부릅니다. "기능 테스트"의 경우 아마도 예상되는 형식의 사전 작성된 데이터 세트를 제공하는 DataSource (예 : 데이터베이스)의 모의를 만들고 싶을 것입니다.

DB 데이터의 유효성에 대한 신뢰도가 높고 DB 쿼리와 웹 페이지 디스플레이 사이의 논리가 매우 작고 위험이 낮 으면 모의를 귀찮게하지 않을 것이며 통합을 허용 할 것입니다. 테스트는 기능을 다룹니다. 이 경우 기능과 통합을 개별적으로 테스트하는 것이 큰 품질의 승리가 될 것이며, 사용 가능한 테스트 시간으로 할 수있는 더 좋은 일이있을 수 있습니다. 이 데이터에 많은 논리가 있다면 기능과 별도로 통합을 테스트해야 할 것입니다. 추가 통합 테스트는 아마도 "데이터베이스에 도달 할 수 없다면 어떻게해야합니까?"와 같은 것들이 포함될 것입니다. 그리고 "데이터베이스가 느리면 어떻게 될까요?"

이 기술은 Ajax와 함께 작동하지만 테스트 도구가 Ajax에서 작동하는지 확인하십시오. 특히 데이터베이스 쿼리 결과를 캡처하는 방법과 웹 페이지에 표시된 결과를 수집하는 방법에 대해 생각해보십시오.

테스트 계획에서 테스트 한 가지 유형이라고 언급했기 때문에 쿼리의 데이터의 유효성이 다른 곳에서 테스트되고 있다고 가정합니다. 나는 또한 통합에 대해 논의하고 있습니다 데이터베이스 그리고 이 보고서 그리고 다른 기능이나 구성 요소는 아니며 테스트의 다른 측면 (성능, 보안 등)은 질문의 범위 였기 때문입니다.