测试工程师在需求评审中的主要职责是什么？
确认自己理解需求、无疑义
确认需求无明显错误、能够支撑后续的用例设计等
在需求分析的时候我们不仅要明白需求文档上的字面意思。最重的就是形成我们的测试点。
那这个时候，我们看需求文档。针对我们的需求，发现全是一堆文字。这里就很明显，没有办法用前面测试理论的某种方法，去进行测试用例的设计。那这个时候呢，我们只能说，按照我们这个从需求去拆分测试点的
思路。把一个个大一点的需求，拆分成一个个小的需求点。由一个小的需求点，形成一条条测试用例。当然在这个过程，我们可以针对某些需求，采用之前的方法，去进行一个补充。进一步的完善，如：等价类，边界
值。那这个时候方法就能用上了。
1.1 实战：购物车需求分析
1 这里我们测的是：”我的购物车” 这一个页面，而不是完整的购物车功能。
2 就算是我的购物车这一个页面，但也涉及到了5个部分（相当于sql的增删改查的功能）：
- 购物车的商品限制（商品的数量和总类）
整体性认识完了，所以我们接下来的一个分析过程，按照上面的5点内容，在xmind里进行一个整体的拆分。
在拆分之前，我们可以先整体感受一下，最终大概会被拆分成多少个点。下面是之前拆过的，我们大概能拆分成6-70多个测试点。差不多70-80条测试用例。如果你真的把这些都写完，你的测试用例绝对能超过刚开始
规定的200条测试用例。
反正不管到底有多少条，先按照我们的套路，一步步往前推进，我们先来看第一块内容：
我们来到需求文档中来看一下需求：
购物车显示需求点：（下面两个大点，两张图和第2点下面的7个小点都是。）
1.购物车没有商品，提示马上去购物。
2.购物车有商品，显示购物车内商品内容
-
1)商品对应价格应和加入购物车时一致。
-
2)小计：正确计算=单价*数量。
-
3)已选择:n件商品,其中n为选中商品件数总和。
-
4)合计：购物车中商品总价。
-
5)点击商品图片或者名称跳转商品详情页面。
-
6)点击【继续购物】跳转商品购物页面。
-
7)点击【去结算】跳转填写核对订单页。
第一个：购物车没有商品，提示马上去购物。
也就是这个时候，它会按照这个需求文档中的效果进行页面的一个展示。这是第一个需求：购物车没有商品的时候，应该怎么去显示。
第二个，我们继续往下读。购物车有商品，显示购物车内商品内容。那就是另外一种情况。会有7个小点。
有商品的时候，它展示是这个样子。
我们把这些需求点，转移（复制）到xmind中去。然后一个个分析。
需求点1：购物车没有商品，提示马上去购物（不需要拆分）
这个地方，相当于给了一个条件，一个结果。是不需要拆分的。
提炼测试点1：购物车没有商品，提示马上去购物。
理解：只要你的购物车是空的，我们测试的时候，只需要检查一下，购物车的这个页面效果是不是按照你这个设计图去显示的。
这个点就不需要拆分。我们在测试的时候，需要关注哪些东西呢？比如说我们需要关注这个效果图，在这个图上给大家一点提示。像做这种UI涉及结果的一个确认的时候。
比如下面图片涉及的三点：
1 文字：你的购物车还是空的，赶紧行动吧
这些文字是我们需要去确认的。
2 示意图：是空的购物车
这个部分是购物车空的，所以示意图是不是空的也要去确认
3 购物车按钮功能：在这个页面，马上去购物的按钮，应该是能够点击跳转的
这三个点，应该是属于这个需求点里面的，我们都需要关注到的基本内容
这条用例你可以不用拆开，但是你的测试关注点可以放在xmind中去强调一下。如下图。
需求点2：购物车有商品，显示购物车内商品内容（需要拆分）
它的显示效果也是有的：
购物车有商品，显示购物车内商品内容。需要测试的时候，具体需要关注的点中也明确了。有下面的7点：
1)商品对应价格应和加入购物车时一致。
2)小计：正确计算=单价*数量。
3)已选择:n件商品,其中n为选中商品件数总和。
4)合计：购物车中商品总价。
5)点击商品图片或者名称跳转商品详情页面。
6)点击【继续购物】跳转商品购物页面。
7)点击【去结算】跳转填写核对订单页。
我们需要根据这7点具体分析，看需不需要继续拆分。
需求点：1)商品对应价格应和加入购物车时一致。（不用拆分）
提炼测试点2：商品对应价格应和加入购物车时一致。
这个部分的价格要和商品的详情页或商品的列表页面价格要一模一样的。这是第一个点，不需要拆分。
需求点：2)小计：正确计算=单价*数量。一般这里也是不用拆分的。
但是会有一个小的细节，就是经验总结出来，这里还是要拆两个部分：数量为1和不为1的来两种情况。
提炼测试点3：小计：数量为1时，小计=单价
提炼测试点4：小计：数量不为1时 ，小计=单价*数量
需求点：3)已选择:n件商品,其中n为选中商品件数总和。（数量的确认，单独看不需要拆分。）
需求点：4)合计：购物车中商品总价。（可以拆分）
（第3个点和第4个点是可以合并在一起的。因为3决定了合计的总金额。我觉得重要的原因，是一步操作就完成，才可以把3和4合并的主要原因。）
提炼测试点5：商品种类为1时 ，合计 = 小计
需求点：5)点击商品图片或者名称跳转商品详情页面。（可以拆分）
提炼测试点7：点击商品图片，跳转商品详情页面。
提炼测试点8：点击商品名称，跳转商品详情页面。
需求点：6)点击【继续购物】跳转商品购物页面。（不用拆分）
提炼测试点9：点击【继续购物】跳转商品购物页面。
需求点：7)点击【去结算】跳转填写核对订单页。（不用拆分）
提炼测试点10：点击【去结算】跳转填写核对订单页。
需要把上面的落实在xmind上去：
购物车显示。总结它的10条测试点：
1：购物车没有商品，提示马上去购物
2：商品对应价格应和加入购物车时一致。
3：小计：数量为1时，小计=单价
4：小计：数量不为1时 ，小计=单价*数量
5：商品种类为1时 ，合计 = 小计
7：点击商品图片，跳转商品详情页面。
8：点击商品名称，跳转商品详情页面。
9：点击【继续购物】跳转商品购物页面。
10：点击【去结算】跳转填写核对订单页。
需求点2：购物车的商品限制
购物车的商品限制需求点：（a,b两点和两张图都是。）
a)单个商品数量最小为1，最大为200。小于1或者大于200时给出提示
b)购物车中商品类型数量最少为0（购物车为空），最大为20
把他们复制到xmind中来，然后再进行分析。看需不需要拆分
第一个是限制商品的数量的，第二个是限制商品的类型。既然限制 那肯定是可以用我们的边界值。限制，就说明是有一定的界限的。
需求点1：a)单个商品数量最小为1，最大为200。小于1或者大于200时给出提示（限制商品数量的）
数学表达式是[1，200]。如果小于1或大于200的时候，给出提示消息。具体提示什么，也在需求文档中也有图。上面我也贴出来了。
那针对这种情况，[1,200]，我们需要得到的点是哪几个点？我们会分别投入几条测试用例？分别是哪几条来测试这几个边界？
不做优化的情况下：0，1，2，20，199，200，201
0和201是我们测试异常的。所以必须存在。
1和200是输入最小和最大的值，也是要留下来的。
所以最终选择的就是：0，1，20，200，201（直接用那个离点的公式也可得出相同的数字）
需求点2：b)购物车中商品类型数量最少为0（购物车为空），最大为20（限制商品种类的）
我们还是需要用边界值，如果统一是5点，需要投入哪5个点来设计测试用例？
当我们不知道怎么选择的时候，就遵循基本的：边界值，边界值两边的，和一位中间的。实在难取舍也没有关系，大不了就多测两个。
0是需要留的。需求有购物车为空
20也是需要测试，最大为20。属于边界
21也是要留的，图片提示最大只能放20个
19属于边界里面的值，可以不要。
1需要，属于第一个有效值。 10需要，属于中间的值。1和10可以取舍一个，也可以都要。
-1不需要，因为在正常逻辑中，是不能加-1个商品的。所以-1是没有任何测试的必要性的。可以删除。
把他们落实到xmind中去：
注意：取点的时候，我们除了点之外，我们更多要结合需求里的提示消息（比如：图片中文字），这些提示消息的内容，都是我们在测试过程中必须检查的点。文字打错了，也属于bug。
购物车的商品限制。总结它的10条测试点：
a)单个商品数量最小为1，最大为200。小于1或者大于200时给出提示（可以拆分如下）
b)购物车中商品类型数量最少为0（购物车为空），最大为20（可以拆分如下）
需求点3：购物车添加商品
购物车添加商品三个需求点：
a) 从商品显示页面中通过【加入购物车】向购物车中添加商品。
b) 添加单个商品数量不能大于购物车单个商品最大限制。
c) 添加商品种类数量不能大于购物车商品种类最大限制。
把它们复制到xmind中去：
我们一一看看下它们能不能拆分：
先诵读一下上面三点的全部内容，有个大概理解：
a) 从商品显示页面中通过【加入购物车】向购物车中添加商品。
它是说从商品的显示页面去加入购物车，也就是你可以看到加入购物车这个按钮的地方去添加商品进来。我们要搞清楚有几个地方，可以加入购物车。或者说有加入购物车这个按钮。
b) 添加单个商品数量不能大于购物车单个商品最大限制。
也就是我们上面提到的那个限制
c) 添加商品种类数量不能大于购物车商品种类最大限制。
我们现在要搞清楚，我们添加购物车的渠道在哪，在哪能看到加入购物车，加入购物车一定不止在一个地方。那么在哪呢？
加入购物车（商品列表页和商品详情页都可以加入购物车）
1. 商品列表页面，就有加入购物车的入口。同时有加入购物车的数量。
首页——点击珠宝 （在商品的分类或者说商品的列表页面，比如说进入到某一个具体的商品分类，比如数卖珠宝的。）
下面就可以看到：商品列表页面，有加入购物车的入口。同时有加入购物车的数量。
2 商品详情页面，也有加入购物车，和调整购物车的数量
从上面的图片中点击商品，进入到 商品详情页面。也有加入购物车，和调整加入购物车的数量。
这是两个最典型的加入购物车的渠道。（如果还有，可以把它再归纳进来。）
我们可以在xmind中把这两点落实进来：我们需要从这两个不同的地方进行确认。
a) 从商品显示页面中通过【加入购物车】向购物车中添加商品。
我们落实到xmind中去：
b) 添加单个商品数量不能大于购物车单个商品最大限制。
那我们添加商品的数量限制，在这个地方去加进去的时候，虽然这个【-1+】的功能，它不应该是我们购物车这个地方来测试。正常来说，是由负责这个页面的人来测。但是它是不是通过这个【-1+】入口这
和购物车有关联关系的。所以你为了保证你这个功能（加入购物车）正常测试以外，也要确保影响你的这个功能点也是能够正常工作的。所以我们在【-1+】这个地方也要做一些测试用例的设计。
其实你不写它也是可以的，因为放到具体页面的时候，那个人一定也要测。但是你站在购物车的这个角度，从你这个商品进来的地方，你怎么进来的，你可以稍带去测一下，所有我们可以列一列。我们在列的过程中，
就会发现，实际上就是商品数量的限制。
商品数量的限制，实际上就是我们，可以把前面的拷贝过来，但是实际上这里还不是太严谨。原因就是：如果真正要测的话，还要考虑商品的库存。
这个库存，我们会把它放到后面，统一去考虑。为了严谨，我们要在xmind中加个条件：库存充足且大于等于200。
0个商品应该是加不进去的。
201加不进去，应该会有相关提示信息。
还是要在这里解释一下：
限制条件这一块的测试用例的设计不是强制的。严格意义上来说，因为它不属于购物车页面的这个功能。它是应该属于商品详情页和商品列表页的那个人去测试。在我这之所以去带这么几条测试用例，那是因为我站在
这一块去分析需求的时候，我知道会受到这两个地方的影响。所以我把这两地方的限制一块给测了。这个用例是写还是不写，你可以不写。但是你在点的时候，你可以点一下。
加入购物车，添加商品进来以后。添加一个，那我们在购物车页面就显示一个。添加两个，那我们在购物车页面就显示两个。你添加两种，那在购物车页面就显示两种。如下图：
不管你在哪一个渠道进来的商品，都会在我的购物车页面进行一个综合展示。
c) 添加商品种类数量不能大于购物车商品种类最大限制。
购物车商品种类最大限制，也是20。那20这个限制，我们在上面也测过了。说的其实是同一个事。
第3个点就不用管它了，那购物车添加商品的分析就到这里告以段落了。
购物车添加商品。总结它的测试点：
a) 从商品显示页面中通过【加入购物车】向购物车中添加商品。（可以拆分，加入购物车）
b) 添加单个商品数量不能大于购物车单个商品最大限制。（前面做过了，可以不写测试用例。但是可以需要点一点，测一下。）
c) 添加商品种类数量不能大于购物车商品种类最大限制。（前面做过了，可以不写测试用例。但是可以需要点一点，测一下。）
需求点4：购物车删除商品
购物车删除商品需求点：（下面三个）
a) 点击商品栏里操作中的【×】号后，购物车中对应商品被删除。
b) 勾选商品，点击【删除选中商品】，购物车中对应的选中商品被删除。
c) 勾选【全选】后，所有商品被选中，点击【删除选中商品】，所有商品均被删除。
把他们复制到xmind上去：
提炼测试点1：a) 点击商品栏里操作中的【×】号后，购物车中对应商品被删除。
第一种情况：你点击商品后面的这个叉叉。这个商品就会给删掉。
提炼测试点2：b) 勾选商品，点击【删除选中商品】，购物车中对应的选中商品被删除。
第二种情况，是你勾选商品，点击删除选中商品。那被选中的商品就会被删除。
提炼测试点3：c) 勾选【全选】后，所有商品被选中，点击【删除选中商品】，所有商品均被删除。
第三种情况：当你有两种以上的商品的时候，点击全选——点击删除选中商品。这两种商品都会给删掉。
在需求里面说的，你就是要有多个商品或者多种商品。你可以再加入一个商品。
购物车删除商品，从这三种情况来看，我们是不是可以通过每一次单一的操作就可以完成。那这个地方还需不需要一个测试点的拆解？答案是不需要的。
注意：第二种情况是需要注意的：b) 勾选商品，点击【删除选中商品】，购物车中对应的选中商品被删除。
这个地方你需要注意两个事情。一个是选中的被删除，另一个就是未选中的不能被删除。虽然这是一条测试用例。但是可以确认到这两个结果。如果你 没选的话，被删除了，那就出现了bug。
需要我们落实到xmind中去：
购物车删除商品。总结上面的3条测试点：
1. 点击商品栏里操作中的【×】号后，购物车中对应商品被删除。（不可拆分）
2.勾选商品，点击【删除选中商品】，购物车中对应的选中商品被删除。（不可拆分）
3.勾选【全选】后，所有商品被选中，点击【删除选中商品】，所有商品均被删除。（不可拆分）
- 未选中的商品不能被删除
需求点5：购物车编辑商品数量
购物车编辑商品数量需求点：（有两大点，两大点又分别有下面两小点）
1) 通过商品数量旁的【+】号和【-】号进行设置
-
a)不能小于最小值1，为1时【-】号不可用。
-
b)超过单个商品最大200或者达到库存量时【+】号不可用。
2) 通过修改编辑框中的数字，直接修改数量
-
a)直接编辑，数量值范围在1-200
-
b)编辑商品数量，不能大于库存
把他们复制到xmind中去：
购物车编辑商品数量：两个需求点的说明
1) 通过商品数量旁的【+】号和【-】号进行设置
a)不能小于最小值1，为1时【-】号不可用。
b)超过单个商品最大200或者达到库存量时【+】号不可用。
2) 通过修改编辑框中的数字，直接修改数量
a)直接编辑，数量值范围在1-200
b)编辑商品数量，不能大于库存
修改商品数量这件事情，有两种修改方式。分来来看（是这里面最绕的地方）
1 通过+ -号来调节你购买商品的数量。这是第一种方式。
2 通过在编辑框里面，输入数字，直接进行修改。
搞清楚这两个方式以后，我们看一下他们分别怎么调整数量。
1) 通过商品数量旁的【+】号和【-】号进行设置
a)不能小于最小值1，为1时【-】号不可用。
实际上还是测边界，但这个时候测边界的时候，它的关注点放在哪里呢？
放在【- +】号可不可用的问题，可用的意思，你可以【+】，往上调节商品的数量，你可以【-】号，往下修改商品的数量。下面是不可以的情况，这个按钮是没有东西的，一个灰的，你是点不了的，它是不起作用
的。这是一个不可用的状态，那接下来，就是围绕这个【- +】可不可用来作文章了。
关于这两个小按钮【- +】可以作文章，我们来看一下。
1) 通过商品数量旁的【+】号和【-】号进行设置
a)不能小于最小值1，为1时【-】号不可用。
b)超过单个商品最大200或者达到库存量时【+】号不可用。
我们刚才留了一个小尾巴，我们的边界到底在哪儿呢？
这个地方出现了一个新的东西：库存量
库存量在哪，决定了我们的边界到底是谁？库存量有两种情况。
我们之前购物车添加商品的边界是：【1,200】
第一种就是：库存量<200时，比如数库存量是150
库存量<200时，假设库存量=150时，我们的边界是就是【1,150】。如果库存量是100，我们的边界就是【1,100】
第二种就是：库存量>200时，比如数库存量是300
如果库存量是300，这时候我们的边界就是【1,200】。相当于你库存是充足的，但是我们这个网站给你限制了，最多也就能给你200个，多了你也买不了。这就是一个库存量>200的情况。
这就出现了两种典型的情况，这个库存量在我分析用例之前，这个图要先搞清楚。这个地方明白了，后面就很好懂了。
更好的理解上面的内容：
1. 库存量<200时，你网站限制200，你没有和库存量作比较，人家下了200，你这个单怎么出呀，人家要200个，你给不了，你说没有库存，你就出问题了。
2. 库存量>200时，库存量充足的情况下面，那也不是你说要一万个就给你一万个。因为网站有限制，最终也就一次出货200。
我们现在要分情况来分析了
1) 通过商品数量旁的【+】号和【-】号进行设置
a)不能小于最小值1，为1时【-】号不可用。（这个地方就不用拆了）
除非你这个卡在了极端的情况，这个库存量等于1，那就没有意义了。假设我们的库存量是在一个合理的取值，比如：100,200,300（不太懂）
1. 不能小于最小值1时，也就是0。
0是加不进去的，在输入框里输入0，是会有下面的提示信息：商品数量必须大于0
在默认的情况下面，【-】号是不可用的，【+】号是可以用的。直接可确认这个结果。
1) 通过商品数量旁的【+】号和【-】号进行设置
b)超过单个商品最大200或者达到库存量时【+】号不可用。（我们前面说了这么多，也就是为了这个超过200的边界情况。）
200：【+】号不可用。关注的点：
201：【+】号不可用
150：【+】号不可用。关注的点：
151：【+】号不可用。关注的点：
这里是把上面的拷过来，然后改了一下数字。但是这里还是可以做下优化的。
我们假设这里是库存量是150。边界是149，150，151。如果让这个更通用，可以写成边界为：
落实到我们的xmind中去：
2) 通过修改编辑框中的数字，直接修改数量
b)编辑商品数量，不能大于库存
它的边界值，分为两种情况：
注意：输入框这里，我们刚才注重的是边界，其实我们还可以做非法测试。比如：字符串，汉字。也是可以加进来的。（这里我没有添加进来。）
购物车编辑商品数量：总结一下它的测试点：
1) 通过商品数量旁的【+】号和【-】号进行设置
a)不能小于最小值1，为1时【-】号不可用。（不用拆分）
b)超过单个商品最大200或者达到库存量时【+】号不可用。（可以拆分两种情况）
2) 通过修改编辑框中的数字，直接修改数量
a)直接编辑，数量值范围在1-200（可以拆分如下）
b)编辑商品数量，不能大于库存：（可以拆分两种情况）
理解：在第2点（a，b）中是需求说明书中的点：
2) 通过修改编辑框中的数字，直接修改数量
a)直接编辑，数量值范围在1-200
b)编辑商品数量，不能大于库存
我的理解是就是，他这样写。是因为两个部分有重复的地方就给省略了。没必要一个功能同样的数据重复测试。
测试组长、经理（第一负责人、管理经验）
概念：是指描述了要进行的测试活动的范围、方法、资源和进度的文档。
（我们跳过写计划这个事情，没有什么好说的。只是让事情有进度，有安排的去推进。）
3、设计测试用例与评审
先看一下：我的购物车，下面有5个模块
先到项目里面去捋一下。
启动下项目，在桌面双击phpStudy.exe。叉掉，下面出现这个图标，说明启动成功。
首先想问一个点，我的购物车这个页面，需不需要你登陆后才能看到，你加入购物车这个行为，需不需要登陆。
如果不付款的情况下，是不需要登陆的。所以在前置条件下，会出现来两种情况，用户是登陆状态，还是非登陆状态。
我们课上分析的那些点，你比如说写了40条用例。那你是想要刷用例数量，你可能还需要看一下，用户登陆的情况，还有用户非登陆的情况。你可能最后会得到2倍的用例数。
第一种：用户未登陆状态
我们看一下，在没有登陆的情况下，可以从前面的页面里，将商品加入购物车。一样可以调节购物车数量。
但是你点击上面的——去结算。就会显示去登陆。所以前面是属于未登陆的一大类情况。（它会把游客加入到购物车的商品，保存在浏览器里面。除非你把浏览器的缓存给清掉了，它才没有了。）
第二种：用户已登陆状态
这种情况就是前置条件是用户已登陆的状态。
登陆好后，就到了购物车这个页面
进入到我的购物车里面去，我的购物车——去购物车结算
已经开始测试用例的设计。（为了更有效率，这里拿别人写好的测试用例，来进行修改和完善。）
我们来看一下xmind的需求：
再继续看一下需求文档的内容
第一点，提示语：您的购物车还是空的，干净行动吧！
这里需要确认的是：必须字还有符号，还有换行都需要一模一样。
第二点：确认购物车的框框必须是空的
第三个：确认这个按钮：马上去购物 （是不是能动的一个问题。）
那这里有个问题：这里是需要写一条测试用例。还是写三条测试用例。其实这里两种情况都是可以的。下面就把它写成一条测试用例来看看
测试用例001：1.购物车没有商品，提示马上去购物。
测试标题：购物车没有商品时，提示马上购物
测试数据：购物车为空（也可以作为预置条件）
1.打开浏览器，输入商城前台地址：localhost
2.点击登录，输入正确的用户名与密码
3.点击【我的购物车】快捷入口
4.删除购物车中所有已选商品
5.观察购物车为空时，页面展示效果
6.点击【马上去购物】
1.系统提示语为【您的购物车还是空的，赶紧行动吧！】
2.购物车图示展示内容为空
3.页面跳转至商品展示页面
这里只是设计测试用例，还没有执行。所以先不写内容。
这里有个问题：在项目中，需求文档里会有预期结果吗？答案是没有的。
预期结果是根据需求文档分析出来的。测试的时候，你看的见得，摸得着的，都是你需要去确认的。在需求文档里明展示的这么一张图，但是你要把图里面，逐一去确认这个内容，转化为你测试的预期结果。甚至有的
时候，它的预期结果，在这个明面上都没有，随着我们熟练度的不断提升以后，进一步的把它不断完善。
看到文字，你一定要去确认文字的内容。
UI设计图标，图标展示什么样，那最终在系统里面看到的就应该是什么样子。
（人眼去比对这两张图，是一样的就OK，不一样的话，就不OK）
按钮，这个功能需要去确认它能不能用。
继续往下走，就会出现购物车有商品的
购物车有商品，它有很多种情况。都会在下面模块逐一去确认到。那放在购物车显示这个地方的话，我们只需要去确认。比如说，有一个商品，或者说有两个商品。就相当于说有一个前置条件。去确认这里面不同种
的情况。在这一块需求（7个需求）里面，我们重点就是需要去确认的是，实际上面就是有三个点：
第一个点：它加入前后价格是不是保持一致的。
（大家想一下，你买一个东西。加入到购物车以后，你比较关注的点是什么？你是不是关注，你加进来的数量对不对，买东西的钱，是不是你之前看到的。你在外面看到的是9毛9，结果进来以后结成99。那这种东
西，你是不是非常关注。）
第二个点：它的小计金额的计算。
第三个点：你会重点关注，我买了多少个商品。我要付多少钱。
这三个点就是比较核心的点。
围绕这三个点，实际上面就可以更改成：
第1条测试用例：就是加入信息，展示的一个确认 需求是：商品对应价格应和加入购物车时一致。
继续，就是我们的一个小计金额的一个确认。小计金额分为两种情况，计算公式结果确认的两种情况：
第2条测试用例：你加入了一个商品。小计金额的计算
第3条测试用例：你加入了商品数量不是一个，大于1个。小计金额的计算
继续，就是合计金额的确认。针对合计金额我们确认有两种情况。
第4条测试用例：我只买了一种东西，合计金额=小计金额（比如：我只买了水）
第5条测试用例：我买了多种商品，合计金额=小计金额1+小计金额2+小计金额3（我买了水，面包，零食，花）
设计到按钮和操作的确认
第6条测试用例：点击商品图片，跳转商品详情页面。
第7条测试用例：点击商品名称，跳转商品详情页面。
第8条测试用例：点击【继续购物】跳转商品购物页面。
第9条测试用例：点击【去结算】跳转填写核对订单页。
我们开始写测试用例了：看下面第二条测试用例
测试用例002：2.购物车有商品，显示购物车内商品内容
测试标题：购物车有商品时，商品对应价格应和加入购物车时一致。（确认什么，什么就是你的标题）
测试数据：购物车有商品
测试步骤：（你的步骤怎么写，就按你的操作来。）
1.打开浏览器，输入商城前台地址：localhost
2.点击登录，输入正确的用户名与密码
3.选择一件商品（如，价格为200元）并加入购物车
4.添加成功后，点击【去购物车结算】按钮
5.检查加入购物车的商品价格
购物车中商品的价格（如，显示为200元）等于商品展示页面的商品价格。
这里只是设计测试用例，还没有执行。所以先不写内容。
注意：添加成功后，点击去购物车结算也是可以到达购物车页面的。
其实除了价格，还可以确认前后一致的点。比如说：商品缩略图，商品名称，市场价，单价，购买价。
你可以在测试用例，测试标题里写购物车有商品时，商品信息应和加入购物车时一致。在预期结果里写：商品缩略图，商品名称，市场价，单价，购买加入前后一致。（但我的测试用例就没写了。懂了就行。）
我们继续写测试用例，看下面两条测试用例
测试用例003和004：确认小计金额，分为两种情况（放在测试数据里）：
测试标题：验证购物车页面小计计算公式（标题重复，可以合并）
购物车有1个商品（gwc-003）
购物车有大于1个商品（gwc-004）
测试步骤：（复制前面的，再修改。突出重点，可以在excel里面用有颜色的字体）
1.打开浏览器，输入商城前台地址：localhost
2.点击登录，输入正确的用户名与密码
3.选择一件商品（如：单价为200元），设置购买数量为1，并加入购物车（gwc-003）
3.选择一件商品（如：单价为200元），设置购买数量为5，并加入购物车（gwc-004）
4.添加成功后，点击【去购物车结算】按钮
5.检查加入购物车的商品,小计金额
这里只是设计测试用例，还没有执行。所以先不写内容。
可以把前面两条测试用例合并成下面的一条测试用例：gwc-005
测试用例005：确认小计金额，分为两种情况合并在一起：
测试标题：验证购物车页面小计计算公式（标题重复，可以合并）
测试步骤：（复制前面的，再修改。突出重点，可以在excel里面用有颜色的字体）
1.打开浏览器，输入商城前台地址：localhost
2.点击登录，输入正确的用户名与密码
3.选择一件商品（如：单价为200元），设置购买数量为1，并加入购物车
4.添加成功后，点击【去购物车结算】按钮
5.检查加入购物车的商品,小计金额
6.设置购买数量为5，检查购买小计金额
6.小计金额=单价*数量
这里只是设计测试用例，还没有执行。所以先不写内容。
购物车的显示，在前面讲过了。
购物车删除商品，没什么好说的。3种情况，3条用例去确认就可以了。
购物车编辑商品数量，是可以单独拿出来讲的。
购物车的商品限制和购物车添加商品。本质就在这个地方：
问：大家只需要注意一下，你限制的这个商品数量的时候，这个商品到底是加的进去，还是加不进去。加不进去，别强加。那这种情况不存在的话，那这条测试用例应该怎么处理?
再添加商品的时候，应该考虑一下库存。库存充足大于200，可以放在预置条件里面来。
购物车商品数量为0的时候，为0的那种情况能不能限制的住，这个标题就没办法确认太明细的结果。可以加一下【商品数量必须大于0】
我们测的是一个限制，我们把需求往下看的时候，你会发现，我实际上是限制谁呀？实际上就是限制我去编辑或者添加商品这两种情况。
不管你是哪种情况，都需要遵循我限制的一个规则。
1 你可以选择加减号去调整（这个设置不了0）
2 也可以直接通过购物车去加
3 也可以选择在输入框去输入对应商品数量（我们采用这个设置0）
不管你用的哪种情况，都可以
这条测试用例，在测试步骤里面，有两点需要注意的是（第3步和第4步）：
1. 要告诉人家，怎么调整数量。
2. 在调整之前，你的购物车里面是什么样子的。
库存>=200，这一列的测试用例都不用写了。都是一个套路。
再写一个，购买商品数量为20的时候。
关于数量，这两种情况，就能概括其他几条测试用例。就不说了。
同样，对数量一个限制的测试用例，实际上适用于对种类的一个限制测试。
答：对于购物车种类为21，这条测试，实际上根本就测不到。你不可能添加21种商品进去。它测不到的情况下面，这条测试用例你可写，也可不写，你写了以后，最终这条测试用例，是不会被执行的。你可把这条试
用例标灰，它不存在，你还不如把它删掉。但我们分析的时候，一定要有分析的过程。
购物车删除商品，很简单。
包括，调节加减号的时候，大家要注意一下，同样一个套路，你要告诉人家，加之前，减之前，是多少。通过你这次加，这次减，来明确你具体变成了多少。这样就可以确定加减号到底能不能用，不能仅仅在靠灰就判
断它能不能用，它亮了，它就能用。我们要验证这个按钮对应功能。
比如说你这里199+1，这里就要显示为200，这就表示真的能加。
关于购物车部分其他用例，都能靠前面的套路整理出来。
注意：我们对数字12345比较敏感，对文字一二三四五不怎么敏感。不管是序号，还是测试用例里面涉及到数字的就写数字12345。
比如说，我们有条测试用例，是21这条测试用例，加不进去，可以写，然后标灰。也可以直接删除。但要有这个分析过程。（后面也会讲到）
1.用例标题写的不好，感觉很怪
2. 预置条件和测试数据不会全是/
2）全是进入localhost，按照这个步骤是进不了对应的测试模块。如果不能清楚表明步骤，写的就没有意义了。
1. 用例标题：有无，有无，是否（这种东西很奇怪）
我们在标题里面明确的是我们的测试点。当你的条件给定的时候，结果是肯定的。它的结果来源于需求说明书里。有就是有，无就是无，没有，有无这种说法。
第一条测试用例，标题：购物车为空，有无提示语。可以修改成：
购物车为空，给出提示消息。消息是什么，写在预期结果里。
（要是无提示消息就是Bug了。）
2. 像这种是没有办法成为用例标题的。因为看不懂你标题想表达的意思。
比如第二个：可以修改成
从购物车添加n件商品，确认商品金额=3*商品单价（你在明确的条件下，得到一个明确的结果。）
3. 预期结果写的不是很明确。比如这里都是写：添加成功。这样写是不对的。
我们放在一个具体的功能里面，我们需要很清晰的结果来支撑我们判定它，到底是对还是不对。
比如说：这里添加20个商品，我们在这里最终确认到了，就是在购物车页面里有20个商品被添加成功了。（这个20很关键）
设定的是多少，看见的就应该是多少。否则就有问题了。
4. 预期结果里写：可用。那怎么证明+号是可用的
你怎么证明加号可不可用？应该加一个看出它数据的变化
1. 可以看到加号是亮的
2. 在步骤里说点击加号。那就确认它的和。这商品的数量有没有由原来的1变为2.
这样我们才能确认这个加号是可不可用的。
购物车有商品时，商品对应价格应和加入购物车时一致。
