부하 테스트에는 학습 곡선이 가파른 복잡한 도구가 포함되는 경우가 많으며, 부하를 구동하기 위해 수천 달러의 비용과 하드웨어에 대한 막대한 투자가 필요할 수 있습니다. 나는 적어도 부하 테스트를 시작할 때 이러한 문제를 피하는 방법을 배웠습니다.
나는 내 접근 방식을 “탐색적 부하 테스트”라고 부르고 싶습니다. 탐색적 테스트에 대해 작성된 대부분의 내용은 간단한 기능 테스트 영역에 속하지만 부하 테스트에도 동일한 개념이 적용될 수 있습니다. 마무리하기 위해 민첩한 자동화 관행을 적용합니다. 모든 기능을 갖춘 상용 또는 오픈 소스 부하 테스트 도구 중 하나를 사용하여 탐색적 부하 테스트를 수행할 수 있지만 사용 가능한 오픈 소스 프로그래밍 라이브러리를 사용하여 범용 스크립팅 언어로 평가를 작성할 때 더 효과적이라는 것을 알았습니다. 이것이 제가 여기서 논의할 전략입니다 웹개발.
탐색적 부하 테스트는 조직이 시스템의 성능 요구 사항을 많이 고려하지 않고 통계적 사용 프로필을 개발하지 않은 경우 가장 유용합니다. 나는 보통 소프트웨어의 한계를 찾아달라는 요청을 받고, 경영진은 어떤 한계를 높여야 할지 결정합니다. 내 경험에 따르면 탐색적 부하 테스트는 작업에 필요한 모든 부하 테스트인 경우가 많지만, 제품이 완성된 후에는 보다 정교한 기능을 사용하고 부하 테스트를 수행해야 한다는 것을 깨닫게 될 수도 있습니다.
발가락을 물에 담그기
로드 테스트를 훌륭하게 수행하려면 몇 가지 프로그래밍을 수행해야 합니다. 아직 프로그래머가 아니더라도, 점차적으로 기술을 쌓을 수 있으므로 용기를 가지십시오. 한 프로젝트에서는 P2P 네트워킹을 수행하는 애플리케이션을 로드 테스트해야 했습니다. 제가 시작할 수 있는 가장 간단한 일은 오래된 정커 컴퓨터를 최대한 많이 가동하고 각 컴퓨터에서 프로그램 인스턴스를 하나씩 실행하는 것이었습니다. 응용 프로그램을 실행하는 4~5대의 컴퓨터는 보다 정교한 로드 평가를 방해할 수 있는 몇 가지 간단한 기능 문제를 흔들기에 충분했습니다.
프로그램의 안정성이 높아짐에 따라 더 많은 인스턴스를 실행해야 했습니다. 저는 개발 팀에 한 대의 컴퓨터에서 두 개 이상의 애플리케이션 인스턴스를 실행할 수 있는 기능을 추가해 달라고 요청했습니다. 경영진은 이러한 노력을 지원했습니다. 왜냐하면 대안은 수십 대의 추가 컴퓨터를 구입하는 것이기 때문입니다. 나는 컴퓨터의 하드웨어 리소스에 따라 각 테스트 컴퓨터에서 5~30개 정도의 프로그램 복사본을 실행할 수 있었고 테스트 랩에서는 총 약 100개의 복사본이 실행되었습니다. 단순히 애플리케이션을 시작하고 시스템에서 서로 만났는지 확인하는 것만으로도 여러 로드 관련 버그를 찾는 데 충분한 테스트였습니다.