目录
测试计划制定方式的维度
测试计划制订人的维度
测试计划制详细程度的维度
团队沟通的维度
测试时间节点的维度
需求的详细程度的维度
客户参与的维度
敏捷测试与传统测试的优缺点有哪些？
敏捷测试的优缺点
优点：
缺点：
传统测试的优缺点
优点：
缺点：
敏捷测试与传统测试相比，有相同之处，也有不同之处。相同之处在于无论是传统测试还是敏捷测试，其基本的测试方法和测试技术是一样的，如白盒测试方法和黑盒测试方法都可以在敏捷测试中使用，等价类、边界值、错误猜测等测试技术也同样适用于敏捷测试，但是，传统测试和敏捷测试在很多方面也存在差异，可以从测试发生的时间节点、团队沟通、自动化测试等 多个重要维度进行对比分析。
测试计划制定方式的维度
传统的：做计划是一次性的活动，因为传统模式按阶段划分，做计划会被安排在最初阶段，后面不再进行相关的计划工作。
敏捷的：做计划是持续性的活动，分为不同的级别。最初阶段做粗粒度的计划，在后续的迭代中不断优化为刚好够用(Just-In-Time)的计划。
测试计划制订人的维度
传统的：测试主管计划整个团队的测试工作，一般做计划时采用“自顶向下”的方式。
敏捷的：团队被授权并主动参与计划，一般做计划时采用自底向上”的方式，团队成员会更具主动性。
测试计划制详细程度的维度
传统的：详细的测试计划。传统模式属于“预定义过程控制模式，需求相对清晰明确。
敏捷的：精益化的测试计划。在最初阶段，需求本身比较模糊，无法也没有必要编写详细的测试计划。
团队沟通的维度
传统的：团队之间的沟通是正式的，很多时候以邮件为载体。
敏捷的：团队之间除了正式沟通，还有很多非正式沟通，如口头沟通。
测试时间节点的维度
传统的：测试发生在软件生命周期的最后阶段，在软件发布上线前。
敏捷的：测试发生在每次 Sprint迭代内，以及跨Sprint 的集成过程中。
需求的详细程度的维度
传统的：在最初阶段就要求给出详细的需求，并且需求需要经过严格评审，不欢迎需求变更。
敏捷的：在最初阶段允许提出粗粒度的需求，在后面的迭代阶段逐渐细化，欢迎需求变更。
客户参与的维度
传统的：在需求被定义后,客户只是有限地参与，只有在需求调研的时候会较多地参与。
敏捷的：客户参与贯穿整个项目生命周期，包括每次迭代的计划会和评审会等。
敏捷测试与传统测试的优缺点有哪些？
敏捷测试的优缺点
优点：
早期和持续反馈：敏捷测试强调从开发周期的早期开始进行测试，并在整个开发过程中持续进行，从而可以更早地发现问题。
更快的迭代周期：由于与开发紧密集成，测试可以在每个短周期内完成，允许快速迭代和响应变化。
更高的客户满意度：通过频繁交付可用的产品增量，客户能够更早看到产品进展，并提供反馈，有助于更好地满足客户需求。
改进的协作：测试人员、开发人员和其他利益相关者之间的沟通更加密切，促进了更好的协作环境。
灵活性：适应需求变更的能力更强，能够迅速调整以应对业务或技术上的变化。
缺点：
文档不足：在某些情况下，敏捷可能缺乏详细的文档记录，对于新加入团队的成员来说可能会造成理解困难。
对团队技能要求高：需要团队成员具备多种技能，包括但不限于编程、测试、业务分析等，以便能够有效地进行跨功能工作。
依赖于团队成熟度：成功的敏捷实践通常需要一个成熟的团队，具有良好的自我管理能力和高度的责任感。
难以预测进度：由于迭代速度快且灵活，有时难以准确预估项目的最终完成时间。
传统测试的优缺点
优点：
结构化和计划性强：传统测试遵循严格的流程，每一个阶段都有明确的目标和产出，这使得项目更容易管理和跟踪。
详细的文档支持：从需求分析到测试用例设计，再到最终报告，传统测试提供了详尽的文档支持，有利于知识传递和后续维护。
风险控制较好：因为有完整的规划，在项目前期就可以识别并处理大部分潜在的风险问题。
缺点：
响应变化慢：一旦进入某个阶段后，如果遇到需求变更，往往需要重新规划整个流程，导致响应速度较慢。
延迟反馈：测试一般放在开发之后，这意味着缺陷发现得晚，修复成本更高。
沟通效率低：各个阶段之间相对独立，不同角色之间的交流较少，可能导致信息不对称或者误解。
用户参与度低：直到项目后期才有机会展示成果给用户看，用户的意见不能及时融入到产品开发中。
综上所述，选择哪种测试策略应根据具体的项目情况来决定。对于一些需要快速迭代、频繁发布更新的项目，敏捷测试可能是更好的选择；而对于那些有严格规范要求、变更不频繁的大型项目，传统测试则可能更为合适。
阅读后若有收获，不吝关注，分享，在看！！！
