测试用例设计总结
Posted 程序员二黑
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了测试用例设计总结相关的知识，希望对你有一定的参考价值。
一、什么是测试用例
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。
二、为什么要写测试用例
1、 理清思路，避免遗漏
理清思路是我们认为最重要的一点，有的系统本来就是一个大而复杂的项目，我们需要把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
2、 跟踪测试进度进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度，方便跟踪我们的测试进度。
3、 回归测试
首先我们的系统不是测一遍就完了的，我们需要在开发环境上测试，测试环境上还要进行回归，其次还有可能涉及到合并测试，而且也有可能会有不同的人在不同的阶段进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
4、 历史参考
在我们所做项目的各个版本中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
另外如果产品发布后出现了发布缺陷，测试用例也是分析发布后缺陷的依据之一。
三、如何编写用例
1、测试需求分析，得到测试点
在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析。
需求分析的主要工作就是：了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐藏的需求；在通过需求交底的过程，确定开发的初步实现思路和方法。随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一些测试可以提前介入的工作等。
需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。
2、分析得到用例优先级
得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优等级，一般分为高中低三个优先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。
3、细化测试点变成可执行case
根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。
根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。
在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
另外需要考虑的就是测试点细化到什么程度的问题，也就是一个度的问题，我们要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易让我们纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。
4、及时更新测试用例
需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。
另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。
5、及时维护通用测试用例
什么是通用测试用例呢？我理解的通用测试用例就是：项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。
当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。
所以说，通用的测试用例是一个对用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试用例，对后面的测试和用例维护有一个很大的指导作用。
四、如何提升用例编写能力
1、 熟悉业务，了解系统
任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。
任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题和业务问题。
2、 用客观的思考方式站在用户的角度分析
作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么，客户不想要什么，也就是所谓的客户的使用场景，这样有利于我们更好的挖掘和思考隐含的需求。
至于这个需求该不该做，那是需求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户基本不会用到的场景有哪些。
3、 多思考，不要拘束于惯性思维
我们知道一个人做一个工作时间越久，也就是我们说的经验越丰富，可能这个思维方式就会越被限定住。
比如，测试的统计表多了，当拿到一个新增的统计表的时候，首先想到的是公用用例上所列的测试点基本上就是最全的了，我都不用思考，直接用就行了。
其实这是一个误区，公用用例的目的是帮助我们减少一些不必要的内耗，但是我们的思维不要被它所限定，如果公用用例中某个点是错的，那我们岂不要一错再错了。
所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要被这种惯性思维束缚，不要被所谓的经验束缚。
4、 不要闭门造车，利用好网络资源
提升测试用例设计能力，多思考是非常重要的，但是不是让你傻思考，当你的进步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学习一些前辈的经验，并把这些运用到实际的测试用例设计中去。
山外青山楼外楼，多浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的测试用例设计能力的提升会有很大的帮助的。
5、 善于总结分享
基于以上四点我们还要做到善于总结，乐于分享，把经常见到的用例设计的误区和一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，不断提升我们的用例设计能力。
最后也给软件测试的朋友们分享一份测试资料：
以上内容，对于软件测试的朋友来说应该是最全面最完整的备战仓库了，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。关注我公众号：程序员二黑，免费获取！
机会只垂青有准备的人，这是一个靠本事的社会。有时候，你之所以发展得不好，不是因为没有机遇，而是因为你没有准备好，导致机遇与你擦肩而过。如果你想要学习，什么时候开始都不晚，而不是瞻前顾后，你只要用尽全力，剩下的交给时间！如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们扣扣群【785128166】，里面有各种软件测试资源和技术讨论。
加油吧，测试人！路就在脚下，成功就在明天！
推荐阅读
以上是关于测试用例设计总结的主要内容，如果未能解决你的问题，请参考以下文章