测试基础: 测试流程:第一课回放
➢全 部测试用例都执行完成。 ➢未修改bug都被确认或置为应有状态,暂缓修改的问题都有详尽的解释。 ➢测试报告编写完成。 ➢测试收尾 工作结束。 ➢测试总结完成。 ➢项目 处于试运行或上线阶段 ➢在测试计划中定 义结束标准 V如计划中规定:系统在一-定性能下平稳运行72小时,本版本中没有严重的BUG,普通BUG的数量在3以下,BUG修复率90%以上 V实际测试达到 上述要求,然后由开发经理,测试经理,项N经理共同签字,认同测试结束,版本即可发布。
➢能正常打开或进入短信界面 ➢短信可以正常编辑、修改、删除 ➢短信可以正常发送和接收 ➢短信页面字体、颜色显示正常 ➢短信字体可调整 ➢给多人同时发短信 ➢给特殊号码发送短信 V如运营商(手机号所属运营商、其他运营商) V不存在手机号 V服务号(收费、不收费) ➢接收验证码 ➢短信耗电量测试 ➢短信不耗流(联网、不联网) ➢短信干扰测试 V编辑短信期间(已经编辑好、正在打字),电话进来 V编辑短信期间(已经编辑好、正在打字),收到短信 V隐藏到后台(已经编辑好、正在打字),进行其他操作,再返回
人力资源、硬件资源、软件资源。
测试策略主要包括功能测试、性能测试、兼容性测试、可用性测试、易用性测试等。测试范围有时候等价于测试策略,有时候可以表示要进行测试的某个软件部位。
也称冒烟测试、版本验证测试、小版本验证测试、版本构建测试。冒烟测试用例是一-组想先运行以确定这个给出的小版本是否可以测试的测试用例。冒烟测试主要测试软件的基本功能,以判断整个软件值不值得进行大规模测试。通常由一个 人进行1-2小时的测试,- -般不测试次要功能和各种错误。
➢冒烟测试 V也称为小版本验证测试 V对软件基本功能的验证 V通过对软件基本功能的测试,确定能否进行后续大规模的测试,如果冒烟测试通过,则后续可以进行大规模测试,否则将软件打回开发 V一一般,冒烟测试由一一个人进行,通常耗时1-2小时 V不同测试类型的冒烟测试可能会有不同,比如性能测试的冒烟测试需要的人力和时间也许会拉长 ➢集成测试 V主要是测试软件多个单元合并到--起时需要的测试 V通常测试软件各部件之间的接口和交互 V--般由多个懂开发的测试人员进行|
包含了产品概述、测试区域/测试策略/测试范围/测试目标(测试项、被测特征)、测试配置/测试资源、测试周期、进度安排(测试任务、人员安排)、测试方法/途径、测试交流、风险分析等内容。目的是指导测试过程,规定测试活动的范围、方法、资源和进度:明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的责任人以及与计划相关的风险。
就说最近的这次网站功能的测试吧首先得到相关文档(需求文档和设计文档).理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK了),考虑到测试环境,测试用例,测试时间等问题。
第二步:设计测试用例.测试策略是:把网站部分的功能点测试完.然后在进行系统测试(另外个模块呢有另-个测试人员负责,可以进行联调测试),网站模块的测试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑) :这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3个步骤,网站才算完成了它的任务。有3个步骤呢,就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50个用例。界面测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。
第三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了.只有有机器能空于下来做该功能测试就可以做了).因为网站本身的环境搭建和其他的系统有点不同,它需要的测试环境比较烦,需要web服务器(Apache tomcat),不过这次需求,网站部分只用到了tomcat,所以只要有tomcat即可
第四步:执行测试
回答思路正常 情况一般每天执行20个左右的用例(指的是概括的用例细分可以有很多).刚开始测试的时候. bug比较多.需要很多时间和开发交流沟通。案例执行会比较慢。越到后面就越快了。
1.看时间,如果时间比较充足,会全部回归,回归时候因为自己操作比较熟练,然后系统基本.上也没有bug。所以执行案例的速度会比较快。 2.如果时间比较紧,就会挑选重要模块来回归测试了
一般由用户/客户进行的确认是否可以接受二 个系统的验证性测试。验收测试根据用户需求,业务流程进行的正式测试以确保系统符合所有验收的准则。
客户或用户,测试人员可以介入。
对系统或子系统建立信心」对系统业功能性的特性赢得信任
Alpha测试:潜在的客户/用户在开发场地进行的测试,也叫内部测试。 Beta测试:由潜在客户/用户在自己的环境下测试软件系统,也叫公测。
软件正常使用后,对软件的变更、更新进行测试
性能表现处理速度、响应时间、CPU 使用、内存使用、硬盘使用等。 负责测试:通过不断增加负载来测试-个系统的性能。 压力测试:通过增加负载超过系统正常工作能力米考察系统能否在异常情况下正常工作
测试-一个软件能做什么,是不是完成后了应该做的工作,没做不该做的工作。
白盒测试也称结构测试、逻辑驱动测试、基于程序木身的测试,是对程序结构进行的测试。
简单讲,软件测试是发现缺陷的过程: IEEE中的定义是,软件测试是使用人工或自动手段来运行或测定某个系统的过程,目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
(1)验证软件是否满足各类文档说明书等规定的软件质量要求 (2)找出软件缺陷 (3)为软件产品的质量测量和评价提供依据
功能代表--个软件能做什么;性能反映软件运行的速度或效率、占用资源的多少等指标:兼容性表示一个软件与其所在运行环境的依赖程度,包括与硬件、操作平台、其他软件的依赖。
➢用例要完整、简洁、-致 ➢至少含有编号、 标题、操作步骤和预期结果。 ➢用例要表明测试目的 ➢用例覆 盖程度要高 ➢用例能够使工作量最小化 ➢用例描述正确、 规范 ➢含有正确的、 规范的测试标题和编号入 ➢用例的分类以及描述要足够清晰 ➢用例要具有可测试性 ➢测试用例易于维护 ➢如果被测对象有所升级,测试用例的说明或者脚本是不是容易维护呢? ➢可复用:比如版本升级后仍然可用 ➢可重复性:不管谁执行此用例, 结果一样。 ➢可追踪性 ➢用例能追踪到一 一个具体的需求。
软件主要的功能。流程、开发环境(开发语言<含数据类型>、数据库、中间件)、运行环境(硬件、软件、网络、软件架构)、用户群、测试范围、测试优先级。
测试执行发现缺陷时立即提交缺陷。
入口准则是进行-项测试工作前需要准备好的前提条件。 出口准则是-项测试工作可以结束的前提条件。
项目经理、开发经理、测试经理、测试人员、开发人员、市场经理、客户等。
编写或设计需求评审检查单,比如可以检查有无错别字、病句,标点符号使用是否正确,格式是否一-致, 是否还有多余需求,是否有错误需求,是否有遗漏需求等。
检查单(编写或设计需求评审检查单,比如可以检查有无错别字、病句,标点符号使用是否正确)。一般由测试人员进行
测试目标:功能测试、性能测试、界面测试、易用性测试、兼容性测试、安企性测试 测试策略:某类别测试的过程、方法以及方法如何应用,测试的注意事项等 测试环境:硬件环境、软件环境、网络环境 前置条件:进行某些测试工作需要做好的准备条件 测试范围:软件需要测试的这个部位
要测试。维护测试(含升级测试)、数据迁移测试、备份恢复测试、灾难恢复测试等
编写需求分析并评审→编写测试计划并评审→设计测试用例并评审一搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结。
(1)收集各类文档,仔细阅读文档,提出问题,分析问题或沟通解决,整理需求信息。 (2)编写测试需求分析说明书:功能分解,编写检查点和测试点。 (3)需求评审。
软件主要的功能、流程、开发环境(开发语言<含数据类型>、数据库、中间件)、运行环境(硬件、软件、网络、软件架构)、用户群、测试范围、测试优先级。
有功能测试、性能测试、负载测试、强度/压力测试、易用性测试、安全测试、配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、可用性测试。
➢TCP/IP 协议 V主要层次结构为: 应用层/传输层/网络层/数链路层。 ➢ARP (Address Resolution Protocol) (地据址解析协议)
分离缺陷,复现缺陷
提交了一个缺陷库中存在或者开发从员己经州道的缺陷。 1、如果缺陷是跟同事提交的重复(任务分工解决,也可以在提交之前查询下库缺陷是否存在。 2、如果缺陷是与自己提交的缺陷重复,则需要提高发现缺陷的能力,通过提高开发能力来理解两个缺陷本质上是一个缺陷。
白盒测试也称结构测试、逻辑驱动测试、基于程序本身的测试,是对程序结构进行的测试。
与变更相关的测试是对修改过的程序业行的测试。 确认测试(再测试)和回归测试。
静态测试:不执行程序的测试。针对文档和不需执行的代码。 动态测试需要执行程序,方法- -般采用黑盒测试方法和白盒测试方法。
软件测试人员提交缺陷报告: 测试负责人审核后将缺陷报告分配给相关的开发人员修改: 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测 返测通过的缺陷报告由负责人关闭 返测未通过的缺陷报告直接返回开发人员重新修改)然后再由测试人员返测直到测试 和开发达成一.致处理意见。
照着需求写用例时遇到的问题多吗? 流程不清晰,脑图和原型图。输入框的长度未交代清楚