我在华为做敏捷测试的那些流程

感悟时分

一、开发和测试的通性困扰？

　　面对复杂性（客户）：不断地修改计划、不断地增加预算、低劣的产品质量……
　　面对复杂性（项目组成员）：经常加班到深夜、提交的产品不合格……

　　二、敏捷开发中的敏捷测试目的：
　　敏捷宣言
　　个体和交互比过程和工具更有价值；能工作的软件比全面的文档更有价值；顾客的协作比合同谈
判更有价值；及时响应变更比遵循计划更有价值。
　　其核心是:以人为本,发挥人的主观能动性.
　　三、传统测试和华为敏捷测试区分：
　　3.1、传统的测试
　　1.守门员:质量保证者，阻止那些不可靠的、无效的、充满BUG的版本发布。
　　2.信息提供者:提供大量积极的、关于项目开发的状态的信息。告诉大家哪些功能正常工作、哪些
功能不能正常工作、哪些BUG必须处理。
　　3.2、华为敏捷测试
　　测试和开发的角色界线变得模糊。有些人主要做测试工作，有些人主要做开发工作，但是在快速
推进的过程中，所有人都会被号召起来测试或支持测试的工作。
　　更多职责:帮助开发人员理解需求,尽早确定测试规范。
　　3.3、敏捷测试中测试人员扮演的角色
　　1.测试是项目的"车头灯"，它告诉大家现在到哪了，正在往哪个方向走。
　　2.测试为项目组提供信息，使得项目组基于可靠的信息作出正确的决定。
　　3.测试人员不作出项目发布的决定。
　　4.测试员不保证质量，整个项目组对质量负责。
　　5.测试不是抓虫子的游戏，它的目的不是纠缠在错误中，而是帮助找到目标。
　   ... ...

　　四、敏捷测试用例的设计和评审要素：
　　4.1、基于需求的用例场景来设计测试用例：
　　1.基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是
软件的根本，验证对需求的覆盖是软件测试的根本目的。
　　2.把测试用例当成"活"的文档,因为需求是"活"的、善变的。因此在设计测试用例方面应该符合敏
捷的"及时响应变更比遵循计划更有价值"这一原则。
　　3.测试用例的设计不是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回
来重新审视和完善测试用例。
　　4.2、敏捷测试用例设计原则
　　通常我们所看到的测试用例的设计是其中一项。
　 　测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测
试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的 哪些要素、需要达到的质量目标、
需要使用的测试方法等。而最复杂的测试用例就像银行取款机系统中工作指令系统界面一样，会指定
输入的每项数据，期待的结果 及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等
等。
　　测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。
另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
　　测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进
行"设计"，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的
测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程
中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。