Test plan for CMS

integration test
Targets Requirements
- This plan use for test correctness of CMS when integration with other - One CMS
services - One PLM
- Can test more testcases in one time, use same CMS and DB - One BI
- Can build to a runnable program which automatically test user's credit in - One AM
Unity system - One AE
- One Admin Portal
- One Agent Portal
- Use RealResultFakeBetting

Common convention Common currency data

To run more testcases in one time and use same DB and CMS we need some This currencies and conversion rates can be used in
conventions when building user hierarchy. It'll make a testcase independently all testcases. It's easily for us when design a testcase
with others. Basicly, one testcase will use distinct company user and its and verify its result.
downline with other testcases. Username of an user or betting account will be
name by this rule: Currency/
username = user/account's code + testcase number + [quality number]* Conversion RMB SGD USD EUR
(*) optional rate
RMB (*) 1 0.8 0.4 0.2
User/Account Code
SGD 1.25 1 0.5 0.25
Company agent CA
USD 2.5 2 1 0.5
Master agent MA
EUR 5 4 2 1
Normal agent NA
(*) Base currency
Bet user BU

Betting account AC

Example convention
We must apply the naming rule when setup DB before running a testcase.
See below example:
Testcase 1 requirements: Testcase 2 requirements:

Company Company

Master Master Master

Normal Normal Normal

BetUser BetUser BetUser BetUser

BettingAccount BettingAccount BettingAccount BettingAccount BettingAccount BettingAccount

Needed DB
Common testflow
We'll test a testcase more time with a specific number of bets input. Each time we run a
testcase we call it as round and later round will has larger input with the previous. It'll
help us easy for control and verify the result in the first run. For example, testcase 1 will be
tested in 3 rounds, in first round we only test with 10 bets and then test with 30 bets in
next round and finally we'll test with 100 bets.
I break down a testcase into phases, and for each phase a set of potential steps will be
done. You can see the testflow diagram below. A testcase doesn't need perform all steps
in a phase. It can only do a subset of step. For example, If we want test with normal bet
then we don't need generate missing or dangling bets (step 2.2 and 2.3).
Start

Step Action
Phase 1:
1-1 Setup currency and currency conversions
Setup DB
1-2 Setup users

1-3 Setup betting accounts

Step Action
Phase 2: 2-1 Config and run BI client
Run testcase
2-2 Generate missing bets
2-3 Generate dangling bets

Step Action Step Action

Phase 3:
Calculate Collect and calculate expected user's credits (base on 4-1 Verify data in database
3-1
expected results bets) after finished phase 2
Collect and calculate expected user's credit (base on 4-2 Verify CMS
3-2
bets) after resolved bets
4-2 Verify BI
Generate resettled bets (resettle missing/dangling bet or
3-3
normal bet) 4-3 Verfify Admin Portal
Collect and calculate expected user's credits (base on
3-4 4-4 Verify Agent Portal
bets) after resolve resettled bets

Step 2-1: Config and run BI clients Step 2-3: Generate dangling bets
(will update later about how to config) Generate dangling bets similar with generation missing bet except one thing we need
change value one of these action pack's properties after inserted: odd, pivot, target type,
Step 2-2: Generate missing bets version, league and teams name. We can clear league name.
To generate a missing bet, we have to insert a new action pack to action_packs table and (1) logout account
then insert new bet to fake_bets table, it must has similar information with action pack we (2) insert a new action pack to action_packs table
just inserted. (3) insert a new fake bet to fake_bets table
(1) logout account (4) clear league name of action pack we just inserted
(2) insert a new action pack to action_packs table (5) login account
(3) insert a new fake bet to fake_bets table
(4) login account

Step 3-1: Collect and calculate expected user credit after finished phase 2
If user's type is bet user, we need to collect user's bets and calculate about (see appendix to get formulas and
queries):
(1) credit: current user's credit. It's credit field in bet_users table.
(2) turnover: total bet's stake was placed. Not include CANCELLED/REJECTED bets.
(3) outstanding: total bet's stake of unsettled bets. It's oustanding field in bet_users table.
(4) PL: total bet's return amount of settled bets. It's pl field in bet_users table.
(5) paid commission: total commission amount user was paid for its agents.

If user's type is agent user, we need to collect downline bet user's bets and calculate about (see appendix to get
formulas and queries):
(6) credit: current user's credit
(7) downline credit: total credit of all its downline users (both child agent and bet users)
(8) downline outstanding: total oustanding of all its bet users ("i think we should call it as member outstanding
similar with member turnover or member PL because only bet user has outstanding")
(9) member turnover: total turnover of all its bet users.
(10) member PL: total PL of all its bet users.
(11) member commission: total paid commission of all its bet users.
(12) received commission: total commission amount that user was received.

Finally this step, we'll have these tables and can use them for verification steps:
Paid
Bet User Credit TurnOver Outstanding PL
Commission

Agent Downline Downline Member Member Member Received

Credit
User Credit Outstanding Turnover PL Commission Commission

Step 3-2: Collect and calculate expected user's credit after resolve all bets
We'll collect and calculate again user credit informations similar with step 3.1 after resolve all
bets were placed in phase 2.

Step 3-3: Generate resettled bets

After bet was settled, we can make it resettle by change its status and return amount in
fake_bets table and then we also need to restart AE.
(1) logout account
(1) change status and return amount of bets we want resettle in fake_bets table
(2) login accout

Step 3-4: Collect and calculate expected user's credits after resolve all resettled bets
After generate resettled bets, we also collect and calculate user credit informations again similar with step 3-1
after resolve all resettled bets which were generated in previous step.
Step 4-1: Verify data in database
After collect and calculate expected user's credits base on bets in step 3-1, 3-3, 3-4, 3-6 and 3-7.
We can use them to verify data in database, BI, CMS (by query DB), Agent Portal and Admin
Portal. To verify data in database we'll query and calculate these fields (see appendix to get
queries):
+ Bet user's credit, outstanding and pl: query directly from bet_users table.
+ Bet user's paid commisson, turnover: query and calculate from bet_transaction table
+ Agent user's credit: query from agent_users table
+ Agent user's downline credit, downline outstanding and member PL : query and calcualte
from bet_users table.
+ Agent user's member turnover, received commission and member commission: query and
calculate from bet_transaction table.

Step 4-2: Verify CMS

We can call directly to CMS by thrift client to get user's credits information. There are api in CMS
we can use to verify:
+ getCredit
+ getPLInfo
+ getOutstanding
+ getBalance

Step 4-3: Verify BI

we can call directly to BI to get response of these api and verify them with our expected results
which were calculated in previous step (see appendix to get details of url and params):
+ getUserCredit
+ getUserBalance
+ getOpenBets
+ getSettledBets
+ getMultiBetsStatus

Step 4-4: Verify Admin Portal

we can call directly to Admin Portal to get response data of these pages and verify them with
expected results (see appendix to get details of url and params):
+ Betting report
+ PL report
+ Resolve bets
+ Rectify bets

Step 4-5: Verify Agent Portal

we can call directly to Agent Portal to get response data of these pages and verify them with
expected results (see appendix to get details of url and params):
+ Balance information in Account Information page
+ Statistics
+ Downline list
+ Downline list detail
+ P/L report
+ Unsettled report