模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
文章
我和敏捷团队的五个约定
作者 覃其慧 发布于 2009年3月2日 上午12时30分
我——作为一名测试人员——有一个与众不同的习惯：每当要加入一个新项目的时候，我总会找到项目中的同伴，真诚而亲切地说：“为了更好地合作，我有5个约定，希望大家能尽量遵守”。
约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议
我们的团队需要让客户频繁的得到可用的软件，客户的不断反馈会给软件的未来做出最正确的方向指引。
如果我们交付的软件有很多质量的问题，存在大量的缺陷，客户会被这些缺陷的奇怪行为干扰，没有办法把注意力放在软件本身的价值是否符合他们的真正需求上， 不能给出最有价值的反馈。所以，我们只有频繁的做测试，在每次交付之前都把质量问题找出来告诉我们的团队，问题才能及时的得到改正。
而我坚信“prevention is better than cure”（预防胜于治疗），我会要把工作的重点放在预防缺陷上，这样可以节省Dev们很多修复缺陷的时间与精力。
为了达到这个目的，我需要跟你一起参加客户需求会议，尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候，我也基本完成了测试用例的准备。
我们可以赶在开发人员们写代码之前就告诉他们我要测什么，让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况，减少缺陷的发生。这是我测试的一项重要任务。
如果你们在大部分需求都整理好了再交给我们，我会浪费掉等待的时间。更重要的是，开发好的软件里面已经有很多本来可以不存在的缺陷在里面了，开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。
所以，请让我尽早了解需求，请不要让我到项目后期才能开始测试。
约定2. 开发人员们，虽然你们是编写自动化测试的专家，但请听听我们意见
我知道，对于你们，自动化测试不过是利用junit, rspec, selenium，watir，uiautomation等等写出的“另一段程序”而已。而对于80%的QA来说，编写自动化测试并不是一件简单的事情。
不过我仍然相信，有测试人员介入的自动化测试更有价值。
你们用单元测试，集成测试来保证代码的质量。然而你们的这些日常测试离代码更近，离最终用户还点远。很多测试都不是在测软件功能。
你们可以把功能测试写的又快又多，而我们可以指出什么功能测试最有必要加到自动化测试中。
你们平时大部分精力都在编码上，没有太多时间去查都有什么缺陷。而我们可以指出什么地方缺陷可能会出现的比较频繁，建议在这些脆弱的地方加自动化测试。
所以请听听我们的意见，我们可以给你们提供这些信息。
约定3. 项目经理们，请不要要求我们测试软件的所有路径
软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径，无止尽的输入，更何况比这个更复杂的商用软件。
如果你们担心没有尝试过全部的路径不可靠，疑惑我们怎么敢说这个软件质量是好的还是坏，都有什么风险。请你们先注意，我们是跟业务分析师一样，都了解软件的价值的。价值可以帮我们做出判断，什么时候可以停止测试并对客户说我们的软件已经满足您的要求了，请放心使用。
因为我们了解价值，我们可以肯定的说哪些软件的使用方式是至关重要的，哪些是不太可能出现的。我们会在全面测试了软件以后，把主要精力放在价值高的功能点上。合理的利用项目有限的时间。
因为我们了解价值，我们可以正确的把发现的问题分类。我们可以帮助dev们把精力放在重要的缺陷上，避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。
所以，请不要要求我们无止尽的测试一个软件。我们了解价值，请相信我们的判断。
约定4. 迭代经理们，如果对于交付风险有任何疑问，请来询问我
BA和Dev们都是关注一个软件在什么情况是可以良好的工作。而我们除了验证这些情况以外，大量的时候都用在寻找什么样的情况软件不能正常的运行。所以除 了针对定义好的软件行为进行测试，我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定义的、不曾预期的行为。这些行为往往将会构成软件 交付的风险。
我们会告诉你们现在都发生了什么问题，分别分布在哪里。
我们会告诉你们，在什么情况下软件可能会有异常行为，是不是会牵连到其他的部分，是否可以绕过去。
我们会告诉你们，哪些部分功能比较不稳定，需要更多的留意。
约定5. 测试人员们，那些敏捷实践对于我们也是有用的。
结对不是dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去，跟其他队友多多交流！
多跟测试队友交流，pair看看设计的测试用例是不是够全面，独自一个人想到的未必足够好。他们会给你诚恳的意见的。对他们，也请一样认真对待。
如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们，design for testability（提高你们设计的可测性）。
如果你发现业务分析师写的需求无法验证，定义的客户行为不够具体，一个用户故事中包含太多了功能点，等等，那么也请大声地告诉他，INVEST（独立，可协商，价值，可估算，短小，可测）。
也请你们多跟开发人员结对写自动化测试，既可以帮助你们学习怎样更好的编写自动化测试，也能帮助开发人员们结对更多的了解用户行为。
这就是我的五个约定，它们是我在团队中顺利展开工作的基础。
作者：覃其慧，ThoughtWorks敏捷咨询师。她参与了大量的敏捷软件开发的实践和敏捷咨询。目前主要关注以价值为驱动的敏捷测试。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
写得真好
发表人
William Zhang
发表于
2009年3月2日 下午8时47分
cool！
发表人
晓庆 张
发表于
2009年3月2日 下午9时28分
Re: cool！
发表人
霍 泰稳
发表于
2009年3月3日 下午6时59分
完全同意！
发表人
Qiang Li
发表于
2009年3月3日 下午9时44分
re
发表人
zakorne Liu
发表于
2009年3月3日 下午10时35分
不错！
发表人
nolearning *
发表于
2009年3月4日 上午7时15分
这对测试人员的要求好高
发表人
Jeffrey Zhao
发表于
2009年3月4日 下午12时1分
不错，总结的很好！
发表人
琳 袁
发表于
2009年3月4日 下午11时0分
一点点反对意见
发表人
继东 刘
发表于
2009年3月5日 上午4时0分
梦
发表人
继东 刘
发表于
2009年3月5日 上午6时46分
值得学习
发表人
孝田 毕
发表于
2009年3月5日 下午7时10分
要做的上面几点，除了测试人员有这个素质外，项目经理的支持是一个非常大的因素。
发表人
辰阳 王
发表于
2009年3月5日 上午10时46分
关键在于企业文化、价值观
发表人
Charlie Zhang
发表于
2009年3月5日 下午8时17分
Re: 关键在于企业文化、价值观
发表人
辰阳 王
发表于
2009年3月6日 上午8时41分
Re: 国内大部分企业还是不重视测试
发表人
Charlie Zhang
发表于
2009年3月9日 上午9时6分
Re: 要做的上面几点，除了测试人员有这个素质外，项目经理的支持是一个非常大的因素。
发表人
晓庆 张
发表于
2009年3月6日 下午6时4分
QA != 测试人员
发表人
Charlie Zhang
发表于
2009年3月5日 下午8时27分
Re: QA != 测试人员
发表人
wayne lynn
发表于
2009年3月8日 上午8时54分
理想状态
发表人
yu xiong gang
发表于
2009年3月8日 上午9时28分
Re: 理想状态
发表人
Charlie Zhang
发表于
2009年3月9日 上午9时22分
好的测试（人员）水平要高于普通程序员
发表人
Charlie Zhang
发表于
2009年3月8日 上午10时6分
传统软件工程 vs 敏捷测试约定一
发表人
Charlie Zhang
发表于
2009年3月12日 上午3时39分
Re: 传统软件工程 vs 敏捷测试约定一
发表人
Zhang Keqiang
发表于
2009年3月20日 下午9时16分
Re: 传统软件工程 vs 敏捷测试约定一
发表人
Zhang Keqiang
发表于
2009年3月20日 下午9时29分
很好，但是现实推广挺难
发表人
ryan yu
发表于
2009年3月16日 上午1时1分
一个TEAM，需要的就是沟通与互相理解
发表人
梁 浦
发表于
2009年8月7日 上午10时22分
对于和开发人员的约定
发表人
Terry Chong (崇桦)
发表于
2009年10月27日 上午2时23分
-
没话说的
我就是做QA的
完全说到了点子上 -
很好的点子！
-
这个约定很好，可以让团队中的其他人了解自己所扮演的角色，防止职责不清楚所带来的问题。那么是不是业务分析师、架构师和开发人员也可以有自己的约定呢？有了这些约定的团队工作起来一定更加有意思。
-
完全同意！
-
非常赞同以上所述的五个约定.测试人员应该在项目中承担更多更有价值的工作.
但是对于很多比较小的开发公司来说,测试人员很难达到这个水准!这种能力的提升,既需要公司由上而下的促进以及提供条件,也需要测试人员由下而上的努力才行. -
不错，另外推荐《Agile Test》。
俺在InformIT上看过一章，讲的也是这些。
www.informit.com/articles/article.aspx?p=1316250 -
这要怎么样的测试人员才行啊
-
另外，业务分析师和QA，开发人员和QA，适当结对进行探索性测试也是不错的！
-
作者可能是用自己为标准,觉得所有的测试人员都希望这样做吧,很遗憾,测试人员的素质是不能假设都有作者那么积极主动,为项目着想的.而且也不是都像作者那样经验丰富.作者只是一厢情愿地认为应该这样做,实际上的价值并不如想象中的那么大.
-
测试人员都有这么高的素质的话,呵呵,那就不会甘于做测试人员了
-
要做的上面几点，除了测试人员有这个素质外，项目经理的支持是一个非常大的因素。
-
国内的软件是很难做到的,不过"一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为",还是值得效仿的,测试人员终还是站着客户的角度去测试软件.
-
2009年3月5日 上午10时46分 发表人 辰阳 王
要做的上面几点，除了测试人员有这个素质外，项目经理的支持是一个非常大的因素。
如果企业和团队文化、管理者的价值观重视测试的话，自然会培养出高水平的测试人员，项目经理对测试的支持也必然是发自内心的。
关键是，管理者有没有意识到高质量测试、自动化测试带来的巨大价值。 -
在本文和讨论中，我看到似乎把测试人员（Tester）和 QA 混为一谈了。
QA 是一个传统概念？
敏捷 QA 到底应该做哪些事？这也是一个有意思的话题。 -
同意你的观点，但目前国内大部分企业还是不重视测试，研发部门领导也一般都是从开发做上去的，要他们转变对测试的观点也不是件容易的事。
-
如果希望项目经理的支持，不如主动创造条件要求支持，而不是被动等待支持
-
是的，我也疑惑，TEST和QA应该是不用的角色吧，承担不同的职责吧？
-
说得很全面。
但，
要找到有这样认识的测试人员很难。
要创建能达成这样共识的团队更难。
崇尚编码，设计的管理者对于测试的认识，往往骨子里都是轻蔑的。他们往往把主力配备到研发里，而对于测试，什么人，他们都认为是合适的。
结果就是初期产品到处都是，开发人员很有成就，测试人员完成了任务，用户（客户）很头痛。 -
其慧的这篇文章写得不错，我大体上赞成。同时我也不觉得这 5 个约定要求很高，这些要求对于敏捷团队来说是起码的，很普通，也很常见，而且有些约定是传统软件工程团队也应该做到，甚至可能做得更好。
在讨论中，有些网友认为这样对测试人员的要求很高，而我认为，这些要求其实并不高，因为：
许多测试人员本身就是程序员，而好的测试（人员）水平要高于普通程序员。
太极敏捷还有一个观点：
如果一名程序员，不知道怎么测试（尤其是通过编写另一段程序的方式来测试）自己所编写的程序，那只能算半拉子程序员。
一个软件研发组织的自动化测试程度和水平往往反映了这个组织的软件工程成熟度水平，那些过度依赖人工测试的组织往往会效率低下，缺乏竞争力。所以，其实大部分测试人员，比如 10 个里面有 8 个，应该会熟练地编写测试程序。当然，我这里说的是先进企业、领导企业的情况。
我在 10 多年前就听说，华为、中兴好像有一种“轮岗”制度，有些程序员做一段时间后，会被鼓励去做测试，或者两者定期交换，这么做是非常科学的。现在想起来，这应该也算一种敏捷实践。
组织测试能力的强弱可能跟行业软件的特点有关，我们通常在通信、金融等具有高质量要求的设备、系统研发行业中看到很强的组织、个人测试能力。
在华为、中兴这样有很强的测试能力的领导企业中，有专门的、庞大的测试部门，采用大量的测试平台、测试工具和技术，测试也分测试项目、测试需求、测试计划和测试架构等等，这种测试和普通的开发有什么区别？
就像其慧所说的，测试人员与业务分析师，其实是同一个角色的两种面孔；programmer or tester，其实也是同一个角色的两个面孔（张恂 太极敏捷）。programmers 开发一个系统，testers 则开发另一个系统来对 programmers 开发的系统进行验证，两者都是开发，两个系统是相对和互补的，两种角色也是相对和互补的。
太极敏捷：Testers are also programmers.
当然这样的测试工作需要大量高水平的会编写程序的测试人员。在此类环境中，测试人员其实就是另一种高水平的程序员（测试程序员）。
资深敏捷 OO 教练 张恂
www.zhangxun.com -
2009年3月6日 上午8时41分 发表人 辰阳 王
同意你的观点，但目前国内大部分企业还是不重视测试，研发部门领导也一般都是从开发做上去的，要他们转变对测试的观点也不是件容易的事。
的确，我有同感。10 年前如此，没想到 10 后还是如此。我估计经过 ISO、CMM/CMMI 两轮热潮后，应该会有所改善。
形成这种现象（始终保持落后状态）的原因比较复杂，也很有意思，值得进一步研究，例如很多企业和管理者疲于应付日常工作，没时间学习，更新自己的知识；信息不对称，从旧教材上学到了淘汰的知识，对正确的软件工程存在误解，媒体的宣传，客户的意识，市场的环境等等。当然了，能存活就不错了，管它呢。
但有一点是明确的，不重视测试、不提升软件工程能力的企业和管理者，在市场竞争中最终没有前途。这也解释了为什么优秀企业和管理者在数量上总是少数，大部分市场份额都被先进、领导企业占了。
这次敏捷风刮起来了，对于软件工程能力落后的企业应该是个改进的机会。 -
2009年3月8日 上午9时28分 发表人 yu xiong gang
要找到有这样认识的测试人员很难。
要创建能达成这样共识的团队更难。
崇尚编码，设计的管理者对于测试的认识，往往骨子里都是轻蔑的。他们往往把主力配备到研发里，而对于测试，什么人，他们都认为是合适的。
结果就是初期产品到处都是，开发人员很有成就，测试人员完成了任务，用户（客户）很头痛。
深有同感，你描述的实际状况很准确，这就是国内软件工程长期存在的一个误区。
这可能和软件工程的大教育有关，也和市场环境有关。开发商、客户都对测试的重要性缺乏正确的共识。 -
原文中提出了敏捷测试的 5 个约定。对于这几个约定，传统软件工程会怎么做，传统与敏捷有什么区别？我们在这里作一个比较，应该很有意思。
我坚信“prevention is better than cure”（预防胜于治疗），我会要把工作的重点放在预防缺陷上，这样可以节省Dev们很多修复缺陷的时间与精力。
“预防胜于治疗”，这点说得很好，预防质量缺陷正是 QA 的主要使命之一。
非常重视预防和计划恰恰也是传统软件工程的特点和长处。当然，与敏捷不同的是，传统软工更强调文档化和数量化，而其预防、计划和准备工作往往是 heavy-weight 的，要保留、记录开发全过程的动态演变。约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议。
这条约定在传统软件工程项目中，是必然的要求。无论 ISO 9001、CMM/CMMI 和 RUP 等等，在过程规范和企业制度里，肯定都会要求所有关键的 Stakeholders（包括测试、QA 人员在内）参加客户需求会议，因为客户需求会议实在太重要了。而且测试、QA 不是仅仅参加会议，发表口头意见就够了，还要形成会议纪要（记录）和正式文件，并在上面签署质量意见。
不要忘了，现在成熟的 ISO 9001、CMMI 团队也应该掌握迭代开发的能力，不应该“到项目后期才能开始测试”。迭代递增式开发是敏捷的基础，然而仅仅做到了迭代开发，未必就是敏捷的。
原文中提到的以下几点，不但敏捷团队应该做到，成熟的传统软件工程团队也可以做到，或应该做到：1) 我需要跟 BA 一起参加客户需求会议，尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候，我也基本完成了测试用例的准备。
2) 我们可以赶在开发人员们写代码之前就告诉他们我要测什么，让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况，减少缺陷的发生。这是我测试的一项重要任务。
3) 请让我尽早了解需求，请不要让我到项目后期才能开始测试。
作者这里谈到的 BA 和 QA/Tester 的分工是比较合理的，本质上还是迭代开发的基本要求。
完成以上 3 个任务（或目标），需求用例（use case）的分析是非常有效的。BA 分析 business use cases，Tester 分析 software/system use cases，并根据软件需求用例来编写 test cases，基本完成测试用例的准备，从而“赶在开发人员们写代码之前就告诉他们我要测什么”。需求用例非常有利于帮助测试了解“客户需求与使用软件的惯常行为”（简述或基本流），而需求用例的扩展条件和扩展流非常有助于发现“重要的有破环性的情况”。
需求用例（use case）分析技术其实在传统软件工程、敏捷软件工程项目中都可以使用。
资深敏捷 OO 教练 张恂
www.zhangxun.com -
很好，但是小公司很难做得到
-
在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践？
从敏捷团队的组建上来说，敏捷团队并没有要求安排专门的测试人员，甚至于在某些的方法中不建议清楚的区分开发人员角色和测试人员角色。 本文讨论的是已经存在独立测试团队的情况，如何在敏捷开发中进行高效的测试。
实践1：测试保护开发
通过快速的自动化测试跟进开发，保证新增和修改不破坏已经获得的成果。
典型步骤如下：
1，开发人员根据需求，采用TDD，编写代码，实现界面和接口。
2，几乎同步，测试人员编写自动化测试，主要是黑盒自动化测试，也不排除白盒自动化测试。
3，一般保证，代码出来后的第2天，相关的自动化测试代码开发完成。
实践2：成为大敏捷团队的成员
子实践1：参加相关会议，如果是SCRUM，参加SCRUM所有要求的会议。
子实践2：可以阅读和修改最大范围的配置项（比如文档，代码，工作项）
子实践3：一起工作，比如把位子搬到开发人员旁边，如果同时参加多个项目，选择一个较近距离的位子。
说明：这个实践本身的宗旨与传统做法并无根本区别，这里的区别在于程度。
实践3：与定期构建一起执行测试人员的自动化测试用例，或者定期构建包括测试人员的自动化测试。
这里用了”测试人员的自动化测试用例“，也有做法是测试人员和开发人员一起维护自动化测试用例，并没有“测试人员的自动化测试用例“，这里主要说明无论测试人员贡献的自动化测试用例处于何种形式，无论构建是否包括测试人员的自动化测试用例，就是要求自动化测试能与构建为基来执行。
子实践1：维护一套自动化测试环境，可以自动获得最新的测试用例和构建成果
子实践2：测试结果可以自动发布到合适的地方，缺陷得到跟踪管理
实践4：设计更多黑盒手工场景化测试用例，安排更多随机场景测试
关 注于局部功能的测试用例在敏捷开发中往往已经被自动化实现了。因此为了发布的测试中，值得设计更多黑盒手工场景化测试用例。选择一些典型场景化测试用例开 发为自动化测试用例也是可以的，但是此类测试用例的自动化开发所需工作量较大，要看测试团队的投入和质量目标安排，如果有象微软一样的测试开发工程师，就 另当别论了。一般而言，从经济角度出发，黑盒手工场景化测试用例是发现潜在缺陷的有效且经济的手段，如果存在丰富经验的测试人员，随机场景测试也是值得更 多采用的。本实践在传统测试中也有，这里要强调的特别之处是可以考虑手工测试全部用场景化测试，大幅减少针对单一功能或局部功能的测试用例。
对测试人员的要求
从以上实践可以看到，测试人员所要掌握的技能有黑盒自动化测试、场景化测试，最好也要常握白盒自动化测试，定期构建和自动测试报告
工具支持
常见的有fit,fitnesse, white, watir, selenium, cruisecontrol, QTP, robot, xUnit系列，xFit系列等等
效果和校验
上述的实践是否有效、是否高效，可以观察如下几点：
1，达到发布条件所需的测试轮次是否减少？测试缺陷密度是否减少？
2，获得快速发布的能力，发布工期偏差是否减小？
3，测试所需总的工作量是否在测试团队承受的范围之内，尤其关注测试后期的工作量是否大幅减少，减少的数量是否比在测试前期增加的数量要更大？
如果没有获得正面收益，就需反思了。 -
以上转自hespr.blogspot.com/2009/03/blog-post.html
看了前面的贴子，似乎对测试人员的要求比较低，原文的5条约定未必能做到。转文所提出的要求就更高了。
但不是不能做到的。而且是有正面实例的。 -
很少会从测试工程师的角度看问题，不过这篇文章是否需要续篇，其他五种角色是否也需要对应的约定呢？
-
对于测试人员和开发人员之前的约定，个人认为最重要的一条是：请不要把测试人员当成你们的敌对者
软件的开发和测试中，往往会遇到很多DEV和TESTER意见不同的时候，小到一个BUG的确认，大到整个功能模块是否达到交付标准等等。而且由于各自的角度不同，会产生很大的分歧，这个时候，请团队中的每一个开发人员都要切记一点，测试人员并不是故意要给你们找茬，他们是在帮助你们完善你们的作品，请把他们当成你们的好帮手而不是敌对者。
在敏捷的环境中，其实更需要DEV和TESTER紧密的合作与交流。这样才能保证在一个迭代结束时交付高质量的产品，并修复尽可能多的产品缺陷。
27 条回复
关注此讨论 回复