对于一个软件测试人员来说，编写测试用例是不可或缺的一项技能，但怎么写好一个需求的测试用例却不是很容易，特别对于新手来说，更是不容易，我也是从新手一步步走过来的，下面我就把我的经验总结出来供大家参考吧。
测试用例是什么
这个问题很简单但却不能不知道，刚入行，我们会很懵，弄清楚这个问题，对我们接下来写测试用例非常有帮助。
测试用例顾名思义就是用来测试的例子，但这个例子却不是随便的，而是通过我们分析后精心设计出来的，是我们测试的一个标准。
书写结构要符合规范
测试用例不仅是我们测试的例子，还是我们软件功能的一个详细描述，一个好的测试用例，不仅仅是自己能看得懂、测试场景全面，还要能让别人看得懂，让别人通过你的测试案例能对你所测试的那个功能有一个全面的了解和认识。
所以测试用例的书写也不是随便的，它有一定的结构。一般有以下几部分组成：
测试用例名称
这个一般是在你写多个需求测试功能点时用它来标记你当前写的是哪个功能测试点的用例，比如你正在写登录账号的测试用例，你就可以在这一栏写上账号登录测试。
测试用例描述
这个一般是对你当前所写测试用例功能点进行一个简单的描述，让人一眼能看出你这个是在测试哪个点。
还拿上面的登录测试来说，我们就可以这样写：输入正确的账号、正确的密码、登录成功。
测试前置条件
前置条件一般就是指在你接下来的操作之前要做的准备工作。
比如有一个需求是这样的：当订单所选国家对应的是否汇总物料的字段标识为Y时，就把这个订单下的所有备件物料汇总到一起，否则不时进行汇总。
那么在我们写这个测试用例的时候，它就有一个前置条件就是所选国家是否汇总物料的标识为Y或N。
测试操作步骤
测试步骤这个很简单，就是把我们执行测试的操作一步步写下来，这个一定要写清楚，方便后来人查阅和学习。
期望结果
就是你在前置条件下执行当前测试用例步骤后得到的一个正确的结果也就是你想要的结果就是期望结果。
了解需求的背景、开发实现方案
为什么要了解需求背景和开发实现方案？了解需求背景可以帮助我们分析哪些应用场景是合理的，哪些是不合理的，哪些场景是涉及到此需求的，我们接下来的测试用例写的才能更接近实际应用。
那如何了解需求背景，一般是从需求提出人那里了解，有的是从产品经理统一了解，这个要根据不同公司的不同安排进行了解。
了解开发实现方案有助于我们从代码层面和实现逻辑上来识别一些潜在的风险问题，同时也给我们测试用例提供更清晰的思路和场景。
开发实现方案的一般是通过开发设计评审，有的公司没有这个步骤，那只有自己主动跟开发小哥沟通了，只有这个了解清楚了，你才能更清楚的知道功能的实现输入和相应的输出是否正确，才能提前识别期望结果与需求提出人的结果是否一致，你的测试用例写得场景才能更全面。
掌握必要的测试用例设计方法
测试用例设计方法也是编写测试用例不可缺少的一部分，掌握一定的测试用例设计方法有助于我们分析测试场景。
不同的需求不的功能实现点要用不同的方法进行分析设计。
一般来说有做比较判断或分类的，在比较判断这个点上常用边界值分析和等价划分方法来分析设计。
有逻辑判断的或功能较复杂的就要用因果图法，正交实验法等这些（这些方法网上都有详细的介绍我就不详细说了）。
比如一个需求功能是这样的：根据报销单中出差人员的出差的城市进行判断所提交的报销金额是否超标。
这里面有一个隐藏的信息就是出差城市和报销金额的对应的关系，这个是在后台的一张表中，这张表结构是这样的：
类别城市名称金额
类别标记这个城市是一类城市还是二类城市，金额就是报销限制金额。
从上述的信息中我们可以看出这个既有分析还有比较判断，所以我们这里要用到边界值分析法和等价划分来分析设计场景。
边界值来分析金额比较的场景,等价划分来划分城市分类，所以得出的分析场景如下几个：
·一类城市，报销金额小于给定金额
·一类城市，报销金额大于给定金额
·一类城市，报销金额等于给定金额
·二类城市，报销金额小于给定金额
·二类城市，报销金额大于给定金额
·二类城市，报销金额等于给定金额
充分考虑功能、性能、安全问题
这个是测试用例编写一个比较重要的点，无论是你做哪个功能软件测试都要考虑这几个点，一般的话我会从这几方面考虑：
在我们了解清楚我们的需求功能以后，一般按照上面这个思路去设计我们的测试场景都是比较全面的。
比如在一个原有的网页上面新增一个查询库存产品余量的功能。
查询条件有：1.产品名称；2.产品型号。
两者可组合查询。
查询结果展示有：
产品名称、产品型号、库存余量、出库总量。
这是一个很简单的查询功能，通过分析我们知道：
数据存于本地数据库表中，直接取的就是一张叫产品余量表里面的数据。
由于产品种类型号比较多，存在单个产品名称查询时数据量比较大的情况。
因为是在原有网页上新增的功能，网页的安全性不需要考虑，但查询接口的安全需要考虑。
由于是新增功能影响到页面布局，所以要考虑易用性和兼容性。
查询功能可能会存在多人同时查询和一个人多次频繁查询的情况，所以性能这块要需要考虑并发，和频繁操作的场景。
基本场景分析完了，我们就可以根据我们上面所说的考虑点列我们的测试场景了，如下：
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
