敏捷、开源和测试之我见

敏捷

敏捷开发方法是一种以人为核心、迭代、循序渐进的开发方法，强调个人与交互胜于过程与工具，强调开发过程中的灵活与主动，但我觉得我们不应该固化思维，如果工具或过程对我们有用，完全可以拿过来，应用到敏捷中去。

这就涉及到我们为什么要用敏捷？不断变化的需求、越来越短的开发周期等等。但其实在我看来，是为了开发符合时代和市场特征的高质量软件~

Ok，21世纪的高质量软件应是什么特征？

首先是方向准确，即你开发的是正确的软件，确实满足了用户的需求，或者说痛点来得更合适，给用户创造了价值。这是第一位的，不管你软件本身质量怎样，你说你运行从无bug，流量、耗电少，这些都是次要的，如果方向不正确，你就输了一大半。

其次是软件本身的质量问题，即运行正确，软件没有或很少 Bug，扩展性很强，性能良好，易用性高。这样的软件是一个运行良好的软件，但还不能称之为高质量的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用，经常出错，性能很差，这样的软件也不是一个高质量的软件。

以上的论述针对一个前提，即你开发的是一个产品而不是项目。项目往往是为某个客户而开展，有特定的需求来源，而产品往往是一个更广泛的概念，是市场上某一类客户群体的价值代表，没有固定的需求来源，而且良好的产品往往要起到引导客户需求的作用，超越现有客户能提出的需求，所以对产品来说，“正确的软件”更加困难，但也更加重要。

在参考了CMMI与敏捷开发方法的融合、案例以及自己已有的项目经验后，提出敏捷开发中如何进行高质量的软件过程。

开发正确的软件决定性在于需求，分为需求获取和反馈、需求分析和需求创造三个方面。

基于角色的方法论，即一切从角色出发考虑问题。每个人思考的角度不一样，客户思考的问题与开发团队的角度不一样，甚至不同客户之间思考问题的角度也不一样。客户的生活工作环境背景、期望、需求等因素是造就角度不同的原因。

我们萌发做某个产品，对产品要解决的问题和创造的价值基本会有个大的方向，在这个基础上，我们分析出产品客户角色的类型，设定用户的生活工作背景，从他得角度去考虑功能、使用的流程和场景。在人机交互这门课上，我们都学过人物卡片，差不多类似这样。开会时，一个人取其中一个卡片，模拟该客户，作需求的讨论分析。通过这种方法，我们可以清晰地获取用户的需求列表，可以以小故事的形式进行具体化阐述。仅仅这样还不够，用户访谈、调查问卷等等，都可以作为我们需求的补充来源。

OK，现在我们有了大量的需求，如何作有效地过滤并筛选出不同价值等级的需求？在这里，我们以市场和客户为中心分析，而不是从技术角度上取考虑。产品的需求进行 SWOT 分析，输入是所有的客户需求、市场现状、产业现状、竞争对手现状等，从优势、劣势、机遇、威胁这4个角度去分析，输出是需求的重要度和紧急度，以及投入的成本。

 

当然，以上只能让我们做一个成功地产品，距离一个伟大的产品还缺一步，就是发现跟随需求，不如去创造需求。创新者可以开辟出一个新的蓝海，创造出符合未来用户需求的规则和产品。老实说，这需要灵性和机遇，没有成熟的方法论。

以上基本可以确定我们第一版产品的需求，然后可以用Axure、Mockup等绘出产品的演示原型，不仅方便与用户的沟通、市场营销人员理解产品，也方便开发人员正确理解需求。

第一版出来后，以后版本的迭代和更新需求基本上靠微创新，以用户体验为中心，更好地改善产品的使用流程和操作体验。个人认为，把自己当做小白用户，切实地放到每个场景下去使用产品是微创新的来源。

软件运行正确关键在于高质量的开发过程。

由团队中的某一个人做架构设计，当然也可以两个结对做。主要是高层次的架构设计，如：组件的结构，软件的层次，技术选型等，没有进一步的详细设计。

a)       组件结构是否清晰。围绕组件的特性：“高内聚”、“松耦合”、“隔离性”、“颗粒度”、“分层”等特点，设计良好的组件结构。组件的抽取过程，可以在公司组织结构部门设立中找到似曾相似的影子。在公司组织结构中，任何事情重复或重要到了一定程度，就会产生一个新的部门，如做销售的人多了，就产生了销售部门，不同省的销售多了，就产生了省分部门。在架构设计中也是一样，任何功能重复的到了一定程度，就应该抽象出新的组件，甚至一个产品。在设计好组件结构后，就可以分工进行开发。

b)      层次结构是否清晰。关系是否混乱？是否需要抽取单独的层次？

c)       是否符合 Do not repeat yourself 的规则。好的架构设计应该是“不重复自己”，并且“不重复已有的成熟组件”。尤其是当架构中有些功能有免费成熟开源框架或者标准可以依据，但架构设计时没有采用考虑，而重新发明轮子，导致不能重用已有的标准或开源框架的优势，这些都是不可取的。

d)      技术选型是否合理。包括数据，模型，展现，逻辑等技术选型，以及使用框架，依赖产品等。

在模块划分完毕后，即可分工开发。团队要定义统一的命名规范，代码结构规范。确保代码和代码结构的质量。团队也可以选用一些自动化的代码扫描工具来分析代码结构及存在的不合规范的地方。每周或每天可以空出时间作代码评审会议，选取团队某人为例，统一团队代码风格，帮助重构改善设计，其他人以其为例完善自己的代码。

敏捷讲究code is design，好的代码应当如沐清风让你慢慢了解其设计和思路。所以不断地重构完善是关键。

好的代码的特点：

a)       高质量代码结构在于开发人员不断重构，把代码按照逻辑结构分成不同的包。

b)      高质量的代码格式一般可以通过工具中的编辑器的代码模板和格式器来控制。

c)       高质量注释即是代码的注释，又是软件的设计文档。

d)      这里强调一点是高质量的命名，不管是包命名，类命名还是变量命名，命名时应该采用能够让人看懂的名字，名字长一些往往更好，尽量少用不清晰的缩写。如：People 对象，应该用 people 等能够一目了然的命名，而不是 p, pe 等简短不清晰的命名。

 

测试驱动、持续集成（自动化集成工具），功能、集成、安全性等测试确保软件的高质量

 

在敏捷开发的各个迭代过程中，如何对过程的质量作量化评价标准？我们是以为用户创造价值为核心的，因此引入的用户满意度评测模型。用户满意度可简要地定义为：用户接受产品和服务的实际感受与其期望值比较的实际程度。

 

顾客满意度是由顾客的需求或期望(E)发与顾客感知(P)间的差距来决定的，差距越大，顾客越不满意。公式：

                                                      

                            

      　　　　　

 

顾客总体满意度公式：

评价的过程：

a)       识别出目标用户

b)      确认用户的需求

c)       将用户对需求的满意度做量化标准，抽样、问卷设计

d)      计算满意度

e)       对结果做分析，寻找原因，以便在下一个迭代中改进

具体参考论文：敏捷开发过程质量控制

没有任何一个方法论是完美无缺，企图笼统地使其适用于任何场景只会徒劳无功。辩证地看待每一个方法论，而不是拘泥于其束缚。过程可以自己定义，不管是哪种方法论，只要是你觉得合适的、有帮助的，就可以吸取其优点应用进来。在选择敏捷方法之前，先要确保你的开发项目是适用于敏捷的，如果你的项目需求是明确地，产品要求高可靠性、高质量行、高及时性，使用传统的软件过程模型可能更合适。并且公司的组织文化要能适应敏捷的要求。敏捷开发面向源码，不面向文档，提倡可运行的软件高于详尽的文档。Jack Reeves提出源码也应该是设计文档，而源码的设计文档是在数据结构和算法方面的低层的设计文档，过分的关注细节，会造成丢失大局。个人认为对于业务流程复杂的系统模型，需要做好系统的高层和中层设计。《软件工程的事实与谬误》中指出软件质量由七个属性组成：可移植性，可靠性，效率，可用性，可测试性，易理解性和可修改性。要做到这些质量，需要从体系结构方面进行设计，建模逻辑视图、开发视图、进程视图和部署视图，从总体的角度定义软件的体系结构风格，是以数据为中心的风格、主程序子程序风格、隐式调用风格、Pipe Line风格、Client-Server风格或者MVC风格，这些都需要在体系结构上进行设计，并生成必要地文档。光从源码中的复杂的文件夹结构，复杂的包结构，是很难快速看出软件的体系结构风格的，不利于维护。而在体系结构的基础上，最好进行一定的中层设计，如果采用结构化的变成方法，则需要对函数的调用关系方面进行一定的设计，如是面向对象的方面，则需要绘制必要地类图、包图，如是对数据库的设计，则需要实体关系图，数据存储的设计。

开源软件

对于应用软件开发商、对于IT技术人员来说, 需要开源、欢迎开源。操作系统、开发工具、支撑软件等软件的开源, 一方面共享了他人的智慧和成果, 加快了产品的开发速度和创新能力, 另一方面也降低了开发成本和风险, 使得所开发的应用软件速度更快、性能更好、质量更高。而对于最终用户来说, 不可能也没必要去了解和掌握IT技术, 尤其是底层技术。他们不会关心IT系统采用什么技术架构, 运行在什么平台、使用什么语言编写, 更不会动手去修改、更新、维护。这些不是他们的业务。他们关心的只是“应用系统能否满足业务需求, 能否安全可靠方便地运行, 能否带来企业效益的提高”。另外关心的是数据和资料的安全性和保密性。所以应用系统的开源对于客户来说毫无疑义, 甚至会存在隐患, 一些不法分子利用开放源代码, 解读系统结构, 盗取商业信息。所以适合开源、需要开源的软件主要集中在操作系统、数据库、支撑软件、服务器、中间件等, 至于应用软件,开源并不是解困之道。

开源软件得到全球的追捧的一个最大理由就是开源为软件企业自主创新提供了机遇。开源软件的社区式开发本身是一种创新, 这种开放式开发方式又可以激发广大软件开发人员的思想火花, 从而可在短时间内产生源源不断的创新产品。但源代码的免费获得与自由修改, 也为各种机会主义者提供了机会, 在开源的幌子下名正言顺地索取资源、窃取成果、模仿产品等。这从另一个方面又会扼杀创新的热情。开源在促进知识的传播发展、保证社会公共利益的同时, 也面临着如何保证个体的利益以保证创新动力的持续的问题。在一片叫好声中, 也有这么一种说法: 开源没有创新, 而是模仿。就目前企业中常使用的一些开源项目, 确实印证了这种说法。首先最常见的几大L inux操作系统, 界面操作包括使用习惯无不在向Windows靠拢; 其次开源数据库不管是MySQL还是PostgreSQL, 实际上功能和IBM、Microsoft、Oracle和Sybase没有太大区别, 不过重复原有数据库系统所做的事情; 再者开源办公套件已经拥有了不少产品, 但基本上都是Microsoft Office的克隆。由于微软事实标准的存在, 多年来已经被用户所习惯, 为了照顾用户的习惯, 所有的开源软件都在向微软产品靠拢、在模仿, 唯一区别的只是开发模式的不同。

开源软件本身存在的问题：

(1) 持续性问题。由于参与者可能随时退出, 有可能无法保障一个程序或项目能进行到底, 其进度和质量有可能无法加以控制。

(2) 版本问题。一个开源项目有可能会面临多个版本问题, 从而在移植性、维护性方面给用户带来困惑。

(3) 知识产权问题。许多国家现在认可软件的专利, 因此当开放源程序中存在牵涉知识产权的内容时, 也可能同时涉及合法性问题。

(4) 服务问题。用户常难以知道相关的开放源程序项目是否存在以及当前的实际状态, 开放源程序世界常缺乏足够的广告, 特别是在没有明确的后台支持公司时。另外及时更新也是问题。

观念意识导致的不正当行为问题：

开源的理念和开源文化的认可普及需要一个过程, 在此之前难免会出现一些负面现象, 功利主义、拿来主义、机会主义等纷纷登台。

(1) 搭便车行为。个别企业通过开源社区, 借助开源爱好者的热情和贡献, 从开源社区中获得免费资源, 以“搭便车”手段获取他人的智力产品, 而不愿意再去开发新产品从事创新活动。这虽然没有侵犯某一特定权利人的权利本身,但从某种程度上说, 侵犯了社会创新激励机制, 从而会扼杀社会创新的热情。

(2) 侵权行为。开源的侵权往往涉及到侵权和被侵权两方面。一方面对于开发者所贡献的源代码本身, 因其无地域性、集市化的开发特点, 使得开源软件难以履行一定的知识产权的形式要素, 而可能缺乏法律保障, 从而增添侵权的可能性。另一方面开源社区也有可能因为发布了含有侵权内容的源代码而本身也间接侵权。

(3) 软件产品责任问题。开源软件协议中明确指明程序开发者是不对程序本身承担任何责任的, 除非是自愿。但软件作为一种知识产品, 软件使用问题不可能根除: 杀毒软件误删文件, 因安装IE插件而导致系统的不稳定, 操作系统漏洞导致病毒、黑客入侵等等。那么, 软件开发商是否应当为其软件中出现的瑕疵承担责任, 为软件使用过程带来的问题负责, 并赔偿由此给用户造成的经济损失呢? 至少目前国际上尚没有这方面的法律规定。

测试

在当今变化不断的软件开发需求下，传统的测试方式很难适应变化，甚至可能出现各种问题，导致出现错误和风险。敏捷开发就是为了应对这样复杂的局面而出现的，这样对于测试的自动化的要求也就越来越高了，并逐步受到开发和测试人员的青睐。自动化测试，简单的说就是: 管理与实施各种测试活动就是自动化测试，其中包括开发和执行测试脚本，以便于通过自动化测试工具来检验是否获得测试需求。

 

自动化测试有以下优点：

1)      提高测试质量：

软件开发过程是一个持续集成和改进的过程，而每一次修改都有可能产生错误。因此，但软件产品的一部分，或者全部，或者应用环境被修改是都需要对软件产品重新进行测试，其目的是验证修改后的系统或者产品的质量是否符合规格说明。例如，对于产品型的软件，每发布一个新的版本，其中大部分功能和界面都和上一个版本相似或相同，这部分功能特别适合于自动化测试，由于自动测试工具提供了简便的回归测试，能以便利的方式验证是否有新错误进入软件产品，既节省了重复手工输入的工作量，保证了测试案例的一致性，避免了人为因素，也可以使测试达到测试每个质量特性的目的，从而提高软件测试的质量。

2)      提高测试效率，缩短测试工作时间：

软件系统的规模越来越大，功能点越来越多，人工测试非常耗时和繁琐，这样必然会导致测试效率低下，而自动化测试工具可以较好的执行这些繁琐的任务。在充分合理地使用测试工具以后，可以减轻测试工程师的手工测试工作，同时，测试工具还可以把控制和管理引入整个测试过程，能够保证测试的进度。

3)      提高测试覆盖率：

通过自动化测试工具的录制和回放及数据驱动来测试功能，可以提高测试覆盖率。通过测试工具的辅助分析功能，可以提高测试的深度。

4)      执行手工测试不能完成的测试任务：

有些非功能性方面的测试，例如，压力测试，负载测试，大数据量测试，崩溃性测试等，人工测试是不可能实现的。

5)      更好的重现软件缺陷的能力：

自动化测试具有更好的一致性和可重复性，由于每次自动化测试运行的脚本是相同的，所以每次执行的测试具有一致性，很容易发现被测试软件的任何改变。

6)      更好的利用资源：

理想的自动化测试能够按计划完全自动地运行，在开发人员和测试人员不可能实行三班倒得情况下，自动化测试可以胜任这个任务。也避免了开发和测试之间的冲突。

7)      增进测试人员与开发人员之间的合作伙伴关系：

自动化测试为测试工程师与程序开发人员协同工作提供了一种更便利的手段。

 

相对于手动测试而言，执行测试比人工测试快；每次测试都准确的执行相同的动作，避免人工测试的错误；可以重复执行相同的操作来测试应用程序；可以编写复杂的测试脚本，找出隐藏在应用程序中的信息；可建立一套测试脚本来测试应用程序的所有功能；可以重复使用测试脚本，即使应用程序使用的接口已经改变。

自动化测试试用的场景：需要反复进行的工作；负载压力测试；公司有大量的测试和开发人员，他们合作完成一个产品，那么如何在生命周期中进行有效管理和合作，借助于自动化的测试管理工具，会取得事半功倍的效果；需要进行测试系统后台或者内部的性能特性，进而进行故障定位和性能调优。

当然自动化测试也有它相应的缺点。首次引入自动化测试工具，不仅不会减少工作量和测试时间，反而会使测试工作更加的艰巨。因为自动化测试工具的前期工作是需要不断的录制、回放和调试自动测试脚本，才能获得预期的测试结果。即使有对引入的自动测试工具非常熟悉的人员，他们在使用中同样也会遇到前期工作量增加的情况。如果业务逻辑相当的复杂，在自动化测试的前期，测试的效率有时候还不如手动测试的的效率快。但是随着自动化测试的不断深入，自动化测试脚本运行次数的不断增加，自动化测试的效率就会越来越高。

       在软件需求变动非常频繁的情况下，需求的每一次变动，测试人员都要对自动测试脚本重新编写，以前的脚本不再使用。然而编写自动测试脚本的工作量比手工测试的工作量要大很多，所以我们一般将手动测试和自动化测试配合在一起使用。

为项目选择测试工具，以及编写自动测试脚本，都需要大量的时间，因此，如果项目周期非常短就不适用自动化测试。项目周期在某种程度上决定了测试方法。

       自动化测试中，制作自动测试脚本是最有难度和价值的，因此，测试脚本是否能够重复使用，这一点是企业最为关注的。

       定制型项目—为客户定制的项目，甚至采用的开发语言、运行环境也是客户特别要求的，开发公司在这方面的测试积累少。

对于业务规则复杂的对象而言，它有复杂的逻辑关系和运算关系，工具很难实现，或者要实现这些测试过程需要投入的测试准备时间比直接进行手工测试所需的时间更长。

做人体感官与易用性测试时，界面的美观、声音的体验、应用性测试，无法用测试工具来实现。

对于不稳定的软件而言，如果软件不稳定，则会由于这些不稳定因素导致自动化测试失败，或者致使测试结果本身就是无效的。

涉及物理交互，自动化测试工具不能很好地完成与物理设备的交互，如刷卡器的测试。