学习biji
测试用例是围绕着需求文档进行编写，对需求不明确的地方是可以进行提出，但是确认后依据产品经理所说的为准每一条测试用例就是执行测试的最小维度的文档
编写测试用例的注意要点：；
1，测试用例包含着一些基础内容：
（1）用例编号：是对多条用例进行唯一的编号
（2）用例标题：简述本条测试用例的测试场景和测试目的，要求尽可能的唯一，要求是陈述句，要做到和预期结果首尾呼应，一般是以‘验证’开头，‘验证xxx操作，满足xxx结果’--验证输入正确的账号。正确的密码，登陆成功
（3）前置条件：描述测试执行之前需要准备的东西，作用是简化用例步骤，把一些重复执行的内容（不在测试范围的内容）进行简述
（4）用例步骤：对执行测试的步骤进行描述，一般不超过6步
（5）预期结果：对测试执行之后的结果进行预知，假设用例步骤执行后没有达到预期结果，可以判定这条用例测出bug
2，excel表格中换行：alt+enter
3，用例标题的编写要与预期结果首尾呼应
4，用最少的测试用例覆盖最多的有效等价类（正常场景）
5，一个无效等价类就是一条测试用例，一条测试用例不能同时覆盖多个无效等价类
6，对于‘不输入’的情况也要考虑无效等价类
7，在用例步骤中的测试数据需要使用“”括起来
8，用例步骤，前置条件，预期结果，如果使用了序号，那么每个序号后面需要标上标点符号，需要统一（, .、）
9，涉及到枚举值的场景，每个枚举值就是一个有效等价类，也就是需单独的一条测试用例。枚举值都要进行单独的测试用例验证
10，每一条测试用例体现的测试数据一般一条，不会出现‘或’
11，预期结果的编写，如果没有要求必要的返回信息，那么要简单描述对应的预期返回结果。如果需求中有明确各种返回的信息，那么就要进行逐一验证，要确保每个结果都得到了覆盖测试
12，时间类型的边界值，也是要验证上点（正常场景）和离点（异常场景），而且也要关注最小的单位
13，编写测试用例时，最好是先写覆盖正常的场景测试用例，再对相关模块的异常测试用例进行编写
14，不要把bug写成测试用例
测试点的分析思路？测试用例的分析思路？==》偏实际应用的思路
面试题：你给我讲一下xxx的测试点？
1，从页面讲起，检查页面的元素是否美观，信息的描述是否准确，页面的功能按钮是否都正常，操作是否简洁友好
2，接着从各种功能上展开描述，讲一个正常的接多个异常的（购物车加入商品功能：正常的商品有库存时是否能加入购物车，异常的商品库存为0时是否能加入购物车，选择数量大于库存量是否能加入购物车，选择数量超过购物车最大值是否能加入购物车）
3,接着从性能上思考，多人操作的情况，快速的连续提交的操作
4，从网络状态思考，弱网（网络差），无网络
5，如果涉及安全的，也要考虑安全的问题，一般是接口信息篡改的问题，有没有涉及一些敏感信息（有无做加密出来）
6，考虑兼容性的问题，软件是否适配不同的系统，不同浏览器，各种网络状态的适配
测试用例的分析思路？===》偏理论方面的一些思路
面试题：拿到一份需求后你会怎样设计测试用例？怎么保证测试的覆盖率===》通过测试方法方面去思考
拿到需求文档之后，我会先分析需求中说明的基本功能，然后对这些基本功能进行业务流程的梳理，进行设计测试用例，包括正常的主体流程和异常的分支流程。
如果涉及到状态转换的场景那么也会对这些场景进行设计测试用例，用于提高业务流程的覆盖情况。
对涉及到边界值的场景会使用到边界值分析法来设计测试用例。
然后也会根据自己对业务和系统的了解来设计测试用例。
如果需求里面的功能涉及到系统的故障恢复能力，容错能力，那么也会使用系统异常法进行设计一些系统异常情况下的测试用例。
如果需求中功能涉及到性能和安全方面的测试，也会设计相关的性能测试用例和安全测试用例
进行用例评审的流程：
首先先说一下自己本次任务的需求内容，让其他同事知道我对需求内容的了解程度（自己对需求的理解），一般是讲本次需求的业务流程，说明本次需求的改点。
接着就是讲解本次需求任务的测试场景和测试点（测试用例进行讲解）
会议结束后，会根据会议上，其他同事提出的点，对自己的测试用例进行修改或者补充
页:
[1]