目录
一、概念
1、需求
2、测试用例
3、软件错误--BUG
4、软件生命周期
5、软件开发模型
6、测试模型
7、软件测试生命周期
二、基础
1、描述一个bug
2、定义bug的级别
3、bug的生命周期
4、开始第一次测试
5、解决争执
三、测试用例基础知识
1、用例基本要素
2、基于需求进行测试用例设计
3、测试用例具体设计方法
（1）等价类
（2）边界值
（3）错误猜测法
（4）场景设计法
（5）判定表法
（6）正交表法
4、测试用例设计万能公式
5、借助fiddler控制网络
6、借助postman进行接口测试
四、测试分类
1、分类图
2、测试对象划分
3、是否查看代码划分
4、实施组织划分
5、开发阶段划分
6、是否运行代码划分
7、是否手工划分
8、地域划分
一、概念
1、需求
需求分为用户需求和软件需求。
用户需求：指甲方提出的需求，如果没有甲方，指终端用户在使用产品时必须要完成的任务。
软件需求：功能需求，详细描述了开发人员需要实现的软件功能。
在进行软件开发时，会把用户需求转为软件需求，软件需求是开发人员和测试人员的重要依据。
2、测试用例
测试用例是为了完成测试而向被测试系统提供的一组集合，这组集合包括：测试环境、测试步骤、测试数据、预期结果等。
3、软件错误--BUG
当且仅当规格说明是存在且正确的，程序与规模之间出现不匹配时就是软件错误。
4、软件生命周期
指软件产品从开始构想到结束使用的过程，包含6个阶段：需求分析、计划、设计、编码、测试、运维。
5、软件开发模型
（1）瀑布模型
每个阶段都只执行一次，线性顺序进行的软件开发模型。
（2）螺旋模型
渐进式模型，不允许有一段独立的测试时间和阶段，测试随着开发的迭代而迭代，保证每个开发阶段的质量。
（3）迭代模型
把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次的分析、设计、编码和测试这些增量组件。
增量 VS 迭代
增量是逐块建造的概念，迭代是反复求精的概念。
（4）敏捷---scrum
角色：
包含产品经理、项目经理、研发团队。
执行流程：
①由产品经理收集用户需求，对这些需求进行优先级排序，形成需求池；
②发布计划会议，由产品经理对需求进行讲解和分析；
③迭代计划会议，研发团队对需求进行分解，分解的标准是完成每一个需求的任务，每个需求都有一个负责人；
④每日例会，由项目经理每日主持站会，项目团队回答已完成了什么，计划完成什么；
⑤演示会议，迭代任务结束后，相关人员进行参加，包括甲方，由相关负责人展示迭代取得的成果，记录反馈结果，由项目经理整理形成新的需求。
⑥回顾会议，对于本次迭代结果进行总结，制定改进计划，下一次迭代继续改进。
6、测试模型
（1）测试v模型
是瀑布模型的变更，测试作为软件开发编码后的一个阶段，清楚的描述了每个测试阶段和每个开发阶段对应关系。
（2）测试w模型
是螺旋模型的变更，测试伴随着整个开发，保证每个开发阶段的质量。
7、软件测试生命周期
需求分析、测试计划、测试设计/测试开发、测试执行、测试评估。
二、基础
1、描述一个bug
对于一个bug的描述应该包含以下几个部分：
（1）发现问题版本
开发人员需要知道出现问题的版本，才能获取对应版本的代码来重现故障。
（2）问题出现环境
环境分为硬件环境和软件环境。如果是一个web项目，需要描述浏览器版本、客户机操作系统等；如果是一个app项目，需要描述机型、分辨率、操作系统版本等。
（3）bug重现步骤
描述问题重现的最短步骤。
（4）预期结果描述
以用户的角度描述程序的行为。
（5）错误结果描述
描述错误的现象。
2、定义bug的级别
（1）Blocker---崩溃
阻碍开发或测试，造成系统崩溃、死机、死循环，数据库数据丢失，数据库连接错误，主要功能丧失，基本模型缺失等问题。
（2）Critical---严重
功能设计与需求严重不符，模块无法启动或调用。
（3）Major---一般
功能没有完全实现但不影响使用。
（4）Minor---次要
界面、性能缺陷，建议类问题，不影响操作功能的执行。
3、bug的生命周期
new：测试人员发现新bug，但还未评审决定开发人员是否修改；
open：确认是bug，指派给相应开发人员进行修改；
fix：开发人员修改bug，修改状态，待测试人员进行验证；
reject：开发人员认为不是一个bug，拒绝修改；
delay：该bug暂时不需要修改或当前不能修改，延期修改；
closed：修改后的bug经测试人员验证通过后，关闭bug；
reopen：修改后的bug，测试人员验证未通过，需重新打开。
4、开始第一次测试
（1）准备工作
①阅读项目有关的文档，包括：需求文档、设计文档、用户手册等；
②参加各种项目会议，了解项目背景、需求、具体业务等；
③熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登陆方式。
④阅读已有的测试方案和测试用例；
⑤阅读旧的bug库，了解系统功能和bug定义级别；
⑥了解规范要求，包括用例编写规范、bug提交规范、测试工具使用规范等。
（2）具体工作
①掌握测试计划；
②掌握测试内容，清楚测试用例数目、执行周期、自由测试时间；
③清楚开发人员和需求人员；
④了解分配给我的测试内容是否需要特殊的测试资源，资源是否满足需求。
5、解决争执
（1）检查自身是否bug描述不清楚；
（2）站在用户角度考虑问题，让开发人员了解到bug对用户可能造成的困扰；
（3）bug定级要有理有据；
（4）提高自身的技术，不光要提出问题，最好也有解决方案；
（5）开发人员依旧不接受时，开三方讨论会，包括开发、测试、产品，确定该bug是否修改。
三、测试用例基础知识
1、用例基本要素
测试环境、测试步骤、测试数据、预期结果
2、基于需求进行测试用例设计
（1）分析测试需求，验证需求是否正确、完整、无二义性、逻辑自洽；
（2）需求正确时，细化测试需求，分为功能测试需求和非功能测试需求；
（3）从测试需求中提炼出一个个测试点或者测试项，根据每一个测试点设计测试用例。
eg：
3、测试用例具体设计方法
（1）等价类
依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，若该测试用例通过，则认为所代表的等价类测试全部通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
有效等价类---对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
无效等价类---根据需求说明书，不满足需求的集合。
等价类设计测试用例组合原则：有效等价类在组合时，一个测试点尽可能覆盖多的有效测试类；无效测试类在组合时，一个测试点只能包含一个无效测试类。
举例采用等价类设计测试用例：
当用户名的长度是6-15，且全为字母时，登陆成功，否则登陆失败。
划分等价类：
测试点：
此时就可以根据测试点设计测试用例了，不再具体举例。
（2）边界值
上点：边界上的点；
内点：边界内的点；
离点：边界左右的一个点，如果是闭区间，离点就是范围外的点；如果是开区间，离点就是范围内的点。
举例：
[6,15]---上点：6,15 ；内点：10...... 离点 ：5,16；
(6,15]---上点：6,15 ；内点：10...... 离点 ：7,16；
针对边界值设置测试点：
边界值：
测试点：
（3）错误猜测法
对被测试软件设计的理解，凭借个人经验推测出软件可能存在的缺陷，从而针对性地设计测试用例
（4）场景设计法
步骤：划分主事件流---根据主事件流划分次事件流---将主事件流次事件流窜起来形成场景，一个场景就是一个测试点。
（5）判定表法
①逻辑关系：
恒等---条件为真，结果为真；条件为假，结果为假；
与---条件全为真，结果为真；
或---条件全为假，结果为假；
非---条件为假，结果为真。
②操作步骤：
理解需求---找到所有可能的输入和输出---分析输入和输出之间的关系---画判定表---把判定表对应到每一个测试用例。
③举例：
淘宝618活动，订单已提交，订单合计大于等于300或有红包，则有优惠。
输入---订单已提交、订单未提交、订单大于等于300、订单小于300、有红包、没有红包；
输出---有优惠、没有优惠
画判定表：
根据判定表就可以设计测试用例了。
（6）正交表法
当判定表法设计用例太多时，可以使用正交表法，用尽量少的用例覆盖输入的两两组合。
①名词解释
因素：变量；水平：变量的取值。
n：代表行数，每一行都是一条组合的测试用例；
k：代表控件个数(因素)；
m：代表每个控件中的可选值(水平)；
k因素，m水平，n是测试用例个数。
②操作步骤
根据需求找出因素数和水平数---选择合适的正交表---每个因素数编号并填入到正交表中。
③举例
说明：名称是自定义的；样式类型有段落和字符；样式基于有正文和标题；后续段落样式有样式1和样式2
找出因素数和水平数：
选择合适的正交表---借助工具(allpairs)生成正交表：
编号替换：
根据正交表编写测试用例：
ps：可以适当加入一些有风险的测试用例。
4、测试用例设计万能公式
从以下几个方面设计：
功能---软件本职工作；
兼容---软件在各个平台运行情况，考虑设备类型、操作系统版本、浏览器版本等；
安全---黑客攻击、xss漏洞、sql注入；
界面---图片布局、图片大小、按钮颜色、文字字体等；
性能---软件页面渲染时长、软件能够承载大量用户访问；
易用---软件设计符合大众操作习惯。
举例：对于一个杯子设计测试用例设计。
对应linux中的zip解压缩命令进行测试用例设计。
5、借助fiddler控制网络
对于某些功能，我们需要改变网速判断功能是否可以正常运行。
每上传单位kb延迟发送300ms，每下载单位kb延迟接收150ms，时间越大，网速越慢。
6、借助postman进行接口测试
接口测试：通过测试不同情况下的入参，根据与之相应的出参信息来判断接口是否符合或满足相应的功能及安全要求。
将复制的url粘贴到postman运行，根据get/post、有无参数、有无正文等进行调整。
四、测试分类
1、分类图
2、测试对象划分
（1）界面测试
UI测试，按照界面的需求(UI设计稿)和界面的设计规则，对软件界面所展示的内容进行测试和检查。
检查内容：①检查界面内容显示的完整性、准确性、一致性；②验证整个界面布局和排版是否合理；③对界面不同控件的测试；④界面布局和色调是否符合当下时事发展。
（2）性能测试
对产品的性能需求进行分析，基于需求完成性能测试的设计和执行，持续进行性能调优。
常见性能问题：①查询速度慢、效率低；②资源泄漏；③线程死锁、线程阻塞；
（3）兼容性测试
明确要测试的兼容环境，考虑软、硬件的兼容。例如：系统自身版本的兼容、应用环境的兼容等。
（4）安全性测试
常见的安全漏洞：
①输入域，如输入域带有病毒脚本或长字符串；②代码本身存在安全问题，如sql注入问题；③数据存储或传递不安全；④对数据进行恶意修改；⑤身份欺骗；⑥有问题的访问控制。
举例：对于上传和下载的安全性测试？
①对上传文件进行过滤和扫描，确保不会上传恶意文件或病毒；②只有授权的用户可以进行上传和下载；③限制不同用户访问不同文件的权限；④确保数据在传输过程是加密的；
（5）易用性测试
关注用户体验，满足标准性和规范性、直观性、灵活性、舒适性、正确性、实用性；
（6）可靠性测试
可靠性=软件正常运行时间/(软件正常运行时间+软件非正常运行时间)*100%
软件非正常运行可能是网络故障、断电、硬件、软件等造成的。
（7）文档测试
文档测试的关注点：文档的术语、正确性、完整性、一致性、易用性。
（8）内存泄漏测试
造成内存泄漏的原因：
①分配完内存忘记回收；②程序写法有问题(如死循环)；③某些api函数使用不正确。
检测方式：
①人工静态法，代码走读；②自动工具法，借助工具记录每次内存分配，了解内存是如何泄漏的。
（9）容错性测试
系统能够处理异常，用户的错误操作不至于系统崩溃。
测试内容包含两方面：
①输入异常数据或进行异常操作，若系统容错性好，系统只给出提示或内部消化掉，而不会导致出错或者系统崩溃。
②通过各种手段，让系统强制性的发生故障，验证已保存的数据是否丢失，系统能否尽快恢复。
（10）安装与卸载测试
测试内容包含：
①不同的安装与卸载方式；②是否可以在不同环境系统安装；③安装或卸载过程是否可以手动取消或暂停；④存储空间不足时，安装是否有提示；⑤卸载和安装过程出现环境问题是否可以合理应对
3、是否查看代码划分
（1）白盒测试---结构测试或逻辑测试
①概念：分析程序的内部结构，针对程序的逻辑结构设计测试用例进行测试，以确定实际运行状态与预期状态是否一致。
②测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
（2）黑盒测试---数据驱动测试
①概念：完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用，满足规范需求。
②测试方法：等价类、边界值、错误猜测法、场景设计法、判定表法、正交表法。
（3）灰盒测试
概念：介于白盒测试和黑盒测试中的一种测试，不仅关注功能是否满足需求，也关注程序内部结构
4、实施组织划分
（1）α测试
用户在开发环境下进行的测试，也可以是公司内部用户在模拟实际操作环境下进行的测试，评价软件产品的FLURPS，该测试不能由开发人员和测试人员完成。
（2）β测试
由软件的最终用户们在一个或多个场所进行。
（3）第三方测试
介于开发和用户间的测试。
α测试与β测试的区别：①测试环境不同，α测试是在开发环境下测试，β测试是在一个或多个用户场所进行的测试；②测试时间不同，α测试先于β测试，β测试周期长。③α测试受开发方控制，用户数量相对较少，时间集中；β测试不受开发方控制，用户数量相对较多，时间不集中。
5、开发阶段划分
（1）单元测试
对软化组成单元进行测试，检测软件基本组成单位的正确性。
ps：java可以使用JUnit进行单元测试。
（2）集成测试
将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行测试，检查软件组成单元之间的接口是否正确。
（3）系统测试
对软件的功能、性能及软件所运行的软硬件环境进行测试。
（4）验收测试
产品发布之前进行的软件测试活动，确保软件准备就绪。
6、是否运行代码划分
（1）静态测试
不实际运行被测软件，只是静态的检查程序代码、界面或文档中可能存在的错误。
（2）动态测试
运行被测软件，输入相应测试数据，检查实际输出结果和预期结果是否相同。
7、是否手工划分
（1）手工测试
由人去一个一个的输入用例并观察结果。
（2）自动化测试
由机器执行，在预设条件下运行系统或应用程序，评估运行结果。预设条件应包括正常条件和异常条件。
8、地域划分
（1）本地化测试
侧重于测试产品，针对特定地区的语言、文化和法规进行测试，确保特定地区的用户可以使用，并且符合当地的法规和习俗。
（2）国际化测试
侧重于测试为全球用户构建的产品功能和能力，检测产品设计中可能影响其全球化的问题。
