文章

敏捷测试人员的十条法则

/分类： /编辑：

敏捷测试人员的十条法则：

提供持续反馈
为客户创造价值
进行面对面的沟通
勇气
简单化
持续改进
响应变化
自我组织
关注人
享受乐趣

提供持续反馈

既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位 。

为客户创造价值

敏捷开发就是在较低的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容，但是测试人员会判断其对故事的影响，因为他们需要考虑测试后果。

进行面对面的沟通

一个团队如果沟通不好则难以协作。如今，许多团队分布于多个地理位置，沟通变得更加重要和富有挑战性。敏捷测试人员应该尽力促进沟通。这是把工作做好的关键因素。

勇气

勇气是极限编程的核心价值，类似测试自动化和持续集成的方式允许团队实践这种价值。 测试人员固守于自己的领域，不与其他业务相关者和技术团队进行任何讨论。虽然你找机会进入了协作的敏捷环境，可能会对找客户索要实例或者找开发人员帮忙自动化测试或者在每日例会时提出一个难题等感到不习惯。

当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时，通常你会产生恐惧感，并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成对每一个用户故事的测试任务？测试如何跟上开发的节奏？如何确定需要多少测试？又或者你是功能测试经理或者质量过程经理，但不清楚在敏捷团队中如何定位自己的角色，也没人知道答案。敏捷测试人员需要勇气找到这些问题的答案，但需要勇气的原因不仅限于此。

简单化

敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还需要采取简单的方法以确保软件符合客户需求。这并不意味着团队不应该花时间分析主题和故事、思考合适的架构和设计。而是说，当业务部门的需求比较复杂的时候，团队可能需要将方案退回给他们，更简单的解决方案也会产生同样的价值。

简单并不意味着容易。对于测试人员来说，这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试，但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。

持续改进

想办法把工作做得更出色是敏捷测试人员应牢记的。

敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更多价值或者得到更好的客户投资回报。敏捷开发的短期迭代更易于尝试新事物，以验证是否值得长期采用。

学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源提高专业技能。

响应变化

响应变化是敏捷实践的重要价值，但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定，所以他们会说：“我已经测试过了，任务完成了”。持续的需求变化是测试人员的噩梦。但是，作为一名敏捷测试人员，我们不得不拥抱变化。周三，我们可能期望启动故事A和B，下周五做故事C。但是到了周五，客户重新设定了优先级，现在需要故事A、X和Y。只要我们持续与客户交流，我们就能处理这些变化，因为我们与团队的其他成员保持同步。

自我组织

敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化，测试人员就会获得全新的视角。自动化测试很困难，但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时，任何测试问题都会更容易解决。

当敏捷团队面对一个严重问题时，比如进度障碍或者构建失败，该问题将是所有人的问题。最高优先级的问题需要整个团队解决。团队应该立刻讨论并决定解决的办法和相关参与人员。

关注人

只有优秀的员工出色地工作，项目才会成功。敏捷价值和准则的宗旨是确保个人和团队成功。敏捷团队成员应该有安全感。不必担心因犯错受指责或者失去工作。敏捷团队成员互相尊重并认可个人成就。敏捷团队的所有人应该有机会提高和发展他们的技能。敏捷团队以可持续的步伐前进，使他们能够遵循严格的实践和保持崭新的视角。正如敏捷宣言所说，我们重视个人和合作超过过程和工具。

享受乐趣

在我们看来，测试人员的理想团队是：所有成员协作，从项目的开始一直到结束，利益相关者与开发团队共同工作，整个团队负责质量和测试。相信很多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的激情。

敏捷测试人员的工作特别令人满意，因为我们的角度和技能对团队产生了真正的价值。

敏捷测试：反学习的关键

/分类： /编辑：

“懂得如何反学习的人学得最快。”
——作者不明

当QA团队和管理层刚刚开始运用敏捷的实践的时候，他们通常会遇到如何将传统的并且在他们脑海里已经根深蒂固的思想和实践忘掉的问题。

下面是一些从QA的角度出发，在实施敏捷实践之前需要忘却的一些关键点： Read more →

敏捷测试需注意的五种危险行为

/分类： /编辑：

如果开发团队采用了敏捷方法，那就意味着程序员需要做更多的软件测试。然而，这并不是说软件测试人员就没事做了。他们需要调整，并学会与以往不同的测试方式。

DragonFire公司的顾问Janet Gregory认为，对用户需求的测试尤为重要，“除非经过测试，否则不能认为任何业务需求已经完成。
”
STAREAST测试展会（STAREAST Conference and Testing Expo）上，Gregory讨论了“新晋敏捷测试员的危险行为与陷阱”，并解释了敏捷测试员所应做的工作。她指出软件测试人员经常做出的危险行为，这些危险行为可能带来的风险，以及如何规避这些危险和风险。 Read more →

敏捷测试的启示

/分类： /编辑：

最近，好像整个软件开发界都在讨论和实践敏捷方法，做什么事情都要敏捷，开发要敏捷，测试也要敏捷。

什么是敏捷？

敏捷宣言：个体和交互比过程和工具更有价值；能工作的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。-

敏捷开发是递增式的、迭代的、不断调整的开发模式。在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），持续地进行回归测试。

敏捷测试是指在敏捷开发模式中的测试。敏捷测试包括单元测试（通常由程序员完成）和可接受性测试（通常由测试人员完成）。 Read more →

敏捷测试中的系统测试模型

/分类： /编辑：

1         引言

系统测试是在将软件产品交付给客户使用之前完成的最终产品测试。此测试一般在完成开发和功能验证测试之后进行。某些入口标准用来确定对于系统测试的代码准备状态（举例来说 ， 回归状态，缺陷后备，等等）。必须达到这些标准，从而正式地开始系统测试并要求结果。 　　在一般的系统测试中，目标是用类似客户的配置在高压下对系统进行类似客户的工作量（举例来说，多平台、多软件版本，等等）。 正式的系统测试执行包含压力、寿命期运行、内存泄漏分析、多应用程序、复杂且各种各样的拓扑、高可用性及中断测试、混合的版本测试、全平台测试、产品集成测试，及文档测试。 Read more →

将测试人员整合到敏捷团队中

/分类： /编辑：

将测试人员整合到敏捷团队中，这是敏捷之道常常重复的一条箴言，可我们并没有认真想过这到底意味着什么或者应该怎么做。

团队中测试人员的角色具体负责什么呢？他们要：

  • 协助团队抽取并定义验收条件（或需求）
  • 提供相关质量信息，而不是通过自动化测试、探索性测试（exploratory test）［译注］来寻找bug
  • 与客户一起工作，识别风险
  • 在开发人员测试（单元测试与集成测试）的薄弱环节投入更多精力。比如，如果我们知道团队已经完成了对数据层的测试，但是GUI层难于进行单元测试，那测试人员就应该花费更多努力在这一层的测试上。

Read more →

敏捷测试之我见

/分类： /编辑：

前两天听了公司一个关于敏捷开发的培训，就在想是不是也有敏捷测试。尽管一个同事说根本没有敏捷测试这个概念，但我仍不死心。Google了一下，这方面的文章确实有限，不过有就是对自己想法的一个最好肯定。

　　在我的理解对应敏捷开发的管理就是敏捷管理，同样对应敏捷开发的测试即是敏捷测试。只是敏捷管理和敏捷测试同样可以应用到非敏捷开发的项目中去。同样敏捷管理和敏捷测试在敏捷开发中将会得到最大的体现，但能不能管理好和测试好就看你做的是不是真正的敏捷管理和敏捷测试，看你是不是真正的将敏捷的思想融入到管理与测试中去了。 Read more →

热衷敏捷测试的十大理由

/分类： /编辑：

最近，Kay Johansen 提出问题“为什么你会热衷于敏捷测试？”收到的答案从严肃到诙谐，不一而足。

1.    不再需要手工测试脚本！ － 相反，自动运行的脚本让测试人员有更多的时间来挖掘测试。

2.    开发人员喜欢我了！ － 迭代结束之前发现问题，而且因为开发人员对代码还有一个比较清晰的印象，所以比较易于找到问题。

3.    现在我可以在撰写特性之前就分解特性！（Kay 与 Philip） － 在撰写特性之前开始测试，测试人员可以预防问题。

4.    自动化测试在一天之内运行很多次 － 任何修改都能得到快速反馈。

5.    营造团队导向的氛围 －（John Overbaugh）－ 每位团队成员不仅关心编码，也会关心测试是否完成（Lisa Crispin）

6.    测试人员可以解决偶发性bug（Lisa Crispin）－ 自动化的测试让每个人都舒服。

7.    经常复审测试实践的机会（Adam Knight）－ 不再是对过去行为的简单重复，实践经常会被复审。在 Adam 的例子里面，过去要5天完成的手工测试减少到只需要30分钟。

8.    我只花很少、很少的时间来调试（Adrian Howard）－ 当我犯了错，我能很快得到反馈 － 所以轻而易举就找到问题，然后解决。

9.    真正改进质量，而不是仅仅记录在文档上（John Overbaugh）－ bug很快就被解决，而不是只放在bug表里面。

10.   因为测试先行，测试的时间总是有的 － Josue Barbosa dos Santos 讲述了在巴西的一个政府办公室工作的故事，那里测试被安排在项目的最后阶段。开发工作总是落后于项目时间表，面临截止期限的项目不测试就发布给用户。引入 TDD和ATDD之后，最少有一部分测试会随着软件开发同步进行。

Kay热衷敏捷测试的首要原因是：我想听到人们说“这是我迄今为止工作过的最好项目！”

 

作者:Mark Levison（金明 译）

敏捷测试用例设计

/分类： /编辑：

敏捷宣言：

个体和交互比过程和工具更有价值；

能工作的软件比全面的文档更有价值；

顾客的协作比合同谈判更有价值；

及时响应变更比遵循计划更有价值。

并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。

测试用例的设计是其中一项。

测试用例的粒度

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。

测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

基于需求的测试用例设计

基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。

要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。

测试用例的评价

测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。

因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。

测试用例数据生成的自动化

在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

可利用一些工具，例如TConfig、PICT等来产生这些数据。

在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用工具生成。

工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。