软件测试基础

软件测试概念：验证软件功能是否满足用户的需求
测试的任务是发现程序中的缺陷，主要由测试人员和开发人员执行，黑盒测试主要由测试人员完成，单元/集成测试主要有开发人员完成，测试贯穿整个软件开发生命周期。
按测试分类：功能测试、性能测试、安全测试等
按测试对象的划分：WEB测试工程师、APP测试工程师、游戏测试工程师、嵌入式测试工程师

初级工程师：测试定义、测试方法、测试生命周期、测试执行、测试管理工具
中级工程师：测试用例、linux、mysql、loadrunner、selenium、appium、Jenkins等
高级工程师：①team leader：需求分析、方案设计、进度把控、风险分析、CI、CD、devops
②自动化测试：自动化测试框架、app、web、C/S
③性能测试：性能测试框架、loadrunner、jmeter、调优
④安全测试：sql注入、xss、白帽子
⑤功能测试：兼容性测试、界面测试、易用性测试、业务测试、回归测试、探索性测试

测试目的：验证软件是否存在问题
测试原则：以用户为中心，遵循软件测试的规范、流程、标准、要求

测试用例（test case）是为了实施测试而像被测试的系统提供的一组集合，包含测试环境、操作步骤、测试数据、预期结果等。好的用例是一个不熟悉业务的人也能依据用例来很快的进行测试，用例表达清晰无二义性，可操作性强，输入输出明确，一条用例只有一个预期结果，可维护性好，对需求的覆盖率高，暴露程序Bug的能力强力。

测试用例表：步骤动作与期望的结果，测试方法，重要性，测试环境，测试前提，功能模块

软件测试的生命周期

需求分析 测试计划 测试设计、测试开发 测试执行 测试评估

软件测试与软件开发的生命周期

需求阶段：测试人员了解需求，对需求进行分解，得出测试需求
计划阶段：根据需求编写测试计划或测试方案
设计阶段：测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例
编码阶段：测试人员一般不需要编码，已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善和细化测试用例以及调整测试计划和方案
测试阶段：测试人员根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告
运行维护：测试人员需要参与的实施工作，测试人员对项目的业务和操作非常了解，可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈。

正确的描述bug：
发现问题的版本，问题出现的详细环境，描述问题重现的最短步骤，预期行为的描述，错误行为的描述。
bug级别：
①Blocker崩溃：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
②Critical严重：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
③Major一般：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
④Minor次要：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

一般的bug生命周期：发现bug，确认bug，判断bug，修改或拒绝修改，回归测试，验证通过关闭bug

如何开始测试
准备：
1.阅读所有项目相关的文档
2.尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务
3.熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
4.阅读已有的测试方案和测试案例
5.阅读旧有的bug库，了解系统功能。和测试团队保持一致的故障定级原则
6.了解公司的规范要求
确认工作内容：
测试计划、测试内容、测试时间、测试的内容开发人员需求人员

案例

例：
1.项目启动，介入了解需求
2.需求分析
3.制定测试方案（测试范围及测试点、测试方法、测试类型、测试管理工具、测试资源、测试计划、测试轮数、配置管理、变更管理、评审管理、准入准出标准等）
4.测试执行流程（需求测试、提测版本测试、系统测试、回归测试、编写测试报告）
5.编写测试用例（用例编号、测试类型，测试内容、操作平台、测试方式、操作步骤、输入数据、预期结果、附件、备注）
6.测试执行（缺陷管理：发现-记录-沟通-跟踪-关闭）
7.输出测试报告（缺陷分析，测试结论）
8.版本发布（跟踪、收集信息反馈）
9.项目总结

测试的覆盖率，测试覆盖率包括功能点覆盖率和结构覆盖率，其中，功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系；而结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率和路径覆盖率等等。而逻辑覆盖法中根据覆盖目标的不同和覆盖源程序语句的详尽程度，逻辑覆盖又可分为：语句覆盖； 判定覆盖；条件覆盖；判定/条件覆盖；组合覆盖；路径覆盖，且这些覆盖程度越往后越全。

基于需求的设计
RBT（Requirements-Based Testing）是基于需求的测试方法，会使测试更加有效，是最根本的软件测试：
1.验证需求是否正确、完整、无二义性、逻辑一致。 2.要从黑盒的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。

黑盒测试
首先考虑边界值，必要时用等价类补充测试用例，可用错误推测法继续追加一些测试用例。对照程序逻辑检查测试用力的逻辑覆盖率时，如果没有达到要求的覆盖标准，应当继续补充足够的测试用例。

1. 等价类划分法

依据需求将输入或输出划分成若干个等价类，从等价类中选出一个测试用例，如果通过，则其所代表的等价类测试通过。

2. 边界值分析法

对输入或输出的边界值进行测试的一种黑盒测试，选择正好等于、刚刚大于或者刚刚小于边界的值进行测试。通常边界值是作为对等价类的补充。

3. 因果图

因果图是一种简化的逻辑图，能够直观的表明程序输入条件与输出动作之间的相互关系。因果图是借助图形来设计测试用例的一种系统方法，适用于被测试程序具有多种输入条件，程序的输出又依赖于输入条件的各种情况。
基本步骤：分析程序说明描述中，哪些是输入哪些是输出，并给每个输入或输出赋予一个标识符–>分析程序说明描述的语义，找出输入与输出或输入与输入之间的关系，根据这些画出因果图–>将因果图转换为判定表–>以判定表的每一列为依据来设计测试用例

4. 正交排列法

正交实验设计是研究多因素多水平的一种设计方法，它是根据正交性，有实验因素的全部水平组合中选出有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交实验设计是一种基于正交表的、高效率快速经济的试验。
因素（Factor），在一项试验中，凡欲考察的变量；水平（level），在试验范围内，因素被考察的值也就是变量的取值
正交表由行数（Runs，N，正交表中行的个数，试验的次数）、因素数（Factors，C，正交表中列的个数）、水平数（Levels，T，任何单个因素能够取的值的最大个数）构成。
正交表的表示形式：L=N（TC）
正交表的两条性质：每一列中各数字出现的次数一样多；任何两列所构成的各有序数对出现的次数一样多。
正交法设计测试用例的步骤：有哪些因素；每个因素有哪些水平；选择合适的正交表；把变量的值映射到表中；把每一行的各因数水平的组合作为一个测试用例；加上可疑且没有在表中出现的用例组合。

5. 判定表驱动分析法

6. 场景设计法

7. 错误猜测法

白盒测试

根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。白盒测试包含静态测试、动态测试、单元测试、评审。静态测试包括代码检查、静态结构分析、代码质量度量、文档测试等，可由人工进行也可借助工具自动运行；动态测试包括功能确认、接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试原则：. 保证一个模块中的所有独立路径至少被测试一次；所有逻辑值均需要测试真（true）和假（false）两种情况；检查程序的内部数据结构，保证其结构的有效性；在上下边界及可操作范围内运行所有循环。

灰盒测试

按开发阶段划分
单元测试（unit testing），也称模块测试，是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性。测试对象是软件设计的最小单位-模块，测试阶段在编码前或编码后，测试依据是代码和注释以及详细设计文档，测试方法白盒，测试内容有模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试（integration testing），也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作，其目的是检查软件单位之间的接口是否正确。测试对象是模块间的接口，测试阶段一般在单元测试之后，测试依据是单元测试的模块和概要设计文档，测试方法黑盒白盒相结合，测试内容有模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响。集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。
系统测试（system testing），包括对功能、性能以及软件所运行的软硬件环境进行测试，包括回归测试和冒烟测试。测试对象是整个软硬件系统，测试阶段在集成测试通过之后，测试依据是需求规格说明文档，测试方法黑盒，测试内用有功能、界面、可靠性、易用性、性能、兼容性、安全性等。系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
回归测试（regression testing）：修改了旧代码后，重新进行测试已确认修改没有引入新的错误或导致其他代码产生错误）
冒烟测试（smoke testing）：其对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可进行后续的正式测试工作）
验收测试（acceptance testing），也称交付测试，是部署软件之前的最后一个测试操作，其目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买者展示该软件系统满足原始需求。测试对象是整个软硬件系统，测试阶段在系统测试通过之后，测试依据是用户需求和验收标准，测试方法黑盒，测试内容同系统测试，有功能、界面、可靠性、易用性、性能、兼容性、安全性等。验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

按测试实施组织划分
（验收测试）
α测试，alpha测试
β测试，beta测试
第三方测试，介于两者之间

按是否运行划分
静态测试（static testing），代码静态分析和文档测试
动态测试（dynamic testing），由构造测试用例、执行程序、分析程序的输出结果三部分组成

按是否手工划分
手工测试（manual testing）
自动化测试（automation testing），功能、性能、安全

按是否查看代码划分
黑盒测试（black-box testing）也称功能测试
白盒测试（white-box testing）也称结构测试、透明盒测试、逻辑驱动测试
灰盒测试（gray-box testing），介于黑白盒之间，多用于集成测试阶段

按测试对象划分
业务测试
界面（UI）测试
容错性测试
文档测试，开发文件、用户文件、管理文件三大类，检查文档的术语、正确性、完整性、一致性、易用性
兼容性测试，平台、浏览器、数据
易用性测试
安装测试
安全测试
性能测试
内存泄漏测试

针对手机软件的系统测试，通常包含以下角度：
1.功能模块测试：首先分析功能模块的功能项，测试每一个功能项是否能够实现对应功能。一般根据测试用例和软件本身的流程就可以完成基本功能测试。
2.交叉事件测试：又叫做事件或者冲突测试，是指一个功能正在执行过程中，同时另外一个事件或者操作对该过程进行干扰的测试。例如通话过程中接收到短信或者闹铃触发，应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机、花屏等严重问题。
3.压力测试：又叫做边界值容错测试或极限负载测试。即测试过程中，已经达到某一软件功能[存储、网络、响应能力]的最大容量、边界或者最大承受极限，仍然对其进行相关操作。例如连续接收或者发送短信，超过收信箱和SIM卡所能存储的最大条数，仍然进行接收或者发送，依次来检测软件在超常态下的表现，进而进行评估用户能否接受。
对手机可以施加的压力测试类型主要包括：
->存储压力：由于手机采用的是栈式存储，所以当一个存储块满了之后，程序员不做相应处理的话，就会导致其他存储区被删除。
->边界压力:边界处理问题一直是容易被忽略的地方
->响应能力压力：有时 某些操作可能处理的时间较长，如果在处理期间，继续进行其他操作时候就会出现问题。
->网络流量压力：执行较大数据流量的功能同时，在进行其他操作，使得网络流量始终处于很高的状态，检验各个功能是否依然正常工作，是否存在因为网络流量瓶颈引起的某功能异常。
4.容量测试：即存储空间已满时候的测试，包括用户可用内存/SIM卡所有空间被完全使用的测试。此时在对可编辑模块和存储空间进行操作，如果软件在极容状态下处理不好，将会导致死机或者花屏等问题。
5.兼容性测试：不同品牌、型号手机，不同网络，不同容量大小的SIM卡之间的兼容性测试。例如：中国电信的小灵通接收到中国移动或者中国联通GSM发来的短消息，需要验证显示和回复是否正常。
6.易用性、用户体验测试：在指定条件下，软件产品被理解、学习、使用和吸引用户的能力，是交互的适应性、功能性和有效性的集中体现。