Software V&V

Test coverage of code is accomplished by which of the following?

=> 

Path testing until all control flow paths have been exercised.

모든 제어 흐름 경로가 실행될 때까지 경로 테스트.

the strategy in path testing is to execute all possible control flow paths, or at least all entry/exit paths through the program. The strategy in branch testing is to execute tests to ensure that every branch alternative has been exercised. The strategy in predicate testing is explore all possible combinatinos or truth values in the program.

경로 테스트의 전략은 가능한 모든 제어 흐름 경로 또는 적어도 프로그램을 통한 모든 입 / 출력 경로를 실행하는 것입니다. 지점 테스트의 전략은 모든 지점 대안이 실행되었는지 확인하기위한 테스트를 실행하는 것입니다. 조건부 테스트의 전략은 프로그램에서 가능한 모든 조합 또는 진리 값을 탐색하는 것입니다.

"Data-flow testing" is used to fill gaps in path and branch testing, but not test all sequences of events related to data objects.

"데이터 흐름 테스트"는 경로 및 분기 테스트의 갭을 메우기 위해 사용되지만 데이터 객체와 관련된 모든 이벤트 시퀀스를 테스트하는 것은 아닙니다.

Test cases do not contain set-up instructions; however, they do contain constraints on test procedures and may be used in more than one test procedure.

Function coverage matrices are usually not found in test procedures.

테스트 사례에는 설정 지침이 포함되어 있지 않습니다. 그러나 시험 절차에 대한 제약이 있으며 둘 이상의 시험 절차에 사용될 수있다.

함수 커버리지 행렬은 일반적으로 테스트 절차에서 찾을 수 없습니다.

중재자, 리더가 있어야 inspection: moderator(leader), reader(facilitator), recorder(scribe), inspector(reviewer), author(owner)

walthrough 는 일반적으로 producer에 의해 leading된다. presenter가 test case의 개요나 ㅅㄷㄴㅅㅊㅁㄴㄷㄴemfdmf 

software review는 leader, recorder, team member로 구성된다.

inspection objectives include finding defects and deviations from specifications and standards, and collecting defect and effort data.

Inspection entry criteria : product and documentation readiness , 

              exit criteria:  resolution of all defect and other project specific criteria.

Inspection techniques and methods: formal structure, use of checklists and standards, inspector preparation, focus on identifying problems, participation by technical personnel only, and inspection data use to monitor effectiveness and manage quality. 

Participant roles : moderator, reader, recorder, inspector, and author.

검사 목적은 규격 및 표준으로부터의 결함 및 편차를 발견하고 결함 및 노력 데이터를 수집하는 것을 포함합니다.

검사 항목 기준에는 제품 및 문서 준비가 포함되며 종료 기준에는 모든 결함 및 기타 프로젝트 별 기준의 해결이 포함됩니다.

검사 기법 및 방법에는 형식 구조, 검사 목록 및 표준 사용, 검사자 준비, 문제 식별에 초점, 기술자 만의 참여 및 효율성을 모니터링하고 품질을 관리하기위한 검사 데이터 사용이 포함됩니다. 참가자 역할에는 사회자, 리더, 레코더, 관리자 및 작성자가 포함됩니다.

Walkthrough

one method used to identify software element defects, in which a presenter provides an overview or test cases of the software element is called a: 

발표자가 소프트웨어 요소의 개요 또는 테스트 사례를 제공하는 소프트웨어 요소 결함을 식별하는 데 사용되는 한 가지 방법은 다음과 같습니다.

The most important aspect of test management is:

Test management involves management of testing schedules more than any other test management activity. 

Test scheduling requires identification and effort estimation for all testing tasks that should be performed, and selection of testing tasks that will be performed. 

Other factors are used to develop testing estimates and to manage testing tasks that are scheduled.

테스트 관리의 가장 중요한 측면은 다음과 같습니다.

테스트 관리에는 다른 테스트 관리 활동보다 테스트 일정을 관리하는 것이 포함됩니다.

테스트 스케줄링은 수행되어야하는 모든 테스트 작업에 대한 식별 및 노력 추정과 수행 될 테스트 작업의 선택이 필요합니다.

테스트 추정을 개발하고 예정된 테스트 작업을 관리하기 위해 다른 요소가 사용됩니다.

Worst-case testing

Worst-case testing can be described as: testing error handling at boundary or extreme values

최악의 테스트는 다음과 같이 설명 할 수 있습니다. 경계 또는 극한값에서의 오류 처리 테스트

Test tools automate test analysis, test execution, and test design processes.

Test libraries are used to manage test documentation and data. Test driver simulate calling unit, modules, or the entire system, while test stubs simulate called unit or sub-modules.  An environment test driver can provide test case initialization, input simulation, output comparison, and other test support capabilities.

테스트 도구는 테스트 분석, 테스트 실행 및 테스트 디자인 프로세스를 자동화합니다.

테스트 라이브러리는 테스트 문서 및 데이터를 관리하는 데 사용됩니다. 테스트 드라이버는 호출 단위, 모듈 또는 전체 시스템을 시뮬레이션하고 테스트 스텁은 호출 된 유닛 또는 하위 모듈을 시뮬레이트합니다. 환경 테스트 드라이버는 테스트 케이스 초기화, 입력 시뮬레이션, 출력 비교 및 기타 테스트 지원 기능을 제공 할 수 있습니다.

Test tools automate test analysis, test execution, and test design processes.

Test libraries are used to manage test documentation and data. Test driver simulate calling unit, modules, or the entire system, while test stubs simulate called unit or sub-modules.  An environment test driver can provide test case initialization, input simulation, output comparison, and other test support capabilities.

Code or Document walk-through's first objectives : To find defects, To find omissions and contractions, To improve software elements; and considering alternative solutions.

second objective: To improve the management system.

코드 또는 문서 워크 아웃의 첫 번째 목표 : 결함을 찾으려면 생략 및 수축을 찾으려면 소프트웨어 요소를 개선하십시오. 대체 솔루션을 고려해야합니다.

두 번째 목표 : 경영 시스템 개선.

formal inspections are primarily bug-prevention methods where software requirements, design, code, or other products are examined by a person or group other than the author to detect faults, violations of development standards, and other problems. 

공식 검사는 소프트웨어 요구 사항, 설계, 코드 또는 기타 제품이 결함, 개발 표준 위반 및 기타 문제를 발견하기 위해 작성자 이외의 사람이나 그룹에 의해 손상되는 버그 예방 방법입니다.

The moderator is the chief planner, the reader leads the inspection team through the software elements, and the inspector identifies and describes defects.

the individual responsible for documenting defects and inspection data is called the recorder.

Moderator는 수석 플래너이며, 

Reader는 소프트웨어 요소를 통해 검사 팀을 이끌고 

Inspector는 결함을 식별하고 설명합니다.

Recorder는 결함 및 검사 데이터를 기록하는 책임이있는 사람입니다

Acceptance testing is performed to verify that the software product conforms to specification. Specifications typically do not require the system to be heavily loaded (stress testing) or be subject to large volumes of data (volume testing).

Additionally, beta testing, which is performed at the user's site, is an alternative to acceptance testing and is most frequently used when several customers are involved.

Acceptance Testing은 소프트웨어 제품이 사양을 준수하는지 확인하기 위해 수행됩니다. 사양은 일반적으로 시스템에 과부하 (스트레스 테스트) 또는 대량의 데이터 (볼륨 테스트)가 요구되지 않습니다.

또한 사용자 사이트에서 수행되는 베타 테스트는 수락 테스트의 대안이며 여러 고객이 참여할 때 가장 자주 사용됩니다.

formal inspections are primarily bug-prevention methods where software requirements, design, code, or other products are examined by a person or group other than the author to detect faults, violations of development standards, and other problems.

공식 검사는 주로 소프트웨어 요구 사항, 디자인, 코드 또는 기타 제품을 결함이 발견 된 개발자 나 다른 그룹이 검토하여 개발 표준 위반 및 기타 문제를 발견하는 버그 예방 방법입니다.

The V&V plan and defect removal procedure may be included in the packages, but add little value. The package should contain results. The test logs and problem reports are critical documents to show the results of the testing effort.

테스트 문서 패키지는 프로젝트 관리자, 품질 보증, 규제 기관 (해당되는 경우) 및 고객에게 테스트가 계획적이고 체계적인 방식으로 완료되었음을 객관적으로 입증합니다....

=> The test documentation package provides objective evidence for the project manager, quality assurance, regulatory agencies (if applicable), and the customer that the test was completed in a planed and systematic way.

"테스트 문서 패키지는 프로젝트 관리자, 품질 보증, 규제 기관 (해당되는 경우) 및 고객에게 테스트가 계획적이고 체계적인 방식으로 완료되었음을 객관적으로 입증합니다.

V & V 계획 및 결함 제거 절차가 패키지에 포함될 수 있지만 가치는 거의 없습니다. 패키지에 결과가 있어야합니다. 테스트 로그 및 문제점 보고서는 테스트 노력의 결과를 보여주는 중요한 문서입니다...."

A test documentation package would be considered incomplete if which of the following items were not included?

"다음 항목 중 어느 것이 포함되어 있지 않으면 테스트 문서 패키지가 불완전한 것으로 간주됩니까?

테스트 문서 패키지는 프로젝트 관리자, 품질 보증, 규제 기관 (해당되는 경우) 및 고객에게 테스트가 계획적이고 체계적인 방식으로 완료되었음을 객관적으로 입증합니다.

V & V 계획 및 결함 제거 절차가 패키지에 포함될 수 있지만 가치는 거의 없습니다. 패키지에 결과가 있어야합니다. 테스트 로그 및 문제점 보고서는 테스트 노력의 결과를 보여주는 중요한 문서입니다...."

The acceptance test plan is a key document in detailing how the developer will demonstrate that the software product meets user requirements.

시스템 및 통합 테스트는 개발자 또는 개발자가 수행하며 공식적으로 사용자를 포함하지 않습니다. 소프트웨어 V & V 보고서는 테스트의 세부 사항이 아니라 테스트 결과를 제공합니다....

System and integration testing are done by the developer or for the developer and do not formally involve the user. The software V & V report presents the results of testing, not the details of the test.

시스템 및 통합 테스트는 개발자 또는 개발자가 수행하며 공식적으로 사용자를 포함하지 않습니다. 소프트웨어 V & V 보고서는 테스트의 세부 사항이 아니라 테스트 결과를 제공합니다. 수락 테스트 계획은 개발자가 소프트웨어 제품이 사용자 요구 사항을 충족시키는 것을 보여줄 방법을 자세히 설명하는 주요 문서입니다....

The document that details the tests to be carried out, the expected results , and is formally agreed to by the developer and the user, is know as the: Acceptance Test Plan.

"수행 할 테스트와 예상 결과 및 개발자와 사용자가 정식으로 동의 한 문서는 수락 테스트 플랜으로 알려져 있습니다.

시스템 및 통합 테스트는 개발자 또는 개발자가 수행하며 공식적으로 사용자를 포함하지 않습니다. 소프트웨어 V & V 보고서는 테스트의 세부 사항이 아니라 테스트 결과를 제공합니다. 수락 테스트 계획은 개발자가 소프트웨어 제품이 사용자 요구 사항을 충족시키는 것을 보여줄 방법을 자세히 설명하는 주요 문서입니다...."

"Which of the following is a major concern of testing?

=> Has a check for errors of logic been accomplished?"

"다음 중 테스트의 주된 관심사는?

=> 논리 오류에 대한 검사가 완료 되었습니까?"

Additional elements are shown in the CSQE Primer. The name of the code writer, estimated hours to correct, and financial impact on the organization, would not normally be included in the defect report.

결함 보고서는 번호가 매겨지고, 간단하고, 이해 가능하고, 재현 가능하고, 읽기 쉽고 비판적이어야합니다. 문제점 보고서 양식에 기록 된 결함 정보에는 영향을받는 프로그램, 버전, 문제점 심각도, 문제점 요약 및 기능 영역이 있습니다....

The defect report should be numbered, simple, understandable, reproducible, legible, and non-judgmental. Defect information recorded on a problem report form includes the following elements: program affected, version, problem severity, problem summary, and function area.

결함 보고서는 번호가 매겨지고, 간단하고, 이해 가능하고, 재현 가능하고, 읽기 쉽고 비판적이어야합니다. 문제점 보고서 양식에 기록 된 결함 정보에는 영향을받는 프로그램, 버전, 문제점 심각도, 문제점 요약 및 기능 영역이 있습니다. 추가 요소는 CSQE 입문서에 나와 있습니다. 코드 작성자의 이름, 수정 예상 시간 및 조직에 대한 재정적 영향은 일반적으로 결함 보고서에 포함되지 않습니다...

Testing decision or branch paths is considered a form of logic testing.

테스트 결정 또는 분기 경로는 논리 테스트의 한 형태로 간주됩니다.

The inspection team leader leads the team through the software element's inspection.

소프트웨어 검사에 앞서 작성자의 역할은 입력 기준을 충족시키는 것입니다. 소프트웨어 검사 중 작성자의 역할은 주로 소프트웨어 요소 재 작업 및 반박 팀 질문에 응답하는 것과 같은 활동을 지원하는 것으로 제한됩니다....

The author's role prior to a software inspection is to meet the entry criteria. The author's role during the software inspection is primarily limited to support activities such as, software element rework and answering inpsection team questions.

소프트웨어 검사에 앞서 작성자의 역할은 입력 기준을 충족시키는 것입니다. 소프트웨어 검사 중 작성자의 역할은 주로 소프트웨어 요소 재 작업 및 반박 팀 질문에 응답하는 것과 같은 활동을 지원하는 것으로 제한됩니다. 검사 팀 리더는 소프트웨어 요소 검사를 통해 팀을 이끌고 있습니다....

"An author of a software user's manual, during a software inspection, include which of the following roles or activities?

=> Answering questions that come up during the inspection."

"소프트웨어 검사 중에 소프트웨어 사용자 설명서 작성자는 다음 역할 또는 활동을 포함합니까?

검사 중에 나타나는 질문에 답하십시오.

소프트웨어 검사에 앞서 저자의 역할은 출입 (출입 금지) 기준을 충족시키는 것입니다. 소프트웨어 검사 중 작성자의 역할은 주로 소프트웨어 요소 재 작업 및 반박 팀 질문에 응답하는 것과 같은 활동을 지원하는 것으로 제한됩니다. 검사 팀장 (저자가 아닌)은 소프트웨어 요소의 검사를 통해 팀을이 끕니다...."

"Delegate responsibility for testing schedules and predictability of testing work.

Test managers should not use the fact that testing schedules are difficult to set as an excuse for not assuming responsibility for their own schedules or providing testing estimates to the project manager."

"테스트를 스케줄링하고 관리 할 때 테스트 관리자는 다음 중 어느 것을 수행합니까?

=> 일정 테스트에 영향을 줄 수있는 시간이 중요한 작업을 확인하고 해결하십시오...."

"fault seeding is used to estimate: sufficiency of testing

Faults are seeded during designing or coding and can be used to be estimate the sufficiency of testing. One can conclude that testing is complete when all failures are invoked."

"오류 시딩은 다음을 추정하는 데 사용됩니다. 테스트의 충분 함

결함은 설계 또는 코딩 과정에서 파급되며 테스트의 충분 성을 평가하는 데 사용될 수 있습니다. 모든 실패가 호출되면 테스트가 완료되었다고 결론을 내릴 수 있습니다.

험프리 (Humphrey)는 실험이이 기법에 대한 타당성이 거의 없음을 시사한다...."

"fault seeding is used to estimate: sufficiency of testing

Faults are seeded during designing or coding and can be used to be estimate the sufficiency of testing. One can conclude that testing is complete when all failures are invoked."

"오류 시딩은 다음을 추정하는 데 사용됩니다. 테스트의 충분 함

결함은 설계 또는 코딩 과정에서 파급되며 테스트의 충분 성을 평가하는 데 사용될 수 있습니다. 모든 실패가 호출되면 테스트가 완료되었다고 결론을 내릴 수 있습니다."

tests designed to evaluate groupings of modules, as an aggregate, are known as:

집합으로 모듈 그룹을 평가하기위한 테스트는 다음과 같이 알려져 있습니다.

in scm, the term "baseline " refers to: software configuration items captured at project milestones.

scm에서 "기준선"이란 용어는 프로젝트 이정표에 캡처 된 소프트웨어 구성 항목을 의미합니다.

The results are documented in an engineering change proposal that goes to the configuration control board for disposition.

변경 요청은 기술적 장점과 다른 구성 항목, 구성 요소, 인터페이스, 비용 및 일정에 미치는 영향에 대해 평가됩니다. 트레이드 오프 분석은 기술적 장점 및 영향 평가의 결과를 사용하여 수행됩니다. 결과는 배치 변경을 위해 구성 제어 보드로 이동하는 엔지니어링 변경 제안서에 문서화되어 있습니다....

change requests are assessed for technical merit and impact on other configuration items, components, interfaces, costs, and schedules. Trade-off analyses are performed using the results of the technical merit and impact assessments.

변경 요청은 기술적 장점과 다른 구성 항목, 구성 요소, 인터페이스, 비용 및 일정에 미치는 영향에 대해 평가됩니다. 트레이드 오프 분석은 기술적 장점 및 영향 평가의 결과를 사용하여 수행됩니다.

"Business processes should be distributed to all partners.

To all partners within the business enterprise."

"비즈니스 프로세스는 모든 파트너에게 배포되어야합니다.

비즈니스 기업 내의 모든 파트너에게."

"audits performed by an organization at a supplier's facility are referred to as: a second-party audit

The second-party audit is performed by a customer on a supplier."

"공급 업체의 시설에서 조직이 수행 한 감사를 2 차 감사

제 2 자 감사는 공급 업체의 고객이 수행합니다."

software change requests should be used to:

소프트웨어 변경 요청은 다음을 위해 사용되어야합니다.

A part of the software planning process is the identification of quality objectives. It is top management's responsibility to ensure that quality objectives are established and are measurable and consistent with the quality policy.

소프트웨어 계획 프로세스의 일부는 품질 목표의 식별입니다. 품질 목표가 수립되고 측정 가능하며 품질 정책과 일관성을 유지하는 것은 최고 경영자의 책임입니다.

The highest priority in considering project staffing is the skill level of assigned personnel.

프로젝트 인력 배치를 고려할 때 가장 우선시되는 것은 지정된 인원의 기술 수준입니다.

"Bootstrap came first and is focused on organizational and project quality attributes.

ISO/IEC 15504 was initially derived from process lifecycle standard ISO/IEC 12207 and from maturity models like Bootstrap, Trillium and the Capability Maturity Model (CMM)."

"부트 스트랩이 처음 왔고 조직 및 프로젝트 품질 속성에 중점을 둡니다.

ISO / IEC 15504는 처음에는 프로세스 수명주기 표준 인 ISO / IEC 12207과 Bootstrap, Trillium 및 Capability Maturity Model (CMM)과 같은 성숙도 모델에서 파생되었습니다."

"Using a pdca process to design a customer survey, while implementing a customer feedback and improvement process, is an example of:

A PDCA process within a PDCA process."

"pdca 프로세스를 사용하여 고객 설문 조사를 설계하고 고객 피드백 및 개선 프로세스를 구현하는 방법은 다음과 같습니다.

PDCA 프로세스 내의 PDCA 프로세스."

"which of the following incomplete list of software quality planning element would have the highest hierarchical importance?

external standards"

"다음 중 소프트웨어 품질 계획 요소의 불완전한 목록 중 가장 높은 계층 적 중요도를 갖는 요소는 무엇입니까?

외부 표준"

new tests are required when perfective maintenance is performed to add new capabilities, modifications, and general enhancements. Perfective tests are added to check that the added capabilities functions as expected.

새로운 기능, 수정 및 일반적인 향상을 추가하기 위해 완벽한 유지 관리가 수행 될 때 새로운 테스트가 필요합니다. 추가 된 기능이 예상대로 작동하는지 확인하기위한 완벽한 테스트가 추가되었습니다.