國立虎尾科技大學 |

Software Testing Environment.

紀錄類型:	書目-語言資料,手稿 : Monograph/item
正題名/作者:	Software Testing Environment./
作者:	Sirbu, Denis.
面頁冊數:	1 online resource (91 pages)
附註:	Source: Masters Abstracts International, Volume: 83-12.
Contained By:	Masters Abstracts International83-12.
標題:	Computer science. -
電子資源:	click for full text (PQDT)
ISBN:	9798819340769

Software Testing Environment.
Sirbu, Denis.

Software Testing Environment. - 1 online resource (91 pages)

Source: Masters Abstracts International, Volume: 83-12.

Thesis (M.E.)--Universidade do Algarve (Portugal), 2016.

Includes bibliographical references

In this thesis it is proposed a distributed software testing environment, that is able to test a wide variety of applications, such as a user space processes, kernel space processes, web applications and others. The testing environment is supported by an API of probes, where each probe has a specific test task according to its purpose. The base API can be extended to fulfil new testing requirements. This environment can be applied to general software testing, programming contests and as a support for programming classes as the Mooshak automatic judging environment. The essential differences between both these environments is where the software testing is performed. Unlike Mooshak, the proposed test environment can use client computers to do the actual test. This reduces the overhead on the server dramatically, which is especially useful when there are many test submissions simultaneously. These are the cases of classroom environments, lab environments or programming contests. Another option is to have a set of testing computers, or slaves, ready to test user code. However this way more hardware is required. The only requirements for a computer to be a slave, part of the testing environment, is that is has installed a java client application that communicates with the master computer also addressed here as the main server. On the main server a portal allows users to access this testing environment. This master computer is also responsible to distribute the testing workload, according to the choosen strategy, sending to each slave the executable and testing probes, which includes the matching pairs of inputs and expected outputs. After the slaves had performed the tests, they generate a report with information on the tests, and send it back to the master, being available to the users on the portal. To support simultaneous clients the portal is thread based, being launched a new thread to serve each new client connection. Communication between all computers in the test environment, is done using the BSD sockets API.

Electronic reproduction.
Ann Arbor, Mich. :
ProQuest,
2024

Mode of access: World Wide Web

ISBN: 9798819340769Subjects--Topical Terms:

573171
Computer science.
Index Terms--Genre/Form:

554714
Electronic books.

Software Testing Environment.
LDR:06532ntm a22003497 4500 001 1149038
005 20240930130032.5
006 m o d
007 cr bn ---uuuuu
008 250605s2016 xx obm 000 0 eng d
020 $a 9798819340769
035 $a (MiAaPQ)AAI29096384
035 $a (MiAaPQ)Portugal1040019961
035 $a AAI29096384
040 $a MiAaPQ $b eng $c MiAaPQ $d NTU
100 1 $a Sirbu, Denis. $3 1475161
245 1 0 $a Software Testing Environment.
264 0 $c 2016
300 $a 1 online resource (91 pages)
336 $a text $b txt $2 rdacontent
337 $a computer $b c $2 rdamedia
338 $a online resource $b cr $2 rdacarrier
500 $a Source: Masters Abstracts International, Volume: 83-12.
500 $a Advisor: Daniel, Helder.
502 $a Thesis (M.E.)--Universidade do Algarve (Portugal), 2016.
504 $a Includes bibliographical references
520 $a In this thesis it is proposed a distributed software testing environment, that is able to test a wide variety of applications, such as a user space processes, kernel space processes, web applications and others. The testing environment is supported by an API of probes, where each probe has a specific test task according to its purpose. The base API can be extended to fulfil new testing requirements. This environment can be applied to general software testing, programming contests and as a support for programming classes as the Mooshak automatic judging environment. The essential differences between both these environments is where the software testing is performed. Unlike Mooshak, the proposed test environment can use client computers to do the actual test. This reduces the overhead on the server dramatically, which is especially useful when there are many test submissions simultaneously. These are the cases of classroom environments, lab environments or programming contests. Another option is to have a set of testing computers, or slaves, ready to test user code. However this way more hardware is required. The only requirements for a computer to be a slave, part of the testing environment, is that is has installed a java client application that communicates with the master computer also addressed here as the main server. On the main server a portal allows users to access this testing environment. This master computer is also responsible to distribute the testing workload, according to the choosen strategy, sending to each slave the executable and testing probes, which includes the matching pairs of inputs and expected outputs. After the slaves had performed the tests, they generate a report with information on the tests, and send it back to the master, being available to the users on the portal. To support simultaneous clients the portal is thread based, being launched a new thread to serve each new client connection. Communication between all computers in the test environment, is done using the BSD sockets API.
520 $a Hoje em dia e muito util ter uma boa ferramenta de teste de software para quem quer fazer um programa com especificacoes restritas. Isto pode custar uma fortuna, e por sua vez nao significa que a compra deste tipo de servico garanta que o programa desenvolvido sob sua especificacao sera 100 % livre em termos de erros, bugs e ate mesmo falhas gerais. Estas 3 palavras que nenhuma empresa quer ouvir. Na historia da informatica aconte- ceram imensas falhas que poderiam ser evitadas testando melhor os programas. Por um lado o teste de aplicacoes torna-se mais facil hoje em dia, se as APIs utilizadas ja tiverem sido sujeitas a testes e livre de erros, proporcionando dessa forma intrinsecas rotinas que podem ser incorporadas em aplicacoes sem a necessidade do programador as reescrever. Por outro lado o teste dessas APIs deve ser extenso e minucioso. Desta forma uma inter- face grafica de utilizador (GUI), por exemplo, pode ser construida a partir de bibliotecas de componentes adequadas a linguagem escolhida para o desenvolvimento. Uma vez que estes componentes sao objectos pre-programados que foram depurados e testados anteri- ormente, a necessidade de testa-los novamente nao e necessaria, sendo apenas necessario testar a sua integracao com a aplicacao. Assim o teste de software e um processo, ou uma serie de processos, destinado a garantir que o codigo respeitas as especificacoes e que nao apresenta comportamentos nao intencionais, mas sim previsiveis e consistentes, oferecendo o melhor desempenho sem surpresas para os utilizadores. Para efetuar testes podemos ter duas opcoes: Analisar o codigo, referidos como testes de caixa branca, ou ignorar o codigo e tratar o sistema como uma caixa negra. Neste conceito, que e escol- hido para o ambiente de testes proposto aqui, descrito aqui, sao aplicadas ao sistema a testar um conjunto de entradas e verificado se para cada entrada a saida e igual a saida esperada de acordo com as especificacoes. Este tipo de testes e usado vulgarmente, mesmo em concursos de programacao, sendo um dos exemplos os concursos organiza- dos pela ACM-ICPC (International Collegiate Programming Contest), para equipas de estudantes. Estas competicoes locais, nacionais e internacionais, sao direcionadas para equipas que consistem em cerca de 3 estudantes de universidades ou outras instituicoes. O objetivo consiste em escrever programas que para entradas dadas irao gerar as saidas de acordo com as especificacoes. Concursos semelhantes sao adotados em muitas univer- sidades, por causa do aspeto competitivo, que faz com que os alunos tenham um objetivo ao completar um exercicio. Os testes de caixa negra podem ser adaptados em varias fases de construcao de um programa. Podem ser usados nos blocos basicos de construcao, onde os componentes sao testados um a um, com determinadas entradas e saidas esperadas. Numa fase posterior de desenvolvimento de um sistema podem ser construidos testes de integracao, tambem de caixa negra, onde os componentes que foram testados ante- riormente sao agora testados em termos de integracao. Podem tambem ser aplicados a modulos e a toda aplicacao. O objetivo principal desta dissertacao foi a criacao de um ambiente de teste de software automatico e distribuido, que possa ser usado nos casos acima descritos.
533 $a Electronic reproduction. $b Ann Arbor, Mich. : $c ProQuest, $d 2024
538 $a Mode of access: World Wide Web
650 4 $a Computer science. $3 573171
650 4 $a Defects. $3 1372731
650 4 $a Failure. $3 1365603
650 4 $a Computers. $3 565115
650 4 $a Programming languages. $3 1468403
650 4 $a Java. $3 1115949
650 4 $a Design. $3 595500
650 4 $a Year 2000. $3 1475163
650 4 $a Operating systems. $3 1473023
655 7 $a Electronic books. $2 local $3 554714
690 $a 0389
690 $a 0984
710 2 $a Universidade do Algarve (Portugal). $3 1475162
710 2 $a ProQuest Information and Learning Co. $3 1178819
773 0 $t Masters Abstracts International $g 83-12.
856 4 0 $u http://pqdd.sinica.edu.tw/twdaoapp/servlet/advanced?query=29096384 $z click for full text (PQDT)