来淘宝目前已经3周了，这三周只重复地做了一个事情，编写测试用例，修改测试用例。不断地修改让我对自己的语言组织能力和逻辑思维能力产生了怀疑，同时，越来越觉得测试用例的写法扑朔迷离。我问了3个人，结果每个人都告诉我不同的写法。把我自己弄的不知所措。但是问的多了，慢慢也就明白了，每个人都有每个人的编写风格，作为测试新人，我们要了解如何去编写测试用例，而不是copy别人的测试用例。只有真正了解了如何去编写，才能写出有自己风格的测试用例。
测试用例基本上都包括以下五部分：
1.前置条件
2.输入参数
3.执行步骤
4.校验点
5.期望值
这这是书写用例的一种形式而已。有些测试用例中，输入参数也可以省略掉。
重要的是设计测试用例、
刚接手工作还没有编写日常用例就跟进了一个项目，我负责的是实体管理和属性管理的增删改查，这样涉及到了页面。我也最先接触到了功能测试和接口测试。
其实知道现在我还是没有完全区分开这两个测试。我觉得在书写测试用例的时候两者是相似的。
只是功能测试一般是在页面上，接口测试则接触底层代码。当然，在接口中我也按功能点书写了功能性的测试。
书写接口测试测试用例的考虑点：
1，充分滴熟悉PRD（产品需求设计）
了解PRD，熟悉业务规则，根据业务规则来确定测试点。为了辅助理解产品的架构，可以画mm图，将需求分类。在编写用例的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。要明白哪些是核心功能！
2 .以下转载自http://qa.taobao.com/?p=5154
（测试用例的有效性）测试用例应该包含清晰的输入数据以及预期输出，没有测试数据的用例更多的是具有指导意义，执行过程中更多的是靠个人根据指导的自由发挥。但是看看我们的基线库更多的是这样指导意义的用例。（但是输入数据又涉及到了维护的问题，以及环境或者业务发生变更后引起的有效性问题）。对于预期的结果不能仅仅是页面上或者界面上的可见结果，如果和数据库发生了交互，必须包含数据库里准确的验证结果。用例基于数据驱动。
（测试用例的可理解性）测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语，测试用例应该按照增删改的顺序进行安排，这样执行的时候效率比较高，避免不必要的重复测试，用例写完不是就ok了，我们最好通读2遍，进行修改，让单条用例流畅。
（测试用例的清晰性）测试用例的验证点必须明确清晰重点突出，按照最新的用例标准，一个用例进行一个功能点的验证，一个萝卜一个坑。对于流程性的用例也是建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。
（测试用例的可维护性）我们的用例主要是基于web的，用例存在一定的变数。
因此在测试用例因为业务需求发生变更的时候，请及时修改，维护测试用例，做到测试用例的实时性与有效性，同时也方便后来的新人同学及时学习，不会产生误解与费解
【这里还应该有一个（测试用例的可重现性），这个在准备数据的时候要注意】
- Ross Collard在”Use Case Testing”一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。如果你在项目或者日常结束后，仔细的分析过我们的bug列表，那么你会觉的这句话非常适用。合理提高我们的测试效率就是在编写测试用例时进行测试用例优先级的划分。
- 1．<span style="color: rgb(255, 0, 0);">用于冒烟测试的用例为最高优先级</span>
- 2．<span style="color: rgb(255, 102, 102);">把基本路径以及各模块主功能的测试标注为高优先级别</span>
- 3．<span style="rgb(255, 204, 204);">把你所有错误和边界值或确认测试标注为中优先级别</span>
- 4．<span style="color:#CC33CC;">把可用性测试以及入口默认值校验等标注为低优先级别.</span>
- 5．<span style="color:#FF99FF;">将功能测试用例分为严重和不严重两类，对于不严重的功能测试用例降级为低优先级用例。</span>