자체 테스트 팁? [닫은

Question

기본적으로 제한된 기간 동안 다른 사람의 도움을받지 않고 코드가 잘 테스트되도록하는 팁이 있는지 궁금합니다.

과거에는 항상 내 코드에서 테스트 할 다른 사람을 찾거나 전용 품질 보증 팀이 모든 것을 극복하고 모든 오류를 찾았습니다.

나는 보통 꽤 조심하지만 항상 내가 놓친 것들이 있고 테스트 할 때 나는 그들을 보지 못한다.

그러나 현재 직장에서 나는 매우 제한된 시간 내에 작성하기 위해 두 가지 PHP 웹 응용 프로그램을 받았으며, 이것이 좋은 생각이 아니라는 의견에도 불구하고 모든 테스트를 직접 수행해야한다고 들었습니다.

다른 사람이 전에이 문제가 있었는지 궁금하고 통찰력을 제공 할 수 있을까요?

각 영역을 코딩하기 전에 빠른 테스트 계획을 작성하고 테스트를 수행하기 전에 요구 사항을 두 번 확인하는 것이 좋을 것이라고 생각했습니다.

Answer 1

테스트 우선 여부에 관계없이 단위 테스트는 첫 번째 방어선이어야하므로 각 응용 프로그램의 각 작품이 생각하는 방식으로 작동하도록합니다. 그러나 다른 눈을 얻는 데 도움이 될 수있는 테스트 유형은 수락 테스트 영역에 더 많이 있습니다. 적용을 전체 작업 방식으로 수행해야합니다. 다양한 이상한 시나리오 나 행동 등에 효과가 있습니까?

유용한 접근 방식 중 하나는 페르소나를 상상하는 것입니다. 먼저 응용 프로그램을 자신처럼 테스트 한 다음 85 세이고, 몹시 잘 볼 수 없으며, 마우스를 잘 사용하지 않는다고 상상하는 것을 다시 테스트하십시오. 당신이해야 할 일이 아니라고 가정 할 때 가장 밝거나 가장 큰 것을 클릭하는 경향이있을 수 있습니다. 이제 당신이 12 살이고 찢어짐을 상상해보십시오. 당신은 지시를 읽지 않을 것입니다. 여전히 작동합니까?

주어진 필드의 경우 사람이 입력 할 수있는 가장자리 사례는 무엇입니까? 공백 만 입력하면 어떻게됩니까? 텍스트 필드에 숫자 만? HTML을 입력하면 어떻게됩니까? 자바 스크립트? 비 서구 알파벳에 뭔가? 정말로 정말 긴 것을 입력하면 어떻게 되나요?

열쇠는 사용자가 마음에 드는 방식으로 응용 프로그램을 통과하는 "행복한 길"을 테스트하는 것이 아닙니다. 아무도 필요없는 방식으로 신청서를 살펴보십시오. 왜냐하면 ... 그들은 할 것입니다.

다른 중요한 작품은 결코 아무것도 무시하지 않는 것입니다. 이상한 화면이 와서 "아, 그건 그냥 우연 일뿐"이라고 스스로에게 말하는 것은 쉽습니다. 당신은 자신을 알아 차리고 그대로가 아닌 모든 것을 추적해야합니다.

Answer 2

얼마나 많은 테스트를 할 수 있는지에 대한 제약이 항상 있습니다. 제약 내에서는 분명히 테스트를 구성해야합니다. 분명히 가장 중요한 영역에 대한 테스트를 먼저 구축하려고합니다 (보안, 손상 가능성, 데이터 손실, 기능).

기능 사양 이외에도 테스트 할 내용을 결정하는 데 도움이되는 많은 수동 도움말을 얻지 못할 것입니다. 그러나 테스트 커버리지 도구 형태로 자동 도움말을받을 수 있습니다. 이 도구는 테스트 한 코드와 테스트하지 않은 코드를 알려줍니다. 테스트되지 않은 코드를 검사하면 코드가 다소 중요했는지 여부를 결정할 수 있으며, 따라서 릴리스 전에 테스트를 코딩 할 자격이 있습니다. 테스트 커버리지 도구는 또한 테스트 된 코드 대 전체 코드의 비율을 알려주고이 비율이 70% 이상인 업계 모범 사례를 알려줍니다. 이 데이터를 사용하여 간단한 인공물을 통해 상사와 더 많은 시간을 협상 할 수 있습니다. "우리는 15%의 테스트 범위 만 가지고 있습니다.

PHP와 함께 작동하는 테스트 커버리지 도구는 여기에서 찾을 수 있습니다.시맨틱 설계 PHP 테스트 커버리지 도구

Answer 3

TDD가 정확히 당신이 찾고있는 것 같아요. 먼저 테스트를 작성한 다음 테스트를 통과하는 코드를 작성하십시오. 당신은 당신과 다른 사람이 필요하지 않으며 (테스트에 대한 도움이 권장 될 것입니다), 코딩을 시작하기 전에도 도구가 무엇을 해야하는지에 대한 명확한 아이디어를 얻을 수 있습니다.

http://en.wikipedia.org/wiki/test-driven_development

Answer 4

고용주는 테스트가 중요하다고 생각하지 않습니다. 당신은 그만두고 적절한 직업을 찾아야합니다.

Answer 5

나는 그것을 말하는 것을 싫어하지만, 나는 당신의 경우 Alex Tingle이 옳다고 생각합니다. 불가능한 상황입니다.

Jacobm과 Santi는 단위 테스트, 수락 테스트 및 테스트 중심 개발을 언급 할 때 정확합니다. 해당 목록에 코드 적용 범위 및 정적 분석 도구를 추가했습니다.

그러나 TDD 또는 기본 단위 테스트는 일반적으로 테스트 시간 감소, 결함 률 감소 및 유지 보수 용이성으로 보상을받지 않지만 사망시에서 제 시간에 전달하는 데 도움이되지 않습니다. 자동 테스트를 작성하는 데 경험이없는 경우 특히 그렇습니다.

정중하게 표현 된 상사는 기술 부채를 부여하도록 요청하고 있습니다. 정확하게 말하면, 그는 당신에게 전문 윤리를 무시하도록 요구하고 있습니다.

미소, "예 선생님"이라고 말하십시오. 할당 된 시간에 최선을 다하고 이력서를 업데이트하십시오.

Answer 6

명심해야 할 한 가지는 개발자가 코드의 "최고의 경로"를 테스트하는 자연스러운 경향이 있다는 것입니다. 다시 말해, 당신은 그것을 썼으므로 특정 지점을 클릭하고 특정 것을 입력하고 테스트해야한다는 것을 알고 있습니다. 물론 이것은 중요합니다.

여기에는 몇 가지 좋은 제안이 있지만, 대부분 (전부는 아님)에 의해 놓친 것처럼 보이는 것은 부정적인 테스트입니다. 기본적으로 경계를 테스트해야하며 악의를 테스트해야합니다. 언급 한 바와 같이, 다음과 같은 필드에 스크립트 코드를 넣으십시오.

<script>alert('abc')</script>

경고를 받으면 올바르게 인코딩하지 못했다는 것이 분명해집니다! 또 다른 일은 다음과 같습니다.

abc' or 'a' = 'a'

이는 인증과 같은 것들에서 SQL 주입 문제를 잠재적으로 보여줄 것입니다. 다음과 같은 것들로 SQL 주입을 테스트 할 수도 있습니다.

abc'; drop table users; select * from dual where 'a' = '

테이블이 방금 사라지면 문제가 있습니다! 많은 예가 있지만 최소한 OWASP Top 10을 테스트하는 데 시간을 보내야합니다.

테스트하려는 다른 장소는 매우 많은 숫자와 같은 것들입니다. 특히 32 비트 플랫폼, 음수 값, 값이없는 정수 입력을 기대할 때 기본적으로 원하는 흐름이 작동하는 것을 테스트 한 다음 해당 할 수있는 모든 작업을 수행합니다. .

Answer 7

테스트 중심 개발 및 단위 테스트의 가치와 효과에 게시 된 이전 답변에 동의합니다. 올바르게 수행하면 생산/전달 가능한 코드를 작성하기 전에 단위 테스트를 작성하는 TDD 프로세스는 초점을 유지하고 설계 및 인터페이스를 검증하는 데 도움이됩니다. 또한 다른 개발자는 매우 간단한 방식으로 코드를 사용하고 소비하는 방법에 대한 명확하고 일관된 방법을 가질 수 있습니다. 단위 테스트는 동일하지 않으며 전체 통합 테스트를 대신 할 수 없습니다. 이 접근법에서는 여전히 전체 통합 테스트 계획을 작성해야 할 수도 있습니다.

나는 .NET에서 Primarliy를 일하며 Nunit과 함께 일하는 데 좋은 결과를 얻지 못했습니다.

나는 전에 PHP에서 일한 적이 없지만 내가 본 것에서 당신은 고려하고 싶을 것입니다. 단순합니다 또는 phpunit.

Answer 8

상사의 요구 사항을 감안할 때, 당신이 그를 위해 일하는 동안 존중 해야하는 것과 마음을 바꿀 수있을 때까지, 당신은 질문에 정답을주었습니다.