一、测试用例的概念和作用
以最少的人力，最少的资源投入最短的时间，内完成测试
测试用例是执行测试的一个实体(包含执行步骤,预期结果,输入参数等操作)。
二、 测试用例的特征：
（1）最有可能抓住错误的；
（2）不是重复的、多余的；
（3）一组相似测试用例中最有效的；
（4）既不是太简单，也不是太复杂。
三、 测试用例的代表性
1.能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
2.测试结果的可判定性：执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
3.可再现性：同样的测试用例系统的执行结果应当是相同的。
4.针对性：对程序中的可能存在的错误有针对性地测试
四、测试用例通常包括以下几个组成元素：
测试用例编号 测试用例名称(测试注册用例) 测试用例设计
软件版本号 测试目的 参考信息 测试环境 输入数据 操作步骤(输入信息,点击搜索…等) 预期结果 测试结果 测试模块
五、编写测试用例的基本方法
1.等价类划分法 2.边界值法 3.因果图法 4.判定表 5.场景法 6.正交表 7.错误推测法
六、因果图的约束符号：E是互斥 I是包含 O是唯一 R是要求 B 不能出现（银行取钱） M是屏蔽
4.场景法：基本流和备选流（基本流只有一个而备选流有很多个）
5.正交表排列：研究多因素多水平的
Ln,(m^K) n 表达的是行数 测试的次数 K示的是控件的个数 （因素） m表示是每个控件包含的值个数 （水平数） 如:L9(3^4) 叫4因素3水平
七、混合正交表的使用
1.正交表生成工具allpairs 2.PICT工具
3.制作取值表 【只列出数据即可，不用编号】
复制取值表的数据,放到文本文档中保存(注意不要更改任何格式,例如文件叫a.txt)
3、把文本文档放在allpairs文件夹中
4、win + r后输入cmd进入控制台
5、进入allpairs文件来
6、在控制台中输入allpairs.exe Test2.txt >youxiu.txt(youxiu是自己起的名字,用来存放生成的组合用例,可以自动生成,不必提前建好)
八、测试用例的评审和变更 如果是测试组内部的评审，应该着重于：.
1.测试用例本身的描述是否清晰，是否存在二义性；
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
3.是否针对需求跟踪矩阵，覆盖了所有的软件需求；
4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。
九、参与评审人员
这里会分为多个级别进行评审。
1)部门评审，测试部门全体成员参与的评审。
2)公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3)客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
十、评审的内容有以下几个方面
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2)优先极安排是否合理。
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5)是否已经删除了冗余的用例。
十一、项目组内部的评审：
1.收集客户需求的人员：注重业务逻辑是否正确。
2.分析软件需求规格的人：注重测试用例是否跟规格要求一致
3.开发负责人：注重测试用例中对程序的要求是否合理。
8.评审检查法
十二、BUG分类
1.bug 臭虫 按照严重程度分为 5个阶段：【系统崩溃、严重、一般、次要、建议】
十三、按照优先级
1.low: 时间和资源允许的情况下修复【建议】
1.medium: 不会延迟发布 会在以后修复【次要】
3.high: 会制约开发和测试的进行需要在发布前修复【一般】
4.veryhigh: 影响系统 产生严重影响【严重】
5.urgent: 导致系统几乎不可用【系统崩溃】
十四、按照测试种类分
逻辑功能类，性能类，界面类，易用性类，兼容性类
十五、常见缺陷的查找
不可以跟UI提的问题！！！（色彩、功能结构布局、添加按钮未放在醒目的位置、导航功能位于界面的右则、图片选用不规范、不清晰、图片变型、字体过大或过小、窗口过大或过小、数据转换）
十六、 可以跟UI提的问题:
1.页面的大小：在B/S结构的软件系统中,当一个页面元素太多，未做精简时,在打开该页面时可能需要较长的加载时。
2.图片未经压缩、格式不正确,比如采用BMP 代码冗余,存在太多无用代码页面元素太多,太过复杂、
3.界面文字：页面信息描述不清楚，有语病，错别字，简单语言复杂化，描述不正确，不符合当前页面，错误的帮助信息，乱码等。
4.容错处理：用户输入错误,系统无提示,无影响，用户不能清楚知道系统不处理的原因;给出信息提示,用户接受后无法继续操作:不给用户一个改过自新的机会
用户输入不合法的信息后,系统进行提示, 用户确定后,系统仍能处理错误的信息。
取消功能不能取消,比如删除,系统给出提示，是否确定删除，用户否认后仍执行了删除.
十七、.按照Bug生命周期.
新建(测试)，确认(程序员)，解决，重新验证，关闭，重新打开
bug是可以“死而复生”的 如果在旧版本中已经关闭了bug 但是在新版本中重新出现了 我们需要修改状态为重新打开。
13.BUG的处理 也叫生命周期
