敏捷测试与传统测试的区别

敏捷测试并不是一种新的测试类型，也不是一个新的测试阶段，更不是一种全新的测试方法论。通俗地讲，在敏捷开发过程中进行的测试就叫敏捷测试。
它是一套测试解决方案、一组实践或者由一定顺序的测试活动构成的特定的测试流程。是为了顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。
敏捷测试与传统测试的区别，并不是敏捷测试测得更快，也不是用的时间更少，更不是将测试的范围缩小，或者将质量降低来减少测试任务，而是在计划、阶段划分、文档、记录、沟通等方面的侧重不同。
1、传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理。而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。
2、传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，模糊了阶段性，而且介入更早。
3、传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。
4、传统测试更关注bug，围绕bug开展一系列的活动，如bug跟踪、度量、分析、报告、质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，bug修复的成本很低。
5、传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响。但敏捷测试的基础就是自动化测试，敏捷测试需要有良好的自动化测试手段支撑的快速测试。
6、传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试中，测试人员需要参与全部开发活动，需要参与整个项目组的所有会议，能够发挥更大的作用。
敏捷测试中的关键过程

在一个sprint中，测试人员的工作内容主要分为五个部分：user story分析、测试用例设计开发、测试执行和分析、测试持续集成、回归测试。这五个部分的工作均要持续到sprint结束，只是启动时刻有早有晚
user story分析工作：敏捷测试是不断确认客户的需求得以圆满实现，因此对用户需求的分析、理解需要一直持续下去，发现有偏差及时纠正，及时设置合理的验收点、测试项。
Testcase Develop工作：设计测试用例，完成测试代码的开发、测试数据的准备，并及时与开发人员沟通软件接口，确保测试代码能够成功驱动业务代码。
Testing & Analysing工作：执行测试，统计测试覆盖率，分析测试结果，若发现bug，及时沟通，并协助定位bug。
Continuous Integration工作：将测试代码进行集成，以保证当前功能若被后续集成代码污染是能够及时得到报警，不断地完善软件产品的功能基线。
RegressionTesting工作：在完成全部user story后，对所有代码进行完整的回归测试，对所有bug修复情况进行确认。

敏捷测试对测试人员的要求
　　优秀的敏捷开发过程越来越重视测试人员，测试人员在其中所起到的作用越来越大，相应的对测试人员的要求就越来越高。一个合格的敏捷测试角色，应当具备以下素质：
1、良好的沟通能力
　　测试人员全程参与所有开发活动，需要与产品、开发、项目经理设置用户进行频繁的沟通，必须具备良好的沟通能力。
2、换位思考能力
　　一方面需要站在产品、用户的角度，考虑产品的功能、性能、易用性等，一方面需要站在开发的角度，思考软件技术方案的可行性，实现的难度、合理性、可测性等，充分考虑到各种情况。
3、掌握多种的测试手段
　　面对不断变化的需求，足够的测试手段储备，是从容应对变化的本钱。
4、一定的开发技能
　　在敏捷开发团队成长到一定程度后，测试与开发角色的界限会变得模糊。在初始阶段，测试人员也应当具备完成单元测试代码编写的能力。
5、拥抱变化
“唯一不变的就是变化”，所以，需求的变动是必然的，每次的需求的调整都是将产品开发推向更正确的方向。在接受变化的同时，测试人员应该积极的反馈可能的设计缺陷和错误。

自动化测试与手工测试
　　轻量级增量开发、快速迭代的特点，使得测试人员需要重点关注两个方面的软件质量，一是新功能的需求符合性，二是原有功能的稳定性、可靠性。通常，对新功能进行灵活性高的手工测试，而对原有功能进行自动化回归测试是目前看来最合理的一种手工测试与自动化测试的分工。
　　敏捷功能测试= 新特性的手工测试（针对user story验证） + 原有功能的自动化测试（回归测试）。

所以可以总结下
测试人员是敏捷团队非常重要的一环，测试人员的成长对敏捷团队非常重要。从传统测试工作转入敏捷测试工作必然会遇到很多不适，但是只要坚持对敏捷的学习和各种新工具的开发使用，一切都能够适应下来。
谁都知道，变化，才是永远不变的，敏捷则是我们应对变化的武器。

然后咱们在看看软件测试用例改怎么编写
一、首先先看看什么是测试用例？
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。

二、写测试用例有什么好处？
理清思路，避免遗漏
这里是我们认为最重要的一点，假如我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
跟踪测试进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。
历史参考
在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
重复性
我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
告诉领导，这事我干过，不然别人怎么知道你测没测，测的全面不全面，拿测试用例给他们看！因为我之前就是这样干活！

三、测试用例的方法
好吧，咱知道啥是测试用例了，也是知道为什么要写测试用例了，那到底应该怎么写？无从下手啊。我们在写测试用例之前，先学习几种方法，它是我们写测试用例的指导思想。

1. 等价类划分
   在某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等价的。假如有一个输入框要求输入1-10000个数，我们不可能用每一个数去试，我们输入5 和输入6去验证和揭露输入框的错误可以看做是等价的。那么这个时候我们就可以随机的抽取一些数据来进行验证。如：10 、99、7777…
   等价类分：有效等价类和无效等价类
   输入框要求输入1-10000的数
   有效等价类：可以输入1-10000之间的数来验证，如：2、5、99、8495…
   无效等价类：可以输入1-10000之外的任意字符验证，如：20000、字母、下划线、特殊符号、空格、回车…
2. 边界值
   边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001…等等，来判定是否超出了我们的范围。
3. 因果图
   因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。呵呵。
4. 错误推测法
   基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。
5. 其它
   设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。

四、测试用例的格式与要素
一个测试用例应该包括：编号，标题，测试场景，测试步骤，预期结果。
当然还可加入一些它选项，如：优先级、测试阶段…

注：上面的格式取自《微软的软件测试之道》，它并不一定适合你，我只是让大家对测试格式有个了解。
关于测试用例的存放管理：

1. 项目管理系统自带的用例管理，一般用例会与项目挂钩，有固定的格式，搜索、修改等功能，使用起来非常方便。如：禅道项目管理、QC、bugfree 等等都带的有用例管理功能。
2. 通过worldExcel文档形式管理，这样的好处就是自己定义测试用例的格式。
   测试用例例子
   基础知识了解的差不多了，下面来看一个具体的测试用例。我们会有更深刻的认识。

注：这不是一个完整的测试用例，格式也不是固定必须这样的，你们可以根据自己的需求编写设计测试用例。

一、.我们在什么时候可以设计测试用例？
当根据客户的需求整理出项目需求分析文档时，我们就可以根据需求文档来编写测试用例了。但是，一般我们（国内大多小公司）项目需求文档都非常“简陋”，所以，很难根据需求文档设计测试用例。
我们只有等到项目开发人员把项目开发出来，给我们系统文档、部署环境、数据库结构（如果系统牵涉到数据库的话），我们根绝这些文档来设计测试用例。

二、测试用例的评审与更新
我们设计的测试用例设计完成之后，是否完整？是否符合系统？符合客户要求？对用例做一个评审是必不可少。关于评审的方式，不同的公司有不同的流程。
我们编写的测试用例也不是经过评审之后就不变了，随着需求的变更、功能的改进，测试用例当然也需要更新和变动。

三、什么情况下不适合写测试用例
文件时间
如果一个功能我很快就测试完了，而且只需要测试一遍，但我们设计测试用例时却比较麻烦，花时间也长。这个时候就没必要编写测试用例了。
需求变动大且频繁
需求的功能变动非常频繁，而且变动很大，之前编写的测试用例根本没法使用，必须要重新编写，这个时候也没必要去设计测试用例了。
项目时间不允许
这一项是不太厚道的做法，如果不是急需交付客户的话，尽量不要这样做；当然了，如果只是给客户展示或试用，可以在之后进行补充和完善测试用例。
不要编写不完整或别人看不懂的测试用例，那样就没有意义了。

四、停止软件测试的标准。
语句覆盖最低不能小于80%00%，测试需求覆盖率达到1，测试用例覆盖率达到100%，一、二级缺陷修复率达到100%，三、四级修复率达到80%
（上面一句是再网上找的，不是标准，只是个参考）
bug等级：
一级：非常严重的bug
二级：严重的bug
三级：一般性的bug
四级：建议性问题

五、关于探索性测试
完全的执行测试用例时一件非常枯燥的事情，个人在执行测试用例时会做一些，其它的非常规性的操作，看系统是否会有相应的处理和提示。我的一部分bug就是再这种非常规操作下发现的。
当然了真正的探索性测试需要对产品的深入了解，以及软件开发技术有一定的深度和广度。姑且把我们的探索性测试看成是瞎捣鼓吧！

六、 交叉测试
有木有发现，当我们第一遍测试系统时，会非常认真，但要我们测试第二遍时，我们不愿意像第一次那样认真的去测了，这不能说明我们不负责，而是每个人都有的心理现象。这个时候，我们可以和其它测试人员交换功能来测试，提高效率，而且更容易发现问题。

七、测试的目的

1. 我们让它做的它必须会做。
2. 我们不让它做的它必须不会做。
   可能你会发现有附加功能的时候，就是客户没有要求，我们加了这样的功能，可能加了这点功能系统看上去会更好。这时怎么办？算问题么？
   作为开发人员，中规中矩的做东西最好，如果真的有非常好的功能要加的话，需要和客户沟通，然后写到需求里。毕竟多一点功能多一点风险。
   作为测试人员，凡是不符合需求文档的都需要当问题点提出。责任分明，以免后续麻烦。