소프트웨어 테스트 엔지니어 작업 요약
소프트웨어 품질은 신흥 산업으로서 점점 더 많은 관심을 받고 있습니다. 소프트웨어 테스트에는 많은 결함이 있습니다. 아래에는 소프트웨어 테스팅 엔지니어의 작업 요약이 여러분에게 도움이 되기를 바랍니다.
소프트웨어 테스팅 엔지니어의 작업 요약 1 부
요즘 소프트웨어 테스팅 작업은 기업으로부터 점점 더 많은 관심을 받고 있으며 많은 사람들이 소프트웨어 테스팅 대열에 투자했습니다. 소프트웨어 테스팅 엔지니어의 역할 팀은 점점 더 커지고 있습니다. 하지만 훌륭한 소프트웨어 테스팅 엔지니어가 되려면 어떻게 해야 할까요? 이것은 모두가 더 궁금해하는 질문입니다. 특히 이 업계에 처음 입문한 Lainiao는 이 질문에 대한 답을 알고 싶어합니다. 이 글은 제가 수년간 IT 회사에서 소프트웨어 테스팅을 해온 경험을 바탕으로 모두가 공유할 수 있는 몇 가지 사항을 요약한 것입니다. 또한 여러분 모두가 귀중한 의견과 제안을 제공할 수 있기를 바랍니다.
단계/방법
3년 이상의 소프트웨어 개발 경험
현재 많은 소프트웨어 회사에서는 갓 졸업한 대학생이나 컴퓨터 전공자가 아닌 사람을 채용하고 있습니다. 회사의 소프트웨어 테스팅 엔지니어에게 이것은 매우 잘못된 것이며 소프트웨어 테스팅에 대한 무책임함을 보여줍니다. 소프트웨어에서 일부 오류를 찾을 수는 있지만 소프트웨어에서 치명적이고 치명적이며 위험한 오류를 찾는 것은 어렵습니다. 우리 모두 알고 있듯이 소프트웨어 공학에는 폭포 모델(Waterfall Model)이라는 모델이 있는데, 이는 가장 기본적인 소프트웨어 모델로, 개발이 그릇의 아래쪽에 있고 왼쪽 상단에 있기 때문에 그릇 모델이라고도 합니다. 모델링, 요구사항 분석, 설계 순서대로 오른쪽 상단에는 테스트, 배포 및 유지 관리가 있습니다. 이는 소프트웨어 개발이 모든 소프트웨어 활동의 기초이자 소프트웨어 테스트의 기초임을 의미합니다. 일정 기간 동안 소프트웨어 개발 작업을 경험한 사람만이 풍부한 경험을 쌓을 수 있고 소프트웨어에서 실수하기 쉬운 부분과 어려운 부분을 알 수 있으며 이는 향후 소프트웨어 테스트 작업에 매우 귀중한 경험을 가져다 줄 것입니다.
역으로 생각하는 능력을 가지세요
몇몇 소프트웨어 테스팅 엔지니어를 만난 적이 있습니다. 그들은 한동안 소프트웨어 테스팅을 한 후 다시 개발 작업에 복귀한 이유를 물었습니다. 대답은 소프트웨어 테스팅이 너무 어렵다는 것입니다. 개발은 미래 지향적인 반면, 테스트는 소프트웨어를 운영하기 위해 항상 이상한 아이디어를 찾아야 합니다. 소프트웨어 사용자는 매우 다양하며 소프트웨어를 사용하는 동안 직면하는 다양한 현상도 크게 다릅니다. 따라서 소프트웨어 테스팅 엔지니어는 역 사고 능력을 갖고, 다른 사람이 생각하지 않는 것을 생각하고, 다른 사람이 생각하지 않는 것을 테스트해야 합니다. 소프트웨어에서 더 많은 오류를 찾을 수 있도록 테스트합니다. 이것이 바로 훌륭한 소프트웨어 테스팅 엔지니어가 되기 위한 가장 기본적인 자질입니다.
소프트웨어 개발자와 의사소통을 잘하세요
의사소통은 오늘날의 소프트웨어 프로젝트에서 숙달해야 할 가장 중요한 기술 중 하나입니다. 소프트웨어 테스터는 소프트웨어 개발자와의 소통을 잘해야 한다. 테스터가 개발자의 눈에 띄지 않도록, 이는 전체 소프트웨어 프로젝트의 품질을 향상시키는 데 매우 중요하다. 커뮤니케이션에는 주로 다음이 포함됩니다.
소프트웨어 요구 사항 및 설계 논의: 이러한 커뮤니케이션을 통해 테스트 중인 소프트웨어 시스템을 더 잘 이해할 수 있으므로 소프트웨어에서 가능한 한 적은 오류를 테스트할 수 있습니다. 소프트웨어 개발자에 대한 압박.
좋은 테스트 결과 보고: 테스터로서 오류를 발견하는 것은 테스터가 가장 의욕적이고 자랑스러워하는 결과인 경우가 많지만, 소프트웨어 오류를 맹목적으로 개발자에게 보고하면 품질과 개발이 저하됩니다. 전체 소프트웨어의 진행 상황. 따라서 소프트웨어 테스팅 엔지니어로서 테스트하는 모듈에 심각한 오류가 없거나 오류가 거의 없으면 개발자에게 달려가서 예상치 못한 결과를 가져올 좋은 소식을 알리는 것이 좋습니다.
업무와 관련되지 않은 사항에 대해 토론합니다. 테스터로서 저는 개발자와 업무와 관련되지 않은 사항에 대해 자주 논의합니다. 예를 들어 뉴스, 흥미로운 것, 가족에 대해 이야기할 수 있습니다. 상호 이해를 강화하면 소프트웨어 작업의 품질이 더 향상될 수 있다는 통계가 많이 나와 있습니다.
리더와의 소통에 능숙하다
테스터는 리더의 눈과 귀가 되는 경우가 많다. 리더는 테스터의 테스트 결과를 바탕으로 회사의 제품 품질을 파악하고 기타 사항을 조정할 수 있다. 일하다.
리더는 일반적으로 업무에 바쁘기 때문에 우수한 테스터로서 테스트 결과를 요약하는 방법을 배워야 하며 이를 차트 형태로 리더에게 보여주는 것이 가장 좋습니다.
자동화된 테스트 도구를 익히세요
테스트 작업은 지루하고 지루할 때가 많습니다. 테스터는 오랫동안 반복적인 수동 작업을 수행해야 하므로 테스트 효율성이 떨어지고 종종 테스트 품질에 영향을 미칩니다. 게다가 성능 테스트, 스트레스 테스트 등과 같은 테스트 도구를 사용하지 않으면 많은 테스트를 수행할 수 없다는 점에서 불리합니다. 시중에는 사용할 수 있는 테스트 도구가 많이 있습니다. 필요에 따라 테스트에 도움이 되는 몇 가지 테스트 도구를 선택할 수 있습니다. 그러나 한 가지 기억해야 할 점은 테스트 도구가 있으면 수동 테스트가 필요하지 않다는 것입니다.
잘 배우는 능력
소프트웨어 테스팅 기술도 시간이 지남에 따라 개선되고 향상되었습니다. 훌륭한 테스터라면 책, 웹사이트, 포럼을 잘 활용하고 지속적으로 개선해야 합니다. 커뮤니케이션 등 다양한 채널을 통해 소프트웨어 테스팅 수준.
7
표현력 향상
소프트웨어 테스터가 소프트웨어에서 결함을 발견하면 결함 보고서를 작성해야 하는 경우가 많고, 결함 보고서를 작성해야 합니다. 상세하고 명확하면 개발자가 가능한 한 빨리 오류를 찾아 수정할 수 있으므로 우수한 테스터가 글쓰기 능력을 향상시키는 것은 매우 필요합니다.
8
비즈니스 지식 이해
소프트웨어 테스트에 관해 말씀하신 비즈니스 지식을 더 잘 이해하는 것이 매우 중요합니다. 더 깊고, 더 중요하고, 더 숨겨진 소프트웨어 오류를 찾을 수 있습니다. 따라서 훌륭한 소프트웨어 테스팅 엔지니어로서 귀하는 비즈니스 지식을 향상시키기 위해 해당 분야의 전문가 및 동료로부터 더 많은 것을 배워야 합니다.
위 내용은 단지 개인적인 경험일 뿐입니다. 모두가 훌륭한 소프트웨어 테스팅 엔지니어가 되기를 바랍니다.
소프트웨어 테스트 엔지니어 작업 요약 2부
1. 첫 경험 공유: 교육은 과거를 나타내고 능력은 현재를 나타내며 학습 능력은 미래를 나타냅니다. ?사실 이는 외국교육 분야의 연구결과이다. 나는 수년 또는 10년 이상 일한 친구들이 이 원칙에 대해 어느 정도 경험을 했다고 믿습니다. 하지만 이 점도 매우 중요하다고 생각합니다. 중요한 사실을 너무 늦게 이해하면 평생 후회하게 될 테니, 이제 막 졸업한 친구들이 일찍 볼 수 있도록 글마다 넣어주세요! /p>
2. 자신만의 개발 방향을 결정하고 이를 위해 실행 가능한 계획을 개발하십시오. 아무 말도 하지 마세요. "나 이제 막 졸업했는데 앞으로 뭘 할지 모르겠어", "그냥 기분 따라가서 먼저 해봐". 그러한 관점은 잠재의식을 통해 당신의 행동이 게으르고 평범하다는 것을 암시하기 때문입니다. 항상 기술 분야에 종사하며 미래의 전문가가 되시나요? 경영의 방향으로 나아가 전문 경영인이 되시나요? 먼저 업계와 현장을 숙지하고 미래를 향해 달려가시나요? 그리고 몇 년 안에 다른 일을 하려고 직업을 바꾸나요? 이것은 매우 중요합니다. 앞으로 몇 년 또는 10년 후에 무엇을 할 것인지가 결정될 것입니다. 어떤 것이 옳은 일입니까!?. -
3. 소프트웨어 개발팀에서는 기술이 만능은 아니지만, 기술 없이는 불가능한 일이 없습니다! 기술팀에서는 기술과 인품도 똑같이 중요하며, 물론 외모도 더 중요합니다. 더 많은 mm를 가진 팀에서. 소프트웨어 프로젝트 팀에서 기술 수준은 중요하게 생각하고 존중해야 할 중요한 가중치입니다. 관리, 시스템 분석, 설계, 코딩, 제품 관리, 테스트, 문서화, 구현, 유지 관리 등 무엇을 하든 기술적 기반이 있어야 합니다. 무지하더라도 일반인이 소프트웨어 개발팀을 이끌고 소프트웨어 개발 프로젝트를 성공적으로 완료하는 모습은 한 번도 본 적이 없습니다. 한번은 고학력자(비기술자)가 여러 사람들을 이끌고 프로젝트를 완료하는 것을 본 적이 있습니다. 프로젝트가 전달된 지 이틀 만에 프로젝트 팀원들이 "더 이상 참을 수 없어요!"라고 말했습니다. 각자의 길을 가십시오. 누구나 그 프로젝트의 성공을 상상할 수 있습니다. -
4. 자신만의 소프트웨어 개발 전문지식 학습 계획을 구체적으로 수립하고 시기적절한 수정 및 조정에 주의하세요(소프트웨어 개발 기술은 너무 빨리 변합니다). 명심하십시오: 소프트웨어 개발자가 1~2년 동안 자신의 지식을 업데이트하지 않으면 그는 더 이상 이 업계에 속하지 않습니다. ?시간이 없다고 스스로에게 말하지 마세요.
시간관리 분야의 유명한 '38원칙'은 다음과 같이 경고합니다. 남은 8시간을 어떻게 활용하느냐에 따라 인생의 성공과 실패가 결정됩니다! 졸업한 이후로 하루 평균 실제 공부 시간은 2시간 이상이었습니다. -
5. 책은 특히 소프트웨어 개발자에게 있어 인류 발전의 사다리입니다. 책은 지식을 배우는 가장 효과적인 방법입니다. 직장에서 당신을 가르쳐 줄 "특별한 전문가"를 만날 것이라고 너무 많이 기대하지 마십시오. 책을 사기 위해 돈을 쓰는 것에 관해서, 내 개인적인 경험은: 중국에서 그 사람들에게서 책을 사지 마십시오. 나는 그 사람들에게서 책을 샀을 때 예외 없이 00% 후회했습니다. 더욱 짜증나는 것은 이 책들이 중고시장에서 팔기 어렵다는 점이다. ?책이 있다고 해서 지식이 있는 것이 아니고, 지식이 있다고 해서 기술이 있는 것이 아니고, 기술이 있다고 해서 문화가 있다는 것이 아니고, 지식이 있다고 해서 지혜가 있다는 것이 아닙니다. ?책을 자신의 지혜로 바꿔야 비로소 책을 진정으로 소유할 수 있습니다. -
6. 특정 기술을 가끔 한두 번만 사용하더라도 피상적인 사용에만 국한하지 마세요. ?모든 일에 조심하는 것은 어느 산업의 엔지니어가 가져서는 안 되는 자질입니다. Windows 애플리케이션을 개발하고, Windows 프로그램의 설계, 로딩 및 실행 원리를 살펴보고, PE 파일 형식을 분석하고, SDK 개발을 사용하여 처음부터 Windows 애플리케이션을 개발해 보세요. vc++, delphi, java 등을 사용합니다. NET 애플리케이션 개발을 시작하려면 시간을 내어 mfc, vcl, j2ee 등을 공부하세요. j2ee, jboss, spring, hibernate 및 기타 우수한 오픈 소스 제품 또는 프레임워크를 사용하는 것 외에도 시간을 들여 유사한 문제에 대한 일반적인 솔루션을 추상화, 분석, 설계 및 구현하는 방법을 알아보세요. 이렇게 해보세요. 그러면 앞으로의 작업에서 당신을 불분명하고 혼란스럽게 만드는 문제에 직면하게 될 것입니다. 왜냐하면 당신은 많은 것을 알고 있고 그 이유를 알고 있기 때문입니다.-
7. 언어로 프로그래밍하되, 하지 마십시오 그것이 당신의 생각을 제한하게 하라. "코드 백과사전"에서는 "언어 프로그래밍에 깊이 들어가고 피상적이지 마십시오"라고 말합니다. 프로그래밍 언어의 존재에는 나름의 이유가 있기 때문에 어떤 언어도 모든 질병을 치료할 수 있는 "만병통치약"은 아닙니다. 프로그래밍 언어가 개발자의 아이디어와 특정 문제 해결 방법에 미치는 영향과 제약에 대한 수많은 예가 있습니다. 내 경험은 다음과 같습니다. 특정 핵심 모듈을 개발하기 위해 객체 지향 도구를 사용할 때 왜 c, c51 및 어셈블리의 모듈식 패키징 방법을 배울 수 없습니까? 기존 데스크톱 개발 도구(현재 주로 vc++, delphi)를 사용하여 system 설계할 때 Java 커뮤니티의 IOC 및 AOP 설계 아이디어를 참조하거나 spring, hibernate, jboss 등과 같은 우수한 오픈 소스 프레임워크에서 배울 수 없는 이유는 무엇입니까? 시간통신과 데이터 수집, 왜 실시간 시스템과 임베디드 시스템의 우수한 시스템 프레임워크와 패턴을 인용할 수 없는가? 왜 모든 것은 자연개발 언어에서 개인과 팀의 전통이나 경험을 바탕으로 해결되어야 하는가? -
8. 요약하고 반영하는 습관을 기르고, 일상 업무의 결과를 의식적으로 다듬어 자신만의 개인 소스 코드 라이브러리, 특정 유형의 문제를 해결하기 위한 일반적인 시스템 아키텍처를 형성하고 심지어는 프레임워크. 우리 모두 알고 있듯이, 소프트웨어 개발자에게 경험이 있는 사람과 없는 사람의 중요한 차이점은 경험이 없는 사람은 작업을 완료할 때 처음부터 시작하는 반면, 숙련된 사람은 재사용 가능한 모듈과 클래스 라이브러리 문제를 자체적으로 재구성하여 문제를 해결하는 경우가 많습니다(사실상). , 이 결론은 소프트웨어 개발 분야에만 국한되어서는 안 되며 다양한 측면으로 확장될 수 있습니다. 이는 재사용 가능한 모든 항목을 직접 구현해야 한다는 의미는 아닙니다. 다른 사람의 성숙하고 테스트된 결과도 수집하고 정리하여 자신의 지식 기반에 통합할 수 있습니다. 하지만 지적재산권, 저작권 등에 문제가 없도록 직접 구현하는 것이 가장 좋습니다. 핵심은 직접 구현한 후에 이 지식을 완전히 숙달하고 이 기술을 소유할 수 있는 것입니다. -
9. 이론과 실습을 동등하게 고려하고 내적 측면과 외적 측면을 모두 배양합니다. 엔지니어의 의미는 엔지니어의 관점에서 사물과 세계를 관찰하고 분석하는 것입니다. 소프트웨어 엔지니어란 소프트웨어 제품의 본질과 소프트웨어 제품 개발의 본질(개인의 의견, 토론 환영)을 진정으로 이해하는 사람입니다.
소프트웨어 개발 언어를 마스터하고, 직장에서 특정 문제를 해결하기 위해 언어 도구를 적용하고, 목표 작업을 완료하는 것은 소프트웨어 엔지니어의 주요 작업이지만 소프트웨어 엔지니어의 관점에서는 중요하고 필수적인 작업이 아닙니다. 실제 소프트웨어 엔지니어의 임무는 소프트웨어 제품 개발 및 소프트웨어 개발 방법론에 대한 이론적 지식을 배우고 숙달하며, 소프트웨어 제품 분석, 설계 및 구현 아이디어를 실제로 이해하고 적용하여 특정 소프트웨어 제품 개발 문제를 해결하는 것입니다. 성숙한 이론과 신뢰할 수 있는 방법론의 관점에서 문제를 생각하고 분석하고 해결하고, 이러한 아이디어와 방법을 구체적인 실천에서 검증하고 수정하여 궁극적으로 자신만의 이론 체계와 실천 방법론을 형성합니다.
소프트웨어 테스트 엔지니어 작업 요약 3부
먼저 내 배경을 소개하겠습니다. 저는 2005년에 통신 대학을 졸업하고 컴퓨터 공학 학사 학위를 취득했습니다. 대규모 통신 장비 제조업체로 소프트웨어 테스트 엔지니어로 일하고 있습니다.
1. T 프로젝트 실행
저는 2005년 7월 13일에 부서에 입사했고, 그제서야 테스트 부서에 배정되었다는 사실을 알았습니다. 학과장님께서 저를 데려가신 후, 강사님께 저를 인계하셨습니다.
부서에 입사한 후 처음 며칠 동안은 주로 회사의 업무 환경을 익히고, 부서 동료들과 알아가고, 제품 지식을 이해합니다. 우리는 전송 장비 분야에 종사했기 때문에 당시 배운 제품 지식은 주로 SDH 프레임 구조, 네트워크 보호 및 스위칭 등 SDH 원리를 기반으로 했습니다.
다음은 제가 진행한 프로젝트를 소개합니다.
프로젝트 이름: T Software
프로젝트 개요: 이 프로젝트는 PC 및 Sun 워크스테이션에서 개발된 소프트웨어이며 CS 구조에 속합니다. 클라이언트는 크로스 플랫폼을 달성하기 위해 Java(처음에는 JDK1.3을 사용하고 나중에 JDK1.4로 전환)로 개발되었습니다. 서버는 C++로 개발되었으며 ACE를 사용하여 크로스 플랫폼(Windows 및 Unix)을 달성했습니다.
인력투자 : 개발 9명, 테스트 3명인 것으로 보인다. (제가 여기 왔을 땐 제품의 두 번째 버전이었는데, 인적 투자도 거의 같았어요)
부서에 합류한 지 며칠 뒤 프로젝트 T가 테스트 단계에 들어갔습니다. 내 임무는 나에게 할당된 테스트 케이스를 실행하는 것이다. 당시에는 테스트케이스에 설명된 내용에 따라 마우스를 클릭하는 줄만 알았고, 프로그램에서 오류나 예외를 발견하면 문제표를 작성하곤 했다. 3개월 동안 아무 생각 없이 테스트 케이스에 마우스만 댔습니다. )
원래 테스트 작업을 생각해보면 정말 부족한 점과 개선할 부분이 너무 많습니다.
1www.wjrdkj.com|www.512jjw.com|www.512zx.net|www.ntzlwj.com, 테스트 사례. 소프트웨어 테스팅의 경우 테스트 케이스가 중요합니다. 테스트 케이스는 모든 테스트 사양을 포괄해야 하며, 테스트 케이스는 쉽게 설명하고 실행하기 쉬워야 합니다. 당시 우리의 테스트 케이스는 엉망이었습니다. 가장 나쁜 점은 이러한 테스트 케이스를 사용하면 제품 품질이 보장되지 않는다는 것입니다. 테스트 케이스의 사전 설정 조건, 작동 단계, 예상 결과에 대한 설명도 지저분하고, 테스트 케이스를 저장하는 데 사용되는 엑셀 테이블의 설계가 부실하고 인터페이스가 친숙하지 않아 테스트 효율성이 어느 정도 떨어집니다.
2. 제품 지식. T 소프트웨어는 PC와 워크스테이션에서 실행되지만 T 소프트웨어 개발의 목적은 제품을 제공하는 것이므로 T 소프트웨어를 더 잘 테스트하려면 제품 지식이 있어야 합니다. 당시에는 멘토를 포함해 3명이 제품에 대해 잘 알지 못해서 일부 테스트 케이스가 검증을 통과했는지 판단할 수 없었던 상황이 발생했습니다. 이로 인해 개발자들과 많은 논쟁이 벌어졌습니다.
3. 소프트웨어 테스팅의 초점이 명확하지 않습니다. 소프트웨어 테스팅은 소프트웨어 엔지니어링에서 중요한 활동으로, 프로그램의 결함을 찾아내고 프로그램의 품질을 보장합니다. 하지만 소프트웨어는 상용 제품이기 때문에 출시 기간이 정해져 있습니다. 1월까지는 소프트웨어를 테스트한 뒤 출시할 수 있다고 사장님이 말씀하셨습니다. 당시 우리는 몇 가지 사소한 문제에 대해 개발자들과 너무 많이 고심했지만 많은 핵심 사항이 고려되지 않았습니다. 일부 심각한 문제가 상대적으로 늦게 노출되어 테스트 시간이 계속 지연되고 한 버전을 테스트했습니다. 그 시절을 생각하면 그냥 "피곤하고 괴롭다"고 표현할 수 있겠네요. : (
4. 테스트 프로세스를 마스터하세요.
7월 중순, T 프로젝트가 개발부서에서 테스트부서로 이관되어 테스트 단계에 돌입했다. 실제로 당시 제품 품질은 이전 테스트 기준을 충족하지 못했지만 이전을 통과할 수 있도록 허용했다. 테스트를 했고 그 결과는 우리에게 엄청난 고통을 안겨주었습니다. 그리고 후속 버전에서도 마찬가지였습니다. 우리는 계속해서 테스트했고 거의 필사적이었습니다. 돌이켜보면 T 소프트웨어는 실제로 개발 및 작성된 것이 아니라 우리가 테스트한 것이었습니다. )