软件测试之客户化测试

从事软件测试工作已经5年了,仔细想想,还真没听说过有一种测试叫客户化测试。看似陌生的名词,其实并不那么陌生,不信,先看看客户化测试的概念:
  所谓客户化测试,是针对一个软件产品的客户化定制能力所做的测试,它侧重于模拟用户使用产品的场景,通过对产品的公开文档、教程以及产品开发接口的使用,按照产品服务部门提供的客户需求,开发相应的功能定制样例,并撰写相应文档以供客户学习和参考。

看完概念之后,忍不住感叹一下,哦,原来这是场景测试啊,场景测试对于测试人员来说应该并不陌生,但是,客户化测试真的等同于场景测试么?带着这个问题,我们继续阅读。

既然名字称为客户化测试,那么,作为测试人员的我们首先可以确定的是,这一刻,我是真正的客户,或者说,扮演真正的客户。客户是如何对待购买的产品呢?可以回忆下自己购置物品时的情景,一般来说,对于新购置的物品,我们会先阅读说明文档,当然,并不是所有人都这么做,这种情况目前先排除在外。

通常来说,一个软件产品提供给客户的除了编译、包装好的安装材料,就是说明文档了。作为软件产品的客户,他们如果想要基于该软件产品做定制开发,就必须通过说明文档对软件由一个全面且深入的了解,尤其是在开发接口(API)方面。所以,为了更好地扮演客户,客户化测试组的测试工程师必须跟客户一样,只能从说明文档获取开发所需的各种信息。也就是说,他们不能去阅读开发设计文档和真正的实现代码。

但问题是,有些项目的说明文档并不会第一时间就被写出来,此时如果需要对某特性做客户化测试该怎么办呢?

其实虽然在每一个开发周期的开始阶段我们看不到完整的说明文档,但总是会有一些相关文档的草稿存在,尽管不完整,甚至可能被推翻或者取消,但早一天了解客户能拿到什么,就多一天时间可以去做客户化测试的设计。

一般而言,客户化测试是允许查看需求分析文档的,因为既然是模拟客户,那么客户的需求显然是客户化测试人员应该知道的东西。还有就是解决方案的规格说明书以及功能测试的设计文档,前者是在客户需求的基础上提出的方案及相关功能描述、风险、优先级排序等内容,后者重描述的功能特性肯定会写入给客户的说明文档中。而我们所说的给客户的说明文档,一般由专门的文档编写人员来负责。

客户化测试的软件设计流程:

一般来说,客户化测试由4个阶段组成:

  确定于研究需求阶段
  设计阶段
  实现与测试阶段
  文档与教程验证

所有需要测试的客户化场景都需要与软件服务部门共同商讨确定,以确保选中的是客户最需要的。

要更好的扮演客户,应当对客户的行业有所了解。所以客户化测试人员需要在一开始就清楚某些产品特性是来自哪些客户的需求,作为这些客户,在对这些产品特性进行客户化定制的时候会提出什么样的目标。

确定于研究需求的阶段:这就要求我们需要尽可能早的介入测试,尽管可能得不到完整的说明文档,但通过一些相关文档的草稿及需求文档,我们也可以尽可能早的进入到客户化测试的设计阶段。
设计阶段:顾名思义,就是进行测试的设计。
实现与测试阶段:这部分包含开发人员对产品的实现与正式以客户的身份介入测试的过程。
文档与教程验证:由于说明文档与产品是同时交付给客户使用的,因此,这里免不了需要对文档及教程进行相应的测试。

通过上述的描述,尽管不是那么详细,但我们已然可以解答文章开篇的问题了,客户化测试是否等于场景测试?答案是不等于,但是包含场景测试,因为我们需要模拟客户对产品在任何可能的情况下的使用,是否能够正常使用以及使用之后是否会对产品本身有相应的影响是客户化测试的最主要的关注点。与此同时,还需要对说明文档及教程进行相应的文档测试。

因此,客户化测试,或许我们可以列出以下一个公式:
  客户化测试=场景测试+功能测试+性能测试+回归测试+文档测试

测试的坑很深,需要我们一步步去探索,客户化测试,好吧,貌似网上很少有这种说法的文章,只是看到了,就随便聊一聊了。

转载于:https://www.cnblogs.com/Ribbon/p/4819654.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值