一、软件测试点的定义
在进行需求分析时，我们会列出所有的测试点，以便清晰地梳理出需要测试的所有方面。
二、何时编写测试点，何时编写测试用例？
如果项目紧急且时间不足，可以先分析测试点，节省编写测试用例的时间，保证测试质量。后续再补充具体的测试用例。如果时间充足，则按照正常的测试流程编写测试用例。
三、测试用例的九大要素
用例编号：如DL_001, ZC_001（可以自己编号，如果有工具，工具一般会自动生成这个编号）
测试项目：对应一个功能模块（细分功能）
测试标题：直接对测试点进行细化，输入内容+结果，同一功能模块标题不能重复
重要级别：高/中/低
预置条件：需要满足一些前提条件，否则用例无法执行
测试输入（数据）：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）
操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
预期结果：根据预期输出比对实际结果，来判断被测试对象是否符合需求（预期结果唯一，不能出现“是否或者”）
实际结果：
四、如何保证用例覆盖度
覆盖显性需求：确保需求文档上的所有功能都被覆盖。
获取隐含需求：通过竞品分析、与业务沟通、站在用户角度分析等方式获取隐含需求。
合理使用用例设计方法：如等价类划分、边界值、场景法。
用例评审：借助开发、产品、业务从不同的角度来提高用例的覆盖度，包括不同人员负责模块交叉部分。
五、测试中的风险及如何把控风险
需求理解偏差：确保对需求的理解没有偏差。
测试人员水平不足：提高测试人员的水平，确保他们能够全面覆盖测试点。
时间不足：合理安排时间，确保测试能够完成。
测试环境不足：提供充足的测试环境，确保所有测试点都能被完全测试。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
扫一扫
902
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
