既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
单元测试应当考虑以下几点：
1、用stub和mock来消除对外部接口的依赖。
2、由创建代码的开发人员编写单元测试。
3、单元测试要能自动化执行，而且要被包含在持续开发构建中。
4、单元测试之间不能有依赖，让每一个单元测试都能独立执行。
5、任何开发人员都要能在他自己的机器上执行单元测试。
6、用代码覆盖率来判断哪些部分的代码没有被单元测试覆盖。
7、在检入代码的修改之前，要保证单元测试100%通过。
任何测试失败都表示构建失败。
功能测试
功能测试常常跟系统测试相关联，它的重点是测试应用程序的功能（包括负面测试和边界条件）。在瀑布项目中，测试团队一般是在这个阶段开始测试工作。测试团队的成员会一直等下去，直到开发者完成了所有的功能，并通过所有的单元测试之后才进入功能测试阶段。 敏捷项目把功能拆分成故事，每次迭代开发一定数量的故事。每个故事都有一些验收标准，这些标准一般都是由业务分析师和测试分析师制定的，它们也可以看作跟测试条件类似。测试分析师会根据验收标准创建测试用例，用它们来检测代码行为的完成程度。故事一旦编码完成，而且单元测试运行通过以后，就可以运行功能测试来判断是否满足验收标准了。这就意味着在敏捷项目中，只要第一块功能已经完成编码，功能测试就可以启动，而且会贯穿整个项目的生命周期。
功能测试应当考虑以下几点
1、要能自动化执行，并且进入持续构建（如果测试运行时间很多长，也可以只在开发持续构建中包含一小部分精挑细选的功能测试，而在系统集成持续构建中包含全部功能测试）。
2、在编码之前写下测试意图，代码完成后对测试进行实现。
3、把通过所有功能测试作为故事完成的条件。
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、自动部署应用程序。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
存中…(img-I3LBV083-1715386837081)]
[外链图片转存中…(img-UalxgP4d-1715386837081)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
1011
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
