Article Preview
Top1. Introduction
The software product lines (SPL) symbolizes an admired technology for supporting the origin of a huge array of applications. They facilitate huge-scale reuse using core software architecture to address the recurring features for a certain domain and different variability points. The design of industrialized SPLs is incremental and steadily evolves for coping with the desires of stakeholder (Figueiredo, E., et al., 2008). The goal of SPL is to generate the tailored programs using different features set. Each feature poses a functionality increment related to stakeholder’s desires. Numserous programs are designed for selecting distinctive features. Based on SPL’s, it is feasible to construct the program families based on related programs (Kästner, et al., 2008). The Software Engineering Institute (SEI) describes the SPL as a group of software-intensive systems, which shares a feature for satisfying the requirements of market for deploying the applications in an arranged manner (Hallsteinsen, et al., 2008) . The aim of SPL is to reduce the cost of devising and evolving a software product. The SPL capture commonalities between the software products for the product family. By utilizing an SPL, the product developers can focus the product-specific issues. Numerous SPL implementations are done to adapt the features with coarse granularity. However, the fine-grained extensions, such as addition of statement in the method needs complicated workarounds or complicate the base code with annotations (Gurp, et al., 2001) . The purpose of testing in SPL is to analyze the core assets that are shared via products and derived from the product line, their individual parts and interaction. The testing in the context includes activities from the corroboration of the initial requirements performed by the customer to complete the product acceptance (Neto, et al., 2011) .
The majority of the software-reliability models are designed on the basis of failure patterns detected from the system test phase and try to project the failure pattern for predicting the software reliability (Kenny, 1993). Moreover, in order to predict the operational reliability, some of the models are utilized for evaluating the defects, which may persist in the code. These defects causes the failure of software’s during the operational use (Chaar, et al., 1993). The combinatorial testing is a specification-based test input generation technique adapted for the testing the application. The literary works based on combinatorial testing aimed to devise new techniques, which may produce test suites with less size, which may cover the pair-wise triple or n-way combination of factors. The problem-solving in combinatorial testing is established to be NP-hard problem. The conventional test case generation methods are effective in generating optimal or near optimal combinatorial test suites, but required more time. The combinatorial testing (Ramgouda, and Chandraprakash, V. 2019b) produces test suites based on artifacts. The artifacts produced functional desires or comprehensive development specifications. In combinatorial testing, the test cover is prepared for each combination to reveal the testing results. However, the size of the resultant test cases may be large, which may lead to huge test cost (Chen, et al., 2010). Combination testing is a technique, like black box testing, which adapts a sampling mechanism for generating the covering array in order to detect the software failures caused by the inputs attributes. The sampling method is based on the extraction of subsets from the whole parameters with error detection module for enhancing the efficiency and reducing the cost under preserving ability for error detection (Zhang, et al., 2017).