编写测试用例

测试用例编写是软件测试的基本技能；也有很多人认为测试用例是软件测试的核心；软件测试中最重要的是设计和生成有效的测试用例；测试用例是测试工作的指导，是软件测试的必须遵守的准则。

总体编写策略：
对于测试用例编写来说，常用的四种方法基本就够用了，等价类、边界值、正交实验法、错误推断法，辅以场景测试法、需求/设计转换法、探索式测试思想，可以应付绝大多数产品的测试。个别的产品还需要在某一点细化和扩充，需要就事论事。

使用各种编写方法的综合设计策略：
1)在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2)必要时用等价类划分方法补充一些测试用例，尤其注意无效等价类情况。
3)如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法（或判定表法、正交试验法）。
4)用错误推测法再追加一些测试用例，主要是利用测试经验。
5)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
6)对程序的应用场景进行研究和思考，增加不同场景下的测试用例；用户场景测试必须重视，很大一部分程序错误就是因为测试场景与用户真实场景的差异性带来的。
7)对业务和程序有更深的理解之后，可以充分发挥发散思维和探索式想法；大家不要误解探索式测试就是漫无目的的测试，其实探索式测试有非常详细的测试指导思路。
等价类
等价类：选取少数有代表性的数据，这一类数据等价于这一类的其它值；找出最小的子集，可以发现最多的错误；
两大特性：必须设计的用例；涵盖了大部分情况；
两类情况：有效等价类；无效等价类；
转化为测试用例
1、按照输入条件、有效等价类、无效等价类建立等价类列表，列出所有的等价类；
2、为每一个等价类固定一个编号；
3、设计一个测试用例，使其覆盖一个或多个有效的等价类；
4、设计一个或更多的测试用例以覆盖剩余的有效等价类；
使用场景：输入条件（取值范围/值个数；必须值集合；布尔值；一组处理值；必须遵守的规则；再细分更小等价类；）
边界值
边界值：所谓边界条件，是指输入和输出等价类中那些恰好处于边界、超过边界、或在边界以下的状态 ；
两个特征：选择一个或多个元素，以便等价类的每一个边界都经过了测试；与仅仅关注输入条件不同，还需要考虑结果空间（输出等价类）设计测试用例；
使用场景：输入+输出都需要考虑（值的范围；值个数；有序集合；内部数据结构；分析规格说明；）
因果图
因果图：输入条件的组合进行分析。用一个系统的方法选择出高效的测试用例集；
分析思路：
1、分析规格说明描述，确定原因和结果，并赋予标识符；
2、分析规格说明语义，找出原因与原因之间，原因与结果之间关系，画出因果图；
3、有些原因与原因之间，原因与结果之间组合不会出现，用记号表明约束或限制条件；
4、因果图转换为判定表；
5、判定表的每一列作为依据，设计测试用例；
使用场景：必须考虑输入条件的各种组合（一种适合于描述多种条件的组合、相应产生多个动作的形式来进行设计）
判定表
判定表：分析和表达多逻辑条件下执行不同操作的情况的工具 ；略过因果图的绘制，直接列出所有组合进行筛选；
分析思路：判定表通常有四个部分组成：条件桩、动作桩、条件项、动作项；
判定表的建立步骤：（根据软件规格说明）
确定规则个数；列出所有条件桩和动作桩；填入条件项；填入动作项，得到初始判定表；简化合并相似规则；
使用场景：控制类和游戏。优点是能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。缺点是不能表达重复执行的动作，例如循环结构。
需求转换法
需求转换法：根据需求，执行需求分析，并编写测试用例。
分析思路：
将需求转换为思维导图；
仔细推敲每一个字的含义；
与用户的使用场景和目的结合；
严格设计每一个用例；
可以建立一种模型，进行需求转换；
使用场景：任何测试、任何情景下都会用到的方法。
注意：需求的变更带来的影响；需求理解偏差带来的影响；需求含糊不清带来的影响等；
设计文档
设计文档：参照设计文档，可以理解软件系统内部设计流程及处理机制，对比写好的测试用例，可以在对应功能及模块处新增；
分析思路：
仔细阅读设计文档；
与相关人员沟通实现机制；
结合测试用例编写方法，对比之前写好的用例；
使用场景：任何测试、任何情景下都会用到的方法。
注意：设计文档的编写正确性；设计文档的理解偏差；

上图是我刚刚编写的，写了一个简单的登录模块下的账号密码、验证码登录部分测试用例。
一般情况下，功能性测试文档直接使用该模板就能满足大部分的需求。
在编写测试用例之前，你得想好有哪些前置条件。这些前置条件满足了才能达到你得预期。比如账号密码登录，前置条件是账号和密码同时正确才能正常登录成功。那么此时你就得编写条件不符的时候，是否也会成功。如果成功了，那就属于BUG，需要技术进行修复。

一般正常情况，请考虑一下几个方面
1、页面布局是否合理，如导航栏上面应该显示三个按钮，实际上却显示了两行。
2、页面文字描述是否准确，如气泡提示：密码格式错误，请重新输入。实际上却显示：账号密码错误。
3、如果有加载规则，是否符合加载规则。如：进入页面加载20条内容，实际上却加载了10条。
4、如果有排列规则，是否符合排列规则。如应按照时间倒序排列，实际上却是正序排列。
5、操作是否符合要求，如单击某个点，是否准确跳转或显示内容。如本应该进行跳转，实际上却未进行跳转。
6、输入框输入的内容是否有符合格式要求。如：账号不允许"，"，而实际上却允许了。
7、输入的内容是否符合合法性要求。如：账号密码是否一致等问题。等等这些基本考虑内容都需要考虑进来。

大概理清楚需要考虑的内容之后，就可以开始动手写了。
1、序号： 不用说，就是按顺序下去的。
2、模块：该功能点具体属于哪个模块的，填写这个主要是方便查找，如：注册/登录模块。
3、编号：对每个用例进行编号，方便后期跟进。毕竟用文字说，容易口误。不过此处建议编号设计的有点规则，方便快速定位查找。如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。
4、功能点：具体指某个功能，如：账号登录、首页、发布等。
5、子功能点：具体指功能点，如：账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
6、用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。
7、前置条件：指要达到预期测试结果，需要满足那些条件才能达到。如：账号密码不一致时，就需要登录失败，那么此时就得保证账号正确或密码正确以及账号正确时是存在的。
8、操作步骤：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。
9、预期结果：说明按照前面写的应该呈现出怎样的结果。
10、测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO。
11、结果描述：如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。
12、测试人员：填写测试人的名字，方便后期跟踪BUG。
13、测试日期：填写测试的时间，方便后期查询。
14、BUGID：跟测试编号一样，自己设定ID规则，方便快速查询。
15、BUG负责人：具体落实到某个人身上，才能更好的解决到问题。
以上就是测试用例的具体填写方法及作用，测试完了之后，记得进行回归测试以确保测试的意义。