BPT - Business Components v/s Scripted Components
Before we dive into the comparison, I would like to define the key terms for this article
It is important for us to understand the key difference between a QTP Test and a Business Process Test. A QTP Test can involve re-usable keywords through use of Actions and Functions. A QTP test can call these Actions and functions in sequence within in the same Run session
Same run session, now this is where the key difference lies when it comes to BPT. In BPT each component (Scripted/Business) is similar to an individual QTP Test which contains only one Action. So when a business process runs it runs each component one by one. Since each component is similar to a QTP Test, QC loads the component in QTP, starts the run, once the run finishes; the next component in the Test is loaded. BPT then collates all the results under a single test result summary. The load, run, stop and unload sequence of components decreases the performance of Business Process execution over normal QTP frameworks. The more the no. of components in your script, the slower it would be.
Business Components v/s Script Components
A business component is a keyword driven component which can be used to perform operations on selected objects present in OR. Business components are easy to create and the process can be easily taught to manual testers as well. This point which projects that BPT testing can be handed over to manual testers for maintenance is the key attraction to companies for going for Business Components over Scripted components.
When choosing Business components the development phase becomes easier, as not a great deal of technical or scripting skills are required by the team. Though most project miss to see is the maintenance and execution cost involved when going with Business components. Business components with advantage of being simple take away the power of flexibility. We cannot use loops, if-else, select statements inside a business component. This increases the number of components that needs to be developed. Consider a online product ordering system, the general sequence to order a product may be something like below
Now Launch Application and Logout are two very common components that would be used across almost all the test case. Product Configuration for different products may involve different screens on the UI. This means for every product we might need to create a different business component. Now these components may have some code in common and rest different from others. To support 15 products in our Test Suite we would need 15 product configuration components + 7 components.
Not every test in our component uses all these components, some test cases may require additional components to do extra verification or they do deviate from the normal flow. This makes it necessary to create as many re-usable components as possible, which are required to implement the test.
Assume that our 15 product test suite requires additional 13 components for product specific verification. Our final test suite implementation now has 35 components and 15 Business process tests. Each business process would use Avg. of 8-9 components. This no. is not huge as such but in projects which involved E2E (End to End) testing the no. can grow as huge as 80-100 components for some of the tests.
In BPT when a test fails, it needs to be run from the start. The test cannot be resumed from a component in between. This is a limitation of BPT. So if our test fails on the 8th component, there is now way to re-run it from that position. This makes it difficult to unit test business process tests and makes the process a bit more time consuming than normal
Now during maintenance consider that one of the objects common across all product configuration gets removed. This change would require us to open each product configuration component and then remove the object. This not a huge task for 15 products, but certainly a huge task when you are supporting over 100+ product configurations. QTP only allows opening one component at a time which means the update can be applied one by one only
To summarize using only Business components would lead to
Now I will show how using Scripted Components we can overcome the above issues
Function LoginToAccount()
Browser("").Page("").WebEdit("userName").Set Paramater("sUserName")
Browser("").Page("").WebEdit("password").Set Paramater("sPassword")
Browser("").Page("").WebButton("Login").Click
End Function
Call LoginToAccount()
The advantage of using this approach is that everything moves into library file. We cannot open multiple components in QTP but we can open multiple libraries at the same time. This makes it easy to maintain scripts when multiple components need to be updated
If UCase(Parameter("bSearchProduct")) = "TRUE" Then
Call SearchProduct()
End If
If UCase(Parameter("bAddProductToCart")) = "TRUE" Then
Call AddProductToCart()
End If
This merging of component reduces the average no. of components required to create a Business Process test. This reduction will result in performance improvement in execution. To give an example, I was able to reduce avg # of components in our project from 15 to 5. This gave an execution time reduction by 120 sec per script. This in a test suite of 1600 scripts was a huge saving. It also reduces the number of components in the Test suite, making maintenance easier.
Call CommonProductConfig()
Select Case Parameter("strProductName")
Case "ProductA"
Call ProductAConfig()
Case "ProductB"
Call ProductBConfig()
Case …
End Select
This approach makes maintenance easier when something in the Common product configuration changes as the changes only need to be done in CommonProductConfig function. This also increases the code re-usability in components.
arrProductNames = Split(Paramater("sProductName"), ";")
For each sProductName in arrProductNames
Parameter("sProductName") = sProductName
If UCase(Parameter("bSearchProduct")) = "TRUE" Then
Call SearchProduct()
End If
If UCase(Parameter("bAddProductToCart")) = "TRUE" Then
Call AddProductToCart()
End If
Next
Note: We didn’t touch the core functions here and they still process the normal product name, they don’t interpret “;” separated products. This logic is instead kept in our scripted component code. That is the reason we add the code Parameter(”sProductName”) = sProductName inside the loop
We can see how using scripted components we have enhanced our test suite to be more flexible and easily maintainable. But for few this may also appear as a disadvantage as it requires some coding skills for maintaining the suite. But isn’t it worth to upgrade skills for people maintaining the test suite? Well I will leave that answer to you
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
.NET 6 - AutoMapper 및 데이터 전송 개체(DTO) 🗺YouTube에서 전체 동영상을 볼 수 있습니다. 오늘 AutoMapper가 무엇이고 왜 필요한지 설명하는 것으로 시작할 수 있습니다. 이제 nuget 패키지가 설치되었으므로 automapper 구현 및 활용을 시작...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.