昌吉建设网站,深圳有名的做公司网站,简洁文章类网站,企业网站有百度权重说明文章目录 目录 前言 一、什么是软件测试 二、软件测试的发展史 三、软件测试和研发的区别 四、测试人员应该具备的能力 五、测试所需要知道的基本概念 1.需求 六、软件错误#xff08;BUG#xff09;的概念 前言
本篇文章主要讲解在学习测试前一些需要了解的知识。 一、什… 文章目录 目录 前言 一、什么是软件测试 二、软件测试的发展史 三、软件测试和研发的区别 四、测试人员应该具备的能力 五、测试所需要知道的基本概念 1.需求 六、软件错误BUG的概念 前言
本篇文章主要讲解在学习测试前一些需要了解的知识。 一、什么是软件测试 最常见的理解是软件测试就是找 BUG 发现缺陷。 现实生活中在很多情况下我们都在默默进行测试 刚新买来一部手机我们要干什么 一场考试 , 做完一遍题目之后 , 进行一遍检查 , 就是在 测试 买一台电视 , 安装好之后打开试试看能不能正常使用 , 也是在 测试 软件测试就是验证软件产品特性是否满足用户的需求 测试试图验证软件是 “ 工作的 ” 也就是验证软件功能执行的正确性 测试的活动是以测试人员 “ 预期的结果 ” 为依据这里的 “ 预期结果 ” 指的是需求定义。 软件测试的特点 软件测试只是一个样本试验具有不可穷尽性。 二、软件测试的发展史 1. 软件调试为主发生在20世界50年代。 2. 1957年Charles Baker对调试和测试进行了区分。 这是软件测试史上一个重要的里程碑标志已经有独立的软件测试了。 3. 1979年《软件测试的艺术》中给出了软件测试的定义测试是为发现错误而执行程序的过 程。它意味着软件测试不仅要证明软件做了该做的事情也要保证它没做不该做的事情。 4. 1983年美国国家标准局(National Bureau of Standards)发布了VVTVVT提出了测试 界很有名的两个名词验证(Verification)和确认(Validation)。 这些意味着软件测试正作为一门独立的专业的具有影响力的工程学发展起来了。 5. 预防为主是当下软件测试的主流思想之一 软件测试已经贯穿到了整个软件开发的生命周期当中了 三、软件测试和研发的区别 难易程度 开发广度小专业度高。测试广度大专业度低 工作环境 基本类似 薪水 中小企业总体比研发低自动化等专业测试领域和研发基本无差距。大厂研发测试基本无差别 发展前景 自动化测试、安全测试等领域发展前景和研发基本一致。 繁忙程度 敏捷模式下差距不大产品发布前压力比较大 技能要求 测试要求更广泛业务能力设计和架构分析能力测试手段和工具使用用户模型分析和理解编程能力 软件测试与调试的区别 目的不同 -调试(Debug)确保程序做了程序员想它做的事情 -测试(Testing)确保程序解决了它该解决的问题 参与角色不同 测试由测试人员和开发人员来执行黑盒测试主要由测试人员完成、单元/集成测试主要是由开发 人员执行。 调试由开发人员完成。 执行的阶段不同 测试贯穿整个软件开发生命周期 调试一般在开发阶段。 四、测试人员应该具备的能力 综合能力 沟通能力测试工程师的沟通能力会直接影响事务开展的效率。良好清晰的沟通能力是一个技术优秀的测试工程师是否可以获得更好发展的“ 敲门砖 ” 。 快速学习的能力对不同业务需求和功能的快速学习与理解能力。 对于测试新技术和新方法的学习能力。 开发能力 文字能力 掌握自动化测试技术 掌握自动化测试技术可以把你从大量重复性的手工劳动中解放出来这样可以把更多的精力花在更多类型的测试上。 优秀的测试用例设计能力 测试用例设计能力是指无论对于什么类型的测试都能够设计出高效地发现缺陷保证产品质量的优秀测试用例 如何提高测试用例设计的能力 1 掌握设计测试用例的方法 2 积累总结 3 阅读好的测试用例设计案例 探索性思维 探索性思维是指测试工程师在执行测试的过程中不断学习被测系统结合自己的经验知识直觉进行系统的错误猜测和逻辑推理整理和分析出更多有针对性的的测试关注点。 案例测试一台自动售票机。 正向逆向边界压力性能耗电量断电外观没零钱 ..... 兴趣 有责任感和一定的压力 责任感是任何工作的都需要的对于测试工作者而言 测试往往是产品质量的最后个把关者由于测试工作成效很难衡量测试用例执行、 bug 数目的多少都无法说明产品的质量是否合格所以责任感是最重要的测试必备素质之一。 压力测试工作者特别是属于互联网行业需要能够抗住各种压力。 五、测试所需要知道的基本概念
1.需求 满足用户期望或正式规定文档合同、标准、规范所具有的条件和权能包含用户需求和软件需求。 IEEE 定义软件需求是 (1) 用户解决问题或达到目标所需条件或权能 (Capability) 。 (2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面(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 | 电子邮箱 | 必填录入电子邮箱 | | 字符型 |
|
| 3 | 密码 | 必输输入的密码隐藏*号显示最短6位 | 6至15 | 字符型 |
|
| 4 | 确认密码 | 必输输入的密码隐藏*号显示最短6位 | 6至15 | 字符型 | |
| 5 | 验证码 | 必填录入验证码 | | 字符型 |
|
| 6 | 注册 | 注册操作 | | 操作型 |
|
1.1.1.1.5 处理
1.1.1.1.5.1 基本事件流
1、 用户选择注册
2、 系统展现用户协议界面并请用户确认是否同意用户协议
1) 若用户不同意协议系统禁止用户注册。
2) 若用户同意协议用户进行注册信息填写。
3、 用户填写注册信息。
注册个人填写姓名电子邮箱密码确认密码验证码。
4、 用户提交注册信息
5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户若未收
到激活邮件可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、 用户可执行激活操作直接跳转至注册邮箱门户页面。
7、 用户通过接收到的电子邮件中的激活信息激活账号用户注册完成流程结束。
1.1.1.1.5.2 扩展事件流
1. 用户注册并激活成功后第一次登录平台时提示用户完善信息
1.1.1.1.5.3 异常事件流
1. 若用户未收到激活邮件可在登录界面录入电子邮件及密码后再次发送激活邮件。
2. 每次发送的激活邮件仅在发送邮件后起24小时之内有效超过24小时后需重新发送激活邮件。
1.1.1.1.6 输出
用户注册成功
1.1.1.1.7 后置条件
该模块为用户登陆等的前置模块。 从软件测试人员角度看需求 需求是测试人员开展软件测试工作的依据。 在具体设计测试用例的时候首先需要搞清楚每一个业务需求对应的多个软件功能需求点然后分析出每个软件功能需求点对应的多个测试需求点然后针对每个测试需求点设计测试用例。 过程如下 业务需求—软件功能需求点—测试需求点—测试用例 以用户登录为例 为什么需求对软件测试人员如此重要 从软件功能需求出发无遗漏的识别出测试需求是至关重要的这将直接关系到用例的 测试覆盖率 对于识别出的每个测试需求点需要采用 具体的设计测试用例的方法 来进行测试用例的设计 如何才可以深入理解被测试软件的需求 测试工程师在需求分析和设计阶段就开始介入 因为这个阶段是理解和掌握软件的原始业务需求的最好时机。 只有真正理解了原始业务需求之后才有可能从业务需求的角度去设计针对性明确从终端用户的使用场景到端到端的覆盖率较高的测试用例集。 测试用例的概念 测试用例 Test Case 是为了实施测试而向被测试的系统提供的一组集合这组集合包含测试环 境、操作步骤、测试数据、预期结果等要素。 测试用例解决了两大问题测什么怎么测 下面是一张测试用例表 测试过程中可能会遇到以下问题 – 不知道是否较全面的测试了所有功能 – 测试的覆盖率无法衡量 – 对新版本的重复测试很难实施 – 存在大量冗余测试影响测试效率 测试用例的产生就是为了解决上述的问题。 六、软件错误BUG的概念 第一个 bug 1945 年 9 月的某天在一间老式建筑里从窗外飞进来一只飞蛾此时 Hopper 正埋头工作在一台名为Mark Il的计算机前并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器电子机械装置那时还没有使用晶体管。突然Mark II 死机了。 Hopper 试了很多次还是不能启动他开始用各种方法查找问题最后定位到了某个电路板的继电器上。Hopper 观察这个继电器惊奇地发现一只飞蛾已经被继电器打死。Hopper 小心地用镊子将飞蛾夹出来用透明胶布贴到 “ 事件记录本 ” 中写上“ 第一个发现虫子的实例 ” 。 Hopper 的事件记录本连同那只飞蛾现在都陈列在美国历史博物馆中。 软件错误的一般定义 程序与规格说明之前不匹配 。 注意以上说法是片面的准确的来说 当且仅当规格说明是存在的并且正确程序与规格说明之间的 不匹配才是错误。 当需求规格说明书没有提到的功能判断标准以最终用户为准 当程序没有实现其最终用户合理预期的 功能要求时就是软件错误。 开发模型和测试模型 随着软件工程学科的发展人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写而是扩展到了整个软件生命周期如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作例如过程管理、产品管理、资源管理和质量管理在这些方面也逐步地建立起了标准或规范。 软件的生命周期 软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物那么软件的生命周期可以分成6 个阶段即需求分析、计划、、设计、编码、测试、运行维护。 瀑布模型 Waterfall Model 需求分析实际上就是产出一个需求文档设计就是产出一个设计文档或者UI视觉稿将需求文档转化为一个个示例图。测试就是执行测试用例提交BUG验收。 适用的项目项目周期短项目非常小小型项目适用于瀑布模型 瀑布模型在软件工程中占有重要地位是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次因此是线性顺序进行的软件开发模式。 优点 – 强调开发的阶段性 – 强调早期计划及需求调查 – 强调产品测试。 缺点 – 依赖于早期进行的唯一一次需求调查不能适应需求的变化 – 由于是单一流程开发中的经验教训不能反馈应用于本产品的过程 – 风险往往迟至后期的测试阶段才显露因而失去及早纠正的机会。 瀑布模型的一个最大缺陷在于可以运行的产品很迟才能被看到。这会给项目带来很大的风险尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现通常会导致前面阶段的工作大面积返工业界流行的说法是“ 集成之日就是爆炸之日 ” 。尽管瀑布模型存在很大的缺陷例如在前期阶段未发现的错误会传递并扩散到后面的阶段而在后面阶段发现这些错误时可能已经很难回头再修正从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想在这个基础上做出自己的修改。例如细化了各个阶段在某些重点关注的阶段之间掺入迭代的思想。 在瀑布模型中测试阶段处于软件实现后这意味着必须在代码完成后有足够的时间预留给测试活动 否则将导致测试不充分从而把缺陷直接遗留给用户。 螺旋模型 Spiral Model 一般在软件开发初期阶段需求不是很明确时采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。 这对于那些规模庞大、复杂度高、风险大的项目尤其适合 。这种迭代开发的模式给软件测试带来了新的要求它不允许有一段独立的测试时间和阶段测试必须跟随开发的迭代而迭代。因此回归测试的重要性就不言而喻了。 从上图我们可以看到螺旋模型可以分为4个象限第一个象限主要制定计划决定目标方案和限制第二个象限主要进行风险分析评价方案识别风险消除风险。第三个象限主要进行实施工程开发验证下一个产品。第四个象限进行客户评估。 优点 – 强调严格的全过程风险管理。 – 强调各开发阶段的质量。 – 提供机会检讨项目是否有价值继续下去。 每个阶段都会进行风险分析避免一些线上问题发生。• 缺点 – 引入非常严格的风险识别、风险分析和风险控制这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。风险分析可能会分析错需要有人力财力的付出。 增量、迭代模型 增量我们可以理解为做博客项目时首先完成登录模块然后完成前端页面模块然后完成后端模块每次做完一个模块才去考虑另一个模块。 迭代同样是博客项目首先将登录模块开发一部分再将前端模块开发一部分完成整个项目的大的框架后再去完善细节。 增量开发能显著降低项目风险结合软件持续构建机制构成了当今流行的软件工程最佳实践之一。增量开发模型鼓励用户反馈在每个迭代过程中促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此在这种开发模式下每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本意味着测试需要频繁进行测试人员需要与开发人员更加紧密地协作。 增量通常和迭代混为一谈但是其实两者是有区别的。增量是逐块建造的概念例如画一幅人物画我们可以先画人的头部再画身体再画手脚…… 而迭代是反复求精的概念同样是画人物画我们可以采用先画整体轮廓再勾勒出基本雏形再细化、着色。 敏捷敏捷是一个思想衍生出很多开发模式 2001 年以 Kent Beck 、 Alistair Cockbum 、 Ward Cunningham 、 Martin Fowler 等人为首的 “ 轻量 ” 过程派聚集在犹他州的Snowbird 决定把 “ 敏捷 ”(Agile) 作为新的过程家族的名称。 在会议上他们提出了《敏捷宣言》 http://agilemanifesto.org/ 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍我们形成了如下价值观。 个体与交互重于过程和工具个体之间面对面沟通比工具更重要
可用的软件重于完备的文档软件比开发文档需求文档等重要
客户协作重于合同谈判与客户之间的沟通比合同更重要
响应变化重于遵循计划应该多问客户的需求而不是遵循与计划
在每对比对中后者并非全无价值但我们更看重前者强调的是前者并没有否定后者价值。比如第二个对比虽然软件比文档重要但是并不代表文档没用。 由敏捷宣言可以看出敏捷其实是有关软件开发的社会工程 (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 。 回顾会议项目团队对本期迭代进行总结发现不足制定改进计划下一次迭代继续改进已达 到持续改进的效果。 总结产品经理收集用户需求项目经理将需求进行优先级划分计划项目什么时候开始什么时候结束。然后进行每日站会主要汇报昨天任务有没有完成如果没有完成遇到了什么问题今天应该干什么。然后进行演示也就是总结本次迭代取得的成果演示会议结束后项目团队进行总结并改进。 敏捷中的测试 挑战 1 轻文档 挑战 2 快速迭代 1 、测试工作的核心内客是没有变的就是不断地找 Bug 只是要调整好自己的心态一切以敏捷的原则为主。 2 、测试人员不能依赖文档测试用例作用减弱更多的采用思维导图、探索性测试强调自由度设计和执行同时执行根据测试结果不断调整测试计划、自动化测试 3 、敏捷讲求合作在敏捷项目组中测试人员应该更主动点多向开发人员了解需求、讨论设计、一起研究Bug 出现的原因。 软件测试 v 模型 V 模型最早是由 Paul Rook 在世纪年代后期提出的目的是改进软件开发的效率和效果。是瀑布模型的变种。 用户需求阶段主要是PM将用户需求收集形成软件需求。需求分析与系统阶段主要验证需求是否正确确定编程语言确定框架。概要设计主要是看项目结构如何设计。详细设计阶段主要是对每个接口或者哪些库设计哪些任务。编码阶段就是写代码。而测试是在编码后才介入单元测试就是测试每一个方法每一个类。集成测试就是测试一个完成的模块。系统测试就是把要上线的所有功能放在一起测试。验收测试就是让验收的人去进行验收测试。 明确的标注了测试过程中存在的不同类型的测试并且清楚的描述了这些测试阶段和开发过程期间 各阶段的对应关系 V 模型指出单元和集成测试应检测程序的执行是否满足软件设计的要求系统测试应检测系统功 能、性能的质量特性是否达到系统要求的指标验收测试确定软件的实现是否满足用户需要或合同 的要求 局限性 : 仅仅把测试作为在编码之后的一个阶段未在需求阶段就进入测试。 特点左边是开发右边是测试 优点测试被划分为许多类型 缺点测试人员介入太晚发现问题的时机就太晚。 软件测试 W 模型 W 模型增加了软件各开发阶段中应同步进行的验证和确认活动。 W 模型由两个 V 字型模型组成分 别代表测试与开发过程图中明确表示出了测试与开发的并行关系。 W 模型特点开发一个V模型测试一个V模型测试的对象不仅是程序需求、设计等同样要测试测试与开发是同步进行的 W 模型优点测试人员尽早介入了需求有利于尽早地全面的发现问题。例如需求分析完成后测试人员就应该参与到对需求的验证和确认活动中以尽早地找出缺陷所在。同时对需求的测试也有利于及时了解项目难度和测试风险及早制定应对措施显著减少总体测试时间加快项目进度。 局限性测试人员和开发人员一定程度上还是串行的。需求、设计、编码等活动被视为串行的测试和开发活动也保持着一种线性的前后关系上一阶段完全结束才可正式开始下一个阶段工作。 无法支持敏捷开发模式不能拥抱变化所以不能适应于敏捷 。对于当前软件开发复杂多变的情况W 模型并不能解除测试管理面临着困惑。
