사전 제작 테스트가 효과적입니까?

고객에게 하나의 제안(단 하나의 요청!)을 제안할 수 있다면, 응용 프로그램을 프로덕션에 넣기 전에 응용 프로그램의 새로운 릴리스에 대한 스트레스 테스트를 수행해야 합니다. 최근에 는 고객이 모든 기능 테스트를 통과했지만 생산 부하를 처리할 수 없기 때문에 생산에 배치된 직후 실패한 응용 프로그램을 배포한 여러 가지 상황에 관여했습니다.

당신이 이해 확신으로, 소프트웨어는 예측할 수 있고 테스트하기 어려울 수 있습니다. 프로그램이 초당 10트랜잭션에서 작동한다는 것을 아는 것은 초당 100트랜잭션에서 작동한다는 것을 아는 것과 는 다가 아닙니다. 10개의 가상 회로와 함께 작동한다는 것을 아는 것은 1000개의 가상 회로와 함께 작동한다는 것을 아는 것과 는 다이에 가 없습니다. 내가 본 각 경우에, 프로그램은 실험실 이나 테스트 환경에서 잘 작동, 하지만 일부 기본 소프트웨어 결함 또는 용량 제한으로 인해 생산에 비참 하 게 실패. 일반적으로 참여하면 응용 프로그램이 아닌 VOS 내에 제한이 있었지만 어디에 있든 고객에게 미치는 영향은 동일합니다. 응용 프로그램이 프로덕션 환경에서 작동하는지 알고 싶다면 프로덕션 환경에서 작동하는 것처럼 테스트해야 합니다.

나는 당신이 생산에서와 같은 한계에 소프트웨어를 테스트 할 수없는 이유를 수년에 걸쳐 많은 변명을 들었습니다. 나는 그들 중 누구도 믿지 않는다. 프로덕션 데이터 스트림및 파일을 캡처하여 테스트할 수 있습니다. 합성 테스트 생성기를 조작하여 양호하고 나쁜 입력을 시뮬레이션할 수 있습니다. 고속 데이터 스트림을 서버에 공급하기 위해 장치에 민감한 인터페이스 코드를 우회할 수 있습니다. 테스트 모드에서 100%를 작업할 수 없더라도 응용 프로그램의 90%를 평평하게 작동하도록 끌어낼 수 있는 많은 트릭이 있습니다. 문제를 프로덕션 시뮬레이션으로 생각하지 말고 가능한 한 빨리 실행할 수 있는 코드를 최대한 많이 얻는 것으로 생각하기 시작합니다. 시스템을 100% CPU 사용률로 유도해야 합니다. "흥미로운" 문제가 나타나는 경향이 있는 곳입니다.

응용 프로그램 소프트웨어를 한계까지 행사함으로써 VOS도 행사하고 있습니다. 프로덕션이 아닌 랩에서 용량 문제를 발견할 수 있습니다. 용량 제한이 무엇이고 어디에 있는지 알 수 있습니다. 응용 프로그램 배포가 성공할 것이라는 훨씬 더 높은 신뢰도로 테스트 단계를 종료합니다. 당신은 당신의 상사와 고객을 행복하게 유지합니다. 그런 좋은 이유가 아닌가요?