自学笔记
测试用例设计原则
一、测试用例设计原则
1、测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。
2、测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
不管是从个人角度还是从公司角度，根据我这几年的经验我觉得case的设计应该符合以下几点：
1、一个case一个功能点：每个case都要有个测点，找准一个测点则可，不能同时覆盖很多功能点，否则执行起来牵连太大；
2、case的易读：从执行者的角度去写case，最好不要有太多的术语在里面，如果要有最好指明具体位置；
3、case的执行粒度：粒度越小越好；
4、步骤清晰：一个case多个步骤，可一个重点，步骤指名人们怎么去操作，expect则指明这样操作之后应该看到什么结果---最好不要用正确，正常，错误之类的含糊主观的字眼。
5、总体设计：先正常，后异常，这样可以确保正常情况下功能能够走通。
总之：对于一个新来的tester，给他个case和我们的软件，他就能顺利取执行case，这是最佳状态，也是我们case设计的标准，按照这个标准，我想出了以上几点要求。
这样做的好处是：
1、执行者不会因为case看不懂再三的去烦扰你，你也不会因为时间长了，业务忘了，看不懂case；
2、如果原来的designer有事，公司可以很快请人顶上，测试可以继续进行，不会被block住；
3、执行case的人能更快的去掌握业务系统流程，不会因为要看懂一个case而大伤脑筋，更别说去真正的执行它了。
关注页面单个功能点验证，充分考虑开发改动的每个点。这个是保证开发每个已知的修改点都能改对。
二、关联
重点考虑修改点对其他模块的影响，包括代码的影响和操作数据引起的影响。
比如新增加的功能增加了数据库表的字段，必须关联的验证每个使用该表的该字段的模块是否正常工作。难点在于需要分析出已知和未知的影响模块，考虑的越多，往往遗漏的问题就越少。
比如：对边界值设计测试用例，应遵循以下几条原则：
1、如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2、如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。
3、根据规格说明的每个输出条件，使用前面的原则1。
4、根据规格说明的每个输出条件，应用前面的原则2。
5、如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
6、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
比如：等价类设计测试用例的原则
1、在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。
3、在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
5、在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
三、测试用例必要元素描述
测试用例编号：用来唯一标识测试用例的编号，由测试组根据具体情况统一管理。
测试用例级别：用来衡量测试用例的重要性，测试组根据具体情况制定统一标准。
测试需求或者测试需求编号：描述测试的目的是什么。
前置条件：运行测试用例必须的条件
测试用列的输入：简单的讲就是用来测试的数据
操作：就是在输入数据之后用户的操作，将会影响到测试的输出
输出：相应的期望结果。
用于黑盒的测试用例