发布新日志

  • 敏捷测试和传统测试的区别

    2010-05-20 15:44:22

    到底有啥区别?敏捷测试是不是一种噱头,还是和传统测试有本质区别,这个问题困扰着我。
    敏捷开发的宣言:
    个体和交互  胜于  过程和工具
    可工作的软件  胜于  面面俱到的文档
    客户协作  胜于  合同谈判
    响应需求  胜于  遵循计划
    这些宣言如何去理解呢
     

    敏捷宣言 – 个体和交互

    •个体和交互

    1.每个团队成员。(这是必需的,每一个项目组成员都要和别人沟通、互动,除非这个项目就他一个人)

    2.发挥每个成员的特点和长处。 为个体塑造弹性的发挥空间。(刚毕业的人做PD、编程序、做测试哪来什么特点和长处,学习都来不及,所以敏捷开发是很有经验的一棒子人去做一个项目,这样各自可以发挥得淋漓至境;话句话说,不是敏捷开发也要强调发挥个人长处,例如让一个长期做功能测试的人去做编程,让DBA去做功能测试,这明显是错误的嘛)

    3.合作、沟通比单纯的写程序更重要。(合作、沟通,这个任何时候、任何地方、任何项目都是必需的,沟通的目的是确认接下来所做的事情是正确的,或者程序员之间交流经验、讨论技术难点)

    4.团队的意义所在 – 你不是一个人在战斗!(现在软件企业,哪个不在强调团队合作)

    •过程和工具

    1.过程追求标准化,限制了个体的发挥。(对于小项目可以这样做,但是,如果做产品没有标准化,产品的生命力在哪里?为了程序员个人的能力发挥,难道限制产品的扩展性、易用性,代码可以可以不用写注释了吗)

    2.工具-越强大的工具学习成本越高。目标是软件开发,不是学习工具。(谬论,工具是用来提高效率的,怎么会变成拖后腿的东西呢;强大的工具一旦学成,以后可以坐享其好处,人,不能这么短视,项目,也不能这么短视)

    3.选择合适的工具。(合适不合适,各有己见)

    敏捷宣言 – 可以工作的软件

    •可以工作的软件

    1.开发的目的是交付可以工作的软件 (所以敏捷只能再小项目和业务简单的项目中运用)

    2.对用户来说文档还存在一定的想像空间,会造成沟通障碍。(文档又不是一板子钉死的,用户不理解就要解释给用户听,但你总不能只带着一张嘴去跟用户说吧;或者拿着只实现了1/10功能的可交付软件去给用户看?)

    3.最好的文档是代码和团队。(代码是最好的文档?但是别人也要读得懂啊,客户能读得懂吗,难道给客户培训一年再让他们去理解代码?我们程序员居然有人拿这个当理由不写文档,你说我一个测试人员有空去你们的代码吗)

    •面面俱到的文档

    1.没有文档的项目是个灾难(看多大的项目了,小项目没文档照样好好的)

    2.文档的目的是沟通和总结,让大家明白要做什么、怎么做(这个没错)

    3.提倡的文档方式-看图说话(对项目成员要求比较高;图的类型要明确下,别只画个UI,就算图了,还有流程图、用例图等等)

    4.必要的时候也是需要完善文档的(啥时候?)

    (是本书都会教上面这些)

    敏捷宣言 – 客户合作

    •客户合作

    1.绝大多数软件系统是不能直接带来效益的(哪来的结论?论据呢)

    2.客户对自己的需求也不是很明确的,我们需要充当顾问(有的客户确实是这样)

    3.跟客户是一起来完成一件事情的,需要客户的不断反馈(什么叫以客户为中心,这就是)

    •合同谈判

    1.软件公司是指着合同来生存的(在鄙人看来,敏捷适合企业级的ERP\MIS,或者政府级的OA自动化项目,对电子商务类基本不适合)

    2.谈判只能暂缓变化,不能阻止变化(变化是必然的)

    3.合同和谈判是必须的,客户合作是企业长期发展的选择(废话)

    敏捷宣言 – 响应变化

    •响应变化和遵循计划

    1.计划赶不上变化(根本就没有想到后面怎么做,哪来变化,本来就是很多不确定,走到哪算哪)

    2.需求在变化、开发人员对业务的认识在变化、技术点在变化(废话)

    3.长期计划稳定,短期迭代。2周到详细计划、一个月的粗计划、三个月的目标计划。(跟螺瀑布式迭代开发有何区别)

    4.当变化没发生的时候不要猜测变化(废话,能算出会有什么变化,那是神啊)

    5.着力完成本计划内的工作任务,不需要为后期工作预留过多的接口和功能冗余(这难道不是短视么?以前强调的扩展性为什么不要?如果现在不考虑,现在很爽,以后就会很痛苦,会付出几倍的汗水去实现)

    6.力求设计简单清晰、降低耦合、模块可以自说明、大胆重构(降低耦合,说的轻松,没有一定的功力和时间,快速响应能做的出来吗?又要快速出可用的软件,又要低耦合,想得美)

    总结

    •目标是完成可以工作的软件(哪个项目不是呢)

    •文档是用来沟通的中间产物(有些是,有些不是,例如帮助文档是要交付给客户的,甚至需求、设计文档和代码都是,所有权归客户所有)

    •团队合作和内部沟通是很重要的,每个人都要为团队负责同时团队也要为每个人负责。(任何开发模式都要求团队合作,除非项目里只有一人)

    •沟通需要争吵,不是一定要和谐。个体要极力为自己观点补充细节,更要聆听不同意见。但最终要统一意见。(误导别人,团队当然要和谐,但是要敢于发表自己的意见、敢于接受别人的批评)

    •工作是需要方法的,同样沟通也是(题目太大了,说了等于没说,具体是啥方法呢)

    •工作氛围是可以相互影响的,不需要太安静(和感冒一样,这主要取决于团队的领袖)

    •积极面对变化(必需的)

    •工作要:快乐、积极、学习、合作 (不是一个项目能做到的,跟公司的企业文化和激励制度有关)

    敏捷宣言的原则

    •我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意(有没有价值得客户说了算,要是一个软件烦他N次,敏捷也就OVER了)

    •即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。(给客户带来好处,但是给软件开发带来麻烦,老板愿意吗)

    •经常性地交付可以工作的软件,交付间隔可以从几周到几个月,交付时间间隔越短越好。

    •在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。(为什么需要天天?业务是保姆啊,如果业务人员天天和开发人员在一起,那谁和客户天天在一起?)

    •围绕被激励起来的个人来构建项目。给大家提供所需的环境和支持,并且信任大家能够完成工作(....)

    •在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。(是的,但是不要没思考就和别人谈)

    •衡量进展的重要尺度是可运行的软件。(还是适合小软件)

    •敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、稳定的开发速度(要响应经常性的需求变化,怎么保证稳定的开发速度?)

    •不断地关注优秀的技能和好的设计会增强敏捷能力。(所以还是需要学习强大的工具)

    •高质量完成本次迭代中最简单的工作是根本。(如何高质量?不是只要软件能运行就可以了吗,每个小任务要又快又高质量完成,怎么可能呢)

    •最好的构架、需求和设计出自于自组织的团队。(废话,如果来自其它团队,沟通不是很麻烦吗)

    •每隔一定时间,团队会在如何才能更有效的工作方面进行反省,然后相应地对自己的行为进行调整。(这个要看团队的领导者如何去主导这个事情,也算是团队的一个文化)

    敏捷开发实践 - 团队组成

    成员分类:

    •团队长

    •业务及需求代表

    •开发人员

    敏捷开发实践 – 结对编程(结对编程就是乌托邦啊

    •两个人在一台机器前共同开发一个功能模块(乌托邦)

    •随时沟通、讨论、画图,随时争抢键盘编码(乌托邦)

    •共同对本模块负责(乌托邦)

    •每天有3-4个小时结对编程就够了,其余时间对系统和技术点研究、测试(以前没有积累吗,什么都要现学现用么,那样质量会高吗)

    •结对编程的个体要经常变换,以便相互学习(说来容易,对方哪有那么容易接手的?两个人能力差不多还行,如果差别较大,那谁跟谁学啊)

    敏捷开发实践 – 任务分解

    •每周项目组长把任务分解成功能点,由队员来结对选择。每个功能点由两个人共同负责,一个人主负责。

    •选择的任务必须按时完成。

    •指定时间对任务的收回以可工作的软件为最高依据。(不用管质量和部署的复杂度吗?)

    •任务尽可能短小,到Function级别(一个任务到底是功能点还是function?就算是function,是哪一层的)

    •任务要分优先级别(必需的)

    •鼓励队员选择非专长功能点,要有相对专长的人配合(不懂啊,为啥这样,提高团队的技能吗,但是这样能保证按时交出可工作的软件吗)

    敏捷开发实践 – 重构

    •单一职责原则

    就一个类而言,应该仅有一个可以引起它变化的原因

    •开放封闭原则

    软件实体(类、模块、函数)应该是可以扩展但不可修改的

    •替换原则

    子类必须能够替换基类

    •依赖倒置原则

    细节依赖于抽象。细节是外层,抽象是内层。

    •接口隔离原则

    不强迫客户依赖他们不使用的方法。接口属于客户,不属于所在类的层次结构。

    总结

    开发项目首要的是解决项目成员之间的合作与分工,解决这个问题之后再选用一个适合团队项目开发和分工的框架引用其中的部分做指导。

    开发还是要尽可能的考虑到位,拿过来就干,每个人依赖沟通,可以培训一下,分析规划和设计是有必要的,总结经验很重要,套路是可变的。

     
  • 单元测试之优化测试用例1

    2010-05-18 17:13:47

    今天灵感突现,写了10几个测试用例,其中一个方法觉得自己想得比较多,给大家分享下
    被测试方法如下
    getSupplyList(int pageNo, int pageSize)

    根据页号和每页条数获取商家信息申请单列表

    Parameters:
    pageNo 页号
    pageSize 每页条数
    Returns:
    返回列表或空(null)

    测试用例如下

    1. testGetSupplyList 

    原理:

    1.1增加三个supply(可以理解成user)

    1.2 调用getSupplyList(1, 20),获得第一页,每页2条

    1.3 验证getSupplyList是否返回20条

    还值得优化的地方:可以验证下返回的supply每个属性值是否正确

    2.testGetSupplyList1

    测试pageNo为0的情况,应该返回第一页的内容

    3. testGetSupplyList2

    测试pageNo为-1的情况

    4. testGetSupplyList3

    测试返回数据的排序情况

    5. testGetSupplyList3

    测试返回数据的排序情况,返回的数据应该根据supplyID顺序排

    6. testGetSupplyList31

    测试pageNo最后一页时

    7. testGetSupplyList4

    测试pageNo超过实际页数时

    8. testGetSupplyList5

    测试pagesize为0和1时

     

    各位看过的,有经验的帮忙说道说道下,这样的单元测试是否可行?

     

  • sonar学习-Cyclomatic complexity圈复杂度

    2010-05-17 13:51:35

    这个词不是很明白,下面是在网上查到的
    解释一
    控制流图是McCabe复杂度计算的基础,McCabe度量标准是将软件的流程图转化为有向图,然后以图论的知识和计算方法来衡量软件的质量。McCabe复杂度包括圈复杂度(Cyclomatic complexity)、基本复杂度、模块涉及复杂度、设计复杂度和集成复杂度等。控制流程图分析是一个静态的分析过程,它提供静态的度量标准技术,一般主要运用在白盒测试的方法中。
    Z$J l8i | J7J!N6{ l'z2B114943 控制流图的一个重要性质是它的可规约性(reducibility)。如果程序中不存在从循环外跳到循环内的goto语句,那么这个程序对应的控制流图是可规约的(reducible),反之这个控制流图就是不可规约的(irreducible)。因此,模块符合结构化程序设计的准则是控制流图可规约的基础。
    Q,_ V s }&`5p0w114943 程序环路复杂性也即为McCabe复杂性度量,它一般常用圈复杂度来描述,记录为V(G)。它用来衡量一个程序模块所包含的判定结构的复杂程度,数量上表现为独立路径的条数,即合理地预防错误所需测试的最少路径条数,圈复杂度大的程序,说明其代码可能质量低且难于测试和维护。经验表明,程序的可能存在的Bug数和圈复杂度有着很大的相关性。51Testing软件测试网 Z i0c ~*n,S'I
    圈复杂度的计算方法很简单,计算公式为:V(G)=e-n+2。其中,e表示控制流图中边的数量,n表示控制流图中节点的数量。其实,圈复杂度的计算还有更直观的方法,因为圈复杂度所反映的是“判定条件”的数量,所以圈复杂度实际上就是等于判定节点的数量再加上1,也即控制流图的区域数,对应的计算公式为:V(G)=区域数=判定节点数+1。
    h r0U&T#@-g o,J o114943 对于多分支的CASE结构或IF-ELSEIF-ELSE结构,统计判定节点的个数时需要特别注意一点,要求必须统计全部实际的判定节点数,也即每个ELSEIF语句,以及每个CASE语句,都应该算为一个判定节点。判定节点在模块的控制流图中很容易被识别出来,所以,针对程序的控制流图计算圈复杂度V(G)时,最好还是采用第一个公式,也即V(G)=e-n+2;而针对模块的控制流图时,可以直接统计判定节点数,这样更为简单。
  • 单元测试之优化用例

    2010-05-06 18:30:22

    最近这个项目,开发人员写了130个方法,但是测试用例写了63个测试用例,代码行覆盖率为80%,分支覆盖率60%,发现有几个问题
    1. 没有按照敏捷开发的原则先写测试用例,而是先写了很多方法(很多方法是空的,没逻辑)
    2. 分支覆盖率比较低,很多else部分没覆盖,有些null没判断
    3. 测试代码冗余非常多,看起来吃力(我后来做了优化,写了一些方法,把经常用的代码放在里面)
     
    我自己java代码不是很熟,边学边做,今天收货还是比较多的
    1. 一个方法返回多个值时,可以再重新写个简单的类,就是做些set\get的事情,例如下面的ResultSet,当然也有其它的方法,我不知道而已
     public ResultSet AddOneSupply(String Pid,String UserName,String Password,String Logo,String Type){
      int Result=0;
      ResultSet res=new ResultSet();
      Supply supply = new Supply();
      UserInfo user = new UserInfo();
      user.setPid(Pid);
      user.setPassword(Password);
      user.setUsername(UserName);
      supply.setUser(user);
      supply.setLogo(Logo);
      supply.setType(Type);
      supply.setCreateTime(new java.util.Date());
      supply.setModifyTime(new java.util.Date());
      Result = merchantService.supplyMerchant(supply);
      res.setSupply(supply);
      res.setiResult(Result);
      return res;
     }
    2. 单元测试进行assert时,尽量用直接查询mysql数据库的方式去校验结果,为此专门写了个类,方便访问mysql和执行SQL语句
     
  • 每日构建初窥

    2010-05-05 10:03:25

    构建工具之一 Hudson
    作用: 联合maven,负责编译代码和单元测试。
    构建工具之二 Sonar
    作用: 随着单元测试会进行覆盖率分析、规则违例分析、代码量分析等(没搞明白到底是Hudson还是Sonar去触发测试的)
     
     
    Hudson里面的一些设置(定时编译、定时测试)
    Build Triggers
     
    Loading...
     
    Loading...
      Projects names
    Multiple projects can be specified like 'abc, def'
     
    Loading...
      Authentication Token Use the following URL to trigger build remotely: HUDSON_URL/job/service_shangdao/build?token=TOKEN_NAME
    Optionally append &cause=Cause+Text to provide text that will be included in the recorded build cause.
     
    Loading...
      Schedule
    Loading...
     
    Loading...
      Schedule
    Loading...
    Build
      Root POM
    Loading...
      Goals and options
    Loading...
      MAVEN_OPTS
    Loading...
      Alternate settings file
    Loading...
     
    Loading...
     
    Loading...
     
    Loading...
     
    Loading...
    Build Settings
     
    Loading...
      Recipients
    Whitespace-separated list of recipient addresses. E-mail will be sent when a build fails.
     
     
     
    .mailHelp{ border: solid #bbb 1px; background-color: #f0f0f0; padding: 1em; margin-bottom: 1em; } hideConfiguredOptions(); addTrigger("Failure"); var advHelpElm = document.getElementById("advancedEmailHelpConf"); advHelpElm.style.display="none";
    Post-build Actions
     
    Loading...
      Files to archive
      Excludes
    Loading...
     
    Loading...
     
    Loading...
     
    Loading...
      Jobs to aggregate
     
    Loading...
      Projects to build
     
     
    Loading...
      Repository URL
      Repository ID
    Loading...
     
    Loading...
     
    Loading...
    Configure email recipients, content, and what should trigger a notification
      Global Recipient List
    Comma-separated list of email address that should receive notifications.
      Default Subject
      Default Content
    Trigger
    Send To Recipient List
    Send To Committers
    Include Culprits
    More Configuration
    Remove
    Failure Help for feature: Email Config
    View More Options (expand)
    Add a Trigger:
    swapEdit("Unstable");swapEdit("Failure");swapEdit("Still-Failing");swapEdit("Success");swapEdit("Fixed");swapEdit("Still-Unstable");
    Still Failing Help for feature: Email Config
    View More Options (expand)
    Success Help for feature: Email Config
    View More Options (expand)
    Fixed Help for feature: Email Config
    View More Options (expand)
    Still Unstable Help for feature: Email Config
    View More Options (expand)
     
    Loading...
      SCP site
      Files to upload
     
    Loading...
      Sonar Installation
      MAVEN_OPTS
    MAVEN_OPTS env var to provide, if not set the plugin will use the MAVEN_OPTS defined by the maven builder config.
      Additional properties
    Additional properties to be passed to the mvn executable (example : -Dsome.property=some.value).

     

     

    30 * * * * -------------表示每小时过后的半小时会编译代码(也就是说每小时都会编译)

    sonar>>Build periodically----------------这个是和sonar的连接处,每次编译完成后会运行sonar

  • UML统一建模语言(一)

    2010-04-28 14:38:26

    从百度上搜到天极网的一个页面,http://soft.yesky.com/lesson/281/2472281.shtml ,快速入门的资料,感觉还蛮有用,UML好多年前学习过,真正用过的机会不多,这次好好学习,好方法宝刀不老,现在还是不过时,值得终生为之学习....
    类图可以分为10个,归为5类
    类型 包含
    静态图 类图、对象图、包图
    行为图 状态图、活动图
    用例图 用例图
    交互图 顺序图、协作图
    实现图 组件图、部署图
     
    对功能测试人员有用的就用例图和和活动图,这两个能够描述参与者(可以是人、硬件、另外一个程序)和系统的所有交互,其它图基本是描述程序级的对象、类行为和关系。
    用例图可以描述出参与者做什么.
    活动图可以描述出参与者什么时候做、怎样做.
    注意:参与者这个词也可以称为角色和执行者,但不建议用角色,在中文里容易搞混,IBM Rational Rose的英文单词是role,翻译成参与者比较好理解。
     
    参与者的泛化关系:泛化关系是一般元素和具体元素之间的一种分类关系。具体元素与一般元素完全一致,但包含一些额外的信息。在允许使用一般元素的场合,可以使用具体元素的实例。 (评注:这是面向对象中用到的概念,如果从类的角度看,那就是两者之间是继承关系)
  • 啥是每日构建

    2010-04-27 16:57:11

    在以前的公司,每日构建就是nightly build,每天晚上对所有的代码进行build和跑一次单元测试,第二天程序们就可以收到邮件构建成功或失败的邮件,如果是自己的问题导致失败,那就赶紧去修改bug,执行的效率应该还有一点吧,但是不很深入,大家写单元测试的兴致也不高。
    这次要做的项目叫SD,也是公司里第一个采用敏捷开发的项目,对大家来说,很多东西都是新的。
    这次用的构建工具hudson(Extensible continuous integration server可扩展的集成服务器,具体参考http://hudson-ci.org/)。代码仓库用maven管理,
    底层代码基本上是java,所以打算用junit+hudson+sonar的形式进行每日构建,初步定为每小时构建一次;
    接下来我要熟悉hudson和maven、sonar,这几个工具虽然平时的测试会用到,但是基本没什么了解,得好好学习下。
Open Toolbar