文章列表
这个ALM解决方案中的个人开发环境我准备以Eclipse为基础进行构建，因此这里简单介绍一下Android Eclipse开发环境的安装过程。
Eclipse的安装其实很简单，选择从Eclipse.org下载J2EE开发版本
然后将自己下载的zip包在自己选定的目录直接展开就可以用了。
然后从http://developer.android.com/sdk/index.html直接下载
最近的工作一直在聚焦软件开发ALM解决方案，看了很多业界的商用解决方案，比如IBM RTC，Microsoft的TFS，这些系统很好狠强大，但是要付的MONEY也很好强大。我们能否用相应的开源构造类似的系统呢？最近我又研究了一些开源的系统，觉得这个应该是可行的，后面希望通过自己的实践能建立这样一套适合Android手机软件开发的ALM解决方案。这套ALM解决方案初步会包括项目管理、缺陷管理、配置管理、持续集成、研发IDE以及测试管理等功能。
初步的软件模块选择如下：
项目管理 Redmine或者TRAC
缺陷管理 MantisBT或者Bugzilla ...
前面主要讲了一些推行敏捷过程中的实践活动，而且主要聚焦在持续集成方面，主要原因是因为持续集成和敏捷下的质量看护往往被实践者忽略而缺乏实践。其实从推行敏捷过程来看，大家都逐步认识到敏捷其实并不仅仅只是一些表面上的实践，实践的效果的好坏很大程度上取决于根植于这个实施敏捷团队的管理和文化基因。
敏捷是理念、优秀实践和根据实际情况灵活应用的三位一体。敏捷最关键的是核心理念，消除研发活动中的浪费，聚焦客户价值；强调团队协作，激发团队潜能；根据实际情况不断调整以适应情况的变化。而迭代交付和持续集成是敏捷的两大核心工程实践。
如何聚焦客户价值呢？首先确保逐步消除软件研发活动中不聚焦客户价值的活动；其次确保 ...
最近抽空看了一下VersionOne推出的第六份敏捷年度调查报告。 从这份报告中看到一些数据很有意思，想从一个敏捷实践者的角度来谈谈这份报告。
首先来说，报告说现在有90%的人都开始具备敏捷开发的相关技术，80%的组织在他们的软件开发过程中采用敏捷开发技术，并且有一半的公司采用敏捷开发超过2年，并且60%的公司中有一半以上的项目采用敏捷开发，这些数据都说明敏捷开发已经成为了软件的普遍技术。
从敏捷团队采用的敏捷技术来看，Scrum（52%）、Scrum/XP混合（14%）、自由组合（9%）名列前三，成为了技术的主流。为什么会这样？我想这是项目应用的结果。Scrum给出了一个完整的产品开发活动 ...
在项目级的质量防护体系逐步建立之后，原先那个只能保障最基本功能和性能的版本级质量防护体系显得越来越起不到防护作用了，因为基本的功能和性能防护在前端比较完备的防护体系下基本也得到了守护。 那是不是就不需要 ...
前面说过项目级的质量保障中，一个很关键的活动就是单元测试。那么到底如何来做单元测试呢？这里先讲一个有关单元测试的小故事。
这个故事说的是Morgan Conrad。
一天早晨，一名程序员向大师提了一个问题：“我想写一 ...
前面谈到了项目级质量保障体系的基本架构建设情况，这里再深入的说说项目级质量保障体系的测试用例体系建设过程。
我们开发的是大型嵌入式软件，从软件测试角度来说，在项目级一般应该包含单元测试、集成测试和系统 ...
在完成了版本级的构建和质量防护体系建设之后，产品的基本CI体系正式投入运行，构建出的版本的最基本质量有了保障。随着版本构建的质量有了控制，任何一个项目组的缺陷对版本构建的影响在CI体系变红的时候立刻就体现出来，版本构建事故频发，项目组在CI纪律的影响下压力越来越来，纷纷开始寻找解决办法。
其实在版本CI体系建设之前，项目组级的单元测试和集成测试以及最基本的系统测试都在做，但是因为没有形成自动体系，主要依赖人工进行，经常会出现项目组因为进度紧张而私自省略项目级质量保障活动的情况，因为当时主要通过后续的较长时延的系统测试来检验版本质量，这样项目组即使省略也没有太大压力。但是现在实时的版本CI体系出 ...
测试基础（四）自动化测试
- 博客分类：
- 测试
在建设CI体系的质量防护体系中，一个关键是测试自动化，这里再谈谈测试自动化的相关背景。按照自动化测试的相关特性，我们可以将到目前为止的自动化测试分为三代：
第一代自动化测试，使用的是工具一体化的自动化测试系统，也就是自动化测试与测试工具、测试对象等相关的测试环境完全绑定，测试用例主要依靠捕捉回放的方式，用例投入大而灵活性很差，主要用于系统回归；
第二代自动化测试，为了解决测试用例与测试环境绑定的问题，引入了各种自动化控制语言，比如TCL、PYTHON、JAVASCRIPT等，通过这些语言灵活控制测试环境的变化，实现了测试用例的独立性，测试用例对于测试过程的描述可以持续继承使用并逐步形成完备的 ...
基础的CI系统建立起来之后，解决了版本构建的问题，大家很高兴。但是版本构建出来的速度虽然快了，但是产品软件的质量还是没有提高，因为所有的软件的版本验证那怕是基本的版本冒烟测试我们都还是手工，现在冒烟测试成为了整个软件版本生产的瓶颈，软件产出来也没有太大意义。如何解决这个瓶颈？沿着前面CI建设的思路，我们开始了版本冒烟测试的CI集成，软件冒烟测试以前是半自动化，现在关键就是把版本构建和软件冒烟测试自动化连接起来。在解决了软件冒烟测试半自动化的人工结果判断的难题之后，通过CI我们顺利的实现了版本构建到版本基本功能冒烟的全过程，现在一个CI生产线下来的软件版本终于具有最基本的质量保障！这对CI系统来说 ...
在经历了初期的迷茫之后，大家开始变得实际起来，大家开始从仔细从基础的角度来思考那些敏捷切实是对我们的研发真正起作用的。
我们首先选择了CI，因为CI是整个软件研发的核心发动机。而我们构建CI的第一阶段就是把版本的构建过程自动化，为什么选择版本的构建自动化呢？因为版本构建过程自动化能真正降低版本构建的人力消耗，在提升版本构建的效率的同时避免人工构建带来的错误。版本构建自动化的改造主要在两个方面，第一个就是所有的版本构建的脚本的清理，确保通过脚本能完整正确的构建脚本，这部分以前有基础，关键是调整以前手动构建中的一些对人的依赖，把这些所谓的依赖尽量通过参数和脚本解除掉；第二个就是选择一个持续集成的平 ...
部门尽然选择试点敏捷，当然需要请一些熟悉敏捷的人来指导，部门的人员也开始了敏捷的相关学习，但是无论是前来指导的所谓敏捷教练还是土产的敏捷专家，大家其实都没有太多真正的敏捷实施经验，因此敏捷实践照葫芦画瓢为主，虽然敏捷的各种实践活动在进行，大家的座位都搬到了一起，但是在深层次对于敏捷的意识层面的理解基本是空白。一个版本下来，所谓的敏捷试点标杆，因为没有从敏捷的本质上认识敏捷，从实质结果上来看其实是瀑布的脑袋顶着敏捷的旗号进行裸奔的疯狂。版本的前期速度虽然很快，但是版本的质量比原来的瀑布模式下赶工开发的产品质量更差，最好直接导致这个噩梦般的版本，两年多后我们现在还在规模投入维护。
从瀑布到敏捷（一）不得不为的敏捷尝试
- 博客分类：
- 系统工程
部门在推行CMM的几年时间里已经建立了较为完备的开发流程，大家的开发能力信心逐渐爆棚，思维中没有搞不定的客户需求。但是，随着客户需求响应周期要求越来越短，瀑布模式下固有的长响应周期越来越无法满足要求。同时产品的规模约来越大，大家普遍都反馈做不动，而且产品的交付质量却每况愈下。一个版本的系统测试缺陷数上万，其中的低级编码缺陷占到50%，不改不行了。如何改？大家意见不一。其时，敏捷正在大热流行，敏捷自然成了大家首先想到的银弹，但是没有相关经验，谁都不敢盲目上马。恰在此时，业界标杆的一些实践成功的信息不时耳闻，再次挑动了大家的本已脆弱的神经，终于促动了部门的敏捷改革。从此，我们也踏上了近三年的坎坷敏捷 ...
在产品有两年多的质量能力提升实践，总结出的三点经验：
1、尽可能在开发流程的早期构建质量防护能力；
2、能力只有构建在工具基础上才能成为组织能力；
3、能力只有集成到开发流程的质量保障体系中才能确保可继承和可持续提升。
没有风险，就不要测试，因此测试的基本测试策略就是基于风险的测试。
那到底该如何进行测试呢？如何选择测试策略最终交付产品的风险更小呢？要根据产品的质量要求和测试类型来确定合适的测试策略。
如一般的IT产品，一般可以考虑从证实的角度进行测试设计；如产品的质量要求很高，比如电信产品等，一般要求在证实的基础上还要多从证伪的角度去考虑。
同时考虑证实和证伪的难易程度，一般在前期的UT/IT测试中可以尽可能多的考虑证伪，在ST和AT测试中一般主要从证实的角度来进行验证。
综合来说，就是根据产品的质量要求和测试类型，测试需要证实和证伪相结合。