매우 큰 응용 프로그램을 테스트하는 방법


10

매우 큰 PHP 앱이 있습니다. 보통 2-3 명의 개발자가 풀 타임으로 일하고 있으며 우리는 변경을하고 버그를 만드는 시점에 도달하고 있습니다 (기침 기능!). 소프트웨어는 복잡하지 않고 단지 많은 일이 일어나고 있습니다 (35 ~ 컨트롤러, 동일한 모델 등).

주의를 기울여도이 뷰의 변경 (요소에서 ID를 트위 킹)이 특정 조건 (한 발에 서있는 동안 로그 아웃 됨)에서 발생하는 아약스 쿼리를 망칠 수 있습니다.

단위 테스트는 가장 먼저 떠오르는 것이지만 다른 앱에서 시도해 보았으므로 잊어 버리거나 테스트를 작성하고 테스트를 작성하는 데 더 많은 시간을 소비합니다. 라이브를 시작하기 전에 코드를 확인하는 준비 환경이 있습니다.

시간제 Q / A 담당자가 필요할까요?

누구나 어떤 제안이나 생각이 있습니다.


"... 그 다음에 테스트 하는 것"은 그 이상 이었습니다 .
ajax333221

답변:


25

예, Q / A 직원이 필요합니다. 많은 이유 중 일부는 다음과 같습니다.

  • 전용 테스터는 비용이 들지만 개발자보다 비용이 적게 들기 때문에 시간을 낭비하지 않으면 추가 비용보다 큰 이점이 있습니다.
  • 전담 테스터는 사물을 테스트하는 방법, 특히 자동화 방법이 명확하지 않은 사항을 알고 있습니다. 브라우저를 통해 시스템과의 상호 작용을위한 자동 테스트를 수행하는 것은 다소 털이 있지만 잘 정립 된 분야입니다. 방법을 이미 알고있는 사람이 있으면 더 좋은 도구와 설정을 배우는 데 더 많은 시간을 소비 할 필요가 없습니다.
  • 전문 테스터는 실제로 결함을 찾는 방법을 알고 있습니다. 그들은 응용 프로그램의 사용자가 생각하는 것처럼 생각할 가능성이 훨씬 높으므로 실제로 프로덕션 환경에서 나타날 시스템의 상태를 실행합니다. 즉, 눈에 잘 띄는 버그가 더 일찍 발견되는 경향이 있음을 의미합니다 매우 긴급한 패치에 대한 당황과 비용을 절약합니다.
  • 그것을 일반화하면 테스터 는 개발자처럼 생각하지 않습니다 . 당신이 그것을 경험하지 않으면 얼마나 큰 차이를 전달하는 것은 어렵습니다. 의식적으로 또는 아닙니다, 개발자는 결함을 찾고 싶지 않습니다 . 그들은 시스템이 어떻게 작동하는지 알고 있으며 실제 비논리적 인 입력이나 실제 생활에서 문제를 일으키는 데이터를 피하는 경향이 있습니다. 무언가가 예상치 못한 방식으로 작동하면 문제를 해결하는 방법을 알고 있으며이를 결함으로 보지 않는 경향이 있습니다. 그들은 결코거의 모든 실제 시스템에서 문제의 주요 원인이지만 시스템 응답이 무엇을 의미하는지 이해하기가 어렵습니다. 요컨대, 프로그래머는 고도로 훈련 된 전문가이기 때문에 사용자가 가지고있는 일반적인 문제를 겪는 경향이 있습니다. 테스터는 가장 관련성이 높은 테스트를 수행하는 데 훨씬 쉬운 시간이 있습니다.

즉, 지붕을 통해 시스템 품질을 높이기 위해 개발자와 테스터 간의 생산적인 협력을 능가하는 것은 없습니다. 개발자는 종종 테스터가하기 전에 무언가 잘못되었다는 증상을 발견합니다. 개발자는 종종 테스터에게 문제를 훨씬 더 효율적으로 재현하는 방법과 적절한 문제 보고서를 작성하는 방법 (예 : 실제로 문제를 파악하는 데 필요한 세부 정보 포함)을 조언 할 수 있습니다. 그러나이 모든 것에는 적어도 하나의 테스터가 필요합니다.


3
+1. 우리는 일반 사용자들이 겪고있는 문제를 감지 할 수 있도록 고도로 훈련을 받았습니다
superM

3

아마도 더 많거나 더 나은 회귀 테스트가 필요합니다 (특히 단위 테스트 아님). 어떤 종류의 테스트를 수행해야하는지 스스로 분석해야하지만 사용자가 말하는 버그를 감지해야합니다. 테스트 계획을 세우고 테스트 우선 순위를 정하는 것이 좋습니다. 이렇게하면 처음에는 테스트 자동화에 대해 너무 많이 생각하지 않습니다.

그런 다음 합리적인 노력으로 일부 또는 대부분의 테스트를 자동화 할 수 있는지 자문 해보십시오. 대답이 예이면 프로그래밍해야합니다. 대답이 "아니오"이고 "시간제 Q / A 사람"이 더 저렴하다고 생각되면, 필요한 것이어야합니다. 대부분의 경우 수동 테스트 및 새로운 테스트 발명을 담당하는 Q / A 담당자 및 많은 자동 회귀 테스트를 모두 보유하는 것이 좋습니다.


회귀 테스트를 언급하고 단위 테스트가 유일한 효과적인 솔루션이 아니라는 점을 지적하면 +1입니다.
Giorgio

안녕하세요, 회귀 테스트에 대해 좀 더 자세히 설명해 주시겠습니까? 나는 이것이 오래된 버그가 다시 발생하는 것을 막는 것이라고 생각하지만 방법을 사용하면이 작업을 수행 할 것을 제안합니까? 단위 테스트? 점검 할 것들의 '체크리스트'? 감사합니다 :)
Wizzard

@Wizzard : 회귀 테스트라는 용어는 기존의 작동중인 기능에 대한 모든 종류의 테스트에 대한 일반적인 용어 일뿐입니다 (앱을 변경할 때이를 방지하지 못함). 여기에는 검사 목록의 테스트, 프런트 엔드 (여기서는 브라우저)를 통한 자동 테스트 및 단위 테스트가 포함됩니다. 내 제안은 먼저 무엇 을 테스트 할지 , 어떻게 테스트 할 것인지에 대해 먼저 생각해야한다는 것 입니다 (예를 들어 "우리는 단위 테스트를 시도했습니다"라고 말하면 이미 "무엇"이 아니라 "어떻게"에 있는지) .
Doc Brown

2

전문적인 QA를 고용하십시오

상용 프로젝트를 개발하는 경우이 작업을 수행해야합니다. 강력한 테스트 전략없이 제품을 준비하면 버그를 수정하면 비용이 더 많이 듭니다. 또한 신규 고객 확보 또는 유지는 응용 프로그램의 테스트 성능에 달려 있습니다.

일반적으로 말하기 단위 테스트는 코드베이스에 적용해야하지만 통합 테스트 및 수동 테스트는 버려서는 안됩니다.


1

단위 테스트는 특히 좋은 프로젝트입니다. 특히 프로젝트가 성장하는 경우에 좋습니다. 작문 단위 테스트를 작성하는 것이 습관이되면 작업이 훨씬 쉬워집니다. YouTube에서 깔끔한 코드 작성에 대한 비디오 가 있으며 유지 관리 및 테스트가 더 쉽습니다.

품질 관리 엔지니어도 필수입니다. 좋은 QA 테스터는 기능상의 버그를 발견 할뿐만 아니라 앱이 사용자에게 친숙한 지 테스트 할 것입니다 (자신이 테스트하기가 거의 불가능 함). 다음 은 QA 팀이 시간과 비용을 절약하고 더 나은 소프트웨어를 제공하는 방법을 설명하는 좋은 기사입니다.


1

15 개의 컨트롤러와 모델은 그리 크지 않습니다. 쓰기 시험을 습관화하는 데 약간의 시간이 걸리며, (친숙한 방법으로) 서로를 향해 차는 것이 많은 도움이됩니다.

테스트 범위를 어느 정도 연장 할 수있는 도구가 있습니다. PHP 용 코드 커버리지 도구


1
죄송합니다. 35 개의 컨트롤러와 같은 수의 모델이 있습니다. 음, 어떤 형태의 단위 테스트가 도움이 될 것 같습니다.
Wizzard
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.