autorenew功能测试案例.docx

Autorenew功能测试一、案例分享功能概述在做印度项目的时候，遇到客户有这样的需求，就是用户订购产品到期后能通过短信的方式续订产品，这个需求涉及到了crm,信管，帐处和信控。帐处这边要关注的地方就是产品扣费提醒这一块。分为产品扣费成功提醒，产品扣费失败提醒和产品扣费前提醒。测试案例设计测试要点罗列：在设计测试场景和编写测试用例的时候，为了不遗漏我们的测试要点，我们可以把我们要测试的点用表格或则列表的方式列出来，这样可以清楚知道我们要覆盖的测试点。测试点枚举值账户类型预付费后付费产品类型autorenew非autorenew提醒类型扣费成功扣费失败扣费前测试场景和测试用例设计:按照上面罗列出来的测试点进行单个覆盖，设计测试场景如下编号测试场景测试用例1预付费用户订购非autorenew产品，产品到期，发送扣费前提醒2预付费用户订购非autorenew产品，产品扣费成功，发送提醒3预付费用户订购非autorenew产品，产品扣费失败，发送提醒4预付费用户订购autorenew产品，产品到期，发送扣费前提醒5预付费用户订购autorenew产品，产品扣费成功，发送提醒6预付费用户订购autorenew产品，产品扣费失败，发送提醒7后付费用户订购非autorenew产品，产品到期，发送扣费前提醒8后付费用户订购非autorenew产品，产品扣费成功，发送提醒9预付费用户订购非autorenew产品，产品扣费失败，发送提醒10后付费用户订购autorenew产品，产品到期，发送扣费前提醒11后付费用户订购autorenew产品，产品扣费成功，发送提醒12后付费用户订购autorenew产品，产品扣费失败，发送提醒这样场景设计出来后，发现要设计出来的测试用例至少有12个。如果再包含异常场景的话，那就会变得更多。由于当时项目很紧，测试时间有限。如果用例太多的话可能会影响测试进度，最后导致功能测试不完整，于是我就压缩了下测试用例的数目，但为了又能完全覆盖测试要点，于是采用了交叉覆盖的方式设计了测试用例。交叉覆盖就是一个用例覆盖多个测试点，同时相同的测试场景和相似的测试用例，可以进行不同点的覆盖。下面是设计的交叉覆盖用例：编号测试场景测试用例1预付费用户订购非autorenew产品，产品到期，发送扣费前提醒2预付费用户订购非autorenew产品，产品扣费成功，发送提醒3后付费用户订购非autorenew产品，产品扣费失败，发送提醒4后付费用户订购autorenew产品，产品到期，发送扣费前提醒5后付费用户订购autorenew产品，产品扣费成功，发送提醒6预付费用户订购autorenew产品，产品扣费失败，发送提醒主要测试步骤：信管开户，查看账户信息跑日帐，查看日志查看提醒数据，有相应数据生成测试用例执行测试执行的主要过程是信管开户和产品扣费，产品首次扣费通过产品订购来实现，之后的扣费是通过帐处的日帐扣费来实现。由于每个测试用例都有信管开户是第一步，这时候我就想到了，如果每个测试用例都要新开户，这样的话垃圾账户数据可能太多，于是我就想到能不能减少开户数据。这样有两个好处，一个是减少垃圾数据，另外也可以提高我们的测试效率。后来我发现在正常的情况下，我们开户出来就可以验证扣费成功这个提醒，然后在生成下次扣费时间的时候，可以验证产品的到期提醒也就是扣费前的提醒。最后我们在构造余额不足的情况下，即可以验证扣费失败的提醒。由于我们是有两种账户，一个预付费和一个后付费，这样我们只要开出来两个账户就可以验证完所有的测试用例。主要测试数据按照上面的测试计划，我们预后付费的测试用例的执行顺序是：验证扣费成功提醒-----验证扣费前提醒-----验证扣费失败提醒下面是后付费测试的相关数据后付费扣费成功提醒U2P_AR_BI_001_008帐处扣费，发送提醒业务需求Autorenew= Y产品，扣费成功目标帐处扣费成功，提醒发出Pre-requisites1.后付费产品账户：104115Post-requisitesnone测试参数Step 1: 开户，查看三户信息v_SO_NBR====256487serv_id====4114acct_id====104115cust_id===db select * from CPromCharValue where m_llObjectId = 4114;_oid, m_llObjectId m_llPromNo m_nObjectType m_nSpecCharId m_szValue m_llGroupId m_dValidDate m_dExpireDate 645, 4114, 40000256487, 0, 22, 1, 6282, 20151014203134, 20