敏捷测试的方法和实践

2024-07-18

敏捷测试的方法和实践（共6篇）

敏捷测试的方法和实践篇1

文 / 朱少民

有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍，产品经理发现了问题，认为需要对功能进行比较大的修改，这时开发人员估计需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊!

什么是敏捷测试呢?敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：

究竟什么是敏捷测试?

敏捷测试有哪些流程改进?

测试人员如何面对敏捷测试的挑战?

在敏捷测试中如何制定相应的自动化测试策略?

什么是敏捷测试

假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。

图1 敏捷测试定义的形象描述

敏捷测试流程的优化

在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员(包括测试经理)讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点(包括策略、特定方法、重点范围等)列出来就可以了。

在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库(在线管理系统)中。在敏捷测试中，可能不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。

图2 敏捷测试流程简要图

在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：

测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论(包括带语言、视频的即时通讯)，仅仅通过邮件是不够的。

参与代码复审(Code Review)，并适当辅助开发人员进行单元测试。

在流程中增加一个环节“产品走查(Product Walk-through)”——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

新功能的测试和回归测试策略

测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：

不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细(大颗粒度)。

持续地进行验证，一旦某块新代码完成(Code Drop)，就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。

实施端到端(End-to-End)的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。

阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。

基于经验，可以实施更多的探索性测试、组合交互性(Interoperation)测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。

回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：

通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小，

基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。

持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。

自动化测试策略

由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图3所示，并说明如下。

图3 自动化测试的策略

构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。

针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试

集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。

在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面(UI)的自动化测试。

良好的IT基础设施，包括自动化构建软件包、自动化版本验证(BVT)、自动化部署、覆盖率自动产生等。

敏捷测试工具

自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。

单元测试工具：TestNG、xUnit家族(如JUnit、NUnit)、JMock、BizMock等。

功能测试自动化：ThoughtWorks Twist。

Web功能测试(frontend)：Selenium IDE/RC、WatiR、WatiN。

Web service测试工具(backend)：soapUI。

性能测试：JMeter+BadBoy。

验收测试框架：Fitnesse、Tellurium。

敏捷测试过程管理工具：微软的Visual Studio ，包括TFS 2010、Scrum模板(MS VS Scrum 1.0)、Test Manager 2010、Coded UI Test等。

业务智能(BI)应用的测试框架：Oraylis BI.Quality (+ NUnit)。

其他一些协作工具等，如TestLink、BugZilla、BugFree、Wiki等。

测试人员在敏捷方法中的价值

在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢?

在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。

测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。

测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。

在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统(模块或组件)，集成测试和端到端(End-to-End)测试显得更为重要，测试人员在这些测试上能发挥更大的作用。

产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。

一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。

理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。

总结

根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：

敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。

敏捷功能测试 = 新特性的手工测试(Use Case验证和探索性测试) + 原有功能的自动化测试 (回归测试)。

敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。

敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。

作者朱少民，网迅(中国)软件有限公司资深QA总监。中国科技大学软件学院教学指导委员会委员，中国软件测试认证委员会(CSTQB)资深专家。在软件工程领域颇有建树，先后获得多项科技进步奖、出版十多部著作和高校精品教材，如《全程软件测试》、《软件测试方法和技术》等。

本文选自《程序员》杂志10期，更多精彩内容敬请关注10期杂志

敏捷测试的方法和实践篇2

在国防信息化程度的不断提高的今天, 军事领域中的软件产品已经成为了和硬件产品比肩而立的重要存在, 军用软件的质量高低也成为了决定军事和武器系统质量的关键因素。随着武器装备系统中的软件规模迎来爆炸式增长, 只有对过程质量的全面控制, 才有可能最大程度的降低风险, 提高软件产品质量。我单位从2011年开始试推行GJB5000A软件研制过程管理, 到如今已实现了军用软件研制能力二级管理的全面覆盖, 期间为兼顾不同专业领域、不同项目类型、不同规模和军兵种的要求, 对体系进行了持续改进。改进焦点在执行GJB5000A标准的大框架下尽可能解决特异性问题上, 同时在开发方法及操作层面上鼓励项目组团队在现有质量体系策略要求下进行创新式探索。其中利用敏捷开发的方法与GJB5000A管理体系的融合就是一种有益思考。

二、GJB5000A质量管理体系结合敏捷方法在科研院所的适应性

2.1 GJB5000A在科研院所的落地实施

GJB5000A-2008《军用软件研制能力成熟度模型》作为框架模型, 体现了业内软件研制过程最佳实践集, 其采用分级表示的方法, 按预先确定的过程域来定义组织的改进路径, 同时规定了软件研制和维护活动中的主要软件管理过程和工程过程的实践。模型五个级别中共定义了22个过程域, 每个过程域由不同个数的专用目标和相同个数的共用目标组成, 每个目标又推荐了不同的实践。在GJB5000A的定义中, 目标是必需的部件, 实践是期望的部件, 我们用满足所有目标来确定过程域的实现, 用实践来指导过程改进和评估。换句话说, GJB5000A标准允许我们用规定的实践或可接受的替代实践来满足目标。所以科研院所要想真正实现标准落地就必须按照单位自身产品特点和用户要求将实践本地化。

在实现本地化过程中, 组织会按照大多数项目的模式定义标准过程, 但却无法确保所有过程适用于所有项目, 同时在执行自由度上也遇到了很大困扰, 强约束导致了项目缺乏灵活性, 而降低约束度则可能带来质量和进度的双重风险。此外, 即使组织开放了项目组利用替代实践实现目标, 但由于团队人员的经验不足, 也很难找到恰当的替代实践, 组织还必须承担面对评估时替代实践有效性的质疑, 所以在组织层面上定义多种开发方法供项目选择就显得尤为重要。

2.2敏捷开发方法在军用软件研制过程中的适用性

软件敏捷开发是一种相对于传统软件开发而言的轻型开发方法, 它改变了传统开发中以文档为驱动的开发模式, 以人为主要驱动核心, 目前常用的基本敏捷实践方法有很多, 如极限编程 (XP) 、Scrum方法、特征驱动开发 (FDD) 等, 每种方法的实践过程都有不同, 但基础都是基于增量和迭代的过程。软件敏捷开发有四大价值观:个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。这些特点使得敏捷开发方法灵活、适用多变需求, 可快速交付, 但应用在军用软件研制过程中可能会带来以下问题:1、敏捷开发方法应用的是需求的快速迭代, 每一个迭代作为一个计划阶段, 很难对项目的整体目标有完整计划。2、敏捷开发方法更注重有效代码的快速交付, 而非文档, 这对有严格军标约束下的文档编制提出了更高的要求。3、敏捷开发最重要的开发方式是与客户一起开发, 因军用软件的需方往往是部队使用方, 面对面开发的形式较难实现。4、敏捷开发方法对开发人员的能力要求极高, 人员要不但要精通设计、编码、测试相关工作, 而且要能参与项目的需求分析和架构设计, 能对频繁变更的需求做出快速响应。

既然敏捷方法会带来以上问题, 我们为何还要考虑在军用软件承研单位引入敏捷开发过程呢?这是因为随着军用软件研制领域中引入的竞争机制, 出现了越来越多需要直接进行代码交付的PK项目, 如果再应用传统研发方式, 就失去了市场竞争优势。所以, 对于规模小、周期短、需求变动频繁、现场开发为主要形式且已经具备了较稳定的开发技术架构的项目而言, 敏捷开发方法既能让项目组在短时间内针对需求拿出有效代码, 而且在快速迭代中能总结大量有用的文档信息。只要我们可以偏重组建成员技术水平在同一层面上的成熟开发团队来承接这样的项目, 必然起到事半功倍的效果。

三、GJB5000A质量管理体系下的敏捷开发方法实施

3.1用敏捷开发方法定义过程

在组织级, GJB5000A三级过程域中的组织过程定义 (OPD) 可以帮助组织建立起自己的敏捷开发方法下的过程定义, 包括过程和过程元素的说明, 过程剪裁指南, 敏捷开发方法下的生命周期, 标准工作环境、组织测量库、组织资产库等。有了组织级定义, 项目组就可以按照集成项目管理 (IPM) 实现方法对组织标准过程进行剪裁, 形成项目的已定义过程 (P’DP) , 这个过程就可以直接指导项目的过程实施。从项目级的角度看, GJB5000A的过程管理关注的是项目做了什么, 而敏捷开发方法正是提供了该怎么做的具体开发方法, 敏捷开发方法中的活动经过合理替代和剪裁的实践方法以实现GJB5000A目标是完全可行的。

3.2敏捷开发方法实践

1. 实践方法的选择。

在敏捷开发的众多方法中, 我们选择了以Scrum为基本敏捷实践, 以持续集成 (CI) 和测试驱动开发 (TDD) 为扩展方法的敏捷开发架构。Scrum方法是敏捷开发中最典型的模型框架, 它把产品需求的实现分为若干个Sprint来完成, 每个Sprint完成后进行产品演示, 收集、细化直至实现用户需求, 整个过程为一个迭代式增量过程。持续集成提倡利用一个全自动的过程, 在一天中根据代码变化进行多次构建 (包括编译、发布和自动化测试) 来验证集成结果和发现集成错误。测试驱动开发技术 (TDD) 基本原理是在开发功能代码之前, 先编写单元测试用例代码是持续集成的验证手段。

2. 项目定义过程。

Scrum结合CI与TDD的过程可以简单描述为:一开始先由项目负责人确定一个Product Backlog (产品需求列表) , 而后召集项目团队召开Sprint计划会议对列表中的需求进行工作量预估和安排, 从中挑选出一个story作为本次迭代完成的目标, 形成Sprint Backlog (迭代需求列表) 分配给项目组成员, 每个成员接收到任务后将任务进一步细化, 在每日例会上汇报自己的完成情况和对下一步工作作出承诺, 同时在公示板上标注出自己的工作情况 (燃尽图法等方法) 。每个项目组成员对工作进行每日集成, 集成后利用测试驱动开发构建测试来快速评估集成结果, 如果发现问题马上修改, 再次集成测试, 反复循环, 直到一个迭代结束形成可用的代码。

3. 用GJB5000A过程管理敏捷开发方法下的研制。

从项目层面看, Scrum方法可以结合GJB5000A过程域中的需求开发, 项目策划、项目监控等, CI与TDD可以结合产品集成、配置管理等, 当敏捷开发的方法在GJB5000A的过程管理方法约束下, 可以得到更精确的控制和工作产品反馈。下表我们就给出了部分实践的实施方案。

四、总结

GJB5000A体系结合敏捷开发方法有别于传统研制方法中以文档为驱动的顺序研制过程, 它充分强调了消除冗余、减少返工、缩短周期, 提高效率的理念, 同时用过程记录的方法收集重要的项目信息, 可以在一轮迭代完成后一次输出成可用的文档和经过测试的可交付代码。于项目而言, 这种研制方式给项目提供了更多的灵活性选择。于组织而言, 因总装备部和军标的强制要求, 承研军用软件的单位必须要在GJB5000A及相关配套军标的要求下建立质量管理体系和规范项目研制过程。通过合理剪裁那些能提高产品质量、提高生产率的方法和模型后, 通过验证和确认方法形成组织标准过程, 必然能增强组织标准框架的适应性和实用性, 提升组织管理能力目标。

参考文献

[1]GJB5000A-2008军用软件研制能力成熟度模型[S].

[2]Mike Cohn.Scrum敏捷软件开发[M].北京:清华大学出版社, 2010.

[3]石柱.军用软件研制能力成熟度模型及其应用[M].北京:中国标准出版社, 2009.

做好功能测试和测试分析的方法篇3

做好功能测试和测试分析的方法有那些? 我们要规划测试流程，首先要熟悉整个项目的规划。

因此积极参与到项目中的每个环节当中去是非常必要的。

至于测试流程，每个公司有每个公司的实情，就如HTSM一样需要结合实际来定制一样，测试流程也需要结合公司的实际情况来规划。

我稍微列举一下几个必要步骤：

首先项目立项，立项以后，基本上每个阶段的时间都有了一个大概的评估。

因此立项之后立马着手于测试计划的编写，当然这个不是最后的方案，测试计划也会根据实际项目的进行而调整。

但是还是要先把初稿编写出来，自己心里有一个大概的框架。

完成测试计划后，拿到需求文档并积极打听开发的设计方案。

根据获取到文档信息，圈定测试范围，思考测试手段。

最后编写测试方案。

需求分析会后，对整个测试范围更加清晰，并可以分解测试点时，开始编写测试分析。

测试分析不需要太详细，但一定要有清晰的思路。

测试分析主要用于指导“你要测什么?”。

编写准入测试用例，可以用于提供给开发自测。

因此此类用例可写得比较详尽。

编写全部的测试用例。

注意测试用例包含的各元素(不会的网上有模板)。

注意用例前置条件要写得清晰明了，因为用例主要用于“你要怎么测?”。

执行准入用例。

虽然开发已经执行过一次，但测试的角度与开发的角度明显不一致。

执行后也可用于判断是否可以进入测试阶段。

执行用例全集。

此过程可判定软件质量，大型项目建议做日报以及周报。

做到及时汇报软件质量情况。

编写准出报告。

根据准出标准，判定软件实现是否已达到与需求一致。

编写用户使用手册。

为了让用户快速上手使用软件，编写手册供用户参考使用。

参考的文档：需求文档、开发设计文档、开发详细设计文档、开发接口文档、开发字典表等涉及的文档。

下面整理了一下本次大家的提问的问题，对部分问题做了解答：

1、公司刚成立不久，请问做客户端的测试流程要注意什么?

回答：首先感谢你的提问。

不太清楚贵公司的具体方针是什么，因此也没办法给太详细的答案。

我个人觉得测试的具体方案跟流程都是需要结合公司实际运营情况来决定的。

可能需要你自身的学习并应用到实际当中去。

按照我的理解给以下建议，希望可以帮到你：

(1)明确需求。

一定要监督需求文档的完整以及可读性，起码可以到能拿出来分解测试需求的情况。

毕竟测试先知来自需求。

(2)跟开发沟通在开发之前可以提供设计文档。

一定要了解开发的设计思路，这里可以发现一部分开发功能是否真的就达到了需求的要求。

(3)选一个适合公司应用的测试模型。

比如V模型或者W模型。

(4)客户端是指APP还是PC的客户端呢?APP的.话，注意兼容性测试是否有实体机测试，并且要做相应的风险评估。

(5)积极与需求、开发沟通并调整部门间的合作关系。

2、老大，WEV和APP测试有什么区别?

回答：WEV?WEB?还是wap?我个人没有做过wap相关测试，可能没办法给一个详细准确的答案。

但是我测试WEB跟APP的时候好像没啥区别，基本测到的项目都是一致的。

一定要说的话，可能使用到的工具有些区别。

测试APP还要考虑到手机上的一些特性，比如耗电，不同制式的网络(2G,3G,4G,wifi)，接电话断开对app的影响，与其他APP的兼容等等。

3、如何对一个功能进行深入的剖析?请问在功能测试方面怎么深入?

回答：问题觉得有点小广，不过我个人从以下几个方面来考虑的。

(1)首先必须是业务，对业务一定要熟，一定要熟!熟到能发现业务逻辑不合理的程度就最好了。

(2)了解你测试的系统。

比如开发的设计方案等，各接口的调用。

(3)脚本测试跟探索测试结合。

当然哪个为主哪个为辅就要结合公司实际情况来应用了。

(4)多应用传统的测试方法来对功能进行测试分析。

4-1、想要了解一下WEB架构的测试。

最好能从计划开始?

4-2、一个项目的产生，在真正工作中，一个测试工程师的工作流程是啥?

回答：两个问题的答案相同，我做web测试跟app测试没啥区别，所以基本都是一套。

(1)项目立项以后，立即咨询项目经理关于项目时间的安排(有些项目经理会直接提供)。

根据项目经理给的时间，按照公司实际的测试流程划分每个测试阶段的时间。

例如：

a.XXXX-XX-XX到YYYY-YY-YY编写测试计划

b.XXXX-XX-XX到YYYY-YY-YY编写测试方案

c.XXXX-XX-XX到YYYY-YY-YY进行测试分析

d.XXXX-XX-XX到YYYY-YY-YY编写准入用例，详细用例

e.XXXX-XX-XX到YYYY-YY-YY执行准入用例，判定是否可以进入测试流程。

如果不通过则打回开发，延后进入测试时间。

这里需要评估风险，一定要跟项目经理沟通预留时间。

如果准入通过则进行下一个步骤。

f.XXXX-XX-XX到YYYY-YY-YY执行详细用例

g.XXXX-XX-XX到YYYY-YY-YY编写准出报告

h.XXXX-XX-XX到YYYY-YY-YY编写用户手册

i.跟踪生产质量

(2)整个测试流程就按照测试计划描述那样，按时间完成则可。

5、探索式测试有哪些方法?

回答：我认识的探索性测试，是一种测试风格。

也就是说他比较强调个人的思维或者特性。

他没有跟传统的测试方法一样有指定的测试技术(等价类，边界值之类的)。

我个人比较喜欢采用的思考方法有：

测试先知扩展。

根据预期结果扩展思维进行测试。

测试条件扩展。

根据不同的测试条件组合扩展测试。

在测试过程中发现bug的路径或者类似路径，进行测试。

不知道你认为的探索是什么样的呢?又是怎么去进行测试的?这一块感觉还有很多谜，可以多多讨论。

6、Linux使用的多吗?

回答：感谢提问，不知道这个问题具体要了解什么方面的内容呢?用不用linux看公司方案。

不过我从进入测试行业开始基本都是基于linux下操作。

7、我想知道金融支付方面该怎么去测，金融测试该怎样高质量的去编写测试用例，去测试?金融测试流程是什么?

回答：话说在没有跟别的测试同行沟通之前我可能会给你一个很肯定的答案。

前段时间在微信群跟别的测试同行沟通过一次，才发现这个问题也是要结合公司实际情况来考虑的。

比如我们公司，安全方面是比较好的，所以很多情况下我们基本不考虑篡改地址信息这种测试方法。

但是如果你们公司安全包装比较差的话，这里是一个很重要的测试点。

这里还是列一下我知道的：

基本编写测试用例还是采用传统的测试方法。

比如金额的输入考虑等价类跟边界值的情况，特别是边界值，很容易出现问题。

如何去测试?我们是采用测试接口以及连接对方测试环境进行联调的方式进行。

当然，联调对方接口各种环境问题出现也是痛苦的一部分。

估计大部分测试这块的同行都要受的折磨。

不知你认识的金融测试又是怎么样的呢?

8、请问如何提高测试效率?

回答：好问题!提这个问题，说明你认为现在的测试效率比较底下的。

不知道具体阻碍你测试效率的是什么呢?因为不了解实际情况，我只能说首先找到阻碍你测试效率的因子，然后对应去解决问题，这样应该会有一个好的提升。

思考以下几个问题：

(1)对业务不熟悉吗?没测试一个功能点都需要找人确认?

(2)对被测系统了解吗?每次提出的问题都是无效bug?

(3)相关的技术了解吗?每次定位问题都需要开发帮忙才能定位?

(4)对测试环境配置了解吗?每次预置条件的设置都需要花大量的时间在上面?

欢迎多多探讨。

9、请问，功能测试进行到什么程度才算完成?需求覆盖率，很难找到bug还是项目进度时间限制?功能测试是如何贯穿在整个项目的各个阶段?

回答：好问题!我们是算需求覆盖率的，这个基本可以体现在测试用例上面。

不知道你们领导希望你们的交付结果要到什么样的情况呢?这个基本是看公司定位的。

我们项目主要大范围地划分为需求，开发(包括单元测试)，系统测试(即功能测试，包括了自动化的冒烟测试)，业务测试，预生产测试，生产上线测试这几个阶段。

10、Bi测试如何开展?

回答：很感谢你的提问。

但是很抱歉，你的问题我可能没办法回答。

我没有测过Bi系统。

11、零基础怎么开始测试?

回答：感谢提问，首先从掌握公司业务开始。

懂得公司业务逻辑了，才能发现问题，这是测试的基本。

然后尽可能补一些测试基础知识。

比如传统的测试方法，linux基本命令，sql语句等。

后续再考虑较为高阶的性能以及自动化等知识。

12、功能测试分析方法常规使用的有哪些?怎样能够较快的引入到日常工作中?

回复：好问题!测试分析方法用的就是传统的测试方法，没错就是你知道的等价类边界值因果图判定表之类的。

我之前数过有10几种吧，具体就不一一列出来了。

下次有时间会整理一个出来，一起来探讨探讨。

13、请问功能测试，就是手工测试吗，测试小白怎么进入测试行业呢?

回答：嗯，描述不太正确呢。

自动化也可以测试功能的。

掌握一些基础知识，就可以入行了XD。

当然能学点语言类的就更好了。

可以参考问题237。

如果还是不能解答到你的疑问，可以多多探讨喔。

14、一直做功能测试，除了管理，还有其他方向可以走吗?

回答：嗯，可能我没有太理解到你的疑问。

为嘛功能测试就只能走管理了呢?管理也不是那么好做的，如果以后公司要发展自动化，那么做为没有接触过自动化的你要如何管理自动化这块呢?又要如何给自动化的同事指导呢?特别推荐学习测试女巫，她也是从功能做到自动化的，虽然不认识她但是我个人非常崇拜她。

敏捷中自动化测试策略篇4

自动化测试是我们应用在敏捷中的类似万能的法宝。但是世界上没有万能的东西。这个就需要我们深刻理解自动化测试, 并且有好的测试策略来应用在自动化测试中。

1 自动化测试中人员的选配

我们的测试团队中, 人员的选配是, 有专门的测试人员, 但是开发人员也会在时间不够的情况下, 加入测试的队伍。在一个敏捷的团队中, 测试人员一般也是具有一定的编程能力的, 当与开发人员沟通一个BUG的时候, 能理解开发人员的话, 沟通更加顺畅。并且在项目需要的情况下, 也会加入开发的队伍中。

2 可以和不可以自动化的测试

2.1 可以自动化的测试

当代码改变, 有新的代码迁入迁出的时候, 这个时候, 需要触发自动化构建。我们通常使用Jenkins这样的持续集成工具, 用于做重复的工作。

自动化单元测试, 我们通常应用junit的单元测试工具, 进行TDD (测试驱动开发) 。

在UI比较稳定的情况下, 做GUI测试。

在回归的时候, 做功能性测试。

在接口测试, 我们可以用Excel, 把测试数据放入其中, 并且跟实际数据进行比较。

负载测试, 我们就必须用自动化了。因为手工测试肯定不准确。我们可以找一些开源的工具来测试。

2.2 不可以自动化的测试

对于可用性测试和探索性测试, 我们需要手工去执行。

3 自动化测试应用的时机

3.1 自动化测试的应用的原因

手动测试的时间远远大于自动化测试。一些重复性的工作最好应用自动化测试。回归测试的时候需要自动化。自动化可以发现手动中一些发现不了的BUG, 比如内存泄露。

3.2 自动化测试的应用的不同部分

在一个敏捷的团队中, 测试可以有自动和手动测试, 比如功能测试。必须手动的测试, 比如探索性测试。必须自动化的测试, 比如单元测试, 性能和压力等。

3.3 自动化测试的应用不同时机

初始的投入, 对于自动化测试来说, 是很大的投资。我们首先评价我们已经已有的工具, 看其价值, 和应用的复杂度。一般来说一些开源工具, 也可以满足我们的需要。而且这样的投入一般是有意义的。

对于变化非常频繁的代码。我们可以根据功能和目的去组织代码。

如果开始自动化呢?并不是非要股买昂贵的商业工具。一般来说, 自动化开始于单元测试, 这样收益是很大的。接着开展可以用于自动化的测试, 我们可以选择一些开源工具。我们并且用一些自动化的构建工具, 比如JENKINS等。我们可以选择开源的功能性验证工具, 比如selenium等。

4 组织测试

在敏捷开发中, 高效的沟通同样也适用于自动化测试。因为在迭代开发中, 当我们用自动化工具发现昨天的测试用例, 今天的版本失败了。我们就必须立刻去找开发沟通。看是, 更改那些地方了, 需求是不是有变化了。以便, 我们的自动化测试, 适应迭代的变化。

在整个团队中, 开发会更多的考虑代码的可测性, 有的时候, 还会给测试人员提供一定的接口, 来实现自动化测试。

工具的选择很重要。在我们的测试团队, 我们有TC, 但是selenium对功能性的验证测试, 有很大的好处, 又比TC好学。就用selenium了。对于开源工具很多都是比较好上手。但是, 对于商业工具, 虽然感觉上很好。但是, 在我们实际的应用的时候, 发现, 难学, 代码维护繁杂。如果, 我们有商业工具的专家, 那么用商业工具, 更能保证项目的质量。

5 结束语

自动化测试策略的应用, 对于我们实现自动化, 是必须经历的过程。好的而自动化测试是质量保证的利器。

参考文献

[1]Sehwaber K, Beedle M.Agile Software Development With Scrum[M].[S.1.]:Prentice Hall, 2001.

[2]Jonathan Rasmusson.敏捷武士看敏捷高手交付卓越软件.李忠利, 译.人民邮电出版社.2012

[3]Lisa Crispin, Janet Gregory, 著.敏捷软件测试:测试人员与敏捷团队的时间指南.孙伟峰, 崔康, 译.清华大学出版社.2010

[4]Martin R G.敏捷软件开发一原则、模式与实践[M].邓辉, 译.北京:清华大学出版社, 2003.

[5]Kniberg H.硝烟中的Scrum和xP一我们如何实施Serum[M].李剑, 译.北京:清华大学出版社, 2011.

[6]Mike Cohn.用户故事及敏捷方法.清华大学出版社.2010

敏捷建模：增强沟通和理解篇5

Lee Ackerman是The Emphasys Group的产品副总裁和CTO。Lee多年来主要调查、评估新理念，设计、开发解决方案，其他人做这些事情的时候他也会伸出援手。他目前的工作重点是帮助一些组织，让他们借助自动化、重用和敏捷最佳实践去提升交付软件的能力。

[1]《IT项目：超支400%，却只实现了25%的收益》：这篇新闻研究了IT项目风险和一些失败相关的惊人数据。

查看英文原文：Agile Modeling: Enhancing Communication and Understanding

干物女是啥意思和测试方法篇6

是日本进口的流行词汇，干物女是已经放弃恋爱，凡事都说：“这样最轻松”的年轻女人，假日时几乎都在家里睡觉，穿着高中时代的体育服装，歪斜躺在家里喝啤酒看棒球转播、DVD等，很像日剧《爱的力量》里的深津绘里，完全追求进入懒散舒服闲适的生活。

这是目前生活在都市中的部分年轻女性的生活写照，她们在网络中被称为“干物女”。当然也有新兴女性“干物女”。引起极大共鸣。很快就因为电视剧改编而成为当下年轻女性认同的流行词汇。不出门不化妆不结婚，一个人看着漫画或电视。

历史起源

有人认为，日浦悟创造出一位干巴巴的“干物女”，并不是责怪现在的年轻女性，现在二、三十岁的女人非常辛苦，又要打扮的漂漂亮亮、争相要在男人面前吃得开，又要提高自己的职场履历与资格，她们中很多人非常辛苦，既要在男性面前表现得强势，又要提高自己的职场资历;虽然年纪不大，却宣称「男人毕业」而放弃找男人，走放松路线，好自为之地当起干巴巴女人来。总结起来就是都市圈里的生活压力、工作压力造就了“干物女”一族。

行为特征

1.痴迷于某事物如动漫、电玩、书籍;某人，如歌星、网络名人;某事情如手工制作、烹调等等，此种痴迷也允许是突发性的，突然间迷恋上，不能自拔。

2.依赖网络，干什么都想上网，即使上网觉得没事做，也要经常挂在网上。

3.有时候会对上班/上学，产生累的想法，想逃避，但却没有办法。

4.作息时间不稳定，不太愿意遵守一个死板的规则作息时间。

5.极少出门，与其出门，不如呆在家里，总之就是懒得动。即使是接到朋友的出门邀请，也会花些时间考虑要不要去。

6.不喜欢接触陌生人，在现实生活中，如果没有摸清对方的脾气和个性，就不太愿意与他做深入的交流，频繁接触陌生人会有不自然的感觉。

7.性格多少有两面性，在不喜欢的事情面前，会掩饰自己内心想法，得过且过，有时候感觉自己有双重性格。

8.有收藏癖，最少喜欢收藏一种或者多种物品，并乐此不疲。

9.体型相对标准型而言偏胖或是偏瘦。

10.是独行侠或单身贵族。

11.有喜欢上虚拟人物的倾向，例如漫画里面的角色，书本里面的角色等非现实生活中的人物。