绵阳网站开发公司,问卷调查,python在线免费网站,wordpress轮翻图参数概念篇
测试相较于开发岗位而言#xff0c;如果同学们的编程能力稍微弱一些#xff0c;可以尝试测试方向#xff08;更简单#xff09;
1. 什么是软件测试 最常见的理解是#xff1a;软件测试就是找BUG#xff0c;发现缺陷。 早期#xff0c;人们更多的将测试看成是对…概念篇
测试相较于开发岗位而言如果同学们的编程能力稍微弱一些可以尝试测试方向更简单
1. 什么是软件测试 最常见的理解是软件测试就是找BUG发现缺陷。 早期人们更多的将测试看成是对软件产品“检验”检查软件的每个功能是否运行正常。 1983年Bill Hetzel将软件测试定义为软件测试就是一系列活动这些活动是为了评估一个程序或者 软件系统的特性或能力并确定是否达到了其预期的效果。 软件测试就是验证软件产品特性是否满足用户的需求 从这话我们可以看出以下两点 测试试图验证软件是“工作的”也就是验证软件功能执行的正确性测试的活动是以测试人员“预期的结果”为依据这里的“预期结果”指的是需求定义。 2. 为什么要有测试(测试的重要性)
假设我们在此时在开发支付模块的功能我们需要优化支付这块的代码( coding… ) 我们写完代码后直接进行上线 (假设此时代码存在报警 xxxx用户支付支付失败 xxxx用户支付支付失败 xxxx用户支付支付失败 …) 如果上线后出现这种情况用户始终无法进行支付体验感不好那么也会影响软件的使用情况 所以是需要测试通过后再进行上线 测试保障软件质量许多公司将测试部门命名为质量保障部
举例 从上图我们可以看出软件测试的场景很多 软件测试的特点 软件测试只是一个样本试验具有不可穷尽性。
3. 软件测试和软件开发的区别 4. 软件测试和软件调试之间的区别 5. 软件测试的岗位
软件测试工程师工程师的主要工作一般包含需求分析、编写测试计划和测试方案、设计测试用例、执行测试用例、跟踪BUG、编写测试报告等 测试开发工程师根据项目的特点来开发一些自动化测试的脚本或自动化测试的工具或者是软件测试工作中用到的提高工作效率的小工具什么的从而能够更有效地进行测试提高软件产品的质量。 测试开发工程师工作的目的就是为了更高效更快捷地让测试工程师进行测试工作测试开发岗位一般要求一定的开发能力解决问题的能力尤为重要。 性能测试工程师针对系统进行性能测试包括使用工具和编写性能自动化测试脚本。 安全测试工程师主要分析产品可能会出现的安全问题做各个方面的渗透测试提高产品的安全性 其它系统测试工程师嵌入式测试工程师硬件测试工程师。
6. 一个优秀的测试人员需要具备的素质 7. 软件测试的发展
软件调试为主发生在20世界50年代。1957年Charles Baker对调试和测试进行了区分。 这是软件测试史上一个重要的里程碑标志已经有独立的软件测试了。1979年《软件测试的艺术》中给出了软件测试的定义测试是为发现错误而执行程序的过程。 它意味着软件测试不仅要证明软件做了该做的事情也要保证它没做不该做的事情。1983年美国国家标准局(National Bureau of Standards)发布了VVTVVT提出了测试界很有名的两个名词验证(Verification)和确认(Validation)。 这些意味着软件测试正作为一门独立的专业的具有影响力的工程学发展起来了。预防为主是当下软件测试的主流思想之一.软件测试已经贯穿到了整个软件开发的生命周期当中了。
基础篇
1. 需求
满足用户期望或正式规定文档合同、标准、规范所具有的条件和权能包含用户需求和软件需求。 IEEE定义软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要 满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求非功能性需求对设计和实现提出了限制比如性能要求质量标准或者设计限制。 在多数软件公司会有两部分需求一部分是用户需求一部分是软件需求 **用户需求**可以简单理解为甲方提出的需求如果没有甲方那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。 **软件需求**或者叫功能需求该需求会详细描述开发人员必须实现的软件功能。 大多数公司在进行软件开发的时候会把用户需求转化为软件需求开发人员和测试人员工作的直接依据就是软件需求 软件需求是测试人员进行测试工作的基本依据。
从软件测试人员角度看需求
需求是测试人员开展软件测试工作的依据。 在具体设计测试用例的时候首先需要搞清楚每一个业务需求对应的多个软件功能需求点然后分析出 每个软件功能需求点对应的多个测试需求点然后针对每个测试需求点设计测试用例。 过程如下业务需求—软件功能需求点—测试需求点—测试用例 以“用户登陆”为例来阐述下整个过程 测试人员根据软件功能需求找到测试需求点 为什么需求对软件测试人员如此重要 从软件功能需求出发无遗漏的识别出测试需求是至关重要的这将直接关系到用例的测试覆盖率 对于识别出的每个测试需求点需要采用具体的设计测试用例的方法来进行测试用例的设计
2. 测试用例
测试用例Test Case是为了实施测试而向被测试的系统提供的一组集合这组集合包含测试环境、操作步骤、测试数据、预期结果等要素。 测试用例解决了两大问题测什么怎么测。 测试过程中可能会遇到以下问题 –不知道是否较全面的测试了所有功能 –测试的覆盖率无法衡量 –对新 版本的重复测试很难实施 –存在大量冗余测试影响测试效率 测试用例的产生就是为了解决上述的问题。
巩固一下完成一个用例的小例子 手机打电话 打电话前 功能相关 1. 手机号码是否正确 2. 电话是否存在黑名单 3. 不同地区的电话号码 … 性能相关 … 打电话过程中 … 挂机后 …
3. BUG 第一个bug 1945年9月的某天在一间老式建筑里从窗外飞进来一只飞蛾此时Hopper正埋头工作在一台名为Mark Il的计算机前并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器电子机械装置那时还没有使用晶体管。突然Mark II死机了。Hopper试了很多次还是不能启动他开始用各种方法查找问题最后定位到了某个电路板的继电器上。Hopper观察这个继电器惊奇地发现一只飞蛾已经被继电器打死。Hopper小心地用镊子将飞蛾夹出来用透明胶布贴到“事件记录本”中写上“第一个发现虫子的实例”。Hopper的事件记录本连同那只飞蛾现在都陈列在美国历史博物馆中。 软件错误的一般定义 程序与规格说明之前不匹配 。 4. 软件生命周期 5. 开发模型和测试模型
随着软件工程学科的发展人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编 写而是扩展到了整个软件生命周期如软件基本概念的形成、需求分析、设计、实现、测试、安装部 署、运行维护直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作例如过程管 理、产品管理、资源管理和质量管理在这些方面也逐步地建立起了标准或规范。
瀑布模型Waterfall Model
瀑布模型在软件工程中占有重要地位是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一 次因此是线性顺序进行的软件开发模式。 优点 强调开发的阶段性强调早期计划及需求调查强调产品测试 缺点 依赖于早期进行的唯一 一次需求调查不能适应需求的变化由于是单一流程开发中的经验教训不能反馈应用于本产品的过程 风险往往迟至后期的测试阶段才显露因而失去及早纠正的机会。 瀑布模型的一个最大缺陷在于可以运行的产品很迟才能被看到。这会给项目带来很大的风险尤其是 集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现通常会导致前面阶 段的工作大面积返工业界流行的说法是“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷 例如在前期阶段未发现的错误会传递并扩散到后面的阶段而在后面阶段发现这些错误时可能已经 很难回头再修正从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想在这 个基础上做出自己的修改。例如细化了各个阶段在某些重点关注的阶段之间掺入迭代的思想。 在瀑布模型中测试阶段处于软件实现后这意味着必须在代码完成后有足够的时间预留给测试活动 否则将导致测试不充分从而把缺陷直接遗留给用户。 螺旋模型Spiral Model
一般在软件开发初期阶段需求不是很明确时采用渐进式的开发模式。螺旋模型是渐进式开发模型的代 表之一。 **这对于那些规模庞大、复杂度高、风险大的项目尤其适合。**这种迭代开发的模式给软件测试带来了新的要求它不允许有一段独立的测试时间和阶段测试必须跟随开发的迭代而迭代。因此回归测试的重 要性就不言而喻了。 优点 强调严格的全过程风险管理强调各开发阶段的质量提供机会检讨项目是否有价值继续下去 缺点 引入非常严格的风险识别、风险分析和风险控制这对风险管理的技能水平提出了很高的要求这需要人员、资金和时间的投入 增量、迭代
增量开发能显著降低项目风险结合软件持续构建机制构成了当今流行的软件工程最佳实践之一。增量开发模型鼓励用户反馈在每个迭代过程中促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此在这种开发模式下每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本意味着测试需要频繁进行测试人员需要与开发人员更加紧密地协作。 增量通常和迭代混为一谈但是其实两者是有区别的。增量是逐块建造的概念例如画一幅人物画我们可以先画人的头部再画身体再画手脚……而迭代是反复求精的概念同样是画人物画我们可以采用先画整体轮廓再勾勒出基本雏形再细化、着色。
敏捷
2001年以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird决定把“敏捷”(Agile)作为新的过程家族的名称。 在会议上他们提出了《敏捷宣言》 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍我们形成了如下价值观。 个体与交互重于过程和工具 可用的软件重于完备的文档 客户协作重于合同谈判 响应变化重于遵循计划 在每次对比对中后者并非全无价值但我们更看重前者。 由敏捷宣言可以看出敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情这是在软件工程几十年的发展过程中相对被忽略的领域。 敏捷开发有很多种方式其中scrum是比较流行的一种。
scrum
scrum里面的角色
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。 其中product owner负责整理user story(用户故事)定义其商业价值对其进行排序制定发布计划对产品负责。 scrum master 负责召开各种会议协调项目为研发团队服务。 研发团队则由不同技能的成员组成通过紧密协同完成每一次迭代的目标交付产品。
迭代开发
与瀑布不同scrum将产品的开发分解为若干个小sprint(迭代)其周期从1周到4周不等但不会超过4 周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交 付。 scrum的基本流程 scrum的基本流程如上图所示 产品负责人负责整理user story形成左侧的product backlog。 发布计划会议product owner负责讲解user story对其进行估算和排序发布计划会议的产出就是制定出这一期迭代要完成的story列表sprint backlog。 迭代计划会议项目团队对每一个story进行任务分解分解的标准是完成该story的所有任务每个任务都有明确的负责人并完成工时的初估计。 每日例会每天scrum master召集站立会议团队成员回答昨天做了什么今天计划做什么有什么问题。 演示会议迭代结束之后召开演示会议相关人员都受邀参加团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来由po整理形成新的story。 回顾会议项目团队对本期迭代进行总结发现不足制定改进计划下一次迭代继续改进已达到持续改进的效果。
软件测试v模型 V模型最早是由Paul Rook在20世纪80年代后期提出的目的是改进软件开发的效率和效果。是瀑布模型的变种 明确的标注了测试过程中存在的不同类型的测试并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系 V模型指出单元和集成测试应检测程序的执行是否满足软件设计的要求系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标验收测试确定软件的实现是否满足用户需要或合同的要求 局限性:仅仅把测试作为在编码之后的一个阶段未在需求阶段就进入测试 软件测试W模型 W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成分别代表测试与开发过程图中明确表示出了测试与开发的并行关系。 W模型特点测试的对象不仅是程序需求、设计等同样要测试测试与开发是同步进行的 W模型优点有利于尽早地全面的发现问题。例如需求分析完成后测试人员就应该参与到对需求的验证和确认活动中以尽早地找出缺陷所在。同时对需求的测试也有利于及时了解项目难度和测试风险及早制定应对措施显著减少总体测试时间加快项目进度。 局限性需求、设计、编码等活动被视为串行的测试和开发活动也保持着一种线性的前后关系上一阶段完全结束才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况W模型并不能解除测试管理面临着困惑
6. 软件测试的生命周期 7. 软件测试软件开发生命周期
需求阶段 –测试人员了解需求、对需求进行分解得出测试需求 计划阶段 根据需求编写测试计划/测试方案 设计阶段 –测试人员适当的了解设计对于设计测试用例是很有帮助的测试人员搭建测试用例框架根据需求和设计编写一部分测试用例 编码阶段 –测试人员一般是不需要编码的但已经编码的模块专业的白盒测试人员可以计划执行单元测试完善、细化测试用例以及调整测试计划和方案。 测试阶段 –测试阶段是软件测试人员最为重要的工作阶段根据测试用例和计划执行测试在执行的过程中记录、管理缺陷测试完成后编写测试报告。 运行维护 –测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解加上测试人员的沟通表达能力一般都比较强所以测试人员可以参与用户使用软件的培训在试运行项目时收集问题并及时反馈给相关负责人。
8. 如何描述一个bug
一个合格的bug描述应该包括以下几个部分 1、发现问题的版本 开发人员需要知道出现问题的版本才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。 2、问题出现的环境 环境分为硬件环境和软件环境如果是web项目需要描述浏览器版本客户机操作系统等如果是app项目需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。 3、错误重现的步骤 描述问题重现的最短步骤。 4、预期行为的描述 要让开发人员指导怎么样才是正确的尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障能写明需求的来源是最好的。 要相信测试人员是最懂需求的。 5、错误行为的描述 描述错误的现象。crash等可以上传logUI问题可以有截图。 6、其他 某些公司会有一些其他的要求例如故障的分类功能故障界面故障兼容性故障等。有些有优先级的分类严重影响测试需要开发人员优先修改的可以设置优先级为高。 7、不要把多个bug放到一起 在无法确认是同一段代码造成的故障时不要将bug放在一起提交 提交了如下bug 1、在短信列表选择一条短信进行删除删除失败 2、在短信列表选择一条短信进行查看在查看页面进行删除删除失败 倾向于第二种 故障发现版本VPS20180226_01 故障类别兼容性 故障优先级中 故障标题:ie下界面显示异常界面文字有重叠 故障描述 测试环境win7IE8 测试步骤1、打开vps首页点击“通知”链接进入通知页面 预期结果通知页面显示正确一页显示10条通知按时间顺序倒序排列 实际结果页面显示10条通知通知顺序正确但是页面文字有重叠 附件上传截图 如何定义bug的级别 bug的定义每个公司都不一致在定义级别之前需要查看公司规范。 以下为样例 1、Blocker崩溃 阻碍开发或测试工作的问题造成系统崩溃、死机、死循环导致数据库数据丢失与数据库连接错 误主要功能丧失基本模块缺失等问题。如代码错误、死循环、数据库发生死锁、重要的一级菜单 功能不能使用等该问题在测试中较少出现一旦出现应立即中止当前版本测试。 2、Critical严重 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符模块无法启动或调用程序重启、自动退出关联程序间调用 冲突安全问题、稳定性等。如软件中数据保存后数据库中显示错误用户所要求的功能缺失程序 接口错误数值计算统计错误等该等级问题出现在不影响其他功能测试的情况下可以继续该版本测 试。 3、Major一般 功能没有完全实现但是不影响使用功能菜单存在缺陷但不会影响系统稳定性。如操作时间长、查询 时间长、格式错误、边界条件错误删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最 多 4、Minor次要 界面、性能缺陷建议类问题不影响操作功能的执行可以优化性能的方案等。如错别字、界面格 式不规范页面显示重叠、不该显示的要隐藏描述不清楚提示语丢失文字排列不整齐光标位置 不正确用户体验感受不好可以优化性能的方案等此类问题在测试初期较多优先程度较低在测 试后期出现较少应及时处理
9. bug的生命周期
每个公司、每一个工具对bug生命周期的定义都是不一致的下面仅是一个常见的例子 测试人员应该跟踪一个Bug的整个生命周期从Open到Closed的所有状态。 BUG状态转换图 Delay(延期)的bug是一定会被修复嘛 – 是的 理论上而言是一定会被修复的 缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。 例如测试人员新发现的Bug必须由测试组长评审后才决定是否Open并分派给开发人员。测试人员Open的Bug可以直接分派给Bug对应的程序模块的负责人也可以要求都先统一提交给开发主管由开发主管审核后再决定是否分派给开发人员进行修改。 Bug的跟踪以及状态变更应该遵循一些基本原则 测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试确保相同的问题不再出现才能关闭缺陷。 对于拒绝修改和延迟修改的Bug需要经过包含测试人员代表和开发人员代表、用户方面的代表或代表用户角度的人的评审。
10. 如何开始第一次测试
作为一个菜鸟在进入测试团队开始第一次测试的时候我们需要做很多的准备 1、阅读所有项目有关的文档包括需求文档、设计文档、用户手册 2、尽可能参加各种项目会议了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务专业性较强的项目例如银行业务需要了解各种业务知识如高低柜、一二三类账户等、存款、贷款等。 3、熟悉项目所使用的测试管理工具、配置管理工具获取对应的地址和登录方式 4、阅读已有的测试方案和测试案例 5、阅读旧有的bug库了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则 6、了解公司的规范要求特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等 在进行了以上的准备工作之后第一次测试工作到来了我们需要与测试组长确认具体的工作内容 1、测试的计划是什么 2、测试的内容是什么test case有多少安排了几天执行有没有自由测试的时间 3、我要测试的内容开发人员是谁需求人员是谁 4、分配给我的测试内容是否需要特殊的测试资源资源是否满足需要 在我们确认了以上内容之后就可以开始测试的执行了
11. 测试的执行和BUG管理
现在我们开始进行测试了
打开待测试的系统打开测试管理工具用例模块开始执行用例发现bug进行复现并确认bug的复现步骤记录bug沟通bug验证以前提交的bug确认本次测试完成编写测试报告 执行测试时处理要做到测试用例和需求的覆盖外还要有临时发挥的能力。根据自己的经验、对测试的感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。 不能拘泥于测试用例或者已经有的测试方法在测试执行过程中要不断总结测试方法和测试故障模型。真正优秀的测试人员在执行测试时是想着做做着想这样的测试效果才好尤其是在测试过程中对程序的处理相当了解的情况下测试的思路会更加清晰和全面。 如何发现更多的bug 1、软件测试同样存在二八原则80%的故障集中于20%的模块如果某部分问题较多加强测试广度和深度 2、开发人员也存在二八原则80%的故障集中于20%的开发人员如果某些开发人员的bug较多加强他开发模块的测试广度和深度 3、多进行逆向思维和发散性的思维(比较依赖测试人员的经验没有测试经验就需要多写测试用例多看看别人的测试用例) 4、不要局限于用例和需求文档 5、尽早介入项目(介入需求就会尽早理解需求), 不要等到开发的差不多了再介入项目
