System funcional do software ou hardware testes conduzidos em um sistema completo e integrado para avaliar a conformidade do sistema. Ele se enquadra no âmbito de testes de caixa preta, e deve exigir nenhum conhecimento do design de interiores do teste de código ou logic.System leva, como entrada, todos os componentes de software "integrado" que passaram com sucesso os testes de integração e do próprio sistema de software integrado com qualquer sistema de hardware aplicável (s) .O objetivo do teste de integração é detectar quaisquer incoerências entre as unidades de software que são integrados em conjunto ou entre qualquer dos testes assemblages.System é um tipo mais limitante do teste; se destina a detectar defeitos tanto dentro das inter-"conjuntos" e também dentro do sistema como um todo. teste de software com base em seus requisitos funcionais. Ele garante que o programa trabalha fisicamente a forma como foi concebido e todas as opções de menu necessários. Ele também garante que o programa está em conformidade com os padrões da indústria relevantes para o ambiente; por exemplo, em um programa do Windows, pressionando F1 traz ajuda. teste de função é geralmente a primeira fase de teste que uma organização de teste é responsável por durante um determinado release. Requisitos baseados em testes de função é uma abordagem para a função de teste - é uma abordagem de teste poderoso e eficaz, o que irá reduzir significativamente o número de defeitos não detectados (falhas) ser liberado para produção. A premissa é que um conjunto bem formulada de requisitos funcionais dar o Designers testar um bases definitivas para caso de teste design.What é teste de função? O objetivo do teste de função é medir a qualidade dos componentes funcionais do sistema. Testes verificar se comporta corretamente do ponto de vista do usuário /negócios e funções de acordo com os requisitos, modelos, storyboards, ou qualquer outro paradigma de projeto usado para especificar a aplicação. O teste de função deve determinar componente ou evento de negócios: executa de acordo com as especificações, responde corretamente a todas as condições que podem ser apresentados por eventos de entrada /dados, move dados corretamente de um evento de negócios para os (armazenamentos de dados, incluindo) ao lado, e que eventos de negócios são iniciados na ordem necessária para atender aos objetivos de negócios da system.What é um requisito? um requisito é uma capacidade ou função que deve ser entregue por um componente ou componentes do sistema. A necessidade de negócios específica ou comportamento como visto por um utilizador externo do sistema. Um ciclo de teste eficaz deve ter um conjunto definido de processos e resultados. Os processos primários entregas de requisitos baseados em testes de função são: planejamento de teste, particionamento /Funcional de decomposição, RequirementsDefinition /verificação, teste Design Caixa, Rastreabilidade (Matriz de rastreabilidade), Test Case execução, gerenciamento de defeitos e Análise de Cobertura. Quais processos e os resultados se aplicam a qualquer situação de teste são dependentes de recursos disponíveis (pessoas, matérias-primas, tempo, etc.) e o mandato da organização do teste. planejamento de teste durante o planejamento a ponta de prova com a ajuda da equipe de teste define o escopo, cronograma e os produtos para o ciclo de teste de função. A ponta de prova oferece um plano de teste (documento) e um cronograma de testes - estes muitas vezes passam por várias revisões durante o ciclo de testes. Partitioning - A decomposição funcional de um sistema é a quebra de um sistema em seus componentes funcionais ou áreas funcionais. Outro grupo na organização pode assumir a responsabilidade pela decomposição funcional (ou modelo) do sistema, mas a organização de testes ainda deve rever este material está completo antes de aceitá-lo para o teste organization.If a decomposição funcional ou partições não foram definidos ou são considerada insuficiente, em seguida, a organização de testes terão de assumir a responsabilidade de criar e manter as partições. Existem vários comerciais, shareware, e produtos freeware disponíveis que auxiliam na decomposição funcional de um sistema e a entrega formal da definição partitions.RequirementsVerificationRequirements funcionais é muitas vezes a entrega mais fracos no processo de desenvolvimento de software. Muitas lojas de desenvolvimento ir diretamente do conceito de software para especificação funcional ou pior do conceito de software ao código sem quaisquer resultados de design de software preliminares. A organização de testes precisa desses requisitos para prosseguir com o teste de função, por isso, se a equipe de desenvolvimento não vai entregar os requisitos para a verificação pela equipe de teste, em seguida, a equipe de teste deve criar seu próprio conjunto de requisitos testáveis. Estes requisitos devem ser discriminados no âmbito dos projetos funcionais apropriados Designer de Teste /Tester partition.Test Caso design.The e implementa casos de teste para validar os executa produtos em conformidade com os requisitos (ver .Testing eo papel de um Tester Designer de Teste). . Esses casos de teste precisam ser detalhados por item na partição funcional adequado e mapeada /atribuída às exigências sendo tested.Traceability (Matriz de rastreabilidade) casos de teste precisa ser rastreada /mapeados de volta para o requisito adequado. Uma vez que todos os aspectos de um requisito foram testados pelos casos de um ou mais testes, então a atividade de design de teste para esse requisito pode ser considerado complete.A equívoco comum feita durante este processo é que todos os casos de teste que exercem uma exigência particular, devem ser mapeados para que exigência - apenas os casos de teste que são criados especificamente para testar um requisito deve ser atribuída a essa exigência. Esta abordagem dá uma imagem muito mais precisa da aplicação quando a análise de cobertura é feito - falha de um caso de teste não significa fracasso de todas as exigências exercidas (em oposição à testado por) o teste case.Test Caso ExecutionAs em todas as fases de testes o conjunto apropriado de casos de teste precisa ser executado e os resultados desses casos de teste gravado. Que casos de teste estão a ser executado deve ser definida dentro do contexto do Plano de Teste eo estado atual do aplicativo que está sendo testado. Se o estado atual do aplicativo não suporta o teste de um ou mais requisitos, então este teste deve ser adiada até que ele faz justificar o dispêndio de recursos de teste. gerenciamento de defeitos em todas as fases de testes quaisquer defeitos detectados durante a execução do teste precisam ser ambas gravadas e gerido pela organização de testes. Durante o teste de função cada defeito deve ser atribuída a um requisito ou requisitos específicos que não estão realizando a especificação. análise de cobertura durante a função de testar um relatório periódico deve ser entregue pela organização de teste para a equipe do projeto. As bases para este relatório será uma análise de cobertura dos requisitos contra casos de teste e excelente objectivo defects.The é determinar a percentagem dos requisitos que são: considerados não testado, executando com a especificação (executado com êxito), e não realizando a Specification (defeitos) .Há vários comerciais, shareware, e produtos freeware disponíveis que podem ser usados para acelerar a criação de todos estes produtos, enquanto a racionalização do teste de função testes process.Managing pode ser uma tarefa avassaladora de uma associação testes inexperiente. Para assegurar o sucesso na organização de teste e nível de projeto escopo do esforço de teste precisa ser meticulosamente definido e seguido. Definição do escopo precisa ser entendida pela organização de teste ea equipe do projeto - se o escopo do esforço de teste precisa ser redefinido, então este deve ser communicated.A plano de trabalho realista com resultados claros e dependências precisa ser redigido e atualizado quando algum evento, que impactos do plano de trabalho de forma positiva ou negativa. A chave do sucesso é administrar as expectativas da equipe de teste ea equipe do projeto ao comunicar claramente o status atual do esforço de teste em bases contínuas.