利用好职场的黄金期—软件测试进阶之路(8)

发表于:2018-10-15 13:36

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:何飞    来源:51Testing软件测试网原创

分享:
  问答(20)把用户当做"用户"还是"客户"?
  【背景】
  前两天有个同学说他在处理现网工单时,遇到一个问题,客服和市场那边催的比较急,说用户是当地最大的通信营业厅,但找到开发,开发说,我们是做产品的,不能因为某个用户比较大,就要立刻解决他的问题,发布上线吧。他觉得这种说法其实没错,但又没办法用这个理由跟客服和市场解释,所以觉得很困惑。
  【你问】
  我们应该把用户当做"用户"还是"客户"?
  【我答】
  对于企业级产品,面向的用户就是企业,一般都是签单的,如果是特别大的签单企业,比如说我们之前最大的用户是波音和美国银行,那他们遇到的一些问题或者提出的一些需求,那就是"大"问题或"大"需求,有可能就是需要你立刻解决,尽快实现,然后就安排上线了。不会管你当前的产品开发计划是什么,都会出一个补丁包上线。
  对于行业定制化产品,比如 ERP 或电子政务系统,是跟客户签订合同的,有约束条件,那他们遇到的问题或提出的需求,其实也可能就是有解决时限的,并不一定会按照你既定的产品开发周期去安排。
  而对于互联网类 应用程序 产品,大多数人认为产品发布周期只要依据自己的产品规划和开发周期去定就行了,除非遇到很严重的功能障碍或漏洞,否则都不需要因为某些用户的"大"问题或"大"需求去临时发包上线。
  我觉得,造成这种观点的原因主要是绝大多数 应用程序 的使用者都是免费在使用,即使是付费使用,那也只是"用户",而不像上面说到的企业级产品和行业定制化产品的用户实际上都是"客户"。
  所以,在互联网 应用程序 产品的现网问题处理机制中,我认为很重要的一点是我们应该把用户当做"用户"还是"客户"?只有从管理层到运维团队的执行人都统一了这个认识,我们才能制定出正确的,且合适的现网问题处理流程,我们才能规定出明确的一些标准:
  1、问题在多长时间内要被响应?
  2、缺陷类问题需要在多长时间内被解决?
  3、什么类型和级别的缺陷类问题需要立即发版本上线?
  4、什么级别的需求类问题需要加入最近的版本发布上线?
  如果从上到下都统一了认识,把每一个免费用户和收费用户都当成我们的客户去对待,就不会有那位同学所面临的困惑了。因为那时候,我们会更聚焦问题本身的严重性和级别了,而不会因为只是某个用户或少数用户遇到某个问题,或提出了某个其实还不错的建议,而不予重视,或者置之不理了。
  问答(21) 如何设计产品的兼容性测试?
  【背景】
  老师,我想请教一下,你们是怎么做兼容性测试的?我现在做兼容性测试,是用浏览器不同版本,不同种类浏览器,不同语言来测试,都要走一遍工作流。我觉得这样做好像很麻烦,而且也搞不清楚这样跟功能测试,业务流程有什么区别?是不是会重复了?
  这个同学问的其实只是兼容性测试里的一种,就是浏览器兼容性测试,常见于 B/S(浏览器/服务端) 结构的产品。其实兼容性测试有好几种类型,我们今天就来看看,对于不同类型的产品,要怎么去设计兼容性测试吧。
  【你问】
  我们应该怎么去设计产品的兼容性测试?
  【我答】
  1、什么是兼容性测试?
  兼容性测试就是验证开发出来的程序在特定的运行环境中,与特定的软件、硬件或数据相组合,是否能正常运行,有无异常的测试过程。
  2、兼容性测试包含哪几类?
  2.1 浏览器兼容性测试:在指定的浏览器上检查 Web 页面样式和元素的展示效果,以及交互是否正常。
  【主流的浏览器】:
  Windows:IE 9/10/11、Firefox(The Latest  ),Chrome(The Latest  );
  Mac:Safari、Chrome(The Latest)、Firefox(The Latest);
  【测试注意事项】:
  1)这个常见于 B/S(浏览器/服务端) 结构的产品。
  2)我们虽然能通过一些官方的统计数据去收集主流的浏览器和版本,但最好让产品经理明确定义出支持哪些浏览器和对应的版本,因为这个也取决于产品的应用人群和具体的业务场景;
  3)浏览器的兼容性测试,主要是检查 Web 页面样式和元素的展示效果,以及交互是否会有异常,跟具体业务逻辑其实无关;
  4)跟前端开发多交流,明确哪些样式或元素不是标准的,多半会出兼容性问题,有针对性地先在所有要求支持的版本的浏览器上去验证,再挑选每种浏览器的一个版本去验证所有的标准页面;
  5)多记录,多总结,做好统计分析,在后续的测试中就只要针对有改动的,易出兼容性问题的元素和样式去测试;
  6)留意 IE 大版本的升级,以及 Chrome(谷歌浏览器) 和 Firefox(火狐浏览器) 的迭代版本更新,阅读更新的版本说明,了解是否有大的改动,可能会影响到页面的展示或者交互,有计划地去做兼容性测试;
  2.2 操作系统兼容性测试:在指定的操作系统上检查产品功能是否正常。
  【主流的操作系统】:
  Windows 系列、Mac OS X 系列、Unix/Linux 系列、Android系列、iOS系列
  【测试注意事项】:
  1)常见于C/S(客户端/服务端) 结构化产品,互联网时代的 应用程序 从广义上说也是 C/S 结构的;
  2)基本的注意事项跟上述的浏览器兼容性测试一样,需要关注的是不同版本的操作系统默认权限级别会有不同,而导致客户端需要访问或调用系统组件或方法时会出错;
  3)同一类操作系统的大版本升级时,需要注意新的版本或补丁里是否继续兼容老的库函数;
  2.3 多版本兼容性测试:为了验证新版本服务端是否同时支持新/老版本客户端而进行的测试。
  【测试注意事项】:
  1)这是很多产品经理在设计需求时容易忽略的地方,也是 C/S 产品和 B/S 产品从兼容性角度来说最大的区别;
  2)产品升级之后,服务端只会是最新版本,但客户端因为不同的用户场景而可能存在老版本,一种是没有强制更新,用户不选择升级,另一种是在一些企业级的域环境里,客户端包是否升级取决于域管理员的策略;
  3)只是单客户端的产品而言,相对简单一些,只要保证服务端每次升级都不会因为新需求而修改老接口,基本就不会有太多兼容性问题;
  4)相对复杂的是那种既有商家版又有用户版的客户端产品,针对会频繁发生交互的功能,需要重点考虑新老版本的兼容性测试;
  2.4 数据兼容测试:因为新功能的需要或者是已有功能的升级改造,涉及到已有数据的读取和写入,而需要进行的验证,以确保数据在新老版本之间都能正常流转的过程。
  【测试注意事项】:
  1)向前兼容(Forward Compability):新版本的软件要能正常且正确的读取和加载老版本生成的数据;
  2)向后兼容(Backward Compability):当前版本的软件要能支持在后续高版本的平台上正常运行;
  3)常见的 Office 类软件或者多媒体制作或播放类软件,不仅需要考虑新版本客户端是否能正常读取老版本生成的文件,还要考虑新版本生成的文件是否能正常被老版本客户端读取,或者有相应的升级提示信息;
  4)还有一类是常见的订单类数据,在老的服务端和客户端组合下产生的数据,是否能在新的服务端和新的客户端组合下读取成功,同时业务流程也可以正常进行;
  5)对于数据兼容性测试来说,更多的会关联后台历史数据的迁移和转换,这一部分也是需要重点区关注的,确保迁移和转换后的数据,用户能正常读取;
  2.5 分辨率兼容性测试:也被称作适配性测试,是指验证被测网页或产品 UI 在各种分辨率下的显示器或各种分辨率、尺寸屏幕的移动设备上都能正常显示的测试过程。
  【测试注意事项】:
  1)一种是普通分辨率的屏幕,另一种需要关注的是高清分辨率的屏幕;
  2)需要关注的问题主要包括:显示是否完整、图片是否被拉伸、文字和图片位置是否有错位;
相关阅读:
版权声明:51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。
22/2<12
《2023软件测试行业现状调查报告》独家发布~

精彩评论

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号