版本发布失败,原因为何?
2014-12-21 00:26
281 查看
故事背景:
公司正在开发“xxx在线教育平台”这样一个教育类项目,目前web端已经实现了在线教育的基本功能,想把web端的部分功能移植到移动手机端,所以开发了android版的手机客户端,接着你懂的,提交测试版本给QA进行测试,但是4轮测试打了10个包,到最后也没法正常发布,原因在哪里呢?
1. 缺少“产品”的概念
开发人员或者产品相关人员,缺少从“产品”的角度考虑问题。常常表现为以下几种情况:
一、产品版本功能规划不合理
举例:首个测试版本,仅有登录,没有退出。这种情况登录后要想退出重新登录,只能卸载软件,重新安装才可以,试想,谁会去重复安装n次来测试登录呢?暂且假设有人这么做了,每次都是卸载后重新安装进行的登录,测试结果可靠不?可想而知,显然,第二个版本的时候问题暴露出来了,虽然有退出功能了,只能登录一次,退出后就不能再登录了。
从产品的角度来看,产品应该是这样的,登录-功能模块操作-退出。确保这一整个流程都是通的。如果时间来不及,中间的功能模块可以减少。这就是所说的“做产品做一半”。
二、产品基础功能不能用
开发不进行简单的流程性测试就抛过来给测试,结果经常是主要功能都不可用。结果只能打回去,重新打包。
三、程序数据写死,为开发自测用数据
程序中的数据不是根据具体用户动态获取的,而是开发写程序时写死的测试用数据。
举例:登录,登录帐号是写死的,不管用哪个帐号登录,都是写死的帐号,这样与用户相关的信息无法真实体现,比如学识获取,课程学习情况,这个使得本应该在前期版本中就应该发现的问题到后期版本中才暴露。
2. 开发对需求理解不够透彻
明明有需求原型,但是就不按照需求原型来,或者是部分按需求原型来,部分不按照需求原型来,结果就是开发出来的产品常常是不符需求。要知道,毕竟工作性质不同,人家产品也不是吃素的。
3. 代码管理混乱
缺少对代码进行管理,常常表现在以下几个方面:
一、原来已经修复的问题再后面版本中又重现出来
二、每次提交测试的版本都不稳定,每个功能模块都出问题
简而言之就是:代码的修改没有很好的控制,过程比较随意,常常是大动手脚,结果到最后没有一个版本是相对稳定,可用的版本
4. 开发和测试缺乏互动
开发提交版本测试的时候,没有提交changlog或者提交的changlog不
明确。这样,如果系统比较复杂,测试人员除缺陷管理系统上提交的缺陷是否被处理外,不懂其它模块是否有做修改,哪些地方没做修改,测试人力不足的情况下, 时间短的情况下测试也就比较没有针对性,自然也就比较容易产生漏测。所以建议要加强这种文档反馈机制,当然口头交流能做到也行。
5. 时间太赶
测试在赶,开发在赶,反正就是很赶,一赶就出问题,常常看到bug被标记已解决,但是新版本测试中发现bug原封不动的存在,,,,,,所以,项目负责人应该学会谈判和计划,尽量为项目争取时间。
6. 不够重视
对提出的问题不够重视,结果就早期提出的问题在往后延几个版本才被处理
7. 考核机制不合理
考核这东西有利有弊,好处在有考核有压力、有责任感、有处罚,坏处就是为了通过考核,逃避处罚,可以不择手段,应付了事等
公司正在开发“xxx在线教育平台”这样一个教育类项目,目前web端已经实现了在线教育的基本功能,想把web端的部分功能移植到移动手机端,所以开发了android版的手机客户端,接着你懂的,提交测试版本给QA进行测试,但是4轮测试打了10个包,到最后也没法正常发布,原因在哪里呢?
1. 缺少“产品”的概念
开发人员或者产品相关人员,缺少从“产品”的角度考虑问题。常常表现为以下几种情况:
一、产品版本功能规划不合理
举例:首个测试版本,仅有登录,没有退出。这种情况登录后要想退出重新登录,只能卸载软件,重新安装才可以,试想,谁会去重复安装n次来测试登录呢?暂且假设有人这么做了,每次都是卸载后重新安装进行的登录,测试结果可靠不?可想而知,显然,第二个版本的时候问题暴露出来了,虽然有退出功能了,只能登录一次,退出后就不能再登录了。
从产品的角度来看,产品应该是这样的,登录-功能模块操作-退出。确保这一整个流程都是通的。如果时间来不及,中间的功能模块可以减少。这就是所说的“做产品做一半”。
二、产品基础功能不能用
开发不进行简单的流程性测试就抛过来给测试,结果经常是主要功能都不可用。结果只能打回去,重新打包。
三、程序数据写死,为开发自测用数据
程序中的数据不是根据具体用户动态获取的,而是开发写程序时写死的测试用数据。
举例:登录,登录帐号是写死的,不管用哪个帐号登录,都是写死的帐号,这样与用户相关的信息无法真实体现,比如学识获取,课程学习情况,这个使得本应该在前期版本中就应该发现的问题到后期版本中才暴露。
2. 开发对需求理解不够透彻
明明有需求原型,但是就不按照需求原型来,或者是部分按需求原型来,部分不按照需求原型来,结果就是开发出来的产品常常是不符需求。要知道,毕竟工作性质不同,人家产品也不是吃素的。
3. 代码管理混乱
缺少对代码进行管理,常常表现在以下几个方面:
一、原来已经修复的问题再后面版本中又重现出来
二、每次提交测试的版本都不稳定,每个功能模块都出问题
简而言之就是:代码的修改没有很好的控制,过程比较随意,常常是大动手脚,结果到最后没有一个版本是相对稳定,可用的版本
4. 开发和测试缺乏互动
开发提交版本测试的时候,没有提交changlog或者提交的changlog不
明确。这样,如果系统比较复杂,测试人员除缺陷管理系统上提交的缺陷是否被处理外,不懂其它模块是否有做修改,哪些地方没做修改,测试人力不足的情况下, 时间短的情况下测试也就比较没有针对性,自然也就比较容易产生漏测。所以建议要加强这种文档反馈机制,当然口头交流能做到也行。
5. 时间太赶
测试在赶,开发在赶,反正就是很赶,一赶就出问题,常常看到bug被标记已解决,但是新版本测试中发现bug原封不动的存在,,,,,,所以,项目负责人应该学会谈判和计划,尽量为项目争取时间。
6. 不够重视
对提出的问题不够重视,结果就早期提出的问题在往后延几个版本才被处理
7. 考核机制不合理
考核这东西有利有弊,好处在有考核有压力、有责任感、有处罚,坏处就是为了通过考核,逃避处罚,可以不择手段,应付了事等
相关文章推荐
- 版本发布失败总结
- chrome 26版本登录提示“糟糕,同步失败”的原因
- 使用vs2005(sp1)能够编译成功,但是发布失败的原因
- 众包发布失败,原因:请您将您的业务需求描述清楚后重新发布。
- 由于.net 4版本原因导致mvc组件安装失败
- Android APP发布混淆版本时可能出现错误的原因--简记(1)
- Oracle为何把最新发布的P6软件版本定义为 15.1
- iOS itunes中,构建版本提交失败原因,以及控制台打印错误dyld: Library not loaded: @rpath/libswiftCore.dylib
- net 2.0 生成成功,发布失败,没有提示错误的原因
- 阿里云 Cent OS 6.3版本自动挂载交换分区失败原因
- 2016/07/31 安装cocoapods 失败 原因:ruby 环境版本必须大雨2.2 --> 更新到2.3后重新安装
- Linux 系统更新命令行模式,出错原因,软件更新器更新失败,系统提示已为最新版本,问题如何解决
- Release版本编译CView GetDocument失败原因
- vs2008发布失败原因
- vs2008发布失败原因
- Linux环境下使用n更新node版本失败的原因与解决
- 4.2.0 版本Anaconda安装 navigator启动失败以及spyider(tensaorflow)Navigator启动失败原因分析
- eclipse中tomcat发布失败(Could not delete May be locked by another process)原因及解决办法
- Hibernate3发布beta版本 支持EJB3风格对象持久化
- 微软解决方案框架MSF4.0的预发布版本支持敏捷过程了