Ograniczanie wyników
Czasopisma help
Autorzy help
Lata help
Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników
Powiadomienia systemowe
  • Sesja wygasła!

Znaleziono wyników: 17

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  testowanie oprogramowania
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
EN
In organization with applied agile software development, where software life cycles are very short (i.e. two weeks), changes to the software are very frequent. Usually resources are scarce – power is expensive, test lines are constantly occupied, and hardware parts must be booked only for regression testing. In this perspective, regression testing might introduce a lot of unnecessary overhead. By comparing statistical methods and related to unsupervised machine learning methods, we discovered that due to a uniform nature of code changes, one can easily achieve 90% of bug prediction accuracy while reducing the original testing queue by 25%.
PL
W organizacji działającej w oparciu o zwinne podejście do rozwoju oprogramowania, gdzie cykle życia oprogramowania są bardzo krótkie (np. dwa tygodnie), zmiany w oprogramowaniu są bardzo częste. Zazwyczaj zasoby są ograniczone — prąd jest drogi, linie testowe są stale zajęte, a części sprzętu muszą być zarezerwowane tylko do testów regresyjnych. W tej perspektywie testy regresyjne mogą wprowadzić wiele niepotrzebnych kosztów całkowitych. Porównując metody statystyczne oraz nienadzorowanego uczenia maszynowego odkryliśmy, że dzięki jednolitej naturze zmian w kodzie, można łatwo osiągnąć 90% dokładności przewidywania błędów przy jednoczesnym zmniejszeniu pierwotnej kolejki testów o 25%.
EN
In this paper a modification of Mike Cohn's test pyramid is described for adaptation during testing in distributed information processing systems which allows expanding the possibilities of testing and applying the features of such systems. Recommendations for further use of the mechanisms of modified Mike Cohn's pyramid are developed. The method of testing the user interface software of the nodes of a distributed system was improved to differ from the existing techniques by including a mechanism of simulation of its operation to allow testing of individual components of the system interface. It is shown that in comparison with end-to-end testing of user interfaces the advantages of using the mechanisms of user interface test simulators allow reducing the time spent on testing any UI service. The time is reduced by decreasing the number of simultaneous user interface services. With a small number of nodes, end-to-end testing of user interfaces is faster than simulation testing of the same user interfaces. As the number of nodes increases, the time required to test the services of a distributed system by simulation tests becomes shorter than the time required to test the same system by a traditional method.
EN
Purpose: The main purpose of the research is to examine the suitability of exploratory tests in the software testing process. Design/methodology/approach: An experiment, carried out for the sake of this study, consisted of two parts. First, a test was performed, and in the second part a survey was conducted, which allowed for the comparison of exploratory and test-based tests. Findings: The results of the tests indicated a slightly lower effectiveness of the exploratory approach, which may have been caused by the conditions of the experiment: the choice of the tested software, short duration of test sessions, participants lacking knowledge about the investigated software and experience in performing exploratory tests. Originality/value: Despite the weaker results obtained, the exploratory tests proved useful, as evidenced by the detection of distinctive errors, not found during tests based on test cases. In the survey, 90% of respondents confirmed the use of formalized test approach, based on test cases, while just over a half (57%) indicated having experience in conducting exploratory tests. Testers considered both approaches useful, addressing greater need for conducting formalized tests using test cases. Results included in the research allowed to indicate the qualities and shortcomings of the exploratory approach to software testing.
EN
Test case prioritization (TCP) has been considerably utilized to arrange the implementation order of test cases, which contributes to improve the efficiency and resource allocation of software regression testing. Traditional coverage-based TCP techniques, such as statement-level, method/function-level and class-level, only leverages program code coverage to prioritize test cases without considering the probable distribution of defects. However, software defect data tends to be imbalanced following Pareto principle. Instinctively, the more vulnerable the code covered by the test case is, the higher the priority it is. Besides, statement-level coverage is a more fine-grained method than function-level coverage or class-level coverage, which can more accurately formulate test strategies. Therefore, we present a test case prioritization approach based on statement software defect prediction to tame the limitations of current coverage-based techniques in this paper. Statement metrics in the source code are extracted and data pre-processing is implemented to train the defect predictor. And then the defect detection rate of test cases is calculated by combining the prioritization strategy and prediction results. Finally, the prioritization performance is evaluated in terms of average percentage faults detected in four open source datasets. We comprehensively compare the performance of the proposed method under different prioritization strategies and predictors. The experimental results show it is a promising technique to improve the prevailing coverage-based TCP methods by incorporating statement-level defect-proneness. Moreover, it is also concluded that the performance of the additional strategy is better than that of max and total, and the choice of the defect predictor affects the efficiency of the strategy.
PL
Metodę priorytetyzacji przypadków testowych (TCP) wykorzystuje się powszechnie do ustalania kolejności implementacji przypadków testowych, co przyczynia się do poprawy wydajności i alokacji zasobów w trakcie testowania regresyjnego oprogramowania. Tradycyjne techniki TCP oparte na pokryciu na poziomie instrukcji, metody/funkcji oraz klasy, wykorzystują pokrycie kodu programu tylko w celu ustalenia priorytetów przypadków testowych, bez uwzględnienia prawdopodobnego rozkładu błędów. Jednak dane o błędach oprogramowania są zwykle niezrównoważone zgodnie z zasadą Pareto. Instynktownie, im bardziej wrażliwy jest kod pokryty przypadkiem testowym, tym wyższy jest jego priorytet. Poza tym, pokrycie na poziomie instrukcji jest bardziej szczegółową metodą niż pokrycie na poziomie funkcji lub pokrycie na poziomie klasy, które mogą dokładniej formułować strategie testowe. Dlatego w artykule przedstawiamy podejście do priorytetyzacji przypadków testowych oparte na prognozowaniu błędów instrukcji oprogramowania, które pozwala zmniejszyć ograniczenia obecnych technik opartych na pokryciu. Wyodrębniono metryki instrukcji w kodzie źródłowym i zaimplementowano wstępne przetwarzanie danych w celu nauczania predyktora błędów. Następnie obliczono wskaźnik wykrywania błędów w przypadkach testowych poprzez połączenie strategii priorytetyzacji i wyników prognozowania. Wreszcie, oceniono wydajność ustalania priorytetów pod względem średnich procentowych błędów wykrytych w czterech zestawach danych typu open source. Kompleksowo porównano wydajność proponowanej metody w ramach różnych strategii ustalania priorytetów i predyktorów. Wyniki eksperymentów pokazują, że jest to obiecująca technika poprawy dominujących metod TCP opartych na pokryciu poprzez włączenie podatności na błędy na poziomie instrukcji. Ponadto stwierdzono również, że strategia dodatkowa cechuje się lepszą wydajnością niż strategie max i total, a wybór predyktora błędów wpływa na skuteczność strategii.
5
Content available Managing complex software projects
EN
In the paper we present our experience with development and maintenance of complex software systems. In particular, we concentrate on monitoring related development, testing and debugging processes. We have analyzed the contents of collected reports (provided by different tools) covering many projects and defined several metrics and statistics helpful in managing complex projects and achieving high quality software. Moreover, we have identified lacking data which could improve these processes.
6
Content available remote Modelling the software testing process
EN
An approach to formal modelling the program testing process is proposed in the paper. Considerations are based on some program reliability-growth model that is constructed for assumed scheme of the program testing process. In this model the program under the testing is characterized by means of so-called characteristic matrix and the program testing process is determined by means of so-called testing strategy. The formula for determining the mean value of the predicted number of errors encountered during the program testing is obtained. This formula can be used if the characteristic matrix and the testing strategy are known. Formulae for evaluating this value when the program characteristic matrix is not known are also proposed in the paper.
PL
Przedmiotem zawartych w artykule rozważań jest modelowanie procesu testowania programu, ze szczególnym uwzględnieniem modelowania wzrostu niezawodności programu w procesie jego testowania. W rozpatrywanym modelu testowany program charakteryzowany jest za pomocą tzw. macierzy charakterystycznej programu. Na bazie skonstruowanego modelu wyprowadzona została zależność na wartość oczekiwaną liczby błędów, wykrycie których spodziewane jest w wyniku realizacji procesu testowania, realizowanego w oparciu o przyjętą strategię testowania. Otrzymana zależność może być wykorzystana w praktyce, jeżeli macierz charakterystyczna programu jest znana. Dla przypadku, gdy macierz ta nie jest znana skonstruowane zostało w artykule obustronne oszacowanie tej wartości oczekiwanej.
EN
Analysis of software reliability plays an important role in quality assurance plan realization during software development. By monitoring changes of evaluated reliability in relation to quality objectives it is possible to analyze current situation in respect to agreed requirements and initiate appropriate actions when needed to secure fulfilling of the goals. The use of software reliability growth models as the only method for reliability evaluation seems to be too much simplified approach. Such approach, based solely on fault detection history, may in some circumstances be risky and lead to significantly wrong decisions related to the software validation process. Taking possible pros and cons into account the model described in this paper is proposed to use a number of additional information concerning the software being tested and the validation process itself, to produce more accurate outcomes from the reliability analysis. The produced outcome gives an appropriate feedback for a decision makers, taking into account assumed software development process characteristic. Integral part of the presented approach is devoted to reliability characteristics of a system being tested in parallel by several independent teams.
PL
Badanie niezawodności oprogramowania stanowi istotną część realizacji planu jakościowego w procesie produkcji oprogramowania. Poprzez monitorowanie zmian wartości prognozowanej niezawodności oprogramowania w odniesieniu do założonych celów jakościowych można dokonywać analizy bieżącej sytuacji oraz w razie konieczności podejmować kroki sprzyjające realizacji założonego planu. Wykorzystanie w celu predykcji niezawodności jedynie modeli wzrostu niezawodności oprogramowania, bazujących na historii wykrywania błędów w badanym oprogramowaniu, wydaje się być podejściem zbyt uproszczonym. Podejście to w pewnych okolicznościach realizacji procesu walidacji oprogramowania może być obarczone dużym błędem i wpływać na podejmowanie błędnych decyzji przez decydenta. W związku z tym, w zaproponowanym modelu wykorzystuje się szereg dodatkowych informacji o testowanym oprogramowaniu oraz samym procesie walidacji w celu uzyskania bardziej wiarygodnych efektów analizy niezawodnościowej, będących jednocześnie odpowiednią informacją zwrotną dla decydenta z punktu widzenia założonych realiów prowadzenia projektu programistycznego. Integralną część prezentowanego podejścia stanowi aspekt wyznaczania charakterystyk niezawodnościowych systemu testowanego równolegle przez kilka niezależnych zespołów.
EN
This article provides short state-of-the-art review over the robotic mobile software testing devices. It presents all devices that are known to the author (one of which is built by the author) in comparison to each other.
EN
Random but visually nice shapes are often needed for cognitive experiments and processes. This study describes a heuristic for generating random but nice shapes. We call them placated shapes. These shapes are produced by applying the Gaussian blur to randomly generated polygons. Subsequently, the threshold is set to transform pixels to black and white from different shades of gray. This transformation produces placated shapes for easier estimation of areas. Randomly generated placated shapes are used for testing the accuracy of cognitive processes by pairwise comparisons. They can also be used in many other areas such as computer games or software testing. Such shapes could also be used for camouflaging heavy army equipment.
PL
W artykule przedstawiono koncepcję programowego symulatora obiektu sterowania przeznaczonego do uruchamiania i testowania oprogramowania dla sterowników PLC. Symulator emuluje zachowanie fizycznego obiektu przemysłowego i komunikuje się ze sterownikiem za pośrednictwem karty wejścia-wyjścia podłączanej do komputera. Pozwala on na przetestowanie tworzonej aplikacji bez udziału fizycznego obiektu, dzięki czemu znacząco przyspiesza proces tworzenia, uruchamiania oraz testowania oprogramowania.
EN
The paper discusses hardware and software tools used to support program testing and verification of Programmable Logic Controllers (PLC). Three main ideas of tools supporting PLC application development are presented: software PLC simulators (Fig. 1), software PLC simulators with software object simulators (Fig. 2), and software object simulators with a hardware PLC (Fig. 4). The last idea is discussed wider in the paper. The authors propose a new concept of the tool for supporting PLC program testing - an object simulator which is a separate device. The simulator consists of a PC equipped with an appropriate I/O card, and an object simulator program running on the PC. The object simulator program is responsible for emulating behavior of an industrial object, and providing appropriate visualization of its operation, enabling also the PLC programmer to simulate object faults. The PC does not communicate with the PLC using a network interface, but through physical I/Os of the PLC. The simulator is thus capable of testing the most of functionality built in PLC I/O modules, and time-critical functions, e. g. interrupts. The proposed concept of an object simulator can provide a reliable substitute for a physical object, and thus a significant part of software tests can be performed with use of the simulator. This can significantly facilitate and accelerate development of the application.
EN
Considerable development resources are consumed during the software-testing phase. The software development manager has to decide how to use the testing-resources effectively in order to maximize the software quality and reliability. The paper discusses a management problem to achieve a reliable software system efficiently during the module testing stage by applying a software reliability growth model. This model both describes the software-error detection phenomenon and represents the relationship between the cumulative number of errors encountered by software testing and the time span of the testing. As testing cost and software reliability are both important factors in the testing-resource allocation problems an investigation is performed in the paper to search for the optimal solution for modular software system with the objectives of maximising system reliability and minimising testing cost.
PL
W artykule przedstawiona jest metoda określania struktury niezawodnościowej programu, rozumianej jako wektor wskaźników niezawodności jego modułów składowych. Modelem rozpatrywanego programu jest graf przepływu sterowania, w którym prawdopodobieństwa uaktywniania poszczególnych modułów składowych w procesie wykonywania programu wynikają z tzw. profilu operacyjnego programu, charakteryzującego rzeczywiste środowisko jego pracy. Struktura niezawodnościowa wyznaczana jest w wyniku rozwiązania określonego zadania programowania matematycznego. Znajomość struktury niezawodnościowej programu umożliwia właściwe zaplanowanie nakładów czasowo-finansowych, wymaganych dla wytworzenia programu, spełniającego założone wymagania niezawodnościowe. Zastosowanie przedstawionej metody zilustrowane zostało przykładem liczbowym.
EN
The partition testing method is a commonly followed practice towards the selection of test cases. For partition testing, the program's input domain is divided into subsets, called subdomains, and one or more representatives from each subdomain are selected to test the program. The goal of such partitioning is to make the division of the program's input domain in such a way that when the tester selects test cases based on the subsets, the resulting test set is a good representation of the entire domain. The main aim of the paper is to analyse the fault-detecting ability of the partition testing method. Using effectiveness metrics for testing and partitioning schemes this paper makes a comparison of various test case allocation schemes in partition testing.
PL
W artykule przedstawione są wyniki porównania dwóch, najczęściej wykorzystywanych w praktyce, strategii losowego tworzenia zbioru danych testowych. Pierwsza z tych strategii, nazywana testowaniem w pełni losowym, polega na losowaniu poszczególnych przypadków testowych ze zbioru wszystkich możliwych zestawów danych wejściowych rozpatrywanego programu, przy czym najczęściej przyjmuje się tutaj, że wylosowanie każdego z tych zestawów jest jednakowo prawdopodobne. Druga z analizowanych strategii zakłada podział całego zbioru wszystkich możliwych zestawów danych wejściowych programu na tzw. partycje, będące podzbiorami, tworzonymi w oparciu o kryteria wykorzystywane w testowaniu strukturalnym. Strategia ta jest nazywana strukturalnym testowaniem losowym. Zawarte w artykule rozważania mają na celu określenie warunków, dla których jedna z ww. strategii testowania losowego jest lepsza od drugiej, w sensie prawdopodobieństwa wykrycia co najmniej jednego błędu.
13
Content available remote Control flow graphs and code coverage
EN
The control flow of programs can be represented by directed graphs. In this paper we provide a uniform and detailed formal basis for control flow graphs combining known definitions and results with new aspects. Two graph reductions are defined using only syntactical information about the graphs, but no semantical information about the represented programs. We prove some properties of reduced graphs and also about the paths in reduced graphs. Based on graphs, we define statement coverage and branch coverage such that coverage notions correspond to node coverage, and edge coverage, respectively.
PL
W artykule została przedstawiona metoda wyznaczania liczby testów na podstawie znajomości liczby elementów interfejsu użytkownika przyrządu wirtualnego. Powiązano liczbę przypadków testowych z ogólną liczbą przeprowadzonych testów, gdy testy przeprowadzane są dla kombinacji elementów interfejsu użytkownika przyrządu wirtualnego. Przedstawiono też sposób określania czasu przeprowadzenia testów na podstawie znajomości liczby przypadków testowych.
EN
In his paper presented is the method of test cases calculation on the basis of number of user interface elements of virtual instrument. The number of test cases was related to overall number of carried out tests, when the test are carried out for combination of user interface elements. The manner of determining time for the tests was presented. That was done on the basis of knowledge of number of test cases.
PL
Istnieje szereg sposobów badania poprawności programów komputerowych. W artykule podejmujemy problem automatycznego testowania oprogramowania przy założeniu, że dany jest zbiór testów (asercji) dla poszczególnych fragmentów kodu. Dla uproszczenia analizy zakładamy, że badany fragment kodu zawiera dokładnie jeden błąd, co nie zmniejsza ogólności rozważań. W artykule analizujemy praktyczne aspekty powyższego problemu oraz rozważamy model teoretyczny oparty na teorii grafów, w szczególności jej chromatyczne aspekty oraz pewien model przeszukiwania grafu opisującego strukturę programu.
EN
There are several criteria for testing program correctness. In this paper we deal with the problem of automatic software testing under the assumption that the set of tests (assertions) is given for selected blocks of code. We simplify the analysis by assuming that the program being tested contains exactly one bug, but this does not lead to loss of generality. We consider some practical aspects of the above problem and a graph-theoretical model in general as well as some chromatic aspects of a graph searching model in particular.
EN
An approach to evaluate the number of errors encountered during the program testing process is proposed in the paper. Considerations are based on some program reliability-growth model, constructed for an assumed scheme of the program testing process. In this model the program under testing is characterized by means of the so-called characteristic matrix and the program testing process is determined by means of so-called testing strategy. The formula for determining the mean value of the predicted number of errors encountered during the program testing is obtained. This formula can be used if the characteristic matrix and the testing strategy are known. Formulae for evaluating this value when the program characteristic matrix is not known are also proposed.
PL
W artkule przedstawiono propozycję modelu wzrostu niezawodności modelu w procesie jego testowania. W celu uwzględnienia, bardzo często występującego w praktyce testowania oprogramowania, zjawiska wykrywania przez różne zestawy danych testowych tych samych błędów wprowadzono pojęcie tzw. macierzy charakterystycznej testowanego modułu. NA podstawie analizy zależności macierzy charakterystycznej i przyrostu wartości wskaźnika niezawodności modułu przedstawiono praktyczne oszacowania tego przyrostu dla wybranych postaci macierzy charakterystycznej testowanego modułu.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.