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

共1条 1/1 1 跳转至页

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

skm2007
高工
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来驱动数据采集和计算。其中要是有一个环节出错，得到的结果就无法预料了。现在的监控日志还不完善，客户看不到出错信息又觉得数据不对，产生怀疑是肯定的。 分析：不能图开发容易而省去步骤，授人与鱼步入授人与渔，要让客户了解系统的运行情况，日志监控必不可少，告诉客户怎么维护系统，总比每次都自个儿到现场查异常问题强的多。   以上这些问题已经让客户对我们的质量不信任了，客户也说我们测试不到位，作为一个测试人员，有时候一听到“测试”两个字，就会竖起耳朵，总认为出现问题可能是我没有测试好引起的，但现在越来越觉得，降低缺陷逃逸率，不仅仅是测试的事情。有时候需要项目组所有成员一起反省！
回复
收藏
0



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

共1条 1/1 1 跳转至页

回复

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