東華大學圖書館 |

Language: English

Help

回圖書館首頁

手機版館藏查詢

Back

Switch To: Labeled | MARC Mode | ISBD

Software Testing Environment.

Sirbu, Denis.

Linked to FindBook

Google Book

Amazon

博客來

Software Testing Environment.

Record Type:	Electronic resources : Monograph/item
Title/Author:	Software Testing Environment./
Author:	Sirbu, Denis.
Published:	Ann Arbor : ProQuest Dissertations & Theses, : 2016,
Description:	91 p.
Notes:	Source: Masters Abstracts International, Volume: 83-12.
Contained By:	Masters Abstracts International83-12.
Subject:	Operating systems. -
Online resource:	https://pqdd.sinica.edu.tw/twdaoapp/servlet/advanced?query=29096384
ISBN:	9798819340769

Software Testing Environment.
Sirbu, Denis.

Software Testing Environment. - Ann Arbor : ProQuest Dissertations & Theses, 2016 - 91 p.

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

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

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.

ISBN: 9798819340769Subjects--Topical Terms:

3681934
Operating systems.

Software Testing Environment.
LDR:06307nmm a2200337 4500 001 2400784
005 20240930130032.5
006 m o d
007 cr#unu||||||||
008 251215s2016 ||||||||||||||||| ||eng d
020 $a 9798819340769
035 $a (MiAaPQ)AAI29096384
035 $a (MiAaPQ)Portugal1040019961
035 $a AAI29096384
040 $a MiAaPQ $c MiAaPQ
100 1 $a Sirbu, Denis. $3 3770839
245 1 0 $a Software Testing Environment.
260 1 $a Ann Arbor : $b ProQuest Dissertations & Theses, $c 2016
300 $a 91 p.
500 $a Source: Masters Abstracts International, Volume: 83-12.
500 $a Advisor: Daniel, Helder.
502 $a Thesis (M.E.)--Universidade do Algarve (Portugal), 2016.
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.
590 $a School code: 7026.
650 4 $a Operating systems. $3 3681934
650 4 $a Year 2000. $3 3770840
650 4 $a Design. $3 518875
650 4 $a Java. $3 517732
650 4 $a Programming languages. $3 3683658
650 4 $a Computers. $3 544777
650 4 $a Failure. $3 3561225
650 4 $a Defects. $3 3682384
650 4 $a Computer science. $3 523869
690 $a 0389
690 $a 0984
710 2 $a Universidade do Algarve (Portugal). $3 3690074
773 0 $t Masters Abstracts International $g 83-12.
790 $a 7026
791 $a M.E.
792 $a 2016
793 $a English
856 4 0 $u https://pqdd.sinica.edu.tw/twdaoapp/servlet/advanced?query=29096384