首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
iOS 开发实用技术导航
NSHipster 中文版
http://nshipster.cn/
cocos2d 开源 2D 游戏引擎
http://www.cocos2d-iphone.org/
CocoaPods
http://cocoapods.org/
Google Analytics for Mobile 统计解决方案
http://code.google.com/mobile/analytics/
WWDC
https://developer.apple.com/wwdc/
Design Guides and Resources
https://developer.apple.com/design/
Transcripts of WWDC sessions
http://asciiwwdc.com
Cocoa with Love
http://cocoawithlove.com/
Cocoa Dev Central
http://cocoadevcentral.com/
NSHipster
http://nshipster.com/
iOS 开发实用书单
iPhone App Development: The Missing Manual
Cocoa and Objective-C: Up and Running
Cocoa Programming for Mac OS X
深入浅出设计模式 Head First Design Patterns
Style Guides
Google Objective-C Style Guide
NYTimes Objective-C Style Guide
Useful Tools and Services
Charles Web Debugging Proxy
Smore
V2EX  ›  iDev

求(si)论(bi),如何改进项目开发当中的部分环节,从而减少上线后的 Bug?

  •  
  •   kepenj · 2015-05-25 15:24:42 +08:00 · 2155 次点击
    这是一个创建于 1457 天前的主题,其中的信息可能已经有所发展或是发生改变。
    上线后的产品出现Bug,一直都是每个团队或者公司头疼的事情。
    Bug有可能出现在产品设计上、也有可能出现在程序开发中(不是黑,但是大多情况下都在这块...)、也有可能是测试的疏忽,总之这个Bug送到了用户手上,也让用户find的出来,这无疑是对公司或者团队的打脸。
    “Bug是不可避免的”,“没有哪一款程序是没有Bug的” ...当然,po猪发这个帖子就是想咨询一下大家:如何改进项目开发当中的部分环节,从而减少上线后的Bug?

    po猪现在能想到的是,开发加入TDD,测试阶段引入自动化; 增加开发和测试的周期; (当然TDD和自动化的加入成本比较高,所以更多的也是考虑到周期的增加.... - -|| )
    7 回复  |  直到 2015-05-26 14:26:51 +08:00
        1
    moro   2015-05-25 15:38:39 +08:00
    bug是不可避免的,
    可以增加一个线上测试版本。
        2
    laoertongzhi   2015-05-25 16:08:59 +08:00   ♥ 1
    开发前: 要求产品提供详细的PRD和流程图 , 增加需求评审环节 。在需求评审之前至少提前一天将PRD和流程图发给研发,让研发消化,以便能够在评审会上提出所有有疑问的地方;

    开发中: 不知道 …… (非程序猿)

    测试ing:研发内部测试 —— 测试环境测试 ——预发布测试(线上真实数据)—— 正式上线
        3
    kepenj   2015-05-25 18:29:05 +08:00
    @moro po猪团队规模较小,就公司而言无法发动内部的大规模测试;部分核心用户的测试量也较少。 po猪可能比较需求能在开发和测试这个阶段去定位或者覆盖,有没有好的一些平台或者工具或者方案去处理这些呢?
        4
    lionyue   2015-05-25 23:55:57 +08:00
    灰度发布两三个版本,收集bug,解决bug,然后再发布
        5
    kepenj   2015-05-26 09:57:49 +08:00
    @lionyue 我理解那就是快速迭代~缩短每个版本的周期。 but 个人认为这种方式有点适用于刚成型的产品。
        6
    fangjinmin   2015-05-26 12:42:53 +08:00
    正确的做法是这样的,对每一个阶段的工作都做review。首先设计和构架完成后, 开发人员一起review,如果有问题,修改到没有为止。第二阶段,编码。规范编码的归程,大家都要遵守,编码后,代码也要review, 检查有没有明显逻辑上的错误或者误输入。第三阶段就是重中之重的测试了。测试分为几轮,unit测试,集成测试和系统测试。尽可能地测试出BUG。从软件工程学上来说,设计,编码和测试所要的时间应该接近于1:1:1,哪个环节少了,都会出问题。问题是越早暴露越好。如果设计的问题,到了系统测试才暴露出来,那改动将是非常之大。
        7
    lionyue   2015-05-26 14:26:51 +08:00
    @kepenj 不是快速迭代,灰度发布是指小范围内发布,通过crash监测、用户反馈、用户回访等方式发现bug,灰度发布几次后,如果bug率降到你们能承受的范围,就可以正式发布了
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3393 人在线   最高记录 5043   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 19ms · UTC 04:56 · PVG 12:56 · LAX 21:56 · JFK 00:56
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1