[TOC]
第一周
Day 1
BUG管理流程和规范
- BUG定义:
缺陷,常常又被叫做BUG,即为设备或程序中存在的某种破坏正常运行能力的问题.错误,或者隐藏的功能缺陷
- 低级BUG:
软件项目按规范流程实施很容易避免,或不应该出现的问题
- 经典BUG:
软件常用功能未关注场景,具有某一类代表性的问题,或者是市场缺陷,具有代表性的问题
测试环境
项目部署环境一般可分为五种:开发环境(DEV),测试环境(SIT),验收环境(UAT),生产环境(PRD),客户生产环境
环境名称 | | | 描述 | | | 说明 |
DEV环境 | | | (Production):外部用户无法访问,前/后端开发联调环境,版本变动很大,由开发团队管理和维护 | | | 功能验证和接口测试可在该环境进行 |
SIT环境 | | | (System Integration Test):统称系统集成测试环境,外部用户无法访问,专门给测试人员使用的,版本相对稳定,由测试团队管理和维护 | | | UI验收和接口自动化可在该环境进行 |
UAT环境 | | | (User Acceptance Test)客户验收环境,同时可提供给设备端测试或系统验证部使用,版本很稳定,由测试团队管理和维护 | | | 目前由测试&产品进行交付前验收 |
PRD环境 | | | (Production):公司内部生产环境,用来作为领导/客户演示或体验的环境,由运维团队管理和维护 | | | 目前是市场,技服,运营等同事体验和验收 |
客户生产环境 | | | 是指正式提供对外服务的环境,连接上互联网即可访问的正式环境,是最重要的环境,由运维&技服团队管理和维护 | | | 目前由公司自营和客户私有化部署,测试可协助验证 |
软测流程
Xmind初学
项目名称
用例路径
用例标题
用例步骤
用例预期
优先级
前置条件
关联需求
Day2
性能测试
概要名词 | 说明 | |
并发用户数 | | | 指的是同一时间段内,系统或应用能够处理的同时进行操作的用户数量 |
响应时间 | | | 指从客户端发出请求开始,到客户端接收到服务器返回的响应结果(包括所有中间处理时间和网络传输时间)所花费的时间 |
TPS | | | 指每秒处理的事务数,TPS=总事务数/总的时间,描述了服务器的处理能力 |
吞吐量 | | | 单位时间内网络上传输的数据量,也可以指单位时间内处理客户请求数量 |
资源利用率 | | | 资源利用率是指系统在处理任务时,已使用的资源量与总资源量的比例。通常用“资源使用量/总的资源可用量x100%”来计算。形成资源利用率的数据。常见资源使用率指标,由CPU使用率,内存使用率,磁盘 |
集合点 | | | 模拟多个用户在同一时刻进行操作,通过设置特定的点来协调并发用户的行为。当一定数量的并发用户到达这个店时,它们会等待知道所有用户都到达,然后一起执行下一个操作或发送请求 |
并发用户数
通用公式:
平均并发用户数为C = nL/T
C是平均并发用户数,n是产生业务的在线用户数量,L是业务产生的平均时间长度,T是指考察的时间长度
基于活跃用户的估算
活跃用户: 指在一定时间段内(如一天,一周,一月)使用过系统的用户
并发用户数 = 活跃用户数 X (平均会话时长 / 平均访问间隔)
TPS
公式:TPS = 总事务数 / 总时间(秒)
规则:TPS = (总业务量 * 80%)/ (总时间 * 20%)
响应时间
响应时间 = 系统响应时间 + 网络传输时间
注: 常规的性能测试工具,响应时间部分的值都包含了这两部分时间
指标 含义 95%Percent 每个事务95%用户的响应时间在该值一下 Minimum 每个事务所有用户最小的行营时间 Average 每个事务所有用户的响应时间算术平均值 Maximum 每个事务所有用户中最大的响应时间 建议接口的95% Percent 指标值低于1秒
Day3
学习冒烟,白黑盒,基础,安全,回归性
冒烟测试
也叫做构建验证测试(Bulid Verification Testing)。通常用于确认新版本的软件是否可以进行基本的共呢个测试或者是否能够正常启动。它的主要目的是在软件发布前快速验证系统的关键功能是否能正常运作。
冒烟测试通常会执行一组进本的测试用例,这些测试用例覆盖了应用程序的核心功能和主要功能点,通常是手动测试实现的
测试时间:通常实在软件开发周期的早期或中期进行。它的目标是确保软件的关键功能已经被完整的集成到系统中,并且系统由于基本的编码错误而无法正常工作的风险较小,一边后续的测试工作可以更有效的进行
回归测试
回归测试(Regression Test)是指在软件项目中,开发人员在修改了软件的代码以修复已经发现的bug后,测试人员在需要重新测试前面已经测试过的内容,以确认此次修改没有引入新的错误。也就是说。回归测试的目的就是检查开发人员在修复已有bug时是否由导致新的bug
完全回归:完全回归是指测试时选择基线测试用例库中的所有用例进行回归测试,这是一种最为保险的策略,相对于部分回归策略,其可以将遗漏回归bug(regression bug)的概率降到最低,但这种方式同时也是所有策略中成本最高的一种方式,尤其是越往后,随着测试用例的不断增多,最后完全回归所需要的时间和成本往往超出了预算
部分回归: 部分回归是指在回归测试时选择基线测试用例库中的一部分用例进行回归测试,而不是所有用例全部执行,相对于完全回归测试,这种测试策略效率很高,并且所需要的时间和成本比较少,但也没有完全回归覆盖率高(或者说遗漏回归bug的概率比完全测试高)。
基于风险选择测试用例 :这种方法是指按照一定的风险标准从基线测试用例库中选择回归测试用例(回归测试包)。首先运行最重要的、关键的和可疑的测试用例,而跳过那些非关键的、优先级别低的或者稳定性高的测试用例,因为这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级。一般而言,测试从主要特征到次要特征。
基于操作剖面选择测试用例 :如果基线测试用例库的测试用例是基于软件操作剖面开发的,那么测试用例的分布情况就反映了系统的实际使用情况。回归测试的测试用例个数可以由测试预算确定,回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性,但实施起来有一定的难度。
- 针对修改的部分选择测试用例 :当测试者对修改的局部化有足够的信息时,可以通过相依性分析分析识别软件的修改情况并分析修改的影响,将回归测试集中在被改变的模块和它的接口上。通常,一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下,回归测试尽可能覆盖受到影响的部分。
白盒
- 白盒测试(White Box Testing),也称作为结构测试或透明盒测试,是一种软件测试方法,旨在检查和评估系统内部的结构,逻辑和代码覆盖率。测试人员了解被测试软件的内部实现细节,使用这些知识来设计和执行测试用例
黑盒
- 黑盒测试(Black Box Testing),关注与对测试系统的功能和接口测试,而不考虑内部实现细节。在黑盒测试中,测试人员只关注系统的输入和输出,通过检查系统的响应和结果来验证是否符合预期行为
Xmind go on
Day5
学操作系统,自动化selenium,RDMS
DI
- DI是Defect Index的简写,意思是缺陷指数,依据处于“打开”状态的BUG的严重程度计算得出的分值
- 计算公式:
DI = 10 * 致命bug个数 + 3 * 严重bug个数 + 0.2 * 一般bug个数 + 0.1 * 提示bug个数
第二周
Day2
再次熟悉用例编写流程与模板,尝试编写用例,正交法
正交法:
正交法来源于正交实验设计,是一种多因素水平的实验设计方法,在软测中它被用来从大量的输入数据组合中挑选出具有代表性的组合进行测试
- 关键术语
- 因素(Factor):测试中的变量或输入条件
- 水平(Level):每个因素可能的取值或状态
- 正交表(Orthogonal Array):用于安排多因素实验
正交表表示法:
正交表通常表示为:Lₙ(mᵏ)
- L:正交表
- n:测试用例数(行数)
- k:最多能安排的因素数(列数)
- m:每个因素的水平数