测试基础
软件测试
测试是为了度量和提高被测试软件的质量，对测试软件进行工程设计、实施、维护的的整个生命周期过程
软件测试是对软件形成过程的文档、检查软件数据和执行程序代码的测试,而不仅是对程序进行的测试。
软件测试基础
定义：使用人工或自动手段来运行或测试某个系统的过程。
目的：在于检验它是否满足规定的需求或是弄清预期结果实际结果之间的差别，评估软件的质量。
软件生命周期（SDLC,System Development Life Cycle,SDLC)是软件从开始立项到最终被废弃不用这个过程叫做软件生命周期，整个生命周期包括需求调研阶段–需求分析阶段（需求规格说明书）–设计（设计文档）–编码–测试–上线交付（部署到客户）–产品支持（运维）
测试的基本原则
测试时上下文相关的
穷尽测试是不可能的
测试是尽早介入的（尽早发现问题，降低项目成本）
杀虫剂悖论（重复使用同一份测试用例，不能发现新bug）
缺陷群集性（在一个bug周围往往存在其他bug）
测试证明存在缺陷
无错谬论（软件带缺陷上线，评估缺陷对客户的影响）
测试对象：程序、数据、文档
软件开发模型
瀑布型
原型
敏捷：是一种以人为核心、迭代、循序渐进的开发方法
软件测试模型
V模型
RAD模型是软件开发过程中的一个重要模型，他通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。
用户需求 验收测试
需求分析 系统测试（根据需求说明书编写）
概要设计 集成测试 （根据概要设计中模块功能及接口等实现方法编写）
详细设计 单元测试（和详细设计一起出来） - 软件编码
W模型
需求分析SRS–概要设计HLD–详细设计LLD–编码实现coding–模块集成–系统构建–系统安装
需求评审–测试项–系统测试计划–系统测试方案–系统测试用例–系统测试报告
概要设计说明书–集成测试计划–IT方案–IT用例
详细设计说明书–单元测试计划–UT方案–UT用例
H模型
软件测试阶段
单元测试
针对软件基本组成单元（软件设计最小单元，函数、类）来进行正确性检验的测试工作
集成测试
是对单元之间及单元与第三方接口之间的测试，目的是验证接口是否与设计相符，是否与需求相符
集成策略：自底而上（驱动模型）、自顶而上（桩模块的开发）、渐增式（依次增加一个没有测试的模块一起测试）
系统测试
是将集成好的软件系统与计算机硬件、外设、数据、和人员等元素结合在一起，在实际运行环境下，对系统进行一系列测试
确认测试（有效性测试）
验证软件有效性，验证软件功能和性能及其特性是否与用户一致，若达到则表明软件是合格的
验收测试
在交付客户部署前，根据合同、SRS、《验收测试计划》进行测试
Alpha测试
由公司员工进行
Beta测试
由其他人（用户）进行
UAT 测试
用户对软件的接受程度的测试，系统操作的可行性、使用感等
回归测试
测试–发现bug–提交bug–修改bug–再次验证的过程
在软件的任意阶段都可以进行，发现缺陷，缺陷得到修复，修改之后的代码是否影响了之前的功能
回归测试策略：完全重复性测试、选择性重复性测试（覆盖修改法、周边影响法、指标达成法）
冒烟测试
验证当前开发交付的版本可不可以进行后续的测试，基本功能能不能跑通
软件测试类型
功能测试
根据SRS 和测试需求列表，检验产品的功能实现是否符合产品需求
根据需求来测的功能
性能测试
用来测试软件在集成系统中的运行性能（响应时间）
Cpu使用情况
IO使用情况
内存使用情况
信道使用情况
每个模块执行时间百分比
一个模块等待IO
负载测试
是不断的对被测对象，施加负荷，观察被测对象在不同符合指标下的性能情况，验证系统的负载承受能力，并要求在超负荷情况下，依然正常实现业务功能。
压力测试
调查系统在超负荷情况下的表现，找到系统运行的极限条件，关注在超负荷的情况下，速度有多快
容量测试
系统到底能够处理多大的数据量
安全测试
是指验证系统的保护机制在实际保护系统不受非法的侵入，保证数据的完整性和保密性。在受到恶意攻击时，设备的自我保护能力、防护能力等
系统的登录
用户管理
防火墙
系统数据
Web安全性，如Web的加密，解密、数字签名等
数据库的安全性
内部的通信协议
系统防病毒测试
GUI测试
对系统界面进行测试，界面设计与界面设计的吻合情况，确认界面处理的正确性
测试对象：简单界面元素：各种控件
组合类界面元素：复杂的界面元素，不如：工具栏，组合框、菜单栏。
完整界面（窗口）：对话框、单文档窗口、多文档父窗口、多文档子窗口等
可用性测试
从用户角度看软件好不好上手。
问题：过分复杂的功能或者指令、困难的安装过程、误信息不准确或者过于简单、用户被迫记住太多信息、语法、格式和定义不一致
安装卸载测试
根据安装、卸载文档进行检查文档中的步骤能不能正确安装。不仅是找安装软件的本身的错误，还要找安装文档本身的错误
异常测试
系统异常测试与系统的指标测试有关系。通过人工干预手段是软、硬件异常，验证异常前后的功能和运行状态，来检查系统的容错、排错和恢复能力。可靠性测试
文档测试
目标是验证用户文档是正确的，并保证操作手册的过程能够工作
网络测试
在网络环境下与其他设备对接，进行系统功能、性能与指标方面的测试，保证对接正常
稳定性测试
长时间运行后，系统的状况如何，系统平均无故障MTBF时间是否满足系统设计要求
兼容性测试
验证被测对象与硬件、其他软件之间的兼容情况、不同的版本、机型、分辨率等
软件测试方法
白盒测试
是依据被测软件的内部结构设计测试用例，来对内部控制流程进行测试，可不顾整体功能的实现
静态测试
不运行被测软件
动态测试
运行被测软件
黑盒测试
只考虑整体功能，不考虑内部具体实现，又称基于规格的测试
灰盒测试
典型的灰盒测试，比如：集成测试和系统测试
既利用被测对象的整体，又利用内部具体实现，采用灰盒
人工测试
有人来完成测试活动
自动化测试
概念：为了提高工作效率，节省人力和成本，把人为驱动的测试转化为机器执行
软件测试流程
测试计划阶段–测试计划（模板、标准等）
测试设计阶段–测试方案（技术性指导）
测试实现阶段–测试用例、测试规格ISTQB（测试活动顺序）
测试执行阶段–测试报告、缺陷报告
测试工程师系统测试各阶段任务
测试相关文档：需求跟踪矩阵（RTM）
需求评审报告
测试计划：测试内容、测试方法、测试手段、测试环境、
测试方案：从技术角度对一次测试活动进行规划工具的设计、测试赛用例的设方法、测试数据的设计等。
环境搭建手册
软件需求阶段：评审SRS
软件设计阶段：审软件概要设计说明书、详细设计说明书、协助编写系统测试计划
软件编码阶段：设计系统测试用例、准备测试资源（测试工具、测试环境等）、开发测试脚本、开发测试工具、准备测试数据
软件测试阶段：执行测试用例、提交缺陷单、跟踪缺陷、回归测试、提交测试报告
补充说明一下埋点测试
埋点测试是指在应用程序或网站中，对埋点代码的正确性和有效性进行测试的过程。埋点代码是在应用程序中嵌入的特殊代码，用于收集和追踪用户行为数据，以支持分析和监控。
在埋点测试中，主要目标是验证埋点代码是否正确地触发、采集和发送数据到相关的分析平台或服务器。通过埋点测试，可以确保数据采集的准确性和完整性，并验证数据是否满足需求，以便做出正确的业务决策和改进。
埋点测试通常包括以下方面：
事件触发测试：验证埋点代码是否在用户执行特定操作时正确触发。例如，点击按钮、提交表单、页面跳转等。
数据发送测试：检查数据是否正确地发送到分析平台或服务器。验证请求的URL、请求方法、请求头、请求体等信息。
数据准确性测试：确保采集的数据准确无误，包括验证事件名称、参数和其他相关信息是否与预期一致。
异常情况测试：模拟各种异常情况，例如网络错误、权限限制、无效输入等，以验证埋点代码的鲁棒性和稳定性。
自动化测试：使用自动化测试工具编写脚本来模拟用户行为，以提高测试效率和一致性。
通过进行埋点测试，可以发现和解决潜在的问题，例如埋点代码未正确添加、数据发送失败或数据不准确等。这有助于确保数据采集工作正常运行，以便进行正确的业务分析和优化决策。
确定埋点代码位置：
要进行埋点测试，首先需要确定要测试的埋点代码的位置。埋点代码通常位于应用程序的关键交互点，例如按钮点击、页面跳转、表单提交等。
在开发过程中，开发人员会在相关代码处添加埋点代码，以便在用户执行这些操作时触发数据采集。
模拟用户行为：
在埋点测试中，需要模拟用户的行为，以触发埋点代码并检查数据发送情况。
这可以通过手动操作应用程序来完成，例如点击按钮、输入文本等。
也可以使用自动化测试工具，如Selenium或Appium，在脚本中编写模拟用户行为的代码。
检查数据发送：
在进行埋点测试时，需要监视数据是否成功发送到分析平台或服务器。
可以使用抓包工具（如Charles、Fiddler）或浏览器的开发者工具来监视网络请求。
检查请求的URL、请求方法、请求头、请求体等信息，以确保数据发送的正确性。
分析数据是否正确：
登录到分析平台的控制台，查看测试期间收集到的数据。
验证事件名称、参数和其他相关信息是否与预期一致。
对于特定的事件，检查事件的属性、关联的用户信息、时间戳等是否正确记录。
执行多种场景测试：
埋点测试应该覆盖各种用户行为和情景，以验证埋点代码在不同条件下的准确性和稳定性。
这包括正常情况下的操作，以及可能的异常情况，例如无效输入、网络错误、权限限制等。
针对每种情景，验证埋点代码的行为是否符合预期，并确保数据采集的准确性。
自动化测试：
自动化测试可以提高测试效率和一致性，并允许重复执行测试用例。
使用自动化测试工具编写脚本来模拟用户行为，并验证埋点代码的行为和数据发送情况。
断言是自动化测试中常用的技术，用于检查数据是否成功发送、是否记录了正确的事件属性等。
日志和错误监控：
在应用程序中添加日志记录和错误监控机制是进行埋点测试的重要步骤。
记录埋点代码执行过程中的日志，包括发送的数据、返回的结果等。
监控日志和错误，及时发现和解决埋点问题，确保数据采集的准确性和稳定性。
通过以上步骤和详细说明，您可以更全面地了解如何进行埋点测试，并确保应用程序能够正确地采集和发送数据到分析平台。
测试人员定位问题的N板斧
1、让子弹飞一会儿
碰到问题先别忙定位，首先请保存犯罪现场，并且确认能复现。然后排除QA的低级问题 。为什么要保存现场？如果以后复现不了，就证明不了问题的存在。有哪些QA的低级问题？常见的就是hosts不对，网络不通，以及操作姿势不正确等等。这个其实就是上文提到的用户层面问题，这里的用户就是QA人员。经常有QA人员发现问题后就赶紧叫开发过来看，开发这时候幽幽地说句“host对吗”，一看不对岂不是很尴尬。
还有一类问题就是脏数据，我们有时候会遇到服务端报500错误，查看日志后，报空指针，那么很有可能就是数据库中关联表的数据被人为删掉导致的。还有的问题是由于工具的影响导致的，例如fiddler。所以发现问题您别慌，让子弹飞一会，确认不是自己的问题再说。
2、直观查看页面表现
这个就是上文提到的对Web页面的观察。不再赘述。
3、看状态码
4xx状态码一般表示是客户端问题（当然也有可能是服务器端配置问题），比如发生了401，那么要看下是否带了正确的身份验证信息；发生了403则要看下是否有权限访问；404则要看下对应的URL是否真实存在。
而5xx一般表示服务端问题。比如发生了500错误，则表明是服务器内部错误，这个时候要配合服务器log进行定位；发生了502则可能是服务器挂了导致的；发生503可能是由于网络过载导致的；发生504则可能是程序执行时间过长导致超时。
4、看服务器日志
如果发生5xx问题，或者检查后端接口执行的sql是否正确，我们最常见的排查方法就是去看服务器日志比如tomcat日志，开发人员一般会打出关键信息和报错信息，从而找到问题所在。测试人员要养成看日志的习惯。并且，如果将来进行开发，也要养成打日志的习惯，否则发现问题真不知道到哪哭去。
5、接口的请求和返回以及js执行是否有报错
在第3点中我们说了状态码的问题，明确了4xx和5xx的问题所在。那么，如果接口返回了200，就一定正常吗？
假设有这么一种情况，要测试一个翻页控件，翻到第二页的时候，发现内容和第一页完全一样，接口请求返回的是200。这个时候你会怎么排查？
这个时候就要看前端发送的参数正不正常，后端返回的内容正不正常，即接口的请求和返回。
我们来看翻页控件的问题。我们看接口的请求（F12控制台查看网络请求或者抓包工具），一般根据开发的习惯，会有pn、ps参数，看看传值是否正确。如果请求参数不正确，那么就是前端的问题。如果正确，那么就看response，看看返回的内容对不对，以此就知道到底是前端问题还是服务端问题。如果发现js执行报错了，那就是前端有问题，比如跨域问题。
请求URL不正确，是前端bug，传参不正确，是前端bug，响应内容不正确，则是后端bug。如果是响应内容不正确的后端问题，那就要继续深挖，是接口吐数据的时候出错了，还是数据库中的数据就错了，还是缓存中的数据错了（如果用到了缓存的话）。经常见到后端开发人员有的负责接口，有的负责写入数据库，有的负责维护缓存，所以如果发现是后端的问题，可以更进一步确认下是哪块的问题。
6、看需求文档
有时候，前端和服务端的交互都正确，但是从测试的角度看不合理。这个时候，我们应该翻翻需求文档（如果没有的话，就直接抛出这个问题）。如果和需求文档不符，那么就要看下谁改合理，是前端改，还是服务端改，或者两者都得改。这里有一个原则，就是前端尽可能少地去承担逻辑，只负责渲染展现。当然，不要以为需求文档就全部正确，它也可能会有错误，我们也应该去发现需求文档的bug，然后再去协调PM，敦促FE或者RD进行修改。在这点上，不得不说，有的开发做的比较好，他会有自己的思想，在开发的时候就能发现需求文档的错误，而有的开发则是无条件无脑执行。
7、后端生成页面问题
后端生成页面，最常见的就是类似于jsp、php、python的某些前后端不分离的框架，这种比较特殊，常见于单人开发的项目，这种项目的问题排查和其他项目总的思路也一样，只不过前后端bug的修改可能都是同一个人而已。
8、开发提供可测性支持
有时候，涉及到多方面合作，不太好测试的情况下，需要开发提供可测性支持。比如，要查看接口给另一个接口发的请求是否正确，可以让开发打印出完整的请求log。还有一些逻辑开关、修改页面数据条数等，都属于可测性支持的范畴。
9、配置的问题
很多时候，bug不是代码问题，而是tomcat配置、nginx配置、jdbc配置等的问题。在这个层面上，测试人员最好能够了解下它们的各项配置，在发现问题后可能就会想到这方面的问题。
10、经验法则
太阳底下没有新鲜事，有经验的人早就遇到过相同的问题。高手往往能够一眼看穿表面现象内部的问题，然后直奔主题，迅速报告或者解决，留下别人在风中凌乱……
11、其他
常见的可能还有构建的问题，比如代码本身都没错，但是合并代码到主干后出问题了，常见的就是代码存在冲突时手动解决的时候。所以我之前有一段时间喜欢问开发在合并代码时有没有冲突，如果有冲突，那是什么地方有冲突，就得重点对待了。
另外，定位到问题后，还要考虑下具体情况，根据开发人员的心态来决定要不要告诉他具体原因。有的开发不够open，会觉得你抢了他的饭碗。而对于open的开发，你们会因此配合的更加默契。
当然，我们在发现问题或者定位到问题原因后，一定要进行一步，就是再次确认问题。所谓确认问题，就是弄清楚问题是否每次都发生，还是概率事件，或者是工具相关的问题（比如换个浏览器是否依然出现？如果换个浏览器不出现的话，很可能就是前端的兼容性问题）。比如翻页控件，我们待测的系统有很多页面都有翻页控件，那么就要看下是否每个页面都会出现这个问题，进而报bug时进行统一说明，也更加方便开发人员批量处理，防止漏改。
评论