Poc&Demo测试流程规范2015.docx

Poc&Demo测试流程规范 阅读之前： 如客户未强行指定要POC测试,请不要主动引导客户进行POC测试，因为POC需要耗费公司大量人力、精力、资源以及你的时间。 如客户有测试的意向或需要证明技术是否可行时，请引导到用现有的客户案例或小i官方的案例进行展示，打消客户非要进行POC的念头。 如果必须要进行POC测试，是需要销售发起POC申请流程的，测试完成后，销售需要提交测试报告，请知晓。 使用一切技巧，打消或减少POC的机会，是一个售前基本的客户控制技能，以不做POC测试拿下客户为上策。 如果必须POC测试，尽量引导客户将测试环境部署在公司远端，而非一定要在客户现场，原因将测试成本降到最低。 如果客户不接受远程部署，必须到测试现场进行POC时，请仔细阅读以下。 POC测试目的 遇到竞争对手时，向用户展示我方知识运营能力（处理复杂问题的能力）、背景语义库能力（迅速完成知识库内容）、基础语料库能力（通用聊天等）、逻辑推理能力（上下文）、多渠道接入能力等方面的优势。 POC测试具体流程图 明确测试需求和知识范围 1、关于测试素材提供的策略技巧 建议1： 知识库容量：建议客户提供的知识条数控制在100条左右；（这里指的是需要和竞争对手进行PK时的情况，假如小i单方面展示或演示，则知识条数应引导控制在30条以内） 测试准备时间：5个工作日时间较合理。 原因：对于我们有积累的领域，对我们更有优势；如果知识点少（假如10条），靠人工用相似问的方式进行堆砌（即竞争对手用穷举的方式进行准备），则测试的效果相差不大，较难体现竞争优势；如果知识点太多（如上万条），只能靠搜索的方式，则测试的效果也会相差不大，较难体现竞争优势。故将知识条数控制在100条左右最为合理，既可以展示我们的技术，又可以屏蔽竞争对手。 建议2： 引导客户提供的业务知识的种类不宜过多，尽量控制在4个种类之内。假如，测试信用卡业务，尽量选取问题的相似性相近的业务类别，如还款、查账、额度查询、业务办理。 原因：当知识点比较相近时，只输入某些关键词（竞争对手的做法）是无法准确定位到某个知识点，业务越相近，关键词的方式越容易冲突，所以提供如上方式的素材是有利于区别关键词和智能语义理解和处理。如果竞争对手是用相似问的方法进行堆砌，在遇到相似的问题，很容易发生互相冲突的状况。 2、确定测试内容及预期效果，并以文档方式相互确认 售前人员需拿到客户提供或确认的测试问题和答案，及客户需要测试的功能要求及效果（如是否P4、图文消息、上下文、反问、动态菜单等）。 注意：不管测试何种渠道以及是否有指定要求，公司测试组默认会在所有测试Demo中放入统一的基本对话、通用聊天及第三方服务（天气、股票、火车票、笑话、餐馆、酒店）； 在测试组工作之前，测试组会根据测试要求提供演示word文档形式与售前确认测试场景及效果。当测试场景及效果要求复合测试预期的时候，测试组才会开始实际工作。 Poc&Demo建设和调试优化 知识素材整理工作 测试组会整理用户提供的知识素材、标准问及答案。知识分类、标准问和标准答案尽量按照原始文件；如果客户不提供原始素材，让我方按案例经验提供，我们通常会选择该领域中最常见问题（即平时积累并整理的领域语义）。无论客户是否提供知识素材，测试组均需要将整理后的表格提供给售前。 售前可以根据客户关系情况，觉得是否将知识整理的结果发给客户。这样做可以让用户知道我们的知识整理的结果，并作为测试回答准确率的依据。 编写测试问题 测试组根据标准问编辑测试问题?【问法要常见且差别要大】，如有类似环境，可从老环境中收集测试问题， 测试问题要尽量多。 测试组测试 测试组根据测试问题，调试模版，要保证所有已知测试问题正确，并能够精确匹配； 测试组完成测试 按照演示文档要求，实现所有效果，完成后，需要对知识库回归测试。 修改演示文档 修改演示文档，加入新增内容或修改原有内容。 输出测试演示文档 将知识整理后的表格（标准问、标准答案）、完善后的演示文档、测试样例（每个标准问提供3-5个测试样例）、外网访问地址、用户名和密码统一提供给售前。 售前根据演示文档的内容进行测试，如有问题，和测试组进行反馈，直至售前判断可以满足客户测试要求为止。 用户现场测试（第一轮） 争取以一轮的测试方式进行PK掉对手或实现技术最高分，要保证这个结果，请用好下方提供的测试策略技巧。 测试过程售前主导 测试的过程最好由售前现场主导，尽量不要让客户自行测试，否则客户测试的过程可能会天马行空。 按照测试文档进行演示 售前尽量说服客户按照我方的演示文档及具体测试问题进行测试，即使不能说服也可让用户先入为主，以我方的测试问的模式来提问。 注：根据客户关系程度，决定是否可以把测试问题提供给客户。如客户关系不能完全把握时，不要将测试问题全部提供给客户