菏泽网站建设制作,自己的网站如何做推广,桂林山水甲天下,做网站怎么加视频一、一个优秀的测试人员需要具备的素质
技能方面#xff1a; 优秀的测试用例设计能力#xff1a;测试用例设计能力是指#xff0c;无论对于什么类型的测试#xff0c;都能够设计出高效的发现缺陷#xff0c;保证产品质量的优秀测试用例。这就需要我们掌握设计测试用例的方…一、一个优秀的测试人员需要具备的素质
技能方面 优秀的测试用例设计能力测试用例设计能力是指无论对于什么类型的测试都能够设计出高效的发现缺陷保证产品质量的优秀测试用例。这就需要我们掌握设计测试用例的方法、阅读好的测试用例设计案例、积累和总结来提高我们测试用例设计的能力。掌握自动化测试技术编写测试工具自动化测试用例。掌握自动化测试技术可以吧你从大量重复性的手工劳动中解放出来这样就可以把更多的精力花在更多类型的测试上。业务快速学习能力我们在工作的时候不可能一直做一类工作不同的工作小组负责不同的业务所以就需要我们快速学习不同的业务。开发能力掌握一定的开发技术这对于测试人员来说是一个优势。 综合方面 沟通能力测试工程师的沟通能力会对测试工作的开展具有很大的影响良好的沟通能力可以让我更快更好的完成我们的工作。文字表达能力测试用例是用文字写出来的你找到的bug也要通过文档来具体的描述。我们在测试完成之后是需要总结出来一个测试文档的里面详细记录了有那些bug,这些bug在哪里产生了什么问题等等都需要我们能够表述清楚。抗压能力抗压能力并不是测试人员独有的这是所有从事互联网人员都需要具备的能力。比如我们工期时间比较紧的时候就需要我们加班。责任感责任感是任何工作都需要的对于测试工作而言测试往往是产品质量的最后一个把关者由于测试工作成效很难衡量测试用例执行、bug数量的多少都无法说明产品的质量是否合格所以责任感是最重要的测试必备素质之一。 二、衡量软件测试结果的依据——需求
1、什么是需求
需求可以分为两部分一部分是用户需求一部分是软件需求 用户需求可以简单理解为甲方提出的需求如果没有甲方那么就是终端用户使用产品时必须要完成的任务该需求一般比较简略。软件需求或者较功能需求、该需求会详细描述开发人员必须实现的软件功能。 2、案例—平台支持邮箱注册
我们实现一个支持使用邮箱注册的一个注册系统如下 用户需求平台支持邮箱注册。
软件需求
1.1.1.1、注册账号
1.1.1.1.1、 功能概述 用户可以通过填写邮箱信息在平台注册个人用户。
1.1.1.1.2、用户角色 匿名用户。
1.1.1.1.3、前置条件 无。
1.1.1.1.4、输入
序号栏目名称栏目说明长度类型备注1姓名必填、录入个人姓名6至15字符型2电子邮件必填、录入电子邮箱6至15字符型3密码必填输入的密码隐藏*号显示最短6位6至15字符型4确认密码必填输入的密码隐藏*号显示最短6位6至15字符型5验证码必填、录入验证码字符型6注册注册操作操作型
1.1.1.1.5 处理
1.1.1.1.5.1 基本事件流
1、 用户选择注册
2、 系统展现用户协议界面并请用户确认是否同意用户协议 若用户不同意协议系统禁止用户注册。 若用户同意协议用户进行注册信息填写。
3、 用户填写注册信息。 注册个人填写姓名电子邮箱密码确认密码验证码。
4、 用户提交注册信息
5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户若未收 到激活邮件可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、 用户可执行激活操作直接跳转至注册邮箱门户页面。
7、 用户通过接收到的电子邮件中的激活信息激活账号用户注册完成流程结束。
1.1.1.1.5.2 扩展事件流 用户注册并激活成功后第一次登录平台时提示用户完善信息
1.1.1.1.5.3 异常事件流
若用户未收到激活邮件可在登录界面录入电子邮件及密码后再次发送激活邮件。 每次发送的激活邮件仅在发送邮件后起24小时之内有效超过24小时后需重新发送激活邮件。
1.1.1.1.6 输出 用户注册成功
1.1.1.1.7 后置条件 该模块为用户登陆等的前置模块
3、从软件测试人员角度看需求
需求是测试人员开展软件测试工作的依据。
在具体设计测试用例的时候首先需要搞清楚每一个业务需求对应的多个软件需求点软后分析出每个软件需求点对应的多个测试需求点然后针对每个测试需求点设计测试用例。
过程如下业务需求—软件功能需求点 —测试需求点—测试用例 对一个软件功能需求点进行拆分涉及到那些测试需求点。功能、兼容性、安全性、性能等等。每个测试需求点在拆分多种测试用例如用户登录的软件功能的功能测试需求点可以拆分为输入的密码和用户名正确验证是否登录成功、用户名和密码中出现空格登录时是否成功、用户名和密码是否大小写是否敏感。 三、测试用例
测试用例是为了实施测试而向被测试的系统提供的一组集合这组集合包含测试环境、操作步骤、测试数据、预期结果等要素。 测试环境就比如我们在力扣上做题他提供给我们一个测试环境Chrome浏览器测试数据我们将代码完成之后会出现测试用例的通过率涉及到的数据就是测试数据。预期结果我们做完题之后期待的通过率为100%这就是预期结果。 测试用例提高测试人员工作效率、降低测试人员工作的重复性问题。测试用例是建立自动化的基础。
四、软件错误bug
1、什么是bug
软件错误的一般定义程序与规格说明书之间不匹配。这是比较片面的说法准确的来说当且仅当规格说明是存在的并且正确软件需求规格说明书程序与规格说明之间的不匹配才是错误预期结果 ! 执行结果即bug.
当需求规格说明书没有提到的功能判断标准以最终用户为准当程序没有实现其最终用户合理预期功能要求时就是软件错误bug。
2、如何描述一个bug
1、发现问题的版本
开发人员需要知道出现问题的版本才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2、问题出现的环境
环境分为硬环境和软环境如果是web项目需要描述浏览器版本客户及操作系统等如果是app项目需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
猫叔重现的最短步骤方便开发人员复现问题。
4、预期行为的描述
要让开发人员知道怎样才是正确的尤其要以用户的角度来描述程序的行为是怎样的。如果依据需求提出的故障能写明需求的来源是最好的。
5、错误行为描述
描述错误的现象。crash等可以上传logUI问题可以有截图。
6、不要把多个bug放在一起
在无法确认是同一段代码造成的故障时不要将bug放在一起提交。
3、如何定义bug的级别
1、Blocker崩溃
阻碍开发或测试工作的问题造成系统崩溃、死机、死循环、导致数据库数据丢失与数据库连接错误主要功能丧失基本模块缺失问题。
2.Critical严重
系统主要功能部分丧失数据库保存调用错误用户数据丢失一级功能菜单不能使用等问题这就是严重的bug.
3、Major一般
功能没有完全实现但是不影响使用功能菜单存在缺陷但不会影响系统稳定性。比如操作时间长查询时间长、格式错误等。
4、Minor次要
界面、性能缺陷、建议类的问题不影响操作功能的执行可以优化性能的方案等。比如错别字、界面格式不规范等问题。
4、bug的生命周期
New新发现的Bug未经过评审决定是否指派给开发人员进行修复。Open确认是Bug并且认为需要进行修改指派给响应的开发人员Fixed开发人员进行修改后标识成修改状态有待测试人员的回归测试验证Rejdcted如果认为不是Bug则拒绝修改Delay如果认为暂时不需要修改或暂时不能修改则延后修改。Closed修改状态的Bug经测试人员的回归测试验证通过则关闭Bug。Reopen如果经验证Bug仍然存在则需要重新打开Bug开发人员重新修复。 五、开发模型和测试模型
1、软件生命周期
软件生命周期是指从软件产品的设想开始到软件不在使用而结束的时间。如果把软件看成时有生命的事务那么软件的生命周期可以分为6个阶段即需求分析、计划、设计、编码、测试、运行维护。 1.1、软件测试的生命周期
软件测试的生命周期为需求分析-测试计划-测试设计、测试开发-测试执行-测试评估
1、需求分析
验证需求的正确性以及合理性。接着便是细化需求找出测试点方便后面写测试用例。
2、测试计划
确定软件有谁测试什么时候开始测试什么时候结束测试、有谁测试
3、测试设计、测试开发
根据需求、写出测试用例手工测试用例、自动化测试用例编写测试工具
4、测试执行
测试用例设计完成之后就要执行测试用例来验证程序功能了。在执行测试用例的过程中可能会遇到软件功能与需求不相符的情况也就是出现bug测试测试人员需要将bug记录下来交给开发人员来处理。
5、测试评估
在测试完成之后就需要测试人员编写一个测试报告。
测试报告中包含了下面的内容
测试人员测试时间开发时间~结束时间开发人员开发时间测试用例bug
2、开发的五大模型
2.1、瀑布模型 特点瀑布模型的每一个阶段都只执行一次因此是线性顺序进行的软件开发模式。
优点每个阶段做什么产出什么非常清晰
缺点风险往往迟滞后期的测试阶段才显露因此失去及早纠正的机会。
项目的使用小型的项目使用于这种模型。
2.2.、螺旋模型
一般在软件开发初期需求不是很明确时采用渐进的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤为适合。这种迭代开发的模式给软件测试带来了新的要求他不允许有一段独立的测试时间和阶段测试必须跟随开发的迭代而迭代。因此回归测试的重要性就不言而喻了。 优点 每个阶段都会进行风险分析避免一些线上问题发生
缺点风险分析依赖于专业的风险评估人员评估这也就存在分析出错的问题反复分析会出现大量的人力和财力的投入。
适用项目庞大的、复杂的并且具有高风险的项目
2.3、增量迭代
假设我们要实现一个项目该项目有3个模块ABC。
增量模型将3个模块按顺序开发先完成A然后完成B接下来完成C按照顺序一个一个完成。
迭代模型先将3个模块的基础框架建好然后在这个基础上继续完善3个部分的一些代码。就像盖房子一样将整体的墙体构建完成然后再对每个房间进行细节上的完善。
2.4、敏捷思想
2001年以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过 程派聚集在犹他州的Snowbird决定把“敏捷”(Agile)作为新的过程家族的名称。
在会议上他们提出了《敏捷宣言》http://agilemanifesto.org/ 我们通过身体力行和帮助他人来 揭示更好的软件开发方式。经由这项工怍我们形成了如下价值观。 个体于交互重于过程和工具可用的软件重于完备的文档客户协作重于合同谈判响应变化重于遵循计划再每对比对中后者并非全无价值但我们更看重前者。 scrume开发模式
scrum开发模型中的三大角色
scrum由product owner产品经理、scrum master(项目经理)和team研发团队组成。 其中产品经理负责整理用户故事定义其商业价值对其进行排序指定发布计划对产品负责。项目经理负责召开各种会议协调项目为研发团队服务。研发团队则由不同技能的成员组成通过紧密协同完成每一次迭代的目标交付产品。 迭代开发
与瀑布不同scrum将产品的开发分解为若干个小sprint迭代其周期从1周到4周不等单不会超过4周参与的团队成员一般是5到9人每期迭代要完成的user story用户故事/需求是固定的每次迭代会产生一定的交付。
scrum的基本流程。 产品负责人负责整理user story 形成product backlog产品代办事项发布计划会议产品经理product owner负责讲解user story对其进行评估和排序发布计划会议的产出就是指定出这一期迭代要完成的story列表product backlog产品代办事项。迭代计划会议项目团队对每一个story进行任务分解分解的标准是完成该story的所有任务每个任务都有明确的负责人并完成工时的初估计。每日例会每天scrum master召集站立会议团队成员回答昨天做了什么今天计划做什么有什么问题。演示会议迭代结束之后召开演示会议相关人员都受邀参加团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来由产品经理整理形成新的story.回顾会议项目团队本期迭代进行总结发现不足制定改进计划下一次迭代继续改进以达到持续改进的效果。 3、测试模型
3.1、v模型 各阶段的大概过程 用户需求产品经理将用户需求收集形成软件需求需求分析与系统设计验证需求是否正确确定编程语言确定框架等。概要设计项目结构如何设计。详细设计每个接口涉及那些库表涉及那些任务。编码写代码。单元测试我们再编写项目的时候再Controller层编写完成一个方法的时候就会进行单元测试。继承测试将许多方法集成测试不同模块接口见是否可以正常的配合使用。系统测试对整个系统功能进行测试也要保证模块和模块之间不会相互影响。验收测试产品和运营确认软件系统符合用户和利益相关者的要求。 特点左边是开发右边是测试。类似于瀑布模型
优点测试被划分成许多类型。
缺点测试人员介入太晚发现问题时机太晚。
3.2、W模型双V模型 特点开发是一个V测试是一个V
优点测试人员尽早介入了需求。
缺点测试人员和开发人员一定程度上还是串行的不能拥抱变化不能使用于敏捷。
V模型和W模型都不能拥抱变化一旦开始就不能再修改用户需求了。不能添加新的需求这就是不能拥抱变化。
