Teste X-Máquina: diferenças entre revisões

Conteúdo apagado Conteúdo adicionado
Linha 1:
O '''(Stream) X-Máquina Metodologia de ensaio''' é um [[teste funcional]] ''completo'' para uma abordagem de teste de [[teste de software | software-]] e de hardware <ref name="HolIp98">M. Holcombe and F. Ipate (1998) ''Correct Systems - Building a Business Process Solution''.
Springer, Applied Computing Series.</ref>, que explora a escalabilidade do <span>modelo de computação</span> [[Córrego X-Machine]] modelo de computação. <ref name="Lay93">Gilbert Laycock (1993) ''The Theory and Practice of Specification Based Software Testing''. PhD Thesis, University of Sheffield. [http://www.mcs.le.ac.uk/people/gtl1/PhDabstract.html Abstract]</ref>
Usando esta metodologia, é provável paraverossímil identificar um finito conjunto-teste <span>finito </span>que exaustivamente determina se a implementação do sistema testado corresponde a sua especificação. Este objetivo é alcançado através de uma abordagem de dividir e conquistar, em que o projeto é decomposto por refinamento <ref name="IpHol98">F. Ipate and M. Holcombe (1998) 'A method for refining and testing generalised machine specifications'. ''Int. J. Comp. Math.'' '''68''', pp. 197-219.</ref> em uma coleção de [[Córrego X-Máquina]] <nowiki/>s, que são implementadosimplementadas como módulos separados, e então testados na abordagem " bottom-up ". Em cada estágio de integração, o método de teste garante que os componentes testados estão corretamente integradaintegrados. <ref name="IpHol97">F. Ipate and M. Holcombe (1997) 'An integration testing method that is proved to find all faults', ''International Journal of Computer Mathematics'' '''63''', pp. 159-178.</ref>
 
A metodologia supera limitações formais de [[G% C3% B6del% 27s_incompleteness_theorem # Relationship_with_computability | indecidibilidade]], exigindo que certos princípios de [[design para teste]] são seguidos durante a especificação e implementação. A escalabilidade resultante significa que sistemas de software <ref name="BogHol98">K. Bogdanov and M. Holcombe (1998) 'Automated test set generation for Statecharts', in: D. Hutter, W Stephan, P. Traverso and M. Ullmann eds. ''Applied Formal Methods: FM-Trends 98'', Boppard, Germany, ''Lecture Notes in Computer Science'' '''1641''', pp. 107-121.</ref> e hardware <ref name="Van01">Salim Vanak (2001), ''Complete Functional Testing of Hardware Designs'', PhD Thesis, University of Sheffield.</ref> práticos são constituídos por centenas de milhares de milhões de estados e transições foram testados com sucesso.
Linha 7:
== Motivação ==
 
Muito do [[teste de software]] é meramente esperançoso, buscando exercerexercitar o sistema de software de várias formas para ver se todas as falhas podem ser detectadas. Teste pode de fato revelar algumas falhas, mas nunca pode garantir que o sistema está correto, uma vez que o teste é longotermina.
Métodos de [[Teste funcionais]] procuram melhorar esta situação, através do desenvolvimento de um [[especificação formal]] que descreve o comportamento esperado do sistema, contra a qual a execução é posteriormente testada (uma espécie de [[teste de conformidade]]). A especificação pode ser validadovalidada contra as necessidades dos usuários e, mais tarde [[provaprovada de Matemática | comprovada]] em termos de[[consistente]] e [[Integralidade (lógica) | completocompleta]] pelo raciocínio matemático (eliminando quaisquer falhas de projeto lógicos). Métodos completos de [[teste] funcionais]funcional exploraram a especificação sistematicamente, gerando conjuntos de testes que exercem o sistema de software implementado '' exaustivamente '', para determinar se ele está de acordo com a especificação. Em particular:
* Teste positivo completo: confirma que todo o comportamento desejado está presente no sistema;
* O teste negativo completa: confirma que nenhum comportamento indesejado está presente no sistema.