传统测试~敏捷测试
先研究一下敏捷宣言背后所蕴含的12条原则
-
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
-
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
-
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
-
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
-
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
-
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
-
可工作的软件是进度的首要度量标准。
-
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
-
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
-
以简洁为本，它是极力减少不必要工作量的艺术。
-
最好的架构、需求和设计出自自组织团队。
-
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
和传统测试的区分，可以概括如下： -
传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。
-
传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，阶段性比较模糊。
-
传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。
-
传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。
-
传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。
-
传统测试更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，缺陷修复的成本很低。
-
传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。
发现的问题
1.研发和测试融合在一起，测试的版本迭代很频繁，测试测过的问题重复出现
2.测试的质量保证问题，一轮的测试拿什么保证质量？
3.测试挑着功能点测试很麻烦
4.预估的工作量不准确
5.实际录入的工作量和禅道中录入的工作量不一致
6.功能点拆分的时候出现大量重复的功能点，到底怎么拆分功能点？
