跨部门的bug的沟通

旅游接入支付传递参数遇到了一个问题,支付中存在如果选择第三方支付后又取消支付后跳转到哪里的问题,支付那边需要传入rback参数。旅游进入支付页面后选择支付方式前,后退的功能是支付那边做的,从哪里进入支付便会回到哪个页面。如果在选择支付方式页面选择了第三方支付,支付宝或者违心支付,在第三方支付页面选择后退取消支付,这时因为是第三方支付跳转到哪里不是我们的系统能控制的。所以支付那边扑获手机的回退事件进行控制,这时rback如果个BU传递的有参数,则按照部门传递的地址进行回退,如果没有传递则走支付的回退到支付方式选择页。

而我们理解错误了,旅游页面进入支付方式选择页面,在支付方式选择页面进行回退不是回退到进入支付的页面而是支付的前一页。我们创建订单时接口会返回支付相关的信息,其中包括参数rback,接口返回的rback是一个字符串,测试说这个接口返回的这个rback为空才是正确的。这是双重的理解错误啊!

其实我们当时的功能是正确的,支付那边曾发过一个邮件主题是“第三方支付,放弃回退到支付方式的BU”,我们这边的测试注意到前开发这边已经修改了rback传递为空走支付的逻辑回退,在加上测试理解错误我们对rback的用法也没有仔细的看契约,导致不知道要怎么改。

时间: 2024-08-26 19:50:48

跨部门的bug的沟通的相关文章

王一恒《跨部门沟通与协作》讲座学习笔记(图文)

上周六,參加了王一恒老师的<跨部门沟通与协作>讲座,老师讲的一些沟通的技巧和理论还是非常有实际操作价值的,在这里与大家共同分享一下. 沟通最忌讳的是一脸死相. "沟"是两个人的事情. 沟通的黄金法则:你希望别人如何对待你,你就如何对待别人. 沟通的最大问题:对别人要求高,自己做不到. 沟通者先管理心情,再管理表情,在处理事情. 微笑是沟通的通行证. 高度决定态度,态度决定一切. 智者.听而问.聪明者,知而言. 脑袋决定位子,格局决定现状. 穷人没有东西给予.也能够给五样东西

互联网产品跨部门沟通的10个原则(转)

摘要: 向对方重复沟通中的主要内容:利用澄清的方式提出不明白的内容:谈论重点议题时尽量不要打断对方讲话: 对产品经理来说,跨部门沟通不良,可能会让他好不容易建立起来的自信瞬间摧毁. 你认为十万火急的事,到了其它部门主管口中,竟然成了“芝麻绿豆大的事”:原本应该合作解决的问题,到了跨部门会议上,又沦为“各弹各的调”,找不到共识. 到底,在不同部门各有不同立场与利益的情况下,怎样才能把话说清楚,把成果做出来?很多人抱怨为什么跨部门沟通这么难?其实,只要掌握几个典型基本原则,进行无障碍的跨部门沟通,并

王一恒《跨部门沟通与协作》讲座学习笔记

上周六,参加了王一恒老师的<跨部门沟通与协作>讲座,老师讲的一些沟通的技巧和理论还是很有实际操作价值的,在这里与大家共同分享一下. 沟通最忌讳的是一脸死相. "沟"是两个人的事情. 沟通的黄金法则:你希望别人怎样对待你,你就怎样对待别人. 沟通的最大问题:对别人要求高,自己做不到. 沟通者先管理心情,再管理表情,在处理事情. 微笑是沟通的通行证. 高度决定态度,态度决定一切. 智者,听而问:聪明者,知而言. 脑袋决定位子,格局决定现状. 穷人没有东西给予,也可以给五样东西:

[译] 如何调试CSS的跨浏览器样式bug

http://www.cnblogs.com/newyorker/archive/2013/01/22/2870682.html 原文 http://www.stubbornella.org/content/2012/05/02/cross-browser-debugging-css/ 作者为YAHOO前端工程师. 首先要做的是挑选一个好的浏览器.我的选择是Chrome,因为它拥有强大的调试工具.当我在Chrome上完成调试后,我会接着在Safari或者Firefox上调试. 如果在这些“好的”

在IT在系统中使用多租户技术的跨部门和虚拟团队的解决方案为员工提供(草案)

1 前言 经过多年的企业信息化建设,Office系统逐步形成有9营业场所的分部门.9专业应用子系统.20独立的信息模块.330一种方法.这些系统或模块内置于Microsoft IIS.Apache Tomcat.Weblogic.Cordys BOP上,相互彼此独立.互不影响. 在不考虑反复投资.资源共享.便于运维的情况下,仍存在一些长期非常难解决的问题: (1).各个系统的组织.账号不统一.维护困难. (2).在一些系统或模块中.对于人员跨部门的情况.仍以两个及以上账号的方式处理,不仅业务不直

基于PaaS平台的人员跨部门多重身份技术解决方案

1.系统现状 系统使用范围为全省,包括省公司本部及各个中心.十三个地市分公司.其中,地市分公司区县按地市分公司部门管理:中心按省公司本部部门管理,只包括省级本部主要人员,其他不在系统内. 系统业务包括:公文管理.部室专业垂直办公.通用办公及专业系统,其中,部室专业垂直管理为9个独立系统,专业系统为9个独立系统,公文管理与通用办公.业务流程(370个流程).综合信息(含20个信息专栏)组成全省集中办公系统. 2.关于人员跨部门多重身份解决措施 由于原系统为分散独立系统,人员跨部门多重身份的情况较少

基于PaaS平台租户部署及人员跨部门设计方案

人员跨部门管理模型 在一个软件系统中,人员跨部门是比较常见的业务现象,而当涉及到流程时就比较麻烦了.现有系统常用方法是为这样的用户建立多个帐号. 例如:张三是党群部管理退休人员的,又是人力资源部副经理,这样两个跨部门的身份,涉及到不同的流程.设置张三为党群部管理退休,再设置张三1位人力资源部副经理,这样,相关业务及流程,不会因为人员的特殊,而进行技术上的特殊处理.唯一缺陷是张三要记两个账号及其密码. 按传统"铁打的衙门,流水的官"的思路,这样的账号就是个岗位或官职,在此定义为组织账号.

在IT系统中使用多租户技术提供人员跨部门及虚拟团队的解决方案(草稿)

1 前言 经过多年企业信息化建设,逐步形成的办公系统中还有9个部门业务网站子系统.9个专业应用子系统.20个独立信息模块.330个流程.这些系统或模块分别搭建在Microsoft IIS.Apache Tomcat.Weblogic.Cordys BOP上,相互彼此独立.互不影响. 在不考虑重复投资.资源共享.便于运维的情况下,仍存在一些长期很难解决的问题: (1).各个系统的组织.账号不统一,维护困难: (2).在一些系统或模块中,对于人员跨部门的情况,仍以两个及以上账号的方式处理,不仅业务不

PHP 开发的 API 多版本管理实践

遇到的情况 本文针对移动互联网客户端需要兼容旧版的情况,强制升级到最新版本的 app 不在讨论之列. 在 bugtags.com 项目中,我们的版本遵循下面规范.1.0.1大功能.小更新.bug 修正我们的版本列表如下: 1.0.1.1.1.2.1.3.1.42.0.2.1.2.2.2.33.0.3.1…5.0 这样一个版本结构,所有版本都可以用,跨度最大时,1.0 用户要跟 5.0 用户并存.以 /api/user/info 接口举例,经过这么多版本的迭代,版本 1.0 跟 3.0 的返回数据