Category: Testing

Testing, Test Automation, Agile Testing

3rd Day @ Agile Testing Days.DE

The 3rd day had also many good sessions, it started with key note “The One Thing You Need To Know” by Mary Poppendieck. She mentioned there are three rules of Lean Development (as in the picture below) : Design /

2nd Day @ Agile Testing Days.DE

Two days conference with presentation tracks after the tutorial day, the 2nd day started at 13th Oct. Jose Diaz and Alessandro Collino gave the welcome speech, obviously they knew that shorter openning is the best :-) Lisa Crispin, the co-author

《Lessons Learned in Software Testing》:网上的非法翻译

前段时间在翻阅《Lessons Learned in Software Testing》这本书,觉得写得很不错,没想到机缘巧合居然在网上搜到相关的中文翻译,可惜的是一看就是非法翻译,或者非法转载(如果有正式的中文版出版过的话。。)。本来准备自己看完后再来写总结的,不过既然看到了这些资源(虽然有非法嫌疑),也就先和大家分享分享啦~ 既没有署名作者,也没有注明文章来源,此乃鸡鸣狗盗之举,将他人智力产物以此等方式加以掩饰,令无知的群众以为是他们的创作。快速地浏览过此网站之后,发觉其中绝大多数文章都属于非法转载,唏嘘啊。此网站貌似还号称是比较红火的测试社区“51Testing软件测试网”,更郁闷的是我以前还参加过他们举办的沙龙,还给他们当嘉宾,NND。。 搜索下,原来已经有中文版出版,看来前面的问题最多也就是转载了,China-Pub上有《软件测试:经验与教训》。这个测试网上也有扫描版的pdf下载,“软件测试经验与教训-293个观点”。 在此网上看到、搜到的其他相关文章有: 软件测试员的角色 (一)软件测试员的思考问题方式 (二)软件测试员的思考问题方式 软件测试手段 测试自动化的19个教训 《软件测试经验与教训》第一章测试员的角色 《测试的经验与教训》15 《测试的经验与教训》6 《测试经验与教训》7 《测试的经验与教训》11 《测试的经验与教训》8

Keyword abstraction (robotframework)

A small piece of experience, comes from one email discussion, quite a long time passed, I haven’t organized it yet, so forgive its rough format… People always say that they need to add a lot of comments to explain complex

《持续集成:软件质量改进和风险降低之道》读后总结 2

豆瓣上有此书的介绍,《持续集成:软件质量改进和风险降低之道》。此书还有配套web站点,提供了此书更新、代码示例和其他材料。 第二部分 创建全功能的CI系统 第五章 持续数据库集成(Countinuous Database Integration, CDBI) 项目成员通常执行的数据库集成活动可以自动化:删除数据库;创建数据库;插入系统数据;插入测试数据;迁移数据库和数据;在多个环境下建立数据库实例;修改列属性和约束条件;修改测试数据;修改存储过程(包括函数和触发器);取得对不同环境的访问权;备份/恢复大量数据。 共享数据库集成脚本是一项最佳实践,直接而简单。所有软件资产都要放到版本控制库中,这包括了所有数据库资产: 删除、创建表和视图的DDL,包括约束条件和触发器 存储过程和函数 实体关系图 针对不同环境的测试数据 具体的数据库配置 利用结合构建脚本使数据库集成自动化,持续执行,在对数据库或源代码进行修改后就执行。将数据库资产放入版本控制库,确保它们有单一来源。测试并审查你的数据库脚本和代码。确保所有数据库集成都由构建脚本管理,所有数据库资产都签入版本控制库,所有(与数据库打交道的)开发者都有一个数据库沙盒。 第六章 持续测试 系统工程有一项原则,线性系统的可靠性是每个系统组件的可靠性的乘积。对于包含100个组件的线性系统来说,如果每个组件的可靠性是99%,整个系统的可靠性就只有37%。所以作为底线,如果我们要构建真正可靠的软件系统,我们就必须确保对象层面的可靠性,这只能通过成功的单元测试来实现。 源代码的可靠性取决于测试覆盖率,测试的价值取决于它们执行的频率。通常将测试分为4个自动执行的分组: 单元测试:可利用NUnit或JUnit这样的单元测试框架。这些单元测试应该没有外部依赖关系,不会依赖于文件系统或数据库。 组件测试:利用NUnit或JUnit这样的单元测试框架,让您的组件测试自动化,如果用到数据库,就是用DbUnit或NDbUnit。这些测试涉及更多对象,通常比单元测试需要花更长的时间来执行。 系统测试:系统测试比组件测试执行的时间更长,通常涉及多个组件。 功能测试:利用Selenium(针对Web应用程序)和Abbot(针对GUI应用程序)这样的工具,可以让功能测试自动化。功能测试从用户的角度执行操作,通常是自动化测试套件中执行时间最长的。 将测试分为一些组,您可以按不同的时间间隔来执行那些较快(如单元测试)和较慢的测试(如组件测试)。根据新的缺陷编写测试,增加代码覆盖率,确保这个缺陷不会再次出现。利用数据库测试框架确保数据处于“已知状态”,这有助于使组件测试可重复。将测试用例限制为一个断言,您可以花较少的时间来追踪测试失败的原因。 第七章 持续审查 利用工具进行自动化的代码审查能够解决80%的问题,让人来处理另外20%的重要问题。审查基于一组预先定义的规则分析代码。审查者(或静态和动态的分析工具)是由确定的标准指导的,团队应该坚持这些标准(通常是一些编码或设计方面的测量指标)。 通过持续执行审查,可以减少发现缺陷和后续修复之间的时间。 复杂度被证实与缺陷有关。请利用您的审查工具来监控代码的复杂度,采取措施来监控复杂度的变化趋势,利用测试用例和重构来降低缺陷的风险。 通过定量地描述配件/包或对象之间的耦合,架构方面的耦合指标可以有效地定位代码的长期维护问题。这些测量指标可以揭示在面对改变时的相关风险。 传入耦合(Afferent Coupling),也称作Fan In 传出耦合(Efferent Coupling),也称作Fan Out 不稳定性 = 传出耦合/(传出耦合

《持续集成:软件质量改进和风险降低之道》读后总结 1

豆瓣上有此书的介绍,《持续集成:软件质量改进和风险降低之道》。此书还有配套web站点,提供了此书更新、代码示例和其他材料。 第一部分 CI的背景知识:原则与实践 第一章 启程 一次构建:不止是一次编译(或是动态语言中的某种称谓)。一次构建可能包含编译、测试、审查和部署以及其他一些事情。一次构建是将源代码放在一起,并验证软件可以作为一个一致的单元运行的过程。 涉及到的工具和参与人员包括:开发人员、版本控制库(如subversion)、CI服务器(如CruiseControl)、构建脚本(如Ant)、反馈机制(如email)、集成构建计算机。 CI的特征:与版本控制器系统的连接;构建脚本;某种类型的反馈机制;集成源代码变更的过程。 其子过程包括:源代码编译;数据库集成;测试;审查(如静态和动态分析);部署;文档与反馈。 第二章 引入持续集成 CI的价值在于: 减少风险 缺陷的检测和修复变得更快 软件的健康程度可以测量 减少假定 减少重复过程 减少重复过程的劳动,让人们有时间做更多的需要动脑筋的、更高价值的工作。 通过对一些重要过程(如测试盒数据库集成)自动化,克服项目中的某些成员对实现改进的抵制。 在任何时间、任何地点生成可部署的软件 增强项目的可见性 有效地决策:CI系统可以对当前的构建状态和品质指标提供及时的信息。 注意到趋势:如构建成功或失败、总体品质以及其他相关的项目信息。 对开发团队的软件产品建立起更强大的产品信心 阻碍团队使用CI的原因: 增加了维护CI系统的开销 变化太大 失败的构建太多 额外的硬件/软件成本 开发者应该执行这些动作 对于在项目中实现CI的团队和个人很有好处的7项实践: 经常提交代码:进行小的变更;在每个任务之后进行提交。 不要提交无法构建的代码 立即修复无法集成的构建 编写自动化的开发者测试 必须通过所以测试和审查 执行私有构建 避免签出无法构建的代码 第三章 利用CI减少风险

《软件测试的艺术》读后总结

近段时间一直在读《软件测试的艺术(原书第2版)》这本书,想看看经典的著作究竟如何讲测试。读完后总体上的感觉是“不错”,和读过的其他测试书籍讲的差不多,可能更简洁些,但还算很全面。这本新版里也增加了对新兴web测试的描述,以及对极限编程方法中如何进行测试也有涉及。其中提及的各种测试技术简单易懂,能否产生效用更多的依赖于使用者的深入理解和灵活应用的能力。 摘录概要内容如下: 第二章 软件测试的心理学和经济学 测试的定义:测试是为发现错误而执行程序的过程。 软件测试的重要原则: 测试用例中一个必需部分是对预期输出或结果的定义。 程序员应当避免测试自己编写的程序。 编写软件的组织不应当测试自己编写的软件。 应当彻底检查每个测试的执行结果。 测试用例的编写不仅应当根据有效和预期的输入情况,而且也应当根据无效和未预料到的输入情况。 检查程序是否“未做其应该做的”仅是测试的一半,测试的另一半时检查程序是否“做了其不应该做的”。 应避免测试用例用后即弃,除非软件本身就是一个一次性的软件。 计划测试工作时不应默许假定不会发现错误。 程序某部分存在更多错误的可能性,与该部分已发现错误的数量成正比。 软件测试是一项极富创造性、极具智力挑战性的工作。 第三章 代码检查、走查与评审 大多数的软件项目都应使用到以下的人工测试方法: 利用错误列表进行代码检查 小组代码走查 桌面检查 同行评审 第四章 测试用例的设计 由于时间和成本的约束,软件测试的最关键问题是:在所有可能的测试用例中,哪个子集最有可能发现最多的错误? 黑盒测试:等价类划分、边界值分析、因果图分析、错误猜测 白盒测试:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖 第五章 模块(单元)测试 模块测试(或单元测试)是对程序中的单个子程序、子程序或过程进行测试的过程,也就是说,一开始并不是对整个程序进行测试,而是首先将注意力集中在对构成程序的较小模块的测试上面。这样做的动机有三个。 首先,由于模块测试的注意力一开始集中在程序的较小单元上,因此它是一种管理组合的测试元素的手段。 其次,模块测试减轻了调试(准确定位并纠正某个已知错误的过程)的难度,这是因为一旦某个错误被发现出来,我们就知道它在哪个具体的模块中。 模块测试通过为我们提供同时测试多个模块的可能,将并行工程引入软件测试中。 模块测试的目的是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。这里的测试目标不是为了说明模块符合其规格说明,而是为了揭示出模块与其规格说明存在着矛盾。 第六章 更高级别的测试 功能测试:试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。 系统测试:最容易被错误理解,也是最困难的测试过程。系统测试并非是测试整个系统或程序功能的过程,因为有了功能测试,这样会显得多余。系统测试有着特定的目的“将系统与其初始目标进行比较”。给定这个目标之后,隐含两方面的含义:(1)系统测试并不局限于系统。如果产品是一个程序,那么系统测试就是一个试图说明程序作为一个整体式如何不满足其目标的过程;(2)根据定义,如果产品没有一组书面的、可度量的目标,系统测试也就无法进行。设计测试用例时应考虑全部的15种类型: 能力测试(facility

robotframework Basic Training @090403 : test cases

Here are those Robot cases created by the trainees. They were not updated after I gave comments on drawbacks of each style, do NOT take as good examples of Robot cases. Pair 1 : Log In Test Setting Value Resource

robotframework Basic Training by ME

Went through the theory part quickly, introducing that "Acceptance Testing" is our focus area in this course, also robotframework is designed for this area. Then explained different levels/types of test automation, frameworks for test automation, then robotframework. Shortly we moved

评《从一个实例详解敏捷测试的最佳实践》

前几日同事分享了一份号称IBM的敏捷实施经验,看完心中有好多疑问,在网上搜索,发现此文应该是率先发布在IBM的DeveloperWorks上面:《从一个实例详解敏捷测试的最佳实践》,但遗憾的是此文中有很多对敏捷开发的误解。 文中所引用的“敏捷软件开发有着自己独特的流程”事实上是Scrum概要图,而非敏捷的流程图。 极限编程、Scrum并非是在敏捷开发前出现的软件开发方法,而是敏捷方法中的一部分,至于测试驱动开发更只是极限编程之中的工程实践而已。 “团队中的项目经理(Scrum master)需要在每个客户需求到来的时候制定 Sprint 的周期,定义每个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。” scrum master并不是团队的经理,也并不是以往的项目经理换个名字,而是具有不同的职责和权力 sprint周期的确定并不是有scrum master一个人来确定,需要由相关人员商讨决定,取决于产品所处的行业环境、客户对交付的要求、团队能否适应短周期等等许多因素 sprint的目标、分派任务、总结得失,这些都应由团队自己担起责任,这才能培养出scrum里面重要的一个role — self-organized team “如果项目进行于开发新功能时期……..如果项目进行于测试新功能时期,”:这依然是瀑布式流程化思想的产物,敏捷宣言中有提到,working software才是唯一的度量,在同一个迭代周期内,需要完成所有的需求分析、开发、测试、客户文档等相关活动,并不会分为“开发时期”和“测试时期” “测试人员需要在每天的站立会议(Daily Standup Meeting)上报告前一个工作日发现的新缺陷情况,项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。需要及时修复的缺陷是目前 Sprint 中的一个新任务,将由项目经理添加到 Sprint Backlog 上并通知开发人员去修复漏洞。” 站立会议是团队成员之间交流状态分享信息的机会,而不是向某个管理人员报告 迭代周期内的工作内容一般在迭代开始前已经确定,并不再变化,因此不存在需要在站立会议上由项目经理来决定是否修复 以及,在迭代周期内对于工作内容的变更都应该由产品负责人来抉择,而非项目经理(如前所言为scrum master) “对于敏捷开发和测试中的审查过程,极限编程中的同行评审(peer review)思想得到了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对,互相评审;有时候,一个开发和一个测试人员也可以组成一对, 互相协作。这样能够有助于缺陷和问题在第一时间被抹杀在萌芽中。”:作者混淆了peer review与pair programming(或pair work) “敏捷开发还有以下几个关键概念 (Key

Top