关于自动化用例设计的思考！
为什么要设计用例？
作为质量保证(QA)人员，设计测试用例的重要性不亚于开发人员编写技术实现方案。如果实现方案设计不周，编码阶段将可能遇到许多问题；同理，如果我们未能设计测试用例，产品质量就难以得到充分保障。
对于不同的测试类型，我们在设计测试用例时候的侧重点和颗粒度有所不同。
设计测试用例的目的，个人观点认为主要有如下几点原因：
方便测试活动开展
我们心中一定需要有质量和效率的意识。我们工作的核心是以更高的效率保证交付产出物的质量，这也是是所有测试工作的最终目标。
在实际工作实践中，绝大多数的测试工作都是围绕测试用例展开的。例如测试用例评审、冒烟测试、提测检查、用例执行、缺陷提交、缺陷跟踪和修复验证，直到最终线上发布。每个阶段都有对应的测试用例、脑图、测试点或者checklist。
保证业务场景覆盖
软件测试工作的核心是通过设计各种场景并进行校验，以确保交付的软件符合预期设计结果。无论是采用功能测试中的等价类、边界值、正交、因果图等用例设计方法，还是自动化测试中的分层概念，都是为了通过特定的方法和手段尽可能地保障业务场景的覆盖率，避免因遗漏而导致问题逃逸到线上，从而影响最终交付产出物的质量。
我们的目标是通过精心设计的测试策略和全面的测试覆盖，确保软件功能的稳定性、一致性和可靠性。
质量管控和评估
随着团队对质量的重视，开始对需求质量、研发质量、发布质量等进行质量评估，通过一系列的手段和策略去提升各个方面的质量，达到最终交付质量。
测试用例是研发过程质量中的重要组成部分，可以说是研发过程中各项测试工作的核心。
我们习惯以多维度的视角，运用各种测试技术手段来检验软件是否满足预期，都是为了验证和确保交付质量。同时，我们也严格遵循流程规范和度量标准，以保证最终交付的产品达到标准。
例如我们想要度量研发提测质量，通过单元测试、代码扫描、冒烟测试的手段，制定对应的度量标准如单元测试覆盖率、冒烟用例通过率、提测退回率、代码质量分等。
这里面我们有些可能不是完整的用例，但是会是一些检查点、度量指标。
如何设计自动化测试用例？
自动化测试的分层模型，我们应该已经很熟悉了，按照分层测试理念，自动化测试的投入产出应该是一个金字塔模型。越是向下，投入/产出比就越高，但开展的难易程度/成本和技术要求就越高。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】
Unit 自动化
单元测试(unit testing) 是指对软件中的最小可测试单元进行检查和验证。最初由开发人员完成，旨在确保其所负责的环节交付的产出物符合进入下一阶段的标准。
对于单元测试，我认为测试人员应该参与其中，共同协作进行测试和验证，以尽早发现问题。具体执行者主要是开发人员，但如果测试人员有能力、时间和精力，他们也可以参与其中的一部分。在设计单元测试用例和执行方面，可以考虑如下几点：
-
• 测试人员和开发人员分清楚职责和边界
-
• 测试人员和开发人员对于用例设计颗粒度达成共识，给出相关标准
-
• 划定业务范围、优先级、实施阶段和执行频率
-
• 测试人员和开发人员制定的度量标准需要达成共识，如覆盖率、通过率、阻碍bug数等
API 自动化
从测试分层金字塔模型来说，API自动化测试是性价比最高的一种测试手段。在设计用例时需要如下思考：
-
• 确定要开展API自动化测试的业务范围
-
• 针对业务范围内的接口进行优先级排序
-
• 优先保障正向业务场景覆盖，逆向场景后面再进行考虑
-
• 明确 API 接口相关基础信息，如接口参数、业务逻辑及数据落库等信息
-
• 优先保证单接口进行，再考虑对接口串联的场景化
UI 自动化
先说 UI 自动化用例设计之前，我们聊聊哪些项目、场景适合开展 Ui 自动化测试，我们需要考虑如下情况：
-
• 需求比较稳定，不会频繁变更
-
• 比较频繁的回归验证和执行
-
• UI界面稳定，变动少
-
• 软件维护周期长，可持续性
-
• 项目进度时间比较充裕
-
• 被测系统开发较为规范，可开展性高
-
• 存在比较好的基础设施
UI层是直接面向用户的入口，我们的业务功能测试工作主要集中在这一层。在进行UI自动化时，应针对性评估和筛选适合的业务场景来设计用例。然而在实际工作实践中，很难完全满足上述条件。
一般来说只要满足下面几点，就可以开展UI自动化测试：
需求稳定，不会频繁变更
UI自动化测试面临的主要挑战是需求和UI的频繁变化。为适应新的改动，脚本需要不断修改和扩展，过多的修改可能导致投入产出比低，从而降低UI自动化测试的价值和意义。一种妥协的办法是选择相对稳定的模块和功能进行自动化测试，而对于变动较大或需求频繁变更的部分，则采用手动回归。
比较频繁的回归验证和执行
测试数据、测试用例、自动化脚本的复用高，只有高频的执行才能体现出价值所在。
软件维护周期长，可持续性
UI自动化测试需要稳定的需求、精心设计的自动化框架以及花费时间进行脚本开发和调试，这实际上是一个软件开发过程。如果项目周期较短且没有足够的时间去支持这一过程，那么自动化测试可能就不再必要。
被测系统UI设计较为规范，可开展性高
主要基于以下几点进行考虑：
-
• 系统UI的差异，不同的系统UI可能会影响自动化测试的效果和效率
-
• 测试工具的适应性，选择的工具是否能适应项目的需求和环境
-
• 测试人员的能力，他们是否能够快速掌握并应用相关的知识和技术。
设计用例需要注意什么？
我们始终需要遵循小步快跑、逐渐迭代的思维原则，先跑起来，进行验证再说。
由易到难，从简单到复杂
不同类型的自动化测试用例设计和实施，都是覆盖范围越大/粒度越小，投入成本越大， ROI递减的过程。
在如今的环境中，大部分企业都强调研发效益的提升和快速迭代的重要性。此时，我们不能再沉溺于“慢工出细活”的传统理念，反而应着眼于如何在更短的时间内，以更低的投入实现核心场景的全面覆盖，以达到快速验证的目标。我们要理智地看待覆盖率、案例数量等度量指标，不应过分追求这些表面的数字，而应关注其背后的真实价值和意义。
我们千万不要面向质量度量和KPI搞自动化测试，这样容易因小失大
可监控、可确认、可评估
在设计自动化测试用例时还应注意这些：
-
• 可监控：用例执行需要很方便的查看执行过程场景，非常清晰的展示相关数据及变化；
-
• 可确认：自动化用例必须要有断言，执行完成需要达到我们的目标
-
• 可评估：自动化执行的结果要可评估，例如通过率为 100%，代表当前功能没有问题
END今天的分享就到此结束了~！点赞关注不迷路！