个人资料
在同一个企业的web APP应用程序项目中，一个是敏捷的，一个是瀑布过程，测试策略有何不同？ 在这两种情况下，测试的重点都是告诉业务客户这个APP应用程序做了什么。 此外，还必须消除APP应用程序作为产品提供后的失败风险。 这些主要区别不在于测试本身，而在于什么时候运行测试，谁来运行测试。 的各个阶段可以在系统准备好后随时开始。 不需要等待上一个测试阶段的完成。
如果你没有参与过敏捷项目，或者刚开始敏捷项目就在寻找指导建议，你可以阅读这篇文章。 那是为你们写的。 文章中的信息虽然不是笔者的创作，而是收集整理的结果，希望这些信息有助于我们朝着更敏捷的过程前进。
敏捷项目的测试阶段与瀑布项目的测试阶段几乎没有区别。 每个阶段都有一个标准，但在进入某个测试阶段之前，不需要等待整个APP应用程序完成。 只要APP完成的部分足以进入下一个测试阶段即可。 测试阶段将持续并行进行，因为测试的是已完成的功能而不是版本。 我在那里进行了很多回归测试。 这意味着回归测试是测试自动化的基础。 敏捷项目还应注意环境和资源，因为测试环境的需求更快、更频繁。
“快速失败”是敏捷项目的格言，意味着我们将尽快确定APP应用程序无法满足业务需求。 为此，必须不断检查解决方案是否满足业务需求，如果不满足，就尽早解决问题。 敏捷团队成员-开发人员、测试人员、架构师、业务分析师和业务代表等都有兴趣尽早提供业务价值。 因此，测试必须由所有团队成员合作进行，而不仅仅是测试人员的责任。
测试分类
敏捷项目和瀑布项目的测试分类差不多。 区别主要在于大部分能源投入的位置以及在每个测试阶段运行的时机。 敏捷项目致力于单元和功能测试，并为以后执行的测试阶段编写高质量的代码。 这样，就可以不发现后期应该会早期发现的缺陷，而将精力集中在需要测试的领域。 瀑布工程存在一个普遍的问题，后期测试的焦点总是找出本来应该在前期发现的缺陷。 这样就提高了修复缺陷的成本，测试工作的投资翻了一番，测试的关注点也落空了。
瀑布项目和敏捷项目的另一个主要区别是测试自动化。 敏捷项目在所有测试领域都以100%自动化为目标。 测试与连续构建系统集成，在代码更改时会自动检测到该测试，构建APP连接并运行所有测试。
测试驱动开发(TDD )常用于敏捷项目中，使用这种方法时，测试用例会比代码先创建一步。 因此，我越来越多地看到为代码和功能编写的测试用例。 通过自动化测试并推进开发，消除重复，任何开发人员都可以编写可靠、无错误的代码，无论其复杂性多高。 TDD通常是单元测试，但也可以用于功能测试、集成测试、用户验收测试和性能测试。
单元测试
单元测试也称为白盒测试，用于测试开发的所有模块。 瀑布项目并不关注这个测试阶段，很多时候即使有也是随便做的。 敏捷项目强调单元测试，并使所有单元测试自动化。 自动化单元测试是敏捷项目的基础，对持续集成和重构起辅助作用。
在单元测试中，需要考虑以下事项。
1、通过stub和mock消除对外部接口的依赖。
2、编写代码的开发人员编写单元测试。
3、单元测试必须能够自动化运行，并包含在持续开发构建中。
4、单元测试之间不能有依赖。 允许每个单元测试独立运行。
5、任何开发人员都必须能够在他自己的机器上运行单元测试。
6、通过代码覆盖率判断哪些部分的代码未被单体测试覆盖。
7、签入代码修改前，保证单元测试100%通过。
如果测试失败，则表示构建失败。
功能测试
功能测试通常与系统测试有关，重点在于测试APP的功能，包括负面测试和边界条件。 在瀑布项目中，测试团队通常在此阶段开始测试工作。 测试团队成员将进入功能测试阶段，直到开发人员完成所有功能并通过所有单元测试。 敏捷项目将功能分割为故事，每次迭代都开发一定数量的故事。 每个故事都有几个检查标准。 这些标准通常由业务分析师和测试分析师制定，并被认为与测试条件相似。 测试分析人员根据检查标准创建测试用例，并使用它们来检测代码行为的完成程度。 一旦故事完成并通过了单元测试的运行，就可以运行功能测试以确定是否符合验收标准。 这意味着，在敏捷项目中，只要对第一个功能进行了编码，就可以开始功能测试，并涵盖项目的整个生命周期。
功能测试必须考虑以下几点
1、自动化运行并进入连续构建(如果测试运行时间太长，持续开发构建可以只包含部分精选的功能测试，而系统集成持续构建可以包含所有功能测试)。
2、编码前写出测试意图，代码完成后进行测试。
3、以通过所有功能测试为故事完成的条件。
4 .将APP应用安装在其他环境(如样机环境或产品环境)中时，需要执行功能测试。
如果测试失败，则表示构建失败。