测试用例梗概（二）

编写测试用例的基本方法（二）

一、正交表法
原理
正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最高生产工艺效果，这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格—正交表来安排试验并进行数据分析的方法。正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交表具备均衡分散的特点，保证了全面实验的某些要求，这些试验往往能够较好或更好的达到实验的目的。
正交实验设计包括两部分内容
第一：怎样安排实验
第二：怎样分析实验结果
应用场景
在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法
判定表，因果图也是考虑控件组合，但是组合数量较少（一般不会超过20中）
公式：Ln(mk)
k是表的列数，表示控件的个数（因数个数）
m是每个控件的取值个数（因数水平）
n是表的行数，也就是需要测试组合的次数
正交表查询地址：https://www.york.ac.uk/depts/maths/tables/orthogonal.htm
正交排列法：http://support.sas.com/techsup/technote/ts723_Designs.txt




正交表法的特点是什么？
1、用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
2、对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
3、体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
二、测试用例评审和变更
测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。
（1）评审
1.测试用例本身的描述是否清晰；
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗(rong)余性，都造成了效率的低下；
3.是否针对需求文档，测试用例是否覆盖了所有的软件需求；
4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。
优点：
测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个快速提高用例设计能力的过程。
需要评审的原因
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。
进行评审的时机
一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。
参与评审人员
这里会分为多个级别进行评审。
1)部门评审，测试部门全体成员参与的评审。
2)公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3)客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
评审内容
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2)优先极安排是否合理。
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5)是否已经删除了冗余的用例。
6)是否包含充分的反面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。
7)是否从用户层面来设计用户使用场景和使用流程的测试用例。
8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
评审方式
1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2)通用邮件与相关人员沟通
3)通用IM(办公通讯)工具直接与相关人员交流
方式只是手段，得到其它人员对于用例的反馈信息才是目的。
无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。
评审结束标准
在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。
评审检查项
（1）《需求规格说明书》是否评审并建立了基线？
（2）是否按照测试计划时间完成了用例编写？
（3）需求新增和变更是否进行了对应的调整？
（4）用例是否按照公司定义的模板进行编写？
（5）测试用例是否覆盖了《需求规格说明书》？
（6）用例编号是否和需求进行对应？
（7）非功能测试需求或不可测试需求是否在用例中列出并说明？
（8）用例设计是否包含了正面、反面的用例？
（9）每个测试用例是否清楚地填写了测试特性、步骤、预期结果？
（10）步骤/输入数据部分是否清晰，是否具备可操作性？
（11）测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？
（12）测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法？是否针对需求不同部分设计使用不同设计方法？
（13）重点需求的用例设计是否至少使用了三种设计方法？
（14）每个测试用例是否都阐述预期结果和评估该结果的方法？
（15）需要进行打印、表格、导入、导出、接口是否存在在打印位置、表格名称、指定数据库表名或文件位置；表格和数据格式是否有说明或附件？
（16）用例覆盖率是否达到相应质量指标？
（17）用例预期缺陷率是否达到相应质量指标？
（2）测试计划
一场对所有软件BUG展开的歼灭战
确定测试范围
制定测试策略
测试资源安排
-------测试时间、工作量、人员
-------由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试
进度安排
-------最好能预留一段缓冲时间，用于应对计划的变更，以及让测试员有时间完善和补充测试用例
风险及对策
-------可考虑建立后备机制

三、软件缺陷和软件缺陷种类
定义
软件缺陷，常常又被叫做Bug，从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

格蕾丝·赫柏（Grace Murray Hopper），是一位为美国海军工作的电脑专家，也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字，正是由赫柏所取的。1947年9月9日，赫柏对Harvard Mark II设置好17000个继电器进行编程后，技术人员正在进行整机运行时，它突然停止了工作。于是他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞蛾，并把“bug”来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。
软件缺陷的种类划分
1、功能不正常
　　简单地说就是所应提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是根本无法使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格说明书中规定的功能无法运行，或是运行结果达不到预期设计。最明显的例子就是在用户接口上所提供的选项及动作，使用者操作后毫无反应。
2、软件在使用上感觉不方便
　　只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题。所谓好用的软件，就是使用上尽量方便，使用户易于操作。如微软推出的软件，在用户接口及使用操作上确实是下了一番功夫。有许多软件公司推出的软件产品，在彼此的接口上完全不同，这样其实只会增加使用者的学习难度，另一方面也凸显了这些软件公司的集成能力不足。
3、软件的结构未做良好规划
　　这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件，在功能的规划及组织上比较完整，相反以自底向上的组合式方法开发处的软件则功能较为分散，容易出现缺陷。
4、提供的功能不充分
　　这个问题与功能不正常不同，这里指的是软件提供的功能在运作上正常，但对于使用者而言却不完整。即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，也必须从使用者的角度进行思考，这就是所谓的“从用户体验出发”。
5、与软件操作者的互动不良
　　一个好的软件必须与操作者之间可以实现正常互动。在操作者使用软件的过程中，软件必须很好地响应。例如在浏览网页时，如果操作者在某一网页填写信息，但是输入的信息不足或有误。当点击“确定”按钮后，网页此时提示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，或直接放弃离开。这个问题就是典型的在软件对操作互动方面未做完整的设计。
6、使用性能不佳
　　被测软件功能正常，但使用性能不佳，这也是一个问题。此类缺陷通常是由于开发人员采用了错误的解决方案，或使用了不恰当的算法导致的，在实际测试中有很多缺陷都是因为采用了错误的解决方法，需要加以注意！
7、为做好错误处理
　　软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误，就是因为程序本身对于错误和异常处理的缺失。例如被测软件读取外部的信息文件并已做了一些分类整理，但刚好所读取的外部信息文件内容已被损毁。当程序读取这个损毁的信息文件时，程序发现问题，此时操作系统不知该如何处理这个情况，为保护系统自身只好中断程序。由此可见设立错误和异常处理机制的重要性！
8、边界错误
缓冲区溢出问题在这几年已成为网络攻击的常用方式，而这个缺陷就属于边界错误的一种。简单来说，程序本身无法处理超越边界所导致的错误。而这个问题，除了编程语言所提供的函数有问题之外，很多情况下是由于开发人员在声明变量或使用边界范围时不小心引起的。
9、计算错误
　　只要是计算机程序，就必定包括数学计算。软件之所以会出现计算错误，大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0.
10、使用一段时间所产生的错误
　　这类问题是程序开始运行正常，但运行一段时间后却出现了故障。最典型的例子就是数据库的查找功能。某些软件在刚开始使用时，所提供的信息查找功能运作良好，但在使用一段时间后发现，进行信息查找所需的时间越来越长。经分析查明，程序采用的信息查找方式是顺序查找，随着数据库信息的增加，查找时间自然会变长。这就需要改变解决方案了！
11、控制流程的错误
　　控制流程的好坏，在于开发人员对软件开发的态度及程序设计是否严谨。软件在状态间的转变是否合理，要依据业务流程进行控制。例如，用软件安装程序解释这类问题最方便直观。用户在进行软件安装时，输入用户名和一些信息后，软件就直接进行了安装，未提示用户变更安装路径、目的地等。这就是软件控制流程不完整导致的错误问题。
12、在大数据量压力下所产生的错误
　　程序在处于大数据量状态下运行出现问题，就属于这类软件错误。大数据量压力测试对于Server级的软件是必须进行的一项测试，因为服务器级的软件对稳定性的要求远比其它软件要高。通常连续的大数据量压力测试是必须实施的，如让程序处理超过10万笔数据信息，再来观察程序运行的结果。
13、在不同硬件环境下产生的错误
　　这类问题的产生与硬件环境的不同相关。如果软件与硬件设备有直接关系，这样的问题就是数量相当多。例如有些软件在特殊品牌的服务器上运行就会出错，这是由于不同的Server内部硬件了不同的处理机制。
14、版本控制不良导致的错误
　　出现这样的问题属于项目管理的疏忽，当然测试人员未能尽忠职守也是原因之一。例如一个软件被反映有安全上的漏洞，后来软件公司也很快将修复版本提供给用户。但在一年后他们推出新版本时，却忘记将这个已解决的bug-fix加入到新版本中。所以对用户来说，原本的问题已经解决了，但想不到新版本升级之后，问题又出现了。这就是由于版本控制问题，导致不同基线的merge出现误差，使得产品质量也出现了偏差。
15、软件文档的错误
　　最后这类缺陷是软件文档错误。这里所提及的错误，除了软件所附带的使用手册、说明文档及其它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计PD、UI Spec等的错误。错误的软件文档内容除了降低产品质量外，最主要的问题是会误导用户！
软件缺陷的属性
按照严重程度分
一般分为5个等级:
系统崩溃，严重，一般，次要，建议
按优先级分
修正优先级：高，中，低
Bug定级示例
（1）1级，系统崩溃
定义：严重阻碍测试和开发工作
对应优先级：最高
具体可分为：
1.功能完全没有实现
2.应用闪退/崩溃无法运行
3.应用必现安全模式，无法运行
4.其他导致功能无法测试的问题
（2）2级，至关重要
定义：非阻碍用例执行的严重问题
对应优先级：高
具体可分为：
1.简单操作应用闪退/崩溃，卡死
2.数据丢失
3.严重影响系统，自身功能无法运行
4.严重数值计算错误
5.数据库损坏或无法保存配置
6.安全性问题（包括数据加密等）
（3）3级，主要
定义：功能存在缺陷，但不影响应用和系统的稳定性
对应优先级：中
具体可分为：
1.内存泄露（长时间不用的对象需要被回收，不被回收占内存）
2.功能实现逻辑覆盖不全面
3.非必现，但复现概率超过50%的闪退/崩溃和安全模式
（4）4级，一般
定义：对应用熟悉度高才能感知到的问题，对应用基本功能实现无影响
对应优先级：中
具体可分为：
1.轻微数值计算错误
2.功能实现有误，与产品文档不完全贴切
3.用户简单操作，即可明显感知的UI问题
（5）5级，较小
定义：界面，性能缺陷
对应优先级：低
具体可分为：
1.操作界面错误（提示显示规则，刷新规则是否与文档一致）
2.边界条件显示错误 　 　 　
3.提示信息和界面效果展示错误（包括未给出信息、信息提示错误等）
4.复现率低于5%的闪退/崩溃和安全模式 　 　 　
5.插件兼容和性能未优化问题 　 　 　
6.非正常操作导致UI显示异常
（6）6级，建议
定义：对于产品的意见或者建议
对应优先级：低
具体可分为：
1.对于产品设计方面的意见和建议
2.对于产品界面优化方面的意见和建议
3.对于产品需要优化增强用户体验方面的意见和建议
按照测试种类分
逻辑功能类，性能类，界面类，易用性类，安装，兼容性类
按照功能模块分
注册，登录，购物车，分类，订单，个人信息
软件缺陷类型


按照解决方案划分

按照Bug生命周期
新建，确认，解决，重新验证，关闭，重新打开

缺陷报告(Bug报告，提的Bug)


Bug的处理

四、测试用例执行和故障管理流程图