这些小活动你都参加了吗?快来围观一下吧!>>
电子产品世界 » 论坛首页 » 综合技术 » 测试测量 » 影响客户满意度的各个方面

共1条 1/1 1 跳转至

影响客户满意度的各个方面

高工
2012-11-30 12:46:58     打赏
          影响客户满意度的方面: 1.易用性不满足导致满意度降低。 原因:需求大方向明确,细节无人推敲。在使用过程中,业务部门的人员总会向我们提出零散的需求,比如:这个页面能不能做个导出,这个查询条件能不能给个默认值。这些易用性方面的小需求不满足,会导致客户满意程度的降低。就像综合查询,客户总是希望能做的更灵活,更易用,现在在使用确认的已经是第三版。 分析:这应该是从需求细化方面控制不到位造成的。对于开发和测试阶段,仅通过一句话的需求,没有需求说明书,也无法把客户的所有需求都考虑到,只能凭经验。更重要的是本来业务不熟练,更没有很多时间去考虑,所以,但也没有很好的建议,这种情况下最好能够有文档,这就需要需求人员在沟通的时候多注意细节,以此来提升客户满意度。但是的确时间是硬伤。而且从开发和测试人员的角度来讲,这种零散需求会打乱我们的工作计划,这也是为什么两周就能收到30个升级包,导致工作超负荷的很大原因之一。 2.使用过程中错误频出导致满意度降低。 这个原因很多,大家都认为报错类的bug应该在测试环节都避免掉,我自己也把这些问题原因分析总结过,但发现80%的错误都是测试环节很难可能发现的。举几个例子: a.某功能报错,找不到函数。 原因:开发调用了一个函数生成用户密码,这个函数是他们自己建了用来批量处理后台数据,引用了oracle自身的一个jar包,测试环境是同步生产库的,而在我发现错误的时候,开发只让我加载这个jar包,并说生产环境已经存在,由于是oracle自身的lib包,跟机器有关系,我也没关心他后台代码是如何实现的,就这样测试通过了。而后来发现生产环境并没有这个jar包,所以报错了,后来开发修改了实现方式; 分析:其实项目中的每个成员都应该有全局观,去探究这个接口到底应不应该这样用,这种问题应该在单元测试杜绝。 b.工作流审核通过后,下一个节点看不到信息。 原因:这是工作流物化视图刷新上的问题,偶现,但是一直没有解决过,后来去掉了工作流的物化视图; 分析:这些偶现的BUG,不能存侥幸心理。已经提了无数次的BUG,非要等到客户叫起来才修改。 c.人员上岗工作流审核通过后,没有做变更人员状态处理 原因:从界面录入,人员分类信息是必填的;但这个人员信息是从OA系统后台导入的,没有导入人员分类信息,而程序中对分类为空的没有做处理,这个分支在测试时也没有发现,因为根本不知道会从OA系统导入数据,所以产生BUG; 分析:我们需要了解更多的应用场景。   3.时间拖延导致满意度降低。 原因:这只能归结为资源不足了,现场的人都忙得手忙脚乱了。之前有一部分原因是对系统原来的架构不熟悉,原来的系统到处是陷阱,导致开发速度比较慢,现在已经好很多了;那些零散需求也是原因之一;一个很重要的原因就是出包一次通过率不客观,一个包退一个来回就得一天。 分析:资源不足永远是前期项目规划不到位的接口,项目经理应该注意去平衡资源与效率的关系。   4.系统性能导致满意度降低。 原因:很多,现场也正在做压力测试,并想办法改进系统性能。比如前台慢的改造为jsp页面,修改js加载方式,后台慢的做优化,加索引,改表结构。 分析:当初设计阶段没有考虑到客户满意度性能问题,后期花费较大的资源去整改,吃力不讨好。   5.对数据正确性有怀疑导致满意度降低。 原因:系统中的报表数据,除去算法上可能的偏差,再就是数据来源太多,从柜台/数据中心/手工导入数据/营销系统同步数据等等,而且有很多需要后台运行job来驱动数据采集和计算。其中要是有一个环节出错,得到的结果就无法预料了。现在的监控日志还不完善,客户看不到出错信息又觉得数据不对,产生怀疑是肯定的。 分析:不能图开发容易而省去步骤,授人与鱼步入授人与渔,要让客户了解系统的运行情况,日志监控必不可少,告诉客户怎么维护系统,总比每次都自个儿到现场查异常问题强的多。   以上这些问题已经让客户对我们的质量不信任了,客户也说我们测试不到位,作为一个测试人员,有时候一听到“测试”两个字,就会竖起耳朵,总认为出现问题可能是我没有测试好引起的,但现在越来越觉得,降低缺陷逃逸率,不仅仅是测试的事情。有时候需要项目组所有成员一起反省!



关键词: 影响     客户     满意度     各个     方面     原因     需求     测试         

共1条 1/1 1 跳转至

回复

匿名不能发帖!请先 [ 登陆 注册 ]