-
敏捷测试和传统测试的区别
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里面的一些设置(定时编译、定时测试)Post-build ActionsLoading...Files to archive Loading...Excludes Loading...Loading...Loading...Loading...Jobs to aggregate Loading...Loading...Projects to build Loading...Repository URL Loading...Repository ID Loading...Loading...Loading....mailHelp{ border: solid #bbb 1px; background-color: #f0f0f0; padding: 1em; margin-bottom: 1em; } Configure email recipients, content, and what should trigger a notification HelpGlobal Recipient List - This is a comma or whitespace separated list of email addresses that should receive emails for a trigger.
Default Subject - This is the default email subject that will be used for each email that is sent. NOTE: this can be overridden in for each email trigger type in the Advanced section.
Default Content - This is the default email content that will be used for each email that is sent. NOTE: this can be overridden in for each email trigger type in the Advanced section.
Advanced HelpTrigger - If configured, and trigger conditions are met, an email of this type will be sent upon completion of a build. Click the help button next to the trigger name to find out more about what conditions will trigger an email of this type to be sent.
Send To Recipient List - If this is checked, an email will be sent all email addresses in the global recipient list.
Send To Committers - If this is checked, an email will be sent all users who are listed under "changes" for the build. This will use the default email suffix from Hudson's configuration page.
Include Culprits - If this is checked and Send To Committers is checked, emails will include everyone who committed since the last successful build.
More Configuration - You can change more settings for each email trigger by clicking on the "+(expand)" link.
Remove - You can remove an email trigger by clicking the "Delete" button on the row for the specified trigger.
Add a Trigger - You can add an email trigger by selecting it from the dropdown menu. This will add the trigger to the list of configurable triggers.
More Configuration HelpRecipient List - This is a comma or whitespace separated list of email addresses that should receive emails for the selected trigger.
Subject - This is email subject that will be used for the selected email trigger.
Content - This is the default email content that will be used for the selected email trigger.
Content TokensYou can specify the email subject line and body text by configuring the appropriate fields. Furthermore, you can insert special text by placing tokens in these fields. The list of available tokens, and a description of each can be found below.
Available Tokens- $DEFAULT_SUBJECT - This is the default email subject that is configured in Hudson's system configuration page.
- $DEFAULT_CONTENT - This is the default email content that is configured in Hudson's system configuration page.
- $PROJECT_DEFAULT_SUBJECT - This is the default email subject for this project. The result of using this token in the advanced configuration is what is in the Default Subject field below. WARNING: Do not use this token in the Default Subject or Content fields. Doing this has an undefined result.
- $PROJECT_DEFAULT_CONTENT - This is the default email content for this project. The result of using this token in the advanced configuration is what is in the Default Content field below. WARNING: Do not use this token in the Default Subject or Content fields. Doing this has an undefined result.
- $PROJECT_URL - Displays a URL to the project's page.
- $FAILED_TESTS - Displays failing unit test information, if any tests have failed.
- $CHANGES - Displays the changes since the last build.
- $BUILD_URL - Displays the URL to the current build.
- $BUILD_LOG - Displays last 250 lines of the build log
- $HUDSON_URL - Displays the URL to the Hudson server. (You can change this on the system configuration page.)
- $BUILD_STATUS - Displays the status of the current build. (failing, success, etc...)
- $BUILD_NUMBER - Displays the number of the current build.
- $PROJECT_NAME - Displays the project's name.
- $CHANGES_SINCE_LAST_SUCCESS - Displays the changes since the last successful build.
Global Recipient List Comma-separated list of email address that should receive notifications. Default Subject Default Content TriggerSend To Recipient ListSend To CommittersInclude CulpritsMore ConfigurationRemove(expand) (collapse) An email will be sent any time the build fails. If the "Still Failing" trigger is configured, then a failure email will not be sent if multiple buildsfail without a successful build.Recipient List Subject Content Add a Trigger: (expand) (collapse) An email will be sent any time the build is unstable. If the "Still Unstable" trigger is configured, then a unstable email will not be sent if multiple buildsare unstable without a successful build.Recipient List Subject Content swapEdit("Unstable"); swapEdit("Failure");(expand) (collapse) An email will be sent if the build status is "Failure" for 2 or more builds in a row.Recipient List Subject Content swapEdit("Still-Failing"); (expand) (collapse) An email will be sent if the build status is "Successful". If the "Fixed" trigger is configured, and the previous build status was "Failure" or "Unstable", then a the "Fixed" trigger will send an email instead.Recipient List Subject Content swapEdit("Success"); (expand) (collapse) An email will be sent when the build status changes from Failure or Unstable to Successful.Recipient List Subject Content swapEdit("Fixed"); (expand) (collapse) An email will be sent if the build status is "Unstable" for 2 or more builds in a row.Recipient List Subject Content swapEdit("Still-Unstable"); hideConfiguredOptions(); addTrigger("Failure"); var advHelpElm = document.getElementById("advancedEmailHelpConf"); advHelpElm.style.display="none"; 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,这几个工具虽然平时的测试会用到,但是基本没什么了解,得好好学习下。
标题搜索
我的存档
数据统计
- 访问量: 25042
- 日志数: 28
- 图片数: 1
- 文件数: 1
- 建立时间: 2008-09-01
- 更新时间: 2021-05-23