测试用例设计思路举例(参考)
测试用例的例子
测试用例的例子
以下是 9 条关于测试用例的例子：
1. 你知道吗，就像医生给病人做全面检查一样，咱测试软件也得设计各种测试用例。
比如说，登录功能，得试试不同的用户名和密码组合，这可不就跟试钥匙开不同的锁一样嘛！
2. 哎呀，测试用例就好比是游戏里的关卡设计呀！比如测试一个购物车功能，要添加商品、删除商品、修改数量等等，这多像一道道关卡等着我们去突破呀！
3. 嘿，你想想，测试用例不就像是为软件挖陷阱，看它会不会掉进去！像测试网页的响应时间，设定个很慢的网络环境，看看它会不会卡顿，这多有意思啊！
4. 哇塞，你觉得测试用例像不像给软件设的一道道难题！比如说测试一个图片上传功能，用各种奇奇怪怪的图片格式，看它能不能应对，这不是跟刁难它一样嘛！
5. 咦，测试用例不就像给软件准备的一场场考试嘛！比如测试软件的兼容性，在不同的操作系统上运行，看它能不能通过，这跟我们考试有啥区别呀！
6. 嘿呀，测试用例可以说是软件的试金石呀！就拿测试一个表单提交来说，必填项不填、输入超长字符，这就是在考验它的坚韧程度呢，不是吗？
7. 哇哦，测试用例不就是探索软件的秘密武器嘛！像测试一个搜索功能，输入各种模糊的关键词，看它能不能找到想要的结果，这多刺激呀！
8. 哈喽呀，测试用例简直就像是在给软件做体检呢！比如测试一个支付功能，模拟各种支付失败的情况，看它怎么处理，这不是在仔细检查它的健康状况嘛！
9. 所以说呀，测试用例真的超级重要啊！它们能让软件的各种问题无所遁形，能让我们的软件变得越来越好！。
测试用例设计思路举例(参考)
ECShop2.7.2用例设计思路举例说明用例设计方法的运用非常灵活，没有绝对的套路可言，以下用例设计思路仅供参考。
操作流程举例参考文档：✓ECShop_2.7.2_简易操作手册V1.0，✓B2C商城ECShop需求规格说明书_2.7.2V1.0设计思路：根据操作手册，理清业务逻辑前后关系，再结合SRS文档确定具体的流程细节和分支流程。
可以通过画流程的方式梳理流程（流程分析法），下面是部分主流程的案例：✧正向订单流程_余额付款1)前台页面浏览商品->加入购物车->结算中心->余额付款2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货->发货3)前台页面确认收货END✧正向订单流程_货到付款1)前台页面浏览商品->加入购物车->结算中心->货到付款2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货✧逆向订单流程1）前台页面确认收货->后台管理中心退货->填写退货信息点确定按钮->确认退货✧商品添加流程_新商品1）后台管理中心商品管理->新建商品类型/新建商品分类/新建商品品牌->添加新商品（通用信息，详细描述，其他信息，商品属性，商品相册，关联商品，配件，关联文章）考虑完所有流程后，再补充考虑部分异常情况，例如：流程中的先后顺序发生变化，或者跳过某个步骤后，系统能否完成后续流程作业。
（有些流程是不可能调换顺序或跳过的）Q：流程分析法在设计测试用例的时候会经过很多页面，操作很多字段，这些页面和字段该如何取值呢？A：流程分析法一般考虑页面或字段的有效取值（一般取等价类中最不容易出错的值），测试过程中不关注页面输入域的各种取值情况，特别是错误取值的情况。
目的是为了确保流程是可用的。
Q：流程分析法既然不能证明某个页面或字段没有问题，那用此法有何意义呢，为何不直接考虑验证每个页面和模块的各种有效和无效的取值？A：流程分析法可快速熟悉系统业务，确保系统主要功能是否实现，是非常重要的测试方法，如果流程分析法都走不通，那该系统的测试工作将遇到更多阻碍。
功能测试的用例设计思路
功能测试的用例设计思路功能测试用例设计思路：一场探索之旅功能测试就像是一场对软件功能的探索之旅，那设计用例就好比绘制探索的地图。
这地图画得好不好，可直接关系到咱们能不能把软件的功能摸得透透的。
咱先说这输入方面。
你看，软件就像个大盒子，输入就像是往这个盒子里丢东西。
如果这个盒子是个计算器，那输入数字就是最基本的操作。
咱得考虑各种各样的数字啊，正数、负数、零，就像生活里有高个子、矮个子和不高不矮的人一样。
咱不能只测试正数，就觉得这个计算器的加法功能没问题了呀。
要是只测了1 + 1 = 2，那万一人家输入 -1 + 1呢？这结果可就不一样了。
这就好比你去超市买东西，只看了苹果的价格，没看香蕉的价格，那能行么？再看看边界值的测试。
这就像是在走钢丝，你得找到那个最边上的点。
比如说，一个输入框要求输入1到100之间的数字，那1和100就是边界啊。
这就像你在一个有围栏的院子里玩，围栏就是边界，你得看看在围栏边上会发生什么。
是能稳稳站住呢，还是会掉出去？要是这个输入框，你输入0或者101会怎样？会不会弹出个友好的提示，还是直接系统崩溃了？这就好比你站在院子的围栏上，是会有个小警告说“别出去啦”，还是直接掉进沟里呢？功能的组合测试也特别重要。
这就像是做菜，一道菜里有好几种食材，每种食材单独吃是一个味道，组合在一起又是另一个味道。
软件里的功能也是这样，一个功能单独运行没问题，和其他功能一起运行的时候呢？比如说，一个文档编辑软件，有保存功能和加密功能。
你先保存了一个文档，然后加密，再保存一次，这过程中会不会有什么问题？会不会保存的时候把加密信息弄丢了？这就像你做蛋糕，先放了面粉，再放鸡蛋，然后又放了一次面粉，结果发现蛋糕没发起来，那肯定是哪里出问题了呀。
还有异常情况的测试。
这就像是给软件来个突然袭击。
软件正运行得好好的，突然断网了，会怎样？就像你正在打电话，突然信号没了，你肯定希望手机能给你个提示，而不是直接死机吧。
测试用例的设计方案-边界值法例子
测试用例的设计-边界值法边界值分析也是一种黑盒测试方法，适度等价类分析方法的一种补充,由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。
因此针对各种边界情况设计测试用例，可以查出更多的错误。
选择测试用例的原则：一、如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据；二、如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1格、比最小个数少1个的数做为测试数据；三、根据规格说明的每一个输出条件，使用规则一；四、根据规格说明的每一个输出条件，使用规则二；五、如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例；六、如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例；七、分析规格说明，找出其他可能的边界条件。
边界值法举例找零钱最佳组合假设商店货品价格 (R) 皆不大於 100 元（且为整数），若顾客付款在 100 元内 (P) ，求找给顾客之最少货币个（张）数？（货币面值 50 元 (N50) ， 10 元 (N10) ， 5 元 (N5) ， 1 元 (N1) 四种）一、分析输入的情形。
R > 1000 < R < = 100R <= 0P > 100R<= P <= 100P < R二、分析输出情形。
N50 = 1N50 = 04 > N10 >= 1N10 = 0N5 = 1N5 = 04 > N1 >= 1N1 = 0三、分析规格中每一决策点之情形，以 RR1, RR2, RR3 表示计算要找 50, 10, 5 元货币数时之剩余金额。
R > 100R <= 0P > 100P < RRR1 >= 50RR2 >= 10RR3 >= 5四、由上述之输入／输出条件组合出可能的情形。
正交实验法设计测试用例例子
正交实验法设计测试用例例子正交实验法（Orthogonal Experimental Design）是一种设计测试用例的方法，通过合理选择测试用例，可以有效减少测试工作量，提高测试效率。
正交实验法的核心思想是通过一定的设计原则，选择一组具有独立性和均匀性的测试用例，以覆盖系统的各个方面，从而发现系统中的问题。
以下是使用正交实验法设计测试用例的一些例子：1. 网页登录功能测试：通过正交实验法设计测试用例，测试网页登录功能的正确性和稳定性。
测试用例包括用户名和密码长度的不同组合、是否输入正确的用户名和密码、是否支持记住密码等等。
2. 购物车功能测试：通过正交实验法设计测试用例，测试购物车功能的正确性和稳定性。
测试用例包括添加商品到购物车的不同顺序、添加不同数量的商品、删除商品、修改商品数量等等。
3. 文件上传功能测试：通过正交实验法设计测试用例，测试文件上传功能的正确性和稳定性。
测试用例包括上传不同类型的文件、上传不同大小的文件、上传多个文件、上传文件的同时进行其他操作等等。
4. 数据库查询功能测试：通过正交实验法设计测试用例，测试数据库查询功能的正确性和性能。
测试用例包括查询不同条件的数据、查询不同数量的数据、查询数据的同时进行其他操作等等。
5. 网络连接功能测试：通过正交实验法设计测试用例，测试网络连接功能的正确性和稳定性。
测试用例包括连接不同类型的网络、连接不同网络的速度、在连接过程中进行其他操作等等。
6. 手机应用程序测试：通过正交实验法设计测试用例，测试手机应用程序的正确性和稳定性。
测试用例包括不同操作系统的手机、不同型号的手机、在不同网络环境下使用等等。
7. 网络游戏测试：通过正交实验法设计测试用例，测试网络游戏的正确性和稳定性。
测试用例包括不同操作系统的电脑、不同网络环境下使用、同时进行其他操作等等。
8. 电子邮件发送功能测试：通过正交实验法设计测试用例，测试电子邮件发送功能的正确性和稳定性。
优秀的测试用例案例
优秀的测试用例案例一、正常登录情况。
1. 测试用例名称：使用正确的用户名和密码登录。
测试步骤：打开登录页面。
在用户名输入框中输入已经注册好的正确用户名，比如说“超级飞侠”。
在密码输入框中输入对应的正确密码，就像给超级飞侠输入它的秘密指令“123456abc”。
点击登录按钮。
预期结果：页面成功跳转到用户的个人主页，能看到类似“欢迎回来，超级飞侠！”这样的欢迎语，并且可以看到个人信息、功能菜单等只有登录后才能看到的东西。
二、边界值情况。
1. 测试用例名称：使用最短允许的用户名和密码登录。
测试步骤：进入登录页面。
输入系统允许的最短用户名，假如是3个字符的“abc”。
输入系统允许的最短密码，比如6个字符的“123456”。
点击登录按钮。
预期结果：成功登录，进入到和正常登录一样的个人主页，显示欢迎语等相关信息。
2. 测试用例名称：使用最长允许的用户名和密码登录。
测试步骤：打开登录界面。
输入最长可接受的用户名，假设是20个字符的“这个用户名超级超级超级长1234567890”。
输入最长可接受的密码，像是30个字符的“这个密码超级超级长abcdefghijklmnopqrstuvwxyz123”。
按下登录按钮。
预期结果：顺利登录，显示个人主页和欢迎信息，没有任何报错提示。
三、异常情况。
1. 测试用例名称：用户名不存在登录。
测试步骤：来到登录页面。
在用户名框里输入一个根本没注册过的名字，例如“不存在的大侠”。
在密码框里随便输入一串字符，像“888888”。
点击登录按钮。
预期结果：页面弹出提示框，上面写着“用户名不存在，请重新输入或者注册”之类的话，并且停留在登录页面，不允许进入个人主页。
2. 测试用例名称：密码错误登录。
测试步骤：打开登录窗口。
输入一个正确注册过的用户名，比如“勇敢小战士”。
但是在密码框里输入错误的密码，像是“错误密码123”。
点击登录按钮。
预期结果：弹出提示框，显示“密码错误，请重新输入”，页面保持在登录界面，不能进入个人主页。
测试用例的案例分析
测试⽤例的案例分析⼀、测试⽤例经典案例1：纸杯的测试⽤例规格：（1）能放多少⽔，是否符合需求。
（2）底盘直径是多少，是否符合标准。
（3）存放时间和存放的环境。
（4）不能装哪些液体。
性能：（1）底盘是否平稳。
（2）是否会漏⽔（时间、温度、液体<兼容性测试>）。
（3）是否容易变形，硬度是否⾜够（压⼒测试）。
（4）是否环保，是否会产⽣化学反应，产⽣有毒物质（安全测试）。
（5）从不同⾼度摔下来的损坏程度（压⼒测试）。
界⾯：（1）界⾯设置是否吸引客户。
（2）是否有相应的提⽰。
（3）图标布局是否合理。
（4）纸杯上的字体是否美观，是否有错别字。
（5）纸杯的图标、⽂字等印刷是否完整。
（6）图案是否容易脱落。
⼈性化：（1）⽔杯的⼿感如何，⼝感如何（易⽤性）。
（2）是否有利于叠在⼀起存放，使⽤时是否容易分开。
（3）外观是否适合拿起。
2：购物车的测试⽤例界⾯：（1）打开淘宝购物车页⾯后，页⾯的布局是否合理，是否完整。
（2）不同卖家的商品在不同的区域显⽰，区分是否明显。
（3）页⾯的功能按钮是否可以正常显⽰。
（4）商品的最下⽅是否可以显⽰失效宝贝。
（5）页⾯的最低端是否显⽰“你可能喜欢”。
（6）向下滑动页⾯，在购物车顶端是否展⽰购物车。
（7）购物车中如果存在有商品降价、库存不⾜、限购件数等，在商品详情下⾯，是否有对应字体展⽰。
功能：（1）购物车页⾯的所有连接是否正常。
（2）从商品信息页⾯添加的商品是否能显⽰在购物车中。
（3）如果没有登录，点击购物车中的商品直接进⾏结算，是否会提⽰⽤户输⼊⽤户名和密码，或者提⽰⽤户进⾏注册。
（4）如果没有选择任何商品时，点击结算，是否提⽰⽤户“请添加要结算的商品”。
（5）勾选商品后，已选商品的总价和优惠满减活动是否会显⽰。
（6）勾选商品，点击结算按钮后，是否可以进去确认订单信息页⾯。
（7）购物车页⾯中，是否可以对添加的商品信息进⾏修改，并⾃动保存成功。
（8）是否可以在购物车中重新修改商品规格。
测试用例实例-三角形用例设计
14
【3，4，3】
（1），（2），（3），（4），（5），（6），（15），（19）
15
【3，3，4】
（1），（2），0）
10
【3，4，3】
（1），（2），（3），（4），（5），（6），（15）
11
【3，4，5】
（1），（2），（3），（4），（5），（6），（16）
非等腰三角形
12
【3，3，3】
（1），（2），（3），（4），（5），（6），（17）
是等边三角形
13
【3，4，4】
（1），（2），（3），（4），（5），（6），（14），（18）
输入条件
有效等价类
无效等价类
是否三角形的三条边
（A>0），（1）
（B>0），（2）
（C>0），（3）
（A+B>C），（4）
（B+C>A），（5）
（A+C>B），（6）
（A≤0），（7）
（B≤0），（8）
（C≤0），（9）
（A+B≤C），（10）
（B+C≤A），（11）
（A+C≤B），（12）
是否等腰三角形
（A=B），（13）
（B=C），（14）
（C=A），（15）
（A≠B）and（B≠C）and（C≠A）（16）
是否等边三角形
（A=B）and（B=C）and（C=A）
（17）
（A≠B），（18）
（B≠C），（19）
（C≠A），（20）
序号
【A，B，C】
覆盖等价类
输出
1
【3，4，5】
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ECShop2.7.2用例设计思路举例
说明
用例设计方法的运用非常灵活，没有绝对的套路可言，以下用例设计思路仅供参考。
操作流程举例
参考文档：
✓ECShop_2.7.2_简易操作手册V1.0，
✓B2C商城ECShop需求规格说明书_2.7.2V1.0
设计思路：
根据操作手册，理清业务逻辑前后关系，再结合SRS文档确定具体的流程细节和分支流程。
可以通过画流程的方式梳理流程（流程分析法），下面是部分主流程的案例：
✧正向订单流程_余额付款
1)前台页面浏览商品->加入购物车->结算中心->余额付款
2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货->发货
3)前台页面确认收货END
✧正向订单流程_货到付款
1)前台页面浏览商品->加入购物车->结算中心->货到付款
2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货
✧逆向订单流程
1）前台页面确认收货->后台管理中心退货->填写退货信息点确定按钮->确认退货
✧商品添加流程_新商品
1）后台管理中心商品管理->新建商品类型/新建商品分类/新建商品品牌->添加新商品（通用信息，详细描述，其他信息，商品属性，商品相册，关联商品，配件，关联
文章）
考虑完所有流程后，再补充考虑部分异常情况，例如：流程中的先后顺序发生变化，或者跳过某个步骤后，系统能否完成后续流程作业。
（有些流程是不可能调换顺序或跳过的）
Q：流程分析法在设计测试用例的时候会经过很多页面，操作很多字段，这些页面和字段该如何取值呢？
A：流程分析法一般考虑页面或字段的有效取值（一般取等价类中最不容易出错的值），测试过程中不关注页面输入域的各种取值情况，特别是错误取值的情况。
目的是为了确保流程是可用的。
Q：流程分析法既然不能证明某个页面或字段没有问题，那用此法有何意义呢，为何不直接考虑验证每个页面和模块的各种有效和无效的取值？
A：流程分析法可快速熟悉系统业务，确保系统主要功能是否实现，是非常重要的测试方法，如果流程分析法都走不通，那该系统的测试工作将遇到更多阻碍。
流程分析的用例非常适合作为系统测试预测试（冒烟测试）项的用例，也可以作为回归测试或验收测试的用例。
订单查询举例
参考文档：
✓B2C商城ECShop需求规格说明书_2.7.2V1.0 订单查询2.4.2章节
设计思路：
对于查询部分的用例设计先考虑正交表，再考虑等价类和边界值填充具体取值是比较合适的，先考虑对不同查询条件的组合查询，然后为正交表补充单个查询的情况，然后再补充什么都不填，和全部都填的情况。
Q：此页面下拉列表取值可考虑选择或不选择两种情况，如果选择，下拉列表中取什么值呢？A：下拉列表的取值按照等价类和边界值的思想得出的具体取值应该是选择第一个，选择中间一个，选择最后一个。
按这样的思路，将这三种取值逐一替换到正交表该字段为选择的每行中。
（替换后若还有行没有替换完，可自行选择替换任意值，也可替换最容易出现问题的值等）
Q：上述查询条件之间是什么关系，例如输入张三的订单号，电子邮件确输入李四的，点击查询按钮，系统同时查询出张三的订单和李四的订单，还是一条都查不出来？
上述字段是否支持模糊查询，需求中没有明确告知，该如何写用例呢？
A：查询条件若在SRS中没有明确给出，在评审阶段应提出和询问需求分析人员或项目经理，若到了测试用例编写期间，依然可以咨询需求分析人员或者开发人员，确定查询关系。
查询关系不明确该部分的用例很难写出。
（记住你不是一个人在孤军奋战，遇到问题要和开发，测试等成员加强沟通）
Q：是不是所有的查询都要用正交表呢？
不是，例如查询条件只有2个，判定表即可。
若查询条件均为必填项，就不存在非必填的情况，直接用等价类+边界值方法即可。
商品添加举例
参考文档：
✓B2C商城ECShop需求规格说明书_2.7.2V1.0 添加新商品2.4.1.5章节
该页面有多个输入条件，输入方式包括：文本框输入，下拉列表选择，复选框，日历控件，浏览上传图片。
共17项，其中含3个必填项。
可以考虑等价类+边界值+正交表的方式完成测试用例设计。
方案一：先考虑等价类+边界值，再考虑组合（正交可选），最后考虑异常分析和错误猜测法。
方案二：若用例设计方法较为熟悉，也可先考虑正交表的组合，在取值的时候用等价类和边界值取具体的数据填充，最后考虑异常分析和错误猜测法。
Q：在写用例的时候除了常规的方法，对错误猜测法不知道如何运用，总是想不出有要考虑些什么，如何能很好的运用错误猜测法呢？
A：通常情况下错误猜测需要经验的积累，如何积累经验才是值得考虑的问题。
例如每次按测试用例执行的时候总会发现一些用例未考虑到的缺陷，这其实就可以作为错误猜测的用例总结起来，今后遇到类似问题在写用例时就可以考虑进去了，积少成多很重要。
Q：界面中有3个必填字段，用正交表该怎么处理呢？不填的话肯定是通不过的。
A：此问题有两种处理方案，一种是只要正交表中遇到该字段为非必填就去掉该行，不考虑该行的用例编写。
（该方法可能导致组合数量大幅度降低，遗漏风险加大，）；另一种是遇到正交表中该字段为非必填的，直接替换成必填，不删除该行。
（此方法可以加大覆盖力度，降低漏测风险）。
用哪种方法可依据实际情况灵活考虑。
Q：是不是所有的输入条件都要考虑组合呢？
A：不是，同查询条件类似，若输入条件较少，考虑判定表；若大多字段都是必填字段，用等价类+边界值即可，无需使用正交表。
展示页面举例
有些页面仅有展示效果，无法对页面进行功能操作，此类页面的测试主要是核对显示信息是否与数据原始来源页面要求一致，页面样式是否符合要求，并不需要运用特定的用例设计方法，在测试策略中可以描述为手工验证。
例如前台订单信息页面，如下所示：
1：对比需求说明书中提及的字段（不少，也不多）:
2：可以考虑数据库字段与前台页面展示效果的一致性
3：前台展示与后台操作一致。