软件测试最全Web应用中的敏捷测试和瀑布测试_瀑布测试和敏捷测试的区别，2024年最新在字节跳动我是如何当面试官的

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

4、在应用程序安装到另外一个环境（如试机环境或产品环境）上的时候需要执行功能测试。

任何测试失败都表示构建失败。

探索性测试

探索性测试又称为随机测试。瀑布项目在它们的测试策略中没有这种测试类型，不过大多数测试人员都会多少做一些探索性测试。在敏捷项目中这是个很关键的测试阶段，因为它可以用来检测自动化测试的覆盖率，并收集对于应用程序质量的反馈。它为测试人员和业务分析师提供了一种结构化的方式去使用、去探索系统，从而找到缺陷。如果探索性测试在某个功能区域内找到了大量缺陷，那这部分的自动化测试用例就要被审核。

探索性测试应当考虑以下几点：

1、在系统集成环境中执行。

2、在较高的层次上监测探索性测试活动。

3、用自动化的环境设置方式来减少搭建环境的时间。

4、将破坏性测试作为探索性测试的一部分。

集成测试

应用程序在作为产品部署的时候，需要各个部分的协作；集成测试就是把这各个独立的部分集成起来进行测试。瀑布项目不但会把应用程序的各个独立模块进行集成，还会把那些虽然不属于项目的一部分，但是要开发当前应用程序就必须用到的一些应用程序也做集成。在敏捷项目中，独立模块间的集成是被持续构建所覆盖的，所以集成测试的关注点就是那些不属于当前项目的外部接口。

集成测试应当考虑以下几点

1、在执行集成测试的时候，需要考虑到当前迭代还没有开发的功能。

2、写一些集成测试来定位特殊的集成点，以协助代码调试，即便功能测试会调用到这些集成点也无妨。

3、将集成测试自动化，放到系统集成持续构建中。

任何测试失败都表示构建失败。

数据验证

如果项目需要移植既有数据的话，就要进行数据验证。它可以保证现有的数据被正确地移植到新的Schema中，新的数据被添加进来，旧的数据被移除。这种类型的测试在瀑布项目和敏捷项目中是被同等对待的，除了敏捷项目会尽力把它自动以外。

数据验证应该考虑以下几点：

1、在系统集成环境、试机环境和产品环境中都要执行。

2、尽可能地自动化。

3、要把测试放到系统集成持续构建中。

任何测试失败都表示构建失败。

用户验收测试（UAT）

UAT关注的是完整的业务过程，它用来确保应用程序能按照业务的处理方式工作并能满足业务需求。它同样还要从客户、消费者、管理员等各种用户的角度出发考虑应用程序的可用性。在瀑布项目中，这个阶段通常就被用来找出应该在早期阶段就被发现的bug。业务人员也会在这个阶段验证开发团队交付的应用程序的质量。敏捷项目用UAT来确保应用程序满足业务需求，因为等到进入这个测试阶段的时候，代码质量已经较高了。在敏捷项目中，业务人员从早期的测试阶段就开始参与，所以他们对交付的东西有更多的信心。

UAT应该考虑以下几点：

1、首先进行手工测试，等它验证了系统行为以后再把它自动化。

2、把自动化测试放到系统集成持续构建中

3、让应用程序的最终用户亲自将整个程序运行一遍，不过项目的测试人员要在旁边协助。

4、在试机环境下执行UAT， 用作验收。

5、只要完成了一个业务过程或者一个主要的UI组件，就要执行UAT。

任何测试失败都表示构建失败。

性能测试

性能测试涵盖的范围比较大，不过一般可以分成以下三类。

1、容量测试：独立测试核心功能组件的容量。例如， 可以支持多个用户并发检索？一秒种能做多少次？等等。容量测试被用来精确度量系统的极限，还可以对容量规划和系统的扩展性起辅助作用。

2、负载测试：侧重于系统在负载下的表现。负载应该要体现出用户所期望系统可以经受得住的流量。

3、压力测试：关注系统在压力下的表现。比较常用的技术是浸泡测试（soak test）；在浸泡测试中，系统会在一定的负载下持续运行一段时间，用来找出长期问题，如内存泄漏、资源泄漏等。压力测试还会覆盖故障转移和恢复，例如正在工作的集群中的一台服务器出现问题，检查是否可以做到故障转移和恢复。

瀑布项目直到项目接近尾声的时候才做性能测试，这个时候应用程序已经“完成了”开发，通过单元测试和功能测试。而敏捷项目则会尽快启动性能测试。

性能测试应该考虑以下几点：

1、在功能测试中设置一些性能度量，例如一个测试第一次运行要花多长时间，接下来每次又要花多久，把这些时间所占的百分比做一下比较（上升表示有问题，下降表示良好）

2、把一些性能测试放到系统集成持续构建中去做。

3、一旦一个业务过程，或是某个规模比较大的功能或接口完工，就要做性能测试。

4、只有在试机环境中运行的时候才签收性能测试。

任何测试失败都表示构建失败。

非功能性测试

非功能性测试所涵盖的范围很广，性能测试通常也属于这个话题。但是因为性能测试是企业解决方案中很重要的一部分，而且需要不同的资源和技能集，所以就被划出来单独成为一个测试阶段。非功能性测试一般都包含有这些内容：可操作性（包括监控、日志、审计/历史记录）、可靠性（包括故障转移，单个组件故障，完整故障，接口故障）以及安全性。无论瀑布项目还是敏捷项目，在这个测试阶段都会遇到重重阻碍，二者的差异不太突出。

非功能性测试应该考虑以下几点：

1、非功能性需求一般都是很难捕获的，而且即便被捕获，也很难进行度量。（例如：99.9%的无故障时间）

2、尽可能让所有的非功能测试都自动化执行，把它们也都放到系统集成测试环境中。

3、在定义测试用例的时候，让真正要监控产品环境并对其提供支持的人也参与进来。

4、在应用程序成为产品以后，非功能测试或监控还要继续。

回归测试

在瀑布项目中，回归测试无论从时间上还是费用上来看，都算得上是成本最高的测试阶段了。如果在项目晚期（如UAT阶段）发现了缺陷，再构建应用程序的时候，就得把所有单元测试、功能测试和用户验收测试重新运行一遍。因为大多数瀑布项目都没有自动化测试，所以回归测试的开销就很大。敏捷项目以持续构建和自动化测试来应对回归测试，使每次构建都可以进行回归测试。

回归测试应该考虑这一点：

每次迭代结束时都做一下手工测试，收集早期反馈。

产品校验

产品校验会在把产品交付给用户使用之前，审查产品环境中的应用程序，看看所有内容是否否都已经正确安装，系统的操作性如何。而有些测试还是只能到了产品环境中才能完整运行的，最好尽快将其完成。无论是瀑布项目还是敏捷项目，产品校验的方式并无二致。

产品校验应该考虑以下几点：

1、让最终用户来做产品校验测试。

2、趁着产品系统还没有正式上线，从这个测试阶段的早期就要尽可能多地执行自动化回归测试。

瀑布项目和敏捷项目的测试阶段还是很相似的，主要差异就是每个测试阶段关注的重点和执行时机。敏捷项目中有大量的自动化测试，用持续集成来减少回归测试对项目带来的影响。在瀑布项目中，如果发现应用程序的质量低下，那么在晚期再去执行前期的测试就是很常见的事情（如在UAT的时候做功能测试）。敏捷项目可以减少测试中的浪费，在早期发现问题，让团队在交付应用时增强信心。

环境

在开发过程的各个阶段都要用到测试环境，从而确保应用程序的正常运行。越到后期，测试环境与预期的产品环境就会越相似。测试环境一般都会包括一个开发环境，让开发者集成代码并运行一些测试。系统集成环境跟开发环境有些类似，不过它会集成更多的第三方应用程序，也许还有大批量的数据。试机环境几乎是产品环境的镜像，也是应用程序变成产品之前的最后一个阶段。

敏捷项目和瀑布项目所需的环境没太大区别，其中一个不同之处在于，敏捷项目从项目伊始直至项目结束，都要用到所有的环境。在敏捷项目中，保证所有的环境都一直正常工作也是很重要的。无论因为什么原因让某个环境出现故障，都要立刻让它重新工作起来。在这个话题上，敏捷和瀑布还有另外一点差异，那就是环境的计划和资源分配对它们的影响不同，尤其是当各种环境被项目之外的团队进行管理的时候，其差异尤为显著。

开发集成环境

开发者在开发环境中集成代码，开发应用程序。瀑布项目对开发环境的重要性不会考虑太多；开发环境中的代码一直都不能工作，到了开发者需要彼此集成代码的时候才想起来使用，而这时项目已经临近尾声。在敏捷项目中，开发环境是整个开发工作中不可分割的一部分，在开始编码之前就必须准备就绪。这个环境会被用来持续地集成代码和运行测试套件。无论因为什么原因造成环境故障，都要立刻修复。

开发环境应该考虑以下几点：

1、集成代码、构建和测试的时间加起来不要超过15分钟。

2、每个开发人员所用的环境跟开发环境保持一致（硬件环境可以不一样，但软件环境一定要一样）。

3、所用的数据要尽可能跟产品数据保持一致。如果产品数据过于宠大，难以载入，也可以只取一部分。在每个发布周期的开始阶段，这些数据要从产品数据中重新更新。

4、管理这个环境的责任应该落在项目团队身上。

5、向这个环境中部署的频率大约是以小时计算。

6、自动部署。

系统集成环境

系统集成环境用来将所开发的应用程序和其他应用程序进行集成。在瀑布项目中，这个环境只会在项目临近尾声的时候才会用到，而且倾向于多个项目共用一个集成环境。在敏捷项目中，一旦开始编码，这个环境就要准备就绪。应用程序会被频繁部署到这个环境中，继而开始执行功能测试、集成测试、可用性测试和探索性测试等等。应用程序的演示是在这个环境中进行。

系统集成环境应该考虑以下几点。

1、集成点应该被真正的外部应用程序所代替。外部应用程序应该处于测试状态，而非真正的生产版本。

2、把产品环境的架构复制过来。

3、把这个环境中所使用的数据应该是产品环境数据的副本，每个发布周期的开始阶段，都要从产品数据中重新更新。

4、建立运行这个环境中所有测试的系统集成持续构建。

5、管理这个环境的责任应该落在项目团队身上。

6、向这个环境中部署构建的频率大约是以天计算。

7、自动部署应用程序。

试机环境

试机环境用来验证应用程序可以部署为产品，而且工作正常。为了达到这个目的，试机环境应该完全复制产品环境，包括网络配置、路由器、交换机以及计算机性能等等。在瀑布项目中这个环境往往需要“预订”也要有一个计划，计划在这个环境中进行多少次部署以及何时进行部署。敏捷项目对这个环境不像对开发环境和集成环境那样依赖；不过在项目的整个生命周期中，还是需要常常进行部署。

试机环境应该考虑以下几点：

1、这里的数据应该是产品数据的完整副本，每次应用程序部署前都要更新。

2、用它来验证UAT， 性能测试和非功能测试（稳定性、可靠性等等）

3、向这个环境中部署构建的频率大约是以迭代计算，如每两周一次。

4、管理这个环境的人应该就是管理产品环境的人，让他提前接触应用程序并进行知识传递。

5、自动部署应用程序。

产品环境

产品环境是应用程序正式上线时的环境。产品校验测试就在这个环境中执行，同时会做一些度量以检验测试成果。瀑布项目和敏捷项目在这里的区别不大。在敏捷项目中，发布过程会尽力做到自动化，为向产品环境中频繁发布提供条件。

产品环境应该考虑以下几点：

1、在应用程序正式上线之前，在产品环境中做回归测试。

2、要做度量，以检验测试成果，例如在前三个月到六个月之前，用户报告了多少问题，问题的严重性如何。

无论是哪种项目，要保证时间期限，就都得做到在需要用到环境的时候就有一个环境可供使用。瀑布项目会设法遵守严格的计划，便于对环境做安排。敏捷项目的灵活性更强。也许有了足够的功能就可以进入试机环境了，或者业务人员会决定产品提前上线。为了做到向试机环境快速部署，然后进入产品环境，就要有系统集成环境以及有关过程的辅助。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

20311)]
[外链图片转存中…(img-njKxSSIM-1715554220311)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！