QA 직원이 볼 수없는 캐싱 로직을 어떻게 테스트 할 수 있습니까?

웹 애플리케이션에서 캐싱 레이어를 구현 한 후 캐싱이 사용자에게 투명하기 때문에 QA가 어떻게이를 테스트해야하는지 궁금합니다.

내가 가지고있는 한 가지 아이디어는 캐시를 채우는 코드를 호출하는 메소드에 로깅을 저장하고 캐시에서 객체를 가져올 때와 데이터베이스에서 재생산이 필요할 때를 기록한 다음 테스터가 로그를 볼 수 있는지 확인하는 것입니다. 예를 들어, 모든 페이지보기 대신 10 분마다 db에서 특정 오브젝트가 다시로드됩니다.

그러나이 상황에 대한 더 나은 사례를 제안 할 수 있습니까?

한 가지 질문은 캐시 자체가 실제로 QA에서 테스트해야하는 요구 사항인지 여부입니다. 캐싱은 성능을 향상시켜 성능 차이를 테스트하여 일부 요구 사항을 충족하는지 확인할 수 있습니다.

그러나 캐싱에 대한 책임이있는 사람은 캐싱에 대해 테스트를하는 것이 좋습니다. 우리는 성능 카운터를 사용했습니다. 캐시 시스템이이를 활용하면 간단합니다. 캐시 자체에서 카운트를 얻는 방법이 있다면 다른 옵션입니다.

당신의 접근 방식을 사용하는 것도 좋습니다. 이 중 하나라도 결과를 확인하는 자동화 된 테스트에 싸여 있으면 아무도 로그를 조사하여 답을 찾을 필요가 없습니다.

시스템 성능이 좋지 않아서 캐시를 구현했습니다. 그것은 사용자와 관련된 것입니다. 품질 관리팀에서 확인할 수있는 사항은 다음과 같습니다.

• 캐시가 도입 된 후에도 시스템은 여전히 ​​옳습니다. 즉, QA에서 확인할 수있는 부실 데이터를 제공하기 위해 캐시를 속이고 다른 오류가 없는지 확인해야합니다.
• 시스템이 이제 성능 향상을 결정했을 때 충족되지 않은 성능 임계 값을 충족시킵니다. 이전 측정을 비교하여 새 측정과 비교할 수 있습니다.

사용자 (및 QA)는 문제 해결 방법에 신경 쓰지 않습니다 . 그들은 문제가 해결 되었다는 것만 신경 쓰고 새로운 문제를 만들지 않았습니다. 캐싱 구현, 개선 된 문자열 구문 분석, 하드웨어 업그레이드 또는 서버에 마법 요정 가루를 뿌린 경우에도 마찬가지입니다.

중요한 비즈니스 로직이나 시스템 상태를 블랙 박스에 깊이 묻 으면 올바른 시스템 동작을 확인하기가 어렵습니다. 전체 시스템보다 시스템에서 단일 구성 요소의 동작을 철저하게 테스트하는 것이 더 쉽습니다. 나는 어떤 메커니즘을 통해 그러한 것들을 명시 적으로 노출하는 것을 선호하므로 의미있는 방식으로 단위 / 회귀 / 통합 / QA 테스트를 할 수 있습니다.

캐시를 사용하는 옵션 중 하나는 캐시에 대한 세부 정보 (내용, 상태 등)를 제공하는 특수 페이지를 표시하는 것입니다. 이는 개발 및 잠재적으로 프로덕션에서 디버깅을 지원할 수 있습니다. 또한 QA는이 페이지를 사용하여 예상되는 캐시 동작에 대한 세부 사항이 제공되는 경우 캐시에 대한 테스트 케이스를 작성할 수 있습니다. 캐시 카운터 동작을 명시 적으로 문서화하기 위해 성능 카운터 및 / 또는 로그 파일을 사용하는 것은 눈에 잘 띄지 않지만 실행 가능한 다른 방법입니다.

이 접근 방식은 엔드 투 엔드 성능 테스트를 대체하지 않습니다. 이것은 캐시 자체가 올바르게 작동하도록하는 메커니즘입니다. 캐싱이 성능에 의도 한 영향을 미치는지 확인하려면 성능 테스트를 사용해야합니다.

또한 캐시 구성과 같은 동일한 인터페이스를 구현하는 새로운 구성 요소로 시스템 구성 요소를 교체하면 불안정하고 믿을 수 없을 정도로 복잡한 변경이 될 수 있습니다. 캐시 예제를 사용하면 이전에 상태 비 저장 상태로 상태를 도입하므로 찾기 또는 재현하기 어려운 버그가 발생할 수 있습니다. 이러한 변경에는 항상 예상되는 시스템 동작을 확인하기 위해 전체 회귀 테스트가 수반되어야합니다.

Andy의 답변에 표시된대로 성능을 테스트하십시오.

많은 조직에서 캐싱 (및 성능)을 구현하는 데있어 가장 큰 장애물은 실제로 다양한 실제로드 및 성능 테스트를 위해 우수한 성능 테스트를 수행하고 테스트를 실행할 수있는 환경이 있다는 것입니다.

이를 위해서는 가능한 한 밀접하게하고 비용을 허용 하는 성능 테스트 환경을 설정하여 프로덕션을 미러링해야합니다. 이는 현재 개발 환경이 아닐 수 있으며, 빠른 응용 프로그램 개발을 위해 더 작고 독립적이어야합니다. 개발 환경은 캐싱을 덜 사용하는 경향이 있으므로 성능 테스트를 위해 프로덕션을 잘 대표하지 않습니다.

성능 테스트 환경에서 앱은 프로덕션 '모드'에서 실행 중이어야합니다. 프로덕션 환경 인 경우 하나 이상의 서버, 프로덕션 환경에 대한 데이터베이스 연결 풀 및 캐싱 등을 설정해야합니다.

또한로드 테스트에 도움이되는 도구를 고려해야합니다.
jmeter는 매우 비우호적이며 기본적으로 사용하기는하지만 매우 인기가 있습니다.
내가 사용한 또 다른 경로 curl는 루비 스크립트로 URL을 URL 로 보내는 것입니다.

확실하게

• 기본 성능 테스트는 한 번의 요청으로 시간을 테스트하기위한 것입니다.
• 로드 테스트는 성능 테스트와 비슷하지만 시스템이 다른 요청에서로드 될 때 응답을 확인합니다.

다음 링크가 도움이 될 수도 있습니다.

• 캐시를 많이 사용하는 단위 테스트 방법에 대한 모범 사례?
• 캐시에 대한로드 테스트 방법
• 로드시 사이트의 성능을 테스트하는 방법이 있습니까?
• http://www.procata.com/cachetest/

테스터에게 서버를 재부팅하고 입력 한 데이터가 여전히 있는지 확인하도록하십시오. 수개월 간의 테스트를 거친 시스템을 보았습니다.

테스트하기 가장 어려운 부분은 데이터가 업데이트되지만 캐시에서 오래된 결과가 반환 되지 않는다는 것입니다 .

이는 캐시에있는 데이터를 항상 사용하여 사용자가 변경 한 후 확인 페이지를 채우면 부분적으로 도움이 될 수 있습니다. 예를 들어 데이터베이스를 업데이트하는 데 사용한 개체를 사용하지 말고 캐시에서 데이터를 요청한 다음 데이터베이스에서 요청하십시오. 조금 느리지 만 버그가 더 빨리 나타날 가능성이 훨씬 높습니다.

이것은 실제로 매우 간단한 대답을 가지고 있으며 캐싱 수준과 관련이 있습니다. 캐싱이 올 바르면 관찰 할 것은 요청 대상에 요청이 없다는 것입니다. 따라서 이는 "예상 된 결과"라는 해킹 된 QA 문구로 귀결됩니다.

웹 계층에서 캐시를 구현하는 경우 캐싱 대상 항목은 테스트 된 각 사용자 세션 (클라이언트 캐시를 구현하는 경우) 또는 여러 사용자 (CDN 스타일 캐시를 구현하는 경우)마다 한 번만 표시 될 것으로 예상됩니다. 일반적인 결과를 위해 데이터 계층에서 캐시를 구현하는 경우 데이터 계층의 프로필 로그에 쿼리가없는 상태에서 캐싱 계층의 캐시 적중률이 높을 것으로 예상됩니다.

기타...

프로그래머, 아마도 코드를 작성한 사람이 단위 테스트를 사용하여 테스트하는 것이 더 좋습니다. 캐싱 코드의 정확성을 테스트하는 것이 그 중 하나입니다. (이 질문을하는 방식에서 QA 담당자는 애플리케이션을 "블랙 박스"로 취급하고 외부 인터페이스를 통해 테스트한다고 가정합니다.)

캐싱 로직은 QA가 주로 블랙 박스 테스트를 수행하므로 개발자가 단위 테스트를 수행해야합니다.

QA는 성능 측면 또는 구현 한 모든 수정 사항에만 관심이 있으므로 캐싱을 활성화 / 비활성화하는 메커니즘 또는 성능을 향상시키는 데 사용한 메커니즘을 QA에 제공 한 다음 성능 차이를 확인할 수 있습니다. 물론 QA는 성능 향상 버전과 비교하여 이전 버전을 확인할 수도 있습니다.

캐싱 솔루션을 테스트 할 때 기본적으로 성능을 테스트 한 것을 구현했습니다. 우리는 XML 결과에 대한 캐싱 솔루션을 수행했으며 캐시 후에 응답을 제공하는 데 매우 낮은 시간이 걸립니다. 또한 로그 항목을 확인하여 서버 로그로 확인했습니다.