网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
在不同的组织级别使用哪些度量标准?
在软件项目级别，开发团队可能会跟踪:
需求和需求覆盖——不同类型的测试实际上覆盖了多少用户遵循的工作流?
缺陷分布——在软件的不同部分发现了多少缺陷?随着时间的推移是否有进展?
缺陷打开和关闭的速度——发现一个缺陷需要多长时间，开发人员在测试过程中注意发现的缺陷的速度有多快?
测试执行趋势——哪些测试是由QA团队的特定成员执行的，哪些是由自动化测试框架或服务器执行的?
燃尽图——这是开发团队必须完成的工作量的可视化图。如果测试是一个单独的活动，燃尽图可以帮助管理层可视化他们距离完成一个版本的测试范围有多近。在敏捷团队中，开发和测试是一个统一的任务——一个故事在测试之前是不会完成的——所以燃尽图同时反映了开发和测试活动。
在部门级别，负责开发和测试的组织单位的领导可能会跟踪:
MTTD（Mean Time To defect)和MTTR(Mean Time to Recovery)——总的来说，组织检测缺陷的平均时间是多少，从影响软件用户的缺陷中恢复的平均时间是多少?
缺陷移除效率——在开发周期中有多少缺陷被识别，有多少被实际修复?
测试和缺陷趋势——在几个月到几年的跨度内，测试活动和缺陷的性质是如何随时间演变的?软件质量在提高吗?我们是否检测和解决了更大比例的缺陷，产品的成熟度和稳定性是提高了还是恶化了?
在公司层面，首席执行官、首席财务官、首席营销官或首席运营官可能会跟踪以下指标:
客户报告或体验的问题——影响组织客户的质量问题有多少，什么样的质量问题?随着时间的推移，这可以提供关于软件质量如何影响用户的“底线”洞察。
缺陷严重程度——在多个项目或产品中，缺陷对用户的影响有多严重?在发现和解决这些缺陷上投入了多少时间，这些时间是否被有效地花费了?例如，组织可能会发现某些产品或项目需要更多的测试资源，因为它们表现出更严重的缺陷，会损害客户满意度和收入。
MTTR和MTTD——在组织层面，发现和响应影响客户的缺陷需要多少时间?
系统中断和停机时间——系统运行中断的频率和持续时间?随着许多软件公司过渡到SaaS交付模型，这些指标变得越来越重要。
在发布前/发布后修复bug的成本——在软件版本发布前和发布后修复发现的问题花费了多少精力?众所周知，bug发现得越晚，解决它们的成本就越高。这个度量可以帮助组织了解在生产中修复一个错误的成本有多高，并且通过扩展，更好的测试来更早地发现缺陷的ROI。
瀑布与敏捷环境中的度量
瀑布模型采用一种非迭代的开发方法，每个阶段都需要在下一个阶段开始之前完成。
在传统的瀑布环境中，测试指标包括:
产品质量——一旦开发接近瀑布式项目的末尾，就会有一致的努力来测试和稳定软件，以达到能够交付给用户的质量水平。
测试有效性——测试有高价值吗?测试团队在发现相关缺陷并帮助开发团队理解和解决它们方面的能力如何?
测试状态——计划了多少测试，运行了多少测试，还有多少测试?
测试资源——在测试组织中，产品或项目有哪些可用的资源，它们的使用情况如何?
在敏捷环境中，一些适用于测试的通用开发指标是:
冲刺燃尽图——帮助团队可视化当前迭代中剩余的工作，以及扩展，还有多少测试需要完成。
工作测试功能/运行测试功能的数量——持续添加到软件中并进行充分测试的功能或敏捷“故事”越多，项目就越健康。
速度——开发团队完成新功能的速度。更快的进展是可取的，但应该与监测技术债务相结合，以确保团队不会在跳过最佳实践或留下质量差距的情况下竞相完成功能。
累积流程——帮助可视化敏捷过程中的瓶颈。特别是，帮助团队可视化测试资源是否足够，以及测试是否放慢了开发周期。
挣值分析——一种成本估计方法，可以帮助确定软件测试作为一个整体的经济价值，以及在单个任务级别上，特定测试是否具有成本效益。
一些具体的敏捷测试指标包括:
自动化测试覆盖率的百分比——度量由自动化测试实现的测试覆盖率占手动测试和自动化测试总数的百分比。这表明了敏捷组织的成熟。
代码复杂度和静态代码分析——使用圈复杂度或其他形式的自动化分析来衡量代码质量。
在生产中发现的缺陷/已逃逸的缺陷——统计在发布日期之后发现的给定发布的缺陷。显示交付给最终用户的软件质量的“底线”指标。
缺陷类别——按组划分的缺陷数量;比如功能错误、通信错误、安全漏洞、性能缺陷。他可以帮助敏捷团队确定导致最终用户80%问题的帕累托20%缺陷。
缺陷周期时间——度量从开始修复一个缺陷到完全解决该缺陷之间所经过的时间。敏捷控制图可以帮助直观地表示敏捷周期内解决任务的速度。
缺陷溢出——度量在给定的冲刺或迭代中没有得到解决的缺陷的数量，以及从一个冲刺溢出来的缺陷的数量，以便在下一个冲刺中得到解决。
手动测试和自动测试使用哪些测试指标?
测试自动化已经席卷全球，人们普遍认为，如果没有广泛的自动化测试，敏捷开发将是不可能的。然而，仍然存在手动测试的空间。对于敏捷团队来说，将关键的验收测试、复杂或敏感的用户故事交给人工测试和分析是很常见的。
传统上，不同的度量标准被用于测试手动和自动软件测试。
手动测试指标
测试用例执行——测试团队或单个测试人员在特定的软件版本上运行了多少测试用例?
测试用例准备——设计了多少测试用例脚本来覆盖软件功能?
缺陷度量——关于年度测试人员发现的缺陷数量和性质的各种度量，包括:
-
缺陷优先级
-
缺陷严重程度
-
缺陷逃逸率——在软件发布之前，手工测试人员无法识别的缺陷的百分比。
测试自动化度量
测试总持续时间——运行自动化测试所需的时间。这很重要，因为测试通常是敏捷开发周期中的瓶颈。
单元测试覆盖率——度量单元测试覆盖了多少软件代码。这个指标给出了软件代码库被广泛测试的大致近似值。
路径覆盖——测试覆盖的线性无关路径的测量。路径覆盖需要非常彻底的测试;程序中的每条语句都至少执行一次，覆盖全路径。
需求覆盖——显示测试了哪些特性，以及有多少测试符合用户描述或需求。测试自动化成熟度的一个非常重要的度量，因为它跟踪交付给客户的特性中有多少是由自动化覆盖的。
通过或失败的测试百分比——统计最近通过或失败的测试数，占计划运行的测试总数的百分比。该度量提供了测试进度的概述，这很容易在构建、发布或时间段之间进行可视化和比较。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
阶课程，涵盖了95%以上软件测试知识点，真正体系化！**
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
995
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
