International Journal of Software Engineering and Knowledge Engineering

Software transactional memory (STM) programs usually use more memory resources than traditional programs. Therefore, estimating an upper bound of memory resources used by an STM program is crucial for optimizing the program and reducing the risks of out-of-memory runtime exceptions. However, due to the complex nesting of transactions and threads, the estimation problem is challenging. In our previous work, we have developed several type systems to address the problem for core imperative languages with STM primitives. This work advances our previous works, in which we add object-oriented constructs to the language while keeping the STM primitives, to make the language closer to practical languages. Then, we built a type system to statically estimate the maximum memory required by well-typed programs of the language.

The equivalent mutants problem is one of the crucial problems in mutation testing. In consequence of its existence, the effectiveness of mutation testing is underestimated. In addition, it will produce a certain amount of useless overhead. Equivalent mutants cannot be detected by any test input. The existing works mostly focus on static analysis to detect, or avoid generating, the equivalent mutants. The essence of these methods is to use prior knowledge to establish some rules of program equivalence. However, (1) it needs a lot of professional labor to sort out the equivalence rules, and (2) only a small part of the rules can be determined in advance, because of the diversity of mutation operators and mutation targets. Consequently, the best result reported so far is 50% of the equivalent mutants can be detected. Since it is generally believed that manual judgment of program equivalence is the most reliable, this paper proposes a novel method to automatically detect equivalent mutants by tracing program behavior like the professionals. The weighted software behavior graph is utilized in the detection of equivalent mutants for the first time. This method can not only figure out different execution paths, but also be sensitive to execution frequency. By comparing the weighted software behavior graphs of an alive mutant and its original program, we are able to examine more precisely whether the alive mutant is the same as the original program, in terms of the state of infection and/or the propagation. Evaluation results on an open dataset of manually evaluated equivalent mutants show that our approach can detect 77.5% of all the equivalent mutants, which is much higher than the existing static methods.

PHP (Hypertext Preprocessor) is a scripting language that has been widely used in web development. This paper conducts an empirical study on bugs in PHP. By analyzing 35,921 bug reports, 6524 revisions, and root causes of randomly selected 500 bugs, we find that: (1) Among all the 385 versions involved in these bugs, there are the most bugs in PHP 4.0.4, PHP 4.0.6, and PHP 4.0.3; Documentation bugs are mainly distributed in PHP 4.y.z and PHP 5.y.z; Security bugs are distributed primarily in the relatively later normal versions of PHP 5.y.z. (2) Documentation, Compile, and Scripting Engine packages are greatly affected by bugs; 73.71% of documentation bugs affect documentation; PHAR, EXIF, and GD are more affected by security bugs. (3) It may be not difficult to repair most bugs since the number of modified lines of code and files are limited; However, nearly 11% of bugs need more than one year to repair; Compared with documentation bugs, security bugs are more difficult to be repaired; The duration of bugs in PHP 8.y.z is shorter than in other versions. (4) Semantic bugs and documentation bugs are the more common root causes of bugs than others. Besides, among semantic bugs, the “Missing Features” bugs and “Processing” bugs are more than others. These results could indicate some potential problems during the detecting and repairing of PHP’s bugs. These findings reveal some laws of bugs in PHP. It could assist developers of PHP in improving their development quality, assist maintainers of PHP in detecting and repairing bugs more effectively, and suggest users of PHP evade potential risks.

In recent years, many intelligent optimization algorithms have been applied to the class integration and test order (CITO) problem. These algorithms also have been proved to be able to efficiently solve the problem. Here, the design of fitness function is a key task to generate the optimal solution. To better solve the class integration and test order problem, we propose a new fitness function to generate the optimal solution that achieves a balanced compromise between the different measures (objectives) such as the total number of stubs and the total stubbing complexity in this paper. We used some programs to compare and evaluate the different approaches. The experimental results show that our proposed approach is encouraging to some extent in solving the class integration and test order problem.

Bug reports are submitted by the software stakeholders to foster the location and elimination of bugs. However, in large-scale software systems, it may be impossible to track and solve every bug, and thus developers should pay more attention to High-Impact Bugs (HIBs). Previous studies analyzed textual descriptions to automatically identify HIBs, but they ignored the quality of code, which may also indicate the cause of HIBs. To address this issue, we integrate the features reflecting the quality of production (i.e. CK metrics) and test code (i.e. test smells) into our textual similarity based model to identify HIBs. Our model outperforms the compared baseline by up to 39% in terms of AUC-ROC and 64% in terms of F-Measure. Then, we explain the behavior of our model by using SHAP to calculate the importance of each feature, and we apply case studies to empirically demonstrate the relationship between the most important features and HIB. The results show that several test smells (e.g. Assertion Roulette, Conditional Test Logic, Duplicate Assert, Sleepy Test) and product metrics (e.g. NOC, LCC, PF, and ProF) have important contributions to HIB identification.

The development and operation of Online Judge System (OJS), which is used to evaluate the correctness of programs, is a nontrivial and difficult task due to the various functional and non-functional requirements. However, although many OJSs have been developed and operated, and their usefulness reported, the theory for constructing OJSs has not been sufficiently discussed. In this paper, we present the functional and nonfunctional requirements oriented to OJS as well as demonstrate the internal components and software architecture of an OJS, which has been in operation for over a decade and has evaluated over six million solutions. We also present real-world experiences and challenges encountered during this long journey of our OJS.