软件测试基础
一.定义
通过手动点击或者工具对被测对象进行测试操作，验证实际的结果是否和预期的结果之间存在差异
二.软件测试的作用
1.通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心
2.测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据支持
3.测试可以降低同类型产品开发遇到问题的风险
三.测试的原则 （在执行测试的时候必须遵守的规则）
1.测试证明软件存在缺陷
2.不能执行穷尽测试-----有些功能是没有办法将所有的测试情况都逻辑出来，所有任何的测试操作都有结束的时间
3.缺陷存在群集现象-----核心功能占20％，非核心占80％，主要集中测试核心的功能，发现缺陷的几率就会高于80％，所以遇到缺陷都会集中在20％的功能模块里
4.某些测试需要依赖特殊的环境
5.测试在项目当中应早介入
6.杀虫剂现象---同样的一个测试用例不能重的执行多次，否则会对它产生免疫
7.不会存在缺陷谬论，任何软件都不可能是完美的
四.测试对象的介绍
软件不仅仅只有功能需要测试，可以将软件分为三个部分：功能集合+使用说明书+配置数据
1.需求分析阶段：各种需求规格说明书
2.软件架构设计：API接口文档（接口测试）
3.编码实现阶段：源代码--白盒测试，单元测试
4.系统测试：软件功能主题
五.测试的级别
软件的开发都会依据相应的开发模式，则测试级别指的就在这个模型当中我们认为定义的开发步骤。
1.单元测试---在软件测试中指组成软件最小的底层代码结构，一般是类，函数，组成
2.集成测试---将多个单元模块组合在一起，验证之间沟通的桥梁是否能正常测试
3.系统测试---对软件的功能主体进行测试
4.验收测试
（1）a测试----内侧
（2）β测试----公测
验收测试的核心就是让用户对当前软件买单
六.系统测试
1.功能测试：验收当前的软件主体功能是否可用
2，兼容性测试：验收当前软件在不同的环境下是否还可以使用。
3，安全测试：验证软件是否是能授权用户提供功能使用。
4，性能测试：相对于当前软件消耗的资源它的产出能力。
七.常见的系统测试方法
1.按测试对象来进行分类
（1）.白盒测试---主要测试的是软件的底层代码，不在意界面，只要求底层的功能是否实现，逻辑是否正确
（2）.黑盒测试---指被测软件外在主体功能是否可用，属于功能性测试
（3）.灰盒测试---接口测试
2.按测试对象是否执行来进行分类
（1）.静态测试---测试执行不执行
（2）.动态测试---软件在真实的使用环境下进行测试
3.按测试手段进行分类
（1）.手动测试---所谓的黑盒测试，对被测对象来进行测试，使被测得对象可以灵活的改变测试操作借环境
（2）.自动化测试---分为两种，一种是自己写的测试脚本，另一种是通过第三方工具对被测对象进行测试，可以高效率的去执行一些人工无法实现的操作
八.软件的质量特性
是基于ISO组织制定的，分为六大特征：
1.功能性：软件需要满足用户显示或者稳式的功能
2.易用性：软件易于学习和上手使用
3.可靠性：指软件必须实现需求当中指明的具体功能
4.效率型：软件的性能
5.可维护性：需求软件具有将某个功能修复之后继续使用的功能
6.可移植性：从当前的一个平台移植到另一个平台上
九.软件测试流程
流程：
从产品接到需求开需求会，确立需求文档，测试就应该编写测试计划，根据需求文档进行编写测试用例，开发进行编码，等编码结束后对主要功能进行冒烟测试，测试执行测试用例，如果发现bug就进行提交bug。例如禅道之类，当开发修改后对bug进行再次的回归测试（1.bug是否已经解决，2.解决后的bug是否对正常的功能有影响）如果bug修改完成测试必须将bug的状态修改为关闭，如果bug没有修改或者是修改后对其他的功能进行影响则bug必须重新打开并再次进行提交
如果公司内部没有需求文档或者是API文档你怎么做测试：
1. 根据公司的产品进行对同行业或是同类软件进行分析，找到相关文档。
2. 根据跟人经验对软件进行测试
3. 先做到UI页面和业务逻辑是否匹配 在进行功能模块的实现能否正常 然后在整个软件进行系统分析并实现，然后开展性能测试或者是接口测试
4. 没有api文档的时候 进行接口测试 可以通过抓包工具（charles /fiddler）来获取接口相关信息（url 请求方式 参数 响应结果等）进行对单个接口测试或者是通过接口录制（bodboy 对web端进行录制 jmeter对移动端的录制） 实现多接口或者一个业务场景进行接口测试
5.进行性能测试或者是自动化测试
测试计划
测试背景，测试目的，测试需求，测试用例及评审执行的进度，bug跟踪，风险评估
如何做测试用例的评审？
1.是否覆盖测试需求上的所有功能点，不违背产品原型和代码设计，用例设计的结构安排是否清晰合理，有利于高效覆盖需求
2.用例是否具有可执行性，前提条件、执行步骤和预期结果是否正确，有明确的验证方法。优先级安排是否合理
3.是否从用户层面来设计用户使用的场景和业务流程
4.是否包含充分的异常测试用例
5.是否简洁，不冗余，复用性强
十.设计测试用例
用例的设计点：
1.功能上测试
2.UI页面
3.性能测试
4.安全测试
5.弱网测试
6.易用性测试
十一.回归测试及缺陷跟踪
1. 回归测试指的就是当我们将某个缺陷提交给开发之后，由他们进行修复，修复完成之后需要测试人员再次对其进行测试（回归测试）
2. 缺陷跟踪：指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪
Day2笔记
测试用例定义：
要素：用例编号所属模块前提条件测试输入预期结果实际结果
备注版本测试人测试日期
测试方法：等价类划分法，因果图法，边界值法，场景法，正交表法，错误推断测法。
测试用例的评审：
评审内容
评审的内容有以下几个方面
1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2)优先极安排是否合理。
3)是否覆盖测试需求上的所有功能点。
4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。
5)是否已经删除了冗余的用例。
6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。
7)是否从用户层面来设计用户使用场景和使用流程的测试用例。
8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤
分为组内和组外评审：
组内评审的人员：测试Leader和 测试人员
组内评审着重与1.用例的冗余性
2.用例的准确性
3.用例的覆盖度70%-80%
4.用例满足需求
组外评审：测试leader测试人员 项目经理 产品经理
组外评审：1.是否满足软件的需求
2.用例覆盖率
3.用例的执行性
4.用例的复用性
5.用例是否具有正反的用例
6.编写用例的模板
7.非功能性测试用例的编写
8.缺陷率在执行的测试用例中的占比
开发团体人员：5：1
10人开发团队 1 UI 5个后台开发 2个移动端 1个测试/运维 1产品
项目开发周期：6个月
版本迭代：大版本1个半月 小版本 1周
测试分工：功能界面性能+接口 自动化
