探索测试的一些总结
1) 探索性测试与脚本化测试的主要区别：1)探索性测试将更多更高的认知水平的工作放在测试执行，而脚本化测试则更关注测试设计；2)前者更强调测试活动的并行和相互反馈(学习、设计、执行与结果分析等)，而后者的测试活动是相对串行的。
2) 脚本化测试的主要优点是：1)尽早发现缺陷；2)不同利益相关者参与评审；3)可重用性；4)测试覆盖率评估。
3) 脚本化测试强调测试的尽早介入，如尽早设计测试用例。但是测试人员越早设计测试用例，对测试对象的了解越少，对风险的了解也越少。测试人员对测试对象的了解是一个逐步的过程，脚本化测试需要更多的工作量以应对这个过程(需求的细化和变更等)。
4) 提供测试对象的质量信息是测试的一个主要目的。但是不同的人对质量的理解是不一样的，脚本化测试能预先定义所有利益相关者的质量要求吗？脚本化测试能预先定义不同缺陷的来源吗？回答是不能。而这正是探索性测试引入的一个初衷。
5) 测试对象的需求是不断变更的、不同开发人员会犯不同的错误、测试环境与组合也是不断变化的，通过脚本化测试很难及时跟踪这些问题，即使能也需要考虑时间与成本。探索性测试的及时反馈与不断修正是一个解决之道。
6) “复现缺陷，并确定复现的具体步骤”、“下棋”、“刑侦现场”、“拼图游戏”等，其中的思维应该是探索性，还是脚本化？哪个效率更高？
7) 组织内引入探索性测试，需要测试人员掌握各种技术与方法、知识、技能与实践，并以此为支撑，不是每天喊着这个概念就可以成功实施的。这个理念也同样适用于敏捷开发与测试。车是好车，但是我们的路修好了吗？
8) 不管是文档化还是存在于测试人员的头脑中，好的测试设计是什么？好的测试设计应该是随着测试环境不断变化的(例如测试组合、测试环境)，以不断扩大测试覆盖率，并将关注点放在高风险的区域。
9) 不同的测试对象和测试目标，需要不同的测试策略和测试技术，而这将得到不同的测试用例、不同的测试文档与不同的测试结果。
10) 探索性测试没有脚本化特点，并代表它是不做准备的，它也不是随机的，而是提供更多的选择。探索性测试同样需要设计各种支撑性的内容：测试数据、失效模式、模型等。没有测试计划文档，也不代表探索性测试是没有计划的。
11) 探索性测试如下象棋，其规则很简单。但是我们在欣赏象棋比赛的时候，不会说：“啊，下象棋的规则真精彩！”相反，我们关注的是隐含在这些规则下选手选择下一步如何走的技巧与技能，它的技术含量也不在其规则，而在选手的技巧与技能。规则简单，技巧复杂。
12) 探索性测试的学习、设计、执行与结果分析等测试活动是相对并行并且是相互支撑的，了解这个并不代表测试人员掌握了探索性测试。正如婴儿学会了爬，并不代表就懂得了走、跑与跳等运动技能。
13) 探索性测试过程中的一个重要挑战是如何设计测试用例(尽管不一定是脚本化的，也可能是在测试执行的时候进行测试设计)，例如：从测试技术到测试用例、从失效模式到测试用例、从风险列表到测试用例、从测试思想到测试用例。
14) 从用户现场反馈了一个问题：他们在配置某个功能的时候，界面上打印了一些奇怪的信息，然后系统就重启了。此时测试人员更倾向于采用探索性测试，而面临的首要挑战就是“如何从失效模式设计测试用例”，以复现该问题。
15) 探索性测试本身不是一种技术，而是一种测试方式或者思维。那么，脚本化测试应该是什么呢？是技术？不是方式或者思维？
16) 什么使得测试活动具有探索性测试特点呢？答案在于测试人员的认知投入：测试人员如何应对持续变化的情况。
17) 探索性测试不一定会有测试用例文档的输出，这并不代表它没有测试设计。探索性测试的设计不是为了控制，而是为了指导你的测试。
18) 探索性测试更强调个人和交互，而不是过程和工具；更强调应对变化而不是遵循计划；更强调可工作的软件而不是可理解的文档；更强调相互合作而不是合同谈判；从这个层面而言，探索性测试是敏捷的。
最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
朱雀
Myth丶恋晨
柔光的暖阳◎
向右看齐
╰+攻爆jí腚メ
傷城~
我会带着你远行
还没有评论，来说两句吧...