CMMI和敏捷测试
敏捷测试敏捷测试的产生：
对于敏捷的理解，最为关键的两个方面，它们是“高度迭代”和“持续不断的客户反馈”
高度迭代
迭代就是指产品的开发过程中，一个完整的开发活动周而复始的进行，产品的功能、性能、可用性在周
期活动的叠加中不断得到更新和加强。甚至指在一个迭代周期内产品活动也具显著的周期性。
同时，团队间、团队内部成员的高度协作及时帮助解决了各成员的依赖性问题，因此，也促进了各个成
员工作的顺利开展，保障了产品活动稳定的持续性、周期性。
持续不断的客户反馈
指在产品开发任何时期，代表项目业务（Business）的利益干系人（Stakeholder）都要参与到产品的需
求分析，设计，以及其他活动的决策制定中来。
致力于在短时间内帮助团队实现将客户的需求转化为高质量的可消费产品，并转化成利润
敏捷宣言
个体和交互比过程和工具更有价值
能工作的软件比全面的文档更有价值
顾客的协作比合同谈判更有价值
及时响应变更比遵循计划更有价值
敏捷测试
在开发的同时进行测试。
加入团队后所做的第一件事，就是搬位子到开发人员旁，我们不再和产品团队有空间距离，不再只是看
文档写用例，不再只是提交bug，不再只是争论某个bug是否必须修改。 敏捷的开发决定了我们必须以
敏捷的测试来应对
“沟通”成了最重要的技能之一
敏捷宣言里讲：个体和交互胜过过程和工具，客户合作胜过合同谈判。在内部需求上，开发人员就是我
们的客户。
敏捷常做的一种合作就是：由测试人员来搭建环境，按重现步骤操作，由程序员在另一端跟踪调试代码，
一边沟通，一边进行，这样就能很准确的发现问题，并且能很快的得到修正。
敏捷测试让测试的角色定位已经变了。因为敏捷开发中，要对质量负责的是整个团队，这一目标就要求
测试人员不再是一个独立的质量监督部门，而是要融入到整个团队中，成为开发中不可分割的一部分。
灵活运用测试方法
在进行敏捷开发中，快速的响应变化的前提，一定是对质量的保证。如果质量无法保证，那是无法对变
化做出响应的。因此这要求程序员能更多的进行自测，包括白盒的，自动化的，测试驱动的。
而站在测试人员的角度上，因为对产品接触的更具体，有了很多机会接触详细的程序设计，测试人员已
经可以尝试直接阅读代码，并在此基础上进行灰盒测试或白盒测试。通过黑盒测试，灰盒测试和白盒测试的
结合，加强对所测的产品的安全性。
适当引入自动化测试。
适当调整测试用例的粒度
测试员最重要的技能就是写用例，通过用例来表达测试思想。即使是到了敏捷时代，这个技能仍然是第
一位的。
只是，如果你的用例写得过于详细和复杂，那么在团队开始响应变化的时候，你就会措手不及了。粒度
大小应该合适，便于调整和修改。
CMM－Capability Maturity Model for Software软件能力成熟度模型；
定义：对于软件组织在定义、实现、量度、控制和改善其软件过程的各个发展阶段的描述。
目的：帮助企业进行对软件工程过程的管理和改进，增强开发制造能力，从而能按时地、不超预算地制
造出高质量的软件。
CMMI--集成的软件能力成熟度模型Capability Maturity Model-Interation
成熟度等级
初始级：过程通常是混乱的，而且组织通常没有提供稳定的环境。
受管理级：组织的项目已确保需求是被管理的，而且其过程是经过计划、执行、度量以及控制的。
已定义级：过程都已被很好地说明与理解，并用标准、程序、工具和方法来表现
定量管理级：选定对整体过程效能有重大影响的子过程，并使用统计和其它量化的技术，来控制这些子过程。
持续优化级：根据对过程变异共同原因的量化理解，持续地进行过程改进。
页:
[1]
