目录
测试用例是测试过程中很重要的一类文档，它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。
一、测试用例的编写流程
需求分析->提取测试点->测试用例编写->测试用例评审
测试用例常用设计方法：（大多数设计时有限等价类，边界值补充，错误猜测及场景优化，非大型复杂项目不考虑因果图判定表）
1.等价类
因材施教的例子:
原则上讲, 老师应该依据每个学生自身的情况, 指定符合的学习方案. 但是实际上学生太多老湿管不过来, 只能分成几类: 优等生强调知识面的扩展和综合能力的提升; 中等生强调夯实基础, 查缺补漏; 差等生强调优先掌握重点, 暂时跳过难点，思路：输入的集合是无穷的, 不能全都覆盖到依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
无效等价类：根据需求说明书，不满足需求的集合。
超市买水果
有效等价类：苹果、桃子、梨
无效等价类：青菜、米、饮料，…
等价类只考虑输入域的分类，没有考虑输入域的组合。
2.边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
3.因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
（1）恒等：如果原因为真，那么结果必定为真。 例如：动物园运来大熊猫，动物园一定有大熊猫
（2）与：只有2个原因都为真，那么结果为真
（3）或：2个原因中有一个为真时，结果就为真
（4）非：只有原因为假，结果才为真
4.正交排列
因果法设计用例太多怎么办？
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成：
行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。
因素数(Factors)：正交表中列的个数，用C代表。
水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”，用T代表。
正交表的表示形式： L=行数(水平数*因素数) L=N(TC)
正交表的两条性质：
每一列中各数字出现的次数都一样多。
任何两列所构成的各有序数对出现的次数都一样多，
正交法设计测试用例的步骤：
1、有哪些因素（变量）
2、每个因素有哪几个水平（变量的取值）
3、选择一个合适的正交表
4、把变量的值映射到表中
5、把每一行的各因素水平的组合作为一个测试用例
6、加上你认为可疑且没有在表中出现的用例组合
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
5.场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：
1、用户激活后再次点击邮件激活链接？
2、已注册用户再次注册？
6.错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的
测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。
1.测试人员对项目测试时间久，对功能，模块的复杂度了解，对研发人员的代码能力了解
2.用户反馈（线上，线下）
3.缺陷库故障库
缺陷：上线前 故障：上线后，生产环境
二、需求答疑评审阶段
参与人员：
产品、开发、测试、需求提出人、其它相关人员
主要工作内容：
对产品需求文档进行评审，对于有疑问或者有错误的地方，进行讨论沟通，来保证对需求理解的准确性和一致性，通过此次会议了解到各模块对应开发人员，以此来确定软件的测试时间
三、制定测试计划
测试主要工作内容：
根据开发计划制定测试计划，测试计划包含：测试目标、通过标准、测试人力安排、测试进度安排等
四、测试用例编写、评审
主要内容：测试工作最重要的环节就是设计产出测试用例。
（参照一测试用例的编写流程）
五、冒烟测试
开发提测后，在正式测试前，需要先验证一下主流程或主要实现功能是否存在问题。
没有问题后再进行系统的测试，避免测试相关工作已经准备开展，而核心业务却执行不下去的情况。
假如说在注册登录这一步或者下单支付的时候就出现了问题，那后面的功能也没法继续测试了，所以这个就叫冒烟测试，
主要是保证主流程使用没问题才能测试，如果没办法跑通冒烟测试就让开发重新做一个版本再提测
六、执行测试用例
冒烟测试结束后，按照测试计划开展全量测试。提交发现的bug让开发人员修复，修复以后再次进行测试（回归验证）
七、测试报告总结
在整个需求或版本测试完成后的总结。主要反应测试过程中的问题以及对应版本的质量情况，是否满足发布标准、遗留的问题的情况、是否影响相关使用、特殊的注意事项等。
（参照测试工作流程图---复盘总结）
八、非特征性测试：
1、负载压力：
指系统在某种指定软件、硬件以及网络环境下承受的流量，如并发的用户数、持续运行时间、数据量等。其中并发的用户数是负载压力的重要体现。
2、负载压力测试：
指在一定测试约束条件下，测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力，负载压力测试是性能测试的重要组成部分
3、性能测试：
用来保证产品发布后系统的性能能够满足用户需求，包括两种测试策略：性能评测、性能调优（初步模拟用户视觉评判页面加载）
4、负载测试：
通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试
5、压力测试：
通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下，系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试压力测试是为了发现在什么情况下系统的性能会变得不可接受
6、并发性能测试：
并发性能测试的过程，是一个负载测试和压力测试的过程；逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点，能过综合分析交易执行指标，资源监控指标来确定系统并发性能的过程；
????????并发性能测试是负载压力测试中的重要内容；
????????并发性能测试包括：应用在客户端性能的测试、应用在网络上性能的测试、应用在服务器端上性能的测试三个方面疲劳强度测试 采用系统稳定运行情况下所能支持的最大并发用户数，或者日常运行用户数，持续执行一段时间业务，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能的过程
7、大数据量测试：
大数据量测试包括独立的数据量测试和综合数据量测试两类
8、独立的数据量测试：
指针对某些系统存储、传输、统计、查询等业务进行的大数据量测试综合数据量：指和压力性能测试、负载性能测试、疲劳
九、缺陷管理
bug的定义：软件没有达到需求宣讲中表明的功能；
软件出现了需求宣讲中不一致的表现；
软件功能超出需求宣讲所包含的范围；
软件没有达到用户期望的目标；
测试人员或用户认为软件的易用性差。
（大致根据三种区分：不符合需求、程序本身出错、不符合用户使用习惯）
bug的生命周期：从开始发现到解决结束
bug描述环境信息：操作系统/数据库/浏览器/软件版本
所属功能模块、测试/开发人员、严重等级(1-5)、客户优先级、风险程度、状态、重现步骤、实际结果、是否要回归问题等
bug严重等级：
致命：系统无法运行，主要功能模块无法使用，无法启动或异常退出，系统无法登陆。
高：主要功能有缺陷，但不影响系统的稳定性，功能没有实现，存在报错，计算错误。
中：界面、性能缺陷，大数据操作时无响应。
低：易用性和建议性的问题，界面颜色搭配不好，有错别字，文字不整等。
修复等级分类：
