坚持原创精神 感谢你阅读后留言！

发布新日志

  • RIP MJ

    2009-07-17 13:23:24

    RIP MJ.

    Hearing your song, touching your dancing and feeling your emotion, but I will NEVER see you again.

    I wish I had had any chance to see you, dance with you, sing with you, touch your heart with the mad fans together.

    ALL I can do now is hearing your voice with tears again and again.

    The world without you is not same any more.

    How can I go back to the life with you!

    Wish you may hear, touch and feel every tear from my heart, a China fan.

    ALL I wanna say is that please Jesus take care of you in the heaven.

    Set me free please.

    RIP MJ!

    查看(181) 评论(1) 收藏 分享 管理

  • 跨WIN平台的应用－驱动软件安装自动测试系统设计

    2008-07-24 13:13:11

    。 业务分析
        一个不大的应用程序，搭载不同的硬件系统，要求运行于不同的WIN平台下，多种安装模式（手工、后台、出厂、在线更新等）的安装软件的测试

    。 特点
        某一平台，语言和硬件下，某一安装模式下，其功能测试周期较短。
        在一个产品稳定后，新硬件的新安装程序容易作
        回归测试由于os/lang/HW/Installation type的组合膨胀，工作量急剧上升
        出厂和后台由于没有人工介入，可以自动化；手工安装和在线更新作为第二步考虑
        考虑到跨越所有WIN平台，跨越语言，UI自动化测试工具可能不是很划得来

    所以该系统的设计主要解决回归 测试覆盖率，schedule 和工作量的矛盾
    。 测试系统搭建原则
        实现必须跨越所有WIN平台
        由server发布，client主动获取和执行的多client运营的基于策略队列的测试系统
        客户端基本策略行为分析：
             自动安装os，恢复定义的网络和显示配置，解释－执行－更新－记录策略及其结果。
        策略执行过程：
             下载安装包－安装安装包－对安装结果记录－开发基线数据分析－测试结果和基线数据校验；对于其中任何一步，采用独立模块解决，既可以作为整体策略运行，也可以作为独立模块在测试时动态运行
        客户端测试系统必须和os耦合最小化，其耦合通过配置而非集成来解决
        测试系统应和daily build的开发系统集成



    查看(201) 评论(0) 收藏 分享 管理

  • 项目里的一些测试工具

    2008-05-09 17:36:16

    回顾一下自己项目里，小组完成一些测试工具

    WIN下
    ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    录制－回放类
        基于ROBOT的回归测试全套脚本
        结合WINDOWS性能监视服务和ROBOT的重复操作下性能监视和分析
    数据库类
        系统数据产生数据库脚本
    测试管理类
        基于TESTMANAGER/SODA的测试计划生成模板
    测试数据生成类
        根据策略自动生成用例
    安装测试
        对系统文件扫描和比较等

    LINUX下
    ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    特殊应用类
        用于本应用系统服务的性能测试，基于SHELL,SQL脚本类
    回归测试类
        基于SHELL/PERL的一些系统服务，系统支持工具回归测试
    系统管理类
        系统基线和初始设置的自动恢复，类似病毒程序
        系统自行安装和安装脚本，配置等自动备份等
    特定应用
        各类临时为方便测试写的小脚本

    未来规划
    ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    更多的回归测试工具
    考虑自动ghost－install连接起测试

    呵呵，写完咯

    查看(694) 评论(1) 收藏 分享 管理

  • 测试程序的耦合

    2008-04-23 12:47:47

    测试系统的开发有很多个性，个人实践中发现，过强的耦合常常是测试开发失败或者部分失败最常见的原因。下面是一些常见易犯错误的耦合

    。 测试框架和测试程序的耦合
       测试框架的设计应该仅仅要求被测试程序满足最小假设，而非很多假设。

    。 测试程序和测试数据的耦合
       测试数据驱动的最大好处就是这个。

    。 测试程序、数据和版本的耦合
       测试程序、数据中和版本耦合的部分应该独立出来，利用接口调用

    。 测试框架和运行端，比如说客户端或者服务器的耦合
       测试框架应该被设计为支持不同运行端动态指定和运行的接口

    。 测试程序、数据的存储和运行的耦合
       应该对程序和数据集中存储，动态分派

    。 测试运行和测试程序编写人员的耦合，这个实际是普及测试程序应用的重要部分

    。 测试程序和被测试系统的运行平台耦合，应该尽量减少对被测试系统的运行平台假设。

    。 测试程序对当前被测试系统假设的耦合，其实就是未来版本的兼容性。这个不易不易啊。

    查看(774) 评论(0) 收藏 分享 管理

  • 测试交流topic，及调查：你会开展什么topic

    2008-04-15 12:47:49

    小调查：   你对什么样的测试交流感兴趣？

    今年年初开始规划小组内部测试交流，以每个月1－2次，每次短类型30分钟，长类型90分钟的形式展开。

    展开的原则是：
      展开的主讲人自己报名
      topic主讲人自行定义
      组员可以提对什么感兴趣
      对有良好效果的严重鼓励，呵呵，还要经常自己上阵啊

    已经开展的topic：
      质量及测试的基本内容
      测试团队顾客及服务内容
      某项目测试经验
      BUG 填写个人标准
      TCPIP Basic

    未来打算开展的topic
      case设计方法
      测试项目过程普及培训

    感受
      30-40%是积极培训和接受培训的
      主讲培训是应该鼓励的
      主讲培训可以理清自己的思路；同时锻炼口才和材料书写能力
      坚持定期操作是困难和有很大积极效果的

    查看(512) 评论(0) 收藏 分享 管理

  • linux 和 vncrobot

    2008-03-26 11:01:36

    开始使用一个测试工具 vncrobot, 不错, 跨平台而且被测试机器已经安装realvnc,所以不存在对被测试系统干扰的问题. 其工作原理和robot的physical方式很接近,不过属于c/s架构.

    在linux下,server代理client和X server通讯. 所以必要的延时和界面方式的选择需要保持一致.

    过程
    . 在rc.local中加入vncserver启动命令,使被测试机器自动启动服务
    . 在客户端运行vncrobot,调入脚本,可以启动测试

    优点
    . 有总比没有好

    缺点
    . 针对位置和图像而非控件和窗口
    . 延时显著

    应用特点
    . 针对成熟模块
    . 可用于回归测试和系统基本数据自动载入恢复
    . 保持X11的参数配置始终一致
    . 不作复杂的事情和异常处理
    . 前台程序和后台服务控制有效互动

    查看(473) 评论(0) 收藏 分享 管理

  • 新年学习计划

    2008-03-06 17:07:05

    看到一篇文章，对照自己看看，顺便明确自己的未来学习计划。自己督促一下

    今年的计划 学海无涯啊

    。 学习一门主流编程预言 java

    。 性能工具，学习架构，争取一整年可以自己写一个简单的性能工具，结合java学习。争取每天1个小时的学习

    。 powerpoint＋excel 精通一点。快的很。

    。 英语，争取可以每天达到1 hour的听力和背单词

    。 设计模式 争取1个月内结束剩余的

    。 分析模式 争取3个月内结束

    其它

    。 50 best practice 争取1个月内结束

    。 管理 慢慢来

    暂时不学习的

    。 SCM

    。 Function tool， linux下就用perl和bash先，robot都已经丢光光了


       【IT168技术文章】 如果你是测试员或是高级测试员,有志转向管理发展,那么需要加强以下几点:

        1. 测试计划的编写(要结合测试的项目,能以此来控制和确定测试所需人员,设备及时间来管理测试时间)

    一般，慢慢进步

        2. 要熟悉BUG跟踪工具及软件测试流程.(如: TD, Bugzilla, CQ等)

    熟悉

        3. 要熟悉配置管理工具. (如: CVS, VSS等)

    不了解

        4. 要熟悉自动化工具.(例如:WinRunner, QTP, Robot, RFT, Automation等,能结合录制完的脚本编写代码)

    好久不用了，待学习

        5. 要熟悉压力及性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分析出性能瓶颈)

    一般，工具不熟悉，知识广泛还可以，分析定位还可以

        6. 要熟悉或精通一门语言. (例如: Java, C++)

    不及格，要学习

        7. 要熟悉数据库.(例如: Oracle, DB2, SQLServer, MySQL)

    熟悉

        8. 要熟悉主流操作系统. (例如: HP Unix, IBM AIX, Sun Solaris, Red Hat Linux, SuSE Linux, Windows)

    还可以

        9. 能用英文流利的和老外交流以及往来Email.

    还可以，还需进步

        10. 语言表达能力强,表达问题清晰明了.

    还可以

        11. 沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜.

    还可以

        12. 学习技术的能力要强,能快速上手一个新的技术.

    一般，比较笨

        13. 乐于与人交流.

    一般，需要进一步加油

    其它
    。 熟悉一门脚本预言
    一般，够用
    。 presentation
    一般 待学习
    。 跟踪和反馈工具
    一般 待学习

    加油！！

    查看(491) 评论(1) 收藏 分享 管理

  • 我对业绩评价标准的理解

    2008-01-22 17:28:57

    分享一下我对业绩评价的理解，请 多多指点

    年初期望
    。 年初沟通年度贡献期望， 依据是项目需求、团队位置、个人职位、级别、工资
    。 年初沟通个人成长期望，依据是项目需求、个人期望、团队期望
    。 基本底线，包括遵守 职业底线、纪律底线、合作底线

    年底回顾
    。 对比年初期望，指出超越、符合、低于期望的部分
    。 重视贡献期望，作为主要考核依据；
    。 个人成长期望不作为考核依据，但是对于赋予更多工作职责时，是重要的考虑依据；不想当元帅的士兵不可以当元帅
    。 必须满足基本底线，对于高于底线，则作为很次要的考核依据。如果不符合，则减分会很厉害；

    小组成员贡献期望典型定义
    。 测试工作按时完成；漏测BUG具有一定偶然性或者困难，非工作态度或者工作能力距离期望有较大差距导致；
    。 测试用例设计符合规范
    。 测试发现问题复现率高，误报率低；
    。 BUG书写符合规范，清晰易懂；BUG处理流程遵守
    。 对于需求、设计的评审有效；及时提出自己的反馈

    典型超越期望
    。 按时保质完成上述工作的
    。 发现大量需求、设计的问题，及时沟通
    。 对于测试流程、方法、用例设计、工具、脚本有及时的更新或者对稳定部分有较好反馈或创新
    。 对于测试环境、数据、沟通等标准有较好反馈或者创新
    。 对于小组面临的风险有较好的预见性或者对解决方案有较好的贡献
    。 对小组的培训工作有较大贡献
    。 对小组的工作范围定义扩展有贡献

    核心
    。 用户满意度
    。 小组的客户满意度
    。 小组的工作能力和工作效率提升
    。 小组工作范围扩展
    。 保持和各个接口团队的良好关系

    成员发展
    。 对于业务领域的深入
    。 对于测试流程、设计、工具的深入
    。 对于开发部分的深入 代码－设计
    。 对于测试技术的深入 操作系统－数据库－脚本－安全等等
    。 对于实践的深入  需求挖掘与管理、测试实践的改进、SCM等深入
    。 管理和沟通      PMP/MTP/团队/沟通等

    查看(914) 评论(3) 收藏 分享 管理

  • 慢机器－快操作

    2008-01-22 10:24:05

    关键字 linux bash 目录监控　link　du

    在我们linux测试系统中，有一套新版测试硬件和老版测试硬件。

    系统有个功能，将大型文件，通常为10G级别载入至特定目录，比方说从USB/DVD/SCSI等。系统监视该目录并利用守护服务进行一系列操作。在用完后删除。

    新硬件上支持这个级别的操作，速度很快，但是老版硬件设计支持100M级别，所以载入时间每文件达到了10min级别，无法忍受。

    我们的EDDIE兄弟出了一个采用解决方案，个人觉得很绝，强。分享分享。

    。　将所有数据文件拷贝至一个目录A，设为只读属性
    。　设计一个扫描程序，将文件扫描一遍，同时生成link文件复制在另一个目录B
    。　设计一个载入程序，对不同参数，将不同集合的link文件载入至被监视目录C
    。　因为文件名完全相同，系统读入生成的C目录下该link文件族时，实际数据来自目录A
    。　删除时，甩掉了link文件
    。　再次载入时，只需要重新运行载入程序
    。　如果有新的数据文件，只需运行扫描程序

    喜欢这个程序，跑起来比新版硬件还快个几十倍，管他几百个G，1秒搞定.........

    查看(395) 评论(0) 收藏 分享 管理

  • 应用程序的数据库测试

    2008-01-21 13:50:52

    对应用程序的数据库测试，总结了一些案例，一起分享，也请贡献您的反馈。

    。　数据库空间结构测试，比方说各个磁盘的大小安排和数据库的空间安排是否搭配。
    。　数据库逻辑结构测试。比方说各个表的设计是否合理，各个参数配置是否合理。存储过程是否有长延时操作等
    。　数据库安全测试。
    。　数据库备份和恢复测试。
    。　数据库性能测试。
    。　如果部署多层数据库，其设计合理性测试。
    。　数据库并发操作测试。
    。　定义的数据库策略测试。
    。　灾难恢复

    不熟悉OLAP和集群，哪位牛人介绍介绍？

    等等。。。。

    查看(700) 评论(0) 收藏 分享 管理

  • 外星人入侵地球有感

    2008-01-18 13:47:26

    半年前，看了一次神奇四侠。

    一个被抽象成邪恶代表的外星人，派出自己的先锋打前站，被地球上坏人借助政府的力量逮着，被好人救出来并感化，然后和后来的主子同归于尽，保卫了地球。

    不知道想教给儿童什么？不和平，抗争，团结还是爱？

    看看人类的臆想和实际的行为。

    探测各个行星，第一追求的是什么？了解是否有氧气和水，也就是是否适合人类居住。干吗？想想历史上人类的战争和资源的争夺。

    恐怕哪一天，人类找到了外星人，不是地球人喊：啊！外星人入侵地球了。　事实上是外星人喊　啊！地球人入侵外星啦！

    查看(348) 评论(0) 收藏 分享 管理

  • 老外的长处

    2008-01-16 14:21:50

    老外好强啊，列列他们的优点，偶要好好学习


    。　英语好的没法说，偶常常听天书笑话，跟着傻笑。。。。
    。　身体好的没法说，偶扛机器，呼哧呼哧；　他扛机架，健步如飞晕倒。要是上了磅秤，他们会以为偶是空气作的，偶就会以为他们是铁打的。。。。
    。　耐心好，大婶大叔了，一天测个7,8,9,10个小时，没问题，问题没。。。。
    。　持久力强，早上7点开会，9点上班，5点下班，7点开会，9点写文档，11点给我mail，12点再回我mail。。。居然第二天外甥打灯笼照旧。。。。妈妈咪啊，是不是太阳公公，月亮婆婆在中国和美国转起来不一样？？？

    总结　
    想想也平衡，谁让他是老外？？？？

    查看(545) 评论(2) 收藏 分享 管理

  • 事件处理的测试

    2008-01-16 14:06:01

    原创，欢迎评论，渴求您的评论，您的爱护是下一篇的动力

    接到事件处理的测试任务，首先是

    测试需求分析
    。　获取事件列表及处理事件规则列表，发现共有超过100个各类事件，及数十个各类规则
    。　任务分析，随机抽取数个事件及对应规则，发现事件的重现和事件处理规则的复杂程度超过想像，经过交流，事件处理后常用操作包括：　丢弃，　上报至web 服务器，　上报邮件至service，　影响其它事件或本事件的后续实例处理
    。　其它：对事件的回调处理的延时要求不高　

    设计实现分析
    。　事件处理服务基本原理：　扫描被监视各类日志，过滤获得关键字，按照定义的策略处理文件进行工作

    测试工作设计
    。　分解：　测试工作应该包括几个独立的模块：　事件的重现，确保上报事件的各工作模块工作正常；　事件处理规则分析，确保规则正确性；　其它，事件处理的服务应该没有内存泄漏；

    。　执行：　
    初次执行
    　　　　设计一个测试工具，可以灵活按照测试人员配置发送事件至对应机器的日志。事件定义，发送目的和策略定义通过配置文件定义，保持工具松耦合
    　　　　努力复现所有事件，对于灾难恢复等等没有条件复现的，从代码中提取
    　　　　按照需求定义策略，设计各类正向反向用例，察看各个策略执行正确性
    　　　　察看长时间运行内存检测；　察看重负载下CPU占有率。　利用原有自定义性能检测工具实现
    　　　　备份事件处理策略定义文件和策略执行文件基线
    　　　　服务控制测试

    测试间隙工作
    　　　　察看所有策略配置文件，白合测试所有策略

    后续维护版本执行
    　　　　根据需求变更定义，维护配置文件，支持新事件或事件变化
    　　　　根据需求变更定义，复现新的事件
    　　　　根据需求变更定义，对新策略测试
    　　　　回归测试中定期复现各类事件，定期进行服务控制测试
    　　　　比较事件策略定义和策略执行基线文档，执行变更控制

    好处
    　　　　加速测试进程
    　　　　对硬件、网络破坏性测试次数显著降低，减少测试成本
    　　　　对无法在中国实现的事件，也可以测试，合作方只需提供一次事件定义
    　　　　测试质量高
    　　　　CM维护性高
    　　　　开发自测容易

    坏处
    　　　　不能说出来，妈妈咪啊

    哈哈哈哈哈哈哈

    查看(492) 评论(0) 收藏 分享 管理

  • 测试中的对比

    2008-01-15 17:26:10

    原创，欢迎评论，期待您独特的视角！

    测试的对比是测试工作中非常重要的部分，是问题复现中最重要的部分，也是测试中最体现经验的部分。

    下面是常用的一些对比方式，请您把你的对比也来加上来

    。　不同的版本对比
    。　不同的操作系统客户端对比
    。　不同的硬件配置对比
    。　不同的用户名对比
    。　不同的数据组合对比
    。　不同的状态转换对比
    。　不同的配置基线对比
    。　不同的操作序列对比

    查看(152) 评论(0) 收藏 分享 管理

  • Waiting for your, not anyone else, only your great idea!

    2008-01-15 17:20:54

    Purpose for this blog is just share work view and experience. And waiting for your big idea and comment.

    But without your feedback, that's just like a needle thrown in the river. Really lost.

    So, I will applause for your comment. That might be the light guiding me through the very next day career.

    I'm waiting for, not anyone else, but only you, your great big idea!

    查看(444) 评论(0) 收藏 分享 管理

  • 需求与测试需求

    2008-01-14 17:30:55

    下面是一篇关于需求和测试需求的关系的理解，欢迎砸砖

    。　需求应该被映射为测试需求

    。　测试需求应包含超越需求的部分
           参照各类测试模型，作为需求的验证请求，比如是否跨平台，支持国际化，支持最大容量，最大在线容量，容灾等等。。。我们可以认为需求也是被测试的部分。所以常常需要领域专家的支持和技术专家的支持
           超越需求的数学模型，如状态和数据转换，不能指望市场人员为你设计所有的最佳测试组合
           超越需求的技术描述，如专业系统的安全防范，不能指望市场人员都是网络安全专家
           超越需求的实现特点，如使用某些具体实现，该实现下常用设计错误的检查
           同行的卓越之处可以作为enhancement提请PM分析

    确实也想不到非常数学的描述，还是欠缺火候，以后想到再补

    查看(514) 评论(0) 收藏 分享 管理

  • 测试中的自动化与自动化测试

    2008-01-14 15:41:39

    翻开任何一个关于测试的著作，常常有很大篇幅的自动化测试工具和理论，写一篇自己关于测试和自动化的理解，欢迎砸砖。。。渴求砸砖，您的反馈是我下一篇最强大的动力

    在我看来，自动化和测试其实是两个并不相关的东西，其中的重合部分构成自动化测试。而我很反对将测试＝自动化测试，同样反对自动化＝自动化测试。。。

    自动化在工作中的核心思想在我看来，套用IBM的话，是on　change
    而测试工具在工作中的核心核心思想是CUT COST

    自动化应该无处不在，举些工作中自动化的例子
    。　每天需要打开若干个固定的网页，一个方法是用bookmark+homepage,也可以用BAT启动FIREFOX打开
    。　对通过dev自测的版本测试，一个脚本就是从服务器上下版本，mount和自动安装，自动CM各类基线文件和安装脚本，重启。。。。。。
    。　对某些反复进行的测试编写测试脚本，如测试数据清空和重载，数据自动导出，数据自动比较，回归测试工具编写，系统数据扫描和比较。。。。。。。。
    。　数据库大数据量生成
    。　长时间进程实时检测
    。　服务的回归测试

    简而言之，如果工作中反复进行一项操作，那就把它自动化，预留合适的配置或者接口，把变化留给它们，把不变留给程序。不要让人工作机器擅长的时间，同样不要让机器作人工擅长的事情，人最擅长沟通和创新，以及判断。比方说用例设计（我作过一个用例设计工具，结果非常不好），TROUBLE SHOOTING，人际交往，计划分配和跟踪等等。

    而专用测试工具的应用如
    。　填报BUG
    。　回归测试执行
    。　大UI数据量和客户端性能测试

    对测试工具应用的界限就是成本小于收入的情况下，通常有
    。　自己无法实现或者成本太高，如性能测试录制、控制和并发实现
    。　需求和测试及开发追踪
    。　测试管理
    。　回归功能测试
    。　BUG填写

    而判断一个事情是人工作，自定义工具作，GUI工具作，性能工具作甚至是EXCEL或者其他工具作，就是LEADER的作用了。

    最后一句总结就是：
    多用工具，但是不要让工具的结果代替您的判断和信息的交流

    查看(429) 评论(0) 收藏 分享 管理

  • 培养下属的心得

    2008-01-12 14:44:42

    最近两年，一直把培养下属作为工作中最重要的事情之一来作，有点心得，写写，欢迎砸砖

    培养下属的收获
    。　竖立统一的团队文化，在我个人的实践是：　正直、客观、业绩导向、合作、发展。最大化工作能力，最小化工作内耗。
    。　对下属的关心爱护的最重要因素。不能耽误职业生涯。
    。　团队能力增长的最重要方法。
    。　竖立统一的工作标准，如　需求分析标准，测试设计和执行标准，文档书写标准，BUG书写标准，沟通标准，测试环境变更标准。

    注意点：
    。　培养愿意被培养的下属，可惜这个比例就一个组织而言，不会很高。对中间的人，要注意导向而不是压服
    。　培养进步的观念比培养具体的细节更加重要
    。　培养创新
    。　及时反馈进步的成果，提示可以发展的方向

    查看(858) 评论(2) 收藏 分享 管理

  • 一个bug追踪过程

    2008-01-12 14:19:33

    在项目中，曾经遇到一个印象很深的问题，就记下来，以后也好参考。

    系统中，客户端向服务器发送一个文件族，包含索引文件和数据文件，服务器对目录有回调，更新数据库相关信息。但是偶尔会出现服务器误认为数据文件没有到达的情况。复现几率不大，同时没有规律。

    判断过程
    。　统计复现规律，上载BUG数据库后等待空闲时间复现
    。　美国不能复现，中国这边复现概率很小
    。　在快的机器上复现概率小，慢的复现概率大
    。　postgress数据库，不熟悉系统命令，作了个性化sql的数据库表记录导出文本工具。每次操作后用gvimdiff比较，无复现个性特点
    。　通过沟通，了解了开发中的对应日志和关键字
    。　重复操作后，过滤所有失败的日志过程
    。　开发脚本，实现按照配置文件序列发送，实现脱离被测试程序，加快测试进度，同时可以确定是否服务器端造成问题
    。　按照日志书写配置文件，发送序列，注明测试程序同样复现，即两者等价
    。　多次统计错误序列，得出在一定序列属性特点的时候，服务器在重负荷的情况下，服务器程序会出现错误

    收获
    。　复现BUG
    。　对文件族的属性有了非常深刻的了解
    。　实现两个以后一直使用的测试工具：　数据库文本导出 和　模拟文件发送工具

    查看(528) 评论(0) 收藏 分享 管理

  • 测试中的bug度量

    2008-01-12 13:52:41

    BUG需要度量，常见的度量尺度包括

    。　发现问题－－版本/小组或成员
    。　关闭问题－－版本/小组或成员
    。　遗留问题－－版本
    。　发现问题－－模块
    。　漏测问题－－版本

    需要注意的问题

    BUG作为一个重要的工作成果，不应作为工作的重要衡量标准，一个简单的悖论，不测试即不会发现任何问题。作测试脚本的同样只能发现很少的问题。同样开发也不能将问题作为工作的重要衡量标准，一个简单的模块承担的风险会比较少。

    但是一个可以衡量的标准是漏测的曲线图，可以作为整个团队调整的参考。

    个人认为，如果发现BUG曲线异常，需要具体问题具体分析。可能是成员的水平态度问题，更有可能是需求和设计的问题，也可能是大家的工作都非常漂亮。这个时候，重要的是千万根据曲线，做出各种调查和验证，切忌匆忙下结论。

    查看(909) 评论(0) 收藏 分享 管理

251/212>
Open Toolbar