验证内容
1、产品的功能。产品功能由企业提供,企业可以根据自己的需求提供功能清单,也可以通过与多家供应商交流后,列出自己所需要的功能;
2、产品的性能。性能指标也是由企业提供,并建议提供具体性能指标所应用的环境及硬件设备等测试环境要求;
3、产品的API适用性;
4、产品相关技术文档的规范性、完整性;
5、涉及到自定义功能研发的,还需验证API开放性,供应商实施能力;
6、企业资质规模及企业实施案例等。
验证内容归根结底,就是证明企业选择的产品或供应商能够满足需求,并且提供的信息准确可靠。
PoC测试工作准备前提
1、前期调研充分,并已经对产品或供应商有了较深入的沟通了解;
2、企业对自己的产品需求比较清晰。
PoC测试工作参与者
使用用户代表、业务负责人、项目负责人、技术架构师、测试工程师、商务经理等
PoC测试工作准备文档
1、PoC测试工作说明文档。内容包括测试内容、测试要求(如私有化部署)、测试标准、时间安排等;
1、功能测试用例。主要确认功能可靠性,准确性。内容包括功能名称、功能描述等;
2、场景测试用例。主要测试企业团队实施响应速度、实施能力、集成能力。这部分通常按照企业需求而定,不建议太复杂,毕竟需要供应商实施干活儿的嘛,拖得太长企业耐性受到影响,时间也会拉长。
3、技术测评方案。主要验证产品的性能、功能覆盖情况 、集成效率、技术文档的质量。
4、商务测评方案。主要包括企业实力、企业技术人才能力、版权验证、市场背景、产品报价等。
PoC测试工作
第一阶段 工作启动
由商务或者对外代表对供应商发布正式邀请并附PoC测试工作说明。
建立PoC协同群。以满足快速沟通,应答。
涉及到私有化部署的,需要收集供应商部署环境要求,并与供应商一起进行部署工作,同时企业参与人员对部署工作情况做好记录。
第二阶段 产品宣讲及现场集中测试
供应商根据企业提供的PoC测试工作说明及相应测试模块的用例或方案进行产品现场测试论证。
企业参与人员参与功能测试,并填写记录和意见。此阶段供应商往往需进行现场操作指导:。
第三阶段 技术测评
供应商根据企业提供的技术要求给出相关支持文档,企业进行现场比对,根据实际情况进行统计记录。并保留供应商提供的资料和对比记录。
涉及到场景demo设计的,建议企业对实施人员能力、实施时长、实施准确性进行比对。
第四阶段 间歇性测试工作
该阶段是在第一阶段启动时,就可以开始了。测试功能外,还包括关键用户使用的体验心得、易用性评价。该部分允许企业用户主观评价,建议可以扩大范围组织间歇性测试,并做好测试用户记录。间歇时间1天或者多天根据实际情况安排。
第五阶段 商务验证
供应商根据企业提供的商务测评方案,积极配合工作。涉及到客户核实的,还需要企业进行考证。该部分工作也是从第一阶段启动时,就可以开始了。
第六阶段 背书归档、分析总结
每个阶段的工作都需要记录好参与人、时间、工作说明,并将测试过程中企业的、供应商的文档分类归档。
对每个阶段进行分析对比,总结评价。
进行整体工作分析总结。
PoC工作按照不同企业,和程度,测试的方式和投入力度不一样。但是目的都是相同的——验证产品或供应商能力真实满足企业需求。
对PoC的总结可能比较片面,甚至可能与大家理解有偏差,欢迎共同交流,一起成长。
银行资产管理项目。它的底层逻辑延续第三、第四讲的观点:云桌面的POC不是测试最好的效果,而是测试最坏的效果。
通常的POC测试都是将服务器和各类设备搬到用户现场,有一个重要的目的是避免网络延迟和丢包,希望在最合适的硬件环境+最好佳的网络,以便为客户提供最好的体验。
POC测试,即Proof of Concept,是业界流行的针对客户具体应用的验证性测试。
简介:
1、POC测试,即Proof of Concept,是业界流行的针对客户具体应用的验证性测试,根据用户对采用系统提出的性能要求和扩展需求的指标,在选用服务器上进行真实数据的运行,对承载用户数据量和运行时间进行实际测算,并根据用户未来业务扩展的需求加大数据量以验证系统和平台的承载能力和性能变化。
2、特别是在应用系统选型阶段,一些大型企业的 业务流程比较复杂,并非单一的功能性演示就能覆盖现实的业务需求,这时候需要事先划定一个小范围的实验对象(但是业务逻辑的复杂性要有典型性,有代表性),通过小范围的项目导入与实施,从真实业务的实践到战略意图的实现,来验证系统方案是否能满足用户的需求,从而作出更客观更准确的判断。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)