2019-06-18 14:27:50 hhl18 阅读数 864
  • JavaWeb实战开发

    本课程详细讲解了以下内容:     1.jsp环境搭建及入门、虚拟路径和虚拟主机、JSP执行流程     2.使用Eclipse快速开发JSP、编码问题、JSP页面元素以及request对象、使用request对象实现注册示例     3.请求方式的编码问题、response、请求转发和重定向、cookie、session执行机制、session共享问题      4.session与cookie问题及application、cookie补充说明及四种范围对象作用域      5.JDBC原理及使用Statement访问数据库、使用JDBC切换数据库以及PreparedStatement的使用、Statement与PreparedStatement的区别      6.JDBC调用存储过程和存储函数、JDBC处理大文本CLOB及二进制BLOB类型数据      7.JSP访问数据库、JavaBean(封装数据和封装业务逻辑)      8.MVC模式与Servlet执行流程、Servlet25与Servlet30的使用、ServletAPI详解与源码分析      9.MVC案例、三层架构详解、乱码问题以及三层代码流程解析、完善Service和Dao、完善View、优化用户体验、优化三层(加入接口和DBUtil)     1 0.Web调试及bug修复、分页SQL(Oracle、MySQL、SQLSERVER)      11.分页业务逻辑层和数据访问层Service、Dao、分页表示层Jsp、Servlet      12.文件上传及注意问题、控制文件上传类型和大小、下载、各浏览器下载乱码问题      13.EL表达式语法、点操作符和中括号操作符、EL运算、隐式对象、JSTL基础及set、out、remove      14.过滤器、过滤器通配符、过滤器链、监听器      15.session绑定解绑、钝化活化      16.以及Ajax的各种应用      17. Idea环境下的Java Web开发

    5719 人正在学习 去看看 颜群

       作为一名测试人员,重要的工作内容之一,就是找BUG,提交BUG,验证BUG,推进BUG的解决,直至软件达到发布的标准,提高软件的质量,及研发的工作效率和质量。

       要找BUG,那么,就要先了解一下BUG的定义是什么?

BUG的定义:

       软件的BUG,狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

       我们的职责就是,发现这些BUG,并提交给开发,让开发去修改。

BUG的由来

1、缺乏有效沟通

2、软件的复杂度

3、编程错误

4、不断变更的需求

5、时间的压力

      了解了BUG的定义以及由来后,那就要去了解BUG的类型,只有了解了BUG的类型,才能有的放矢,才能有目的,有范围的去寻找BUG,避免盲目寻找BUG,浪费宝贵的测试时间。 

BUG的类型

       要确定一个BUG的类型,需要对项目(或产品)有比较深的理解。这个划分对于问题类型的统计就比较重要了。

       划分方式一:

       功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、文档错误、兼容问题、用户体验、其它。

       划分方式二:

      功能类、性能类、界面类、易用性类、兼容性类、其它。

       找到BUG后,那么,就要对BUG区分等级,以便开发人员,根据BUG的优先级来处理BUG,优先解决紧急的,致命的BUG,次要解决严重的BUG,接着解决一般的BUG,再接着解决轻微的BUG,最后,解决界面上的细小问题,这样,能提高软件研发的进度,提高软件的质量。

BUG的等级

       Bug等级,这个划分有分三级或四级,也有分五级的。如果是等级越高,那么可能被修复的等级会高一些,有些公司还会根据你提的BUG数量和BUG等级来考察你的绩效。很多情况下,我们提交BUG大致的等级差不多即可,没有严格区分。

如何判断BUG的等级(严重程度1、2、3、4),一般可以参照下面的判断条件

    1、致命错误(1级提BUG需慎重)

(1)常规操作引起的系统崩溃,死机,死循环

(2)造成数据泄漏的安全性问题,比如恶意攻击造成的账户私密信息泄露

(3)涉及金钱

(4)用户数据受到破坏,或者危及人身安全

     2、严重错误

 (1)重要功能不能实现;

 (2)错误的涉及面广,影响到其他重要功能的正常实现;

  (3)严重操作导致的程序崩溃、死机、死循环;

  (4)外观难以接受的缺陷;

  (5)密码明文显示;

  (6)数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响

    3、一般错误

不影响产品的运行、不会成为故障起因,但对产品外观和下道工序影响较大的缺陷

  (1)次要功能不能正常实现;

  (2)操作界面错误(包括数据窗口内列名定义、含义不一致);

  (3)查询错误,数据错误显示;

  (4)简单的输入限制未放在前端进行控制;

  (5)删除操作未给出提示;

     4、细微错误

程序在一些显示上不美观,不符合用户习惯,或者是一些文字的错误

   (1)界面不规范;

   (2)辅助说明描述不清楚;

   (3)提示窗口文字未采用行业术语;

   (4)界面存在文字错误;

三级BUG_未修改成功,又重新打开等级上升一次_二级BUG_二级还是没解决_直接一级BUG

改进建议:可以提高产品质量的建议,包括新需求和对需求的改进。

       找到BUG,提交BUG后,那么,就要进入BUG的生命周期了。

bug的生命周期

BUG的生命周期,就是一个BUG被发现到这个BUG被关闭的过程。

生命周期中缺陷状态:新建-->指派-->已解决-->待验-->关闭

发现BUG-->提交BUG-->指派BUG-->研发确认BUG-->研发去修复BUG-->回归验证BUG-->是否通过验证-->关闭BUG

如果待验的BUG在验证时没有解决好,我们需要重新打开--指派—已解决—待验,循环这个过程。

中间其他状态:拒绝、延期等

BUG的处理流程图(生命周期图)

 

 

 

设计如此(不是缺陷):1、核对需求规格说明书  2、找业务或者产品进行确认  3、确认是设计如此(不是缺陷),则直接关闭BUG。4、确认设计不是如此,跟开发沟通,重新激活指派BUG

重复BUG: 测试人员找到对应重复BUG的ID。如果确认是重复BUG,直接关闭(通常是关闭,后面提交的那个重复的BUG)

无法重现:1、确认开发的环境,跟操作步骤是否跟测试人员一致;2、在与提交BUG相同的环境下,重复验证一定的次数,比如,15-20次等,再未重现BUG,将状态该为无法重现

注意事项:

开发人员应在BUG系统中,备注好以下信息:

已修改BUG应在该BUG的注释处,备注修改方案及信息,以备以后出现类似的问题时,可以快速的找到原因

设计如此(不是缺陷)、不予解决、延期解决的BUG、无法重现的BUG,应备注处理的原因,节省沟通的时间,以及,如果后续有相同问题时,可以快速查找到原因

重复BUG注明重复BUGID

状态处理

1.已经指派的BUG---已经指派给开发的,应随时关注并进行跟踪自己所提BUG的状态变化!如果一直未修复,提醒开发人员修改;如果已经修复等待测试环境更新后进行验证

2.已解决的BUG----等待测试环境更新后进行验证,验证通过则关闭;验证不通过则重新指派给开发

3.重复BUG----先去查看下是否跟开发指定的BUG或者,自己在BUG系统内看到的BUG重复?如果确定重复则关闭;如果不重复,说明原因,重新打开指派给开发。

4.不是缺陷----确认开发环境是否和测试环境一致,如果如开发所说不是缺陷则进行关闭;如果确认是缺陷跟开发沟通,沟通未达一致找产品/反馈老大确认,确认是BUG注明情况并再次指派给开发。

5.无法重现----确认开发环境是否跟测试环境一致?包括操作步骤,浏览器、环境、特定账号等,如果多个版本验证之后,如开发所说重现不了,依据BUG的严重程度跟产品,开发一起确认关闭;如果找到重现原因,注明清楚并再次指派给开发。

6.不予解决---找产品经理进行确认。确认不予解决进行关闭;确认需要解决请备注原因并打开指派给开发

7.设计如此---找产品经理进行确认。确认设计如此进行关闭;确认是问题,备注原因重现指派给开发。

8.延期修改---请看下BUG严重程度,是否影响当前版本发布?与产品经理进行确认。不予延期请根据情况重新打开并将情况进行备注说明;确定延期则做好记录,后续版本进行关注。

 

2018-08-11 08:56:33 zimingzim 阅读数 1106
  • JavaWeb实战开发

    本课程详细讲解了以下内容:     1.jsp环境搭建及入门、虚拟路径和虚拟主机、JSP执行流程     2.使用Eclipse快速开发JSP、编码问题、JSP页面元素以及request对象、使用request对象实现注册示例     3.请求方式的编码问题、response、请求转发和重定向、cookie、session执行机制、session共享问题      4.session与cookie问题及application、cookie补充说明及四种范围对象作用域      5.JDBC原理及使用Statement访问数据库、使用JDBC切换数据库以及PreparedStatement的使用、Statement与PreparedStatement的区别      6.JDBC调用存储过程和存储函数、JDBC处理大文本CLOB及二进制BLOB类型数据      7.JSP访问数据库、JavaBean(封装数据和封装业务逻辑)      8.MVC模式与Servlet执行流程、Servlet25与Servlet30的使用、ServletAPI详解与源码分析      9.MVC案例、三层架构详解、乱码问题以及三层代码流程解析、完善Service和Dao、完善View、优化用户体验、优化三层(加入接口和DBUtil)     1 0.Web调试及bug修复、分页SQL(Oracle、MySQL、SQLSERVER)      11.分页业务逻辑层和数据访问层Service、Dao、分页表示层Jsp、Servlet      12.文件上传及注意问题、控制文件上传类型和大小、下载、各浏览器下载乱码问题      13.EL表达式语法、点操作符和中括号操作符、EL运算、隐式对象、JSTL基础及set、out、remove      14.过滤器、过滤器通配符、过滤器链、监听器      15.session绑定解绑、钝化活化      16.以及Ajax的各种应用      17. Idea环境下的Java Web开发

    5719 人正在学习 去看看 颜群

 

本文介绍下软件测试的基本概念,以使大家对软件测试行业有一个基本的了解。

主要分三部分介绍:发展综述、职业发展、核心技能。

第一部分:发展综述

1、BUG/Defect的由来

“Bug”的创始人赫柏的报告格蕾丝.郝柏Grace Murray Hopper),是一位为美国海军工作的电脑专家,也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字,正是由赫柏所取的。1945年的一天,赫柏对Harvard Mark II设置好17000个继电器进行编程后,技术人员正在进行整机运行时,它突然停止了工作。于是他们爬上去找原因,发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾,这显然是由于飞蛾受光和热的吸引,飞到了触点上,然后被高电压击死。所以在报告中,赫柏用胶条贴上飞蛾,并把“bug”来表示“一个在电脑程序里的错误”,“Bug”这个说法一直沿用到今天。

2、软件缺陷事件回顾:

事件1:WINDOWS操作系统蓝屏--多版本之间的兼容性 ;

事件2:迪士尼的狮子王CD光盘不能使用--PC机器之间的兼容性 ;

事件3:Android 5.0臭名昭著的内存泄露Bug--性能测试的重要性;

事件4:HP100款笔记本电脑软件暴露严重漏洞--安全测试的重要性;

事件5:美F-22机群系统瘫痪,软件质量威胁国家安全 ;

事件6:一个 bug ,45分钟损失了 4.65 亿美金,直接导致破产;

事件7:致命的辐射治疗,医疗设备电力软件的Bug,3人直接死亡;

事件8:一架吉努克型直升飞机坠毁,29名乘客全部罹难;

事件9:2011 年温州7.23 动车事故-- 由于温州南站信号设备在设计上存在严重缺陷,遭雷击发生故障后,导致本应显示为红灯的区间信号机错误显示为绿灯;

事件10:一触即发的第三次世界大战: 1980年,北美防空联合司令部曾报告称美国遭受导弹袭击,后来证实,这是反馈系统的电路故障问题,但反馈系统软件没有考虑故障问题引发的误报;1983年,苏联卫星报告有美国导弹入侵,但主管官员的直觉告诉他这是误报,后来事实证明的确是误报;

3、软件测试简史

国外软件测试发展简史介绍:

 

1968,软件工程概念诞生;测试也逐步发展;1975,测试先驱在IEEE发表了软件数据选择的原理,将软件测试定义为一种研究方向,此时软件测试被定义为“证明软件的工作是正确”的活动,理念为“证实”;1979,软件测试艺术一书,认为测试是“发现错误而执行的活动”,理念为“证伪”;1983,软件测试完全指南指出“测试是以评价一个程序或者系统属性为目标的任何一种活动,测试是对软件质量的度量”,测试应该走向前端,进行缺陷预防;1996,提出“测试成熟度模型”“测试能力成熟度模型”等;2002,测试是为了度量和提高被测软件的质量,对测试软件进行工程设计、实施和维护的整个生命周期的过程;

国内软件测试发展简史介绍:

 

1、第一代测试人员很大一部分是直接从软件程序员转岗的,有一定的编码基础,对系统的实现细节理解深入;2、校园招聘中学生对于测试的岗位非常模糊,有些被动选择做测试;软件管理认为测试就是找BUG,不理解测试策略、测试设计等的意义;3、软件测试入门简单,但是对整个系统有深入的把握,软件测试比开发更难深入;中国软件测试人员经验缺乏,大部分为0-3年;

4、软件测试行业对比

谷歌:SET,帮助开发更快更好的测试;帮助产品更好地采集使用信息和用户反馈;安全性、可靠性、性能等专项测试;TE,重点评估对用户的影响及软件产品整体目标上的风险;

微软:SDET,保证质量;提升研发效率;

腾讯:业务上线之前尽可能地发现导致商业目标无法达成的缺陷;独立的体验测试团队;QQ平台很传统;

华为:保证质量;交付;公司平台的流程、工具、技术更新;

第二部分:职业发展

1、技术发展方向

软件测试主要分为管理和技术两个大方向。管理类职位较少,比重也较低,对管理感兴趣的同学可以考虑,另外也需要一定的机会。技术类发展方向多样:产品测试专家/专项测试专家/交付测试工程师等。

详细信息看下图所示:

2、职业发展方向

由于软件测试人员的职业特点,接触的东西非常广且全,非常有利于职业的转型和发展。

从测试职业来看,可以有:测试开发、专项测试、质量管理、产品交付等;

从工作类别来看,可以转型的方向有:开发、产品、售前/售后、其它(市场/销售/咨询等)等

从工作趋向来看,可以转型的方向有:测试创业(围绕测试行业的创业,如测试培训、测试咨询、测试技术类公司等)、跨行测试(比如从传统公司到互联网、银行、AI智能等)、自由创业(与测试不是强相关的创业,科技行业/餐饮行业/零售业等)、自由独立(财务自由)等

第三部分:核心技能

1、软件测试的核心是什么?

常见的有如下一些观点:

观点1、测试用例是测试核心?

观点2、测试策略是测试核心?

观点3、自动化测试和工具是测试核心?

观点4、用户需求及验收标准是测试核心?

观点5、手工测试是测试的核心?

这些观点都是仁者见仁、智者见智,任何东西都没有太绝对的。就我的理解来看,我比较倾向于观点2,也就是说测试策略是软件测试的核心。

我认为软件测试的核心原则就是:合理调度和分配有限的资源,保证正确的时间做正确的事,进行“刚刚好”的测试,最大程度保证产品质量。

2、软件测试的价值是什么?

借用”软件测试价值提升之路“一书,并结合自己的理解。我认为软件测试分为三个阶段:

起点:打破思路、匹配业务、面向商业、问题改进;

测试人员要把目光放在产品的商业成功上,面向服务用户,结合业务需求,打破常规思路,以“问题”为出发点,不断的使得开发流程体系持续改进和提高,从而推进产品质量的不断提高,促进企业在商业和社会上的成功。

飞跃:拦截缺陷、提供数据、过程可控、基本价值;

测试人员要把拦截软件缺陷、监控测试过程、提供测试数据作为测试工作的三大“法宝”,这也是测试的基本价值,也是我们必须要守护的领地。

升华:质量屏障、交付先锋、额外价值、拓展价值;

测试人员除了守护自己领地之外,还能做非常多的额外工作,以拓展测试人员的价值,我们可以是质量的屏障,可以是产品交付的先锋,可以是公司体系流程建设的推进者和改革者。一切的一切都建立在测试人员要做好自己的本职工作,同时随时做好准备,扩充自己的技能包,迎接更大的困难和挑战,为企业不断服务并做出更大的贡献。

3、软件测试的核心能力

想做好软件测试,确实需要一些能力,如下列举了一些核心的要求:

技能包1、业务知识快速学习能力;

技能包2、测试用例的编写和设计;

技能包3、自动化测试及编程基础;

技能包4、测试的基本理论与知识;

技能包5、测试工具的使用与开发;

技能包6、测试策略的制定与实施;

技能包7、解决问题的思路及沟通;

技能包8、自我的测试体系及模型;

技能包9、全面的质量分析及把控;

技能包10、仔细耐心认真踏实勤奋;

……

希望大家不断实践、不断提高、不断总结,提高软件测试的能力。

 

2019-04-09 18:19:54 qq_43255303 阅读数 310
  • JavaWeb实战开发

    本课程详细讲解了以下内容:     1.jsp环境搭建及入门、虚拟路径和虚拟主机、JSP执行流程     2.使用Eclipse快速开发JSP、编码问题、JSP页面元素以及request对象、使用request对象实现注册示例     3.请求方式的编码问题、response、请求转发和重定向、cookie、session执行机制、session共享问题      4.session与cookie问题及application、cookie补充说明及四种范围对象作用域      5.JDBC原理及使用Statement访问数据库、使用JDBC切换数据库以及PreparedStatement的使用、Statement与PreparedStatement的区别      6.JDBC调用存储过程和存储函数、JDBC处理大文本CLOB及二进制BLOB类型数据      7.JSP访问数据库、JavaBean(封装数据和封装业务逻辑)      8.MVC模式与Servlet执行流程、Servlet25与Servlet30的使用、ServletAPI详解与源码分析      9.MVC案例、三层架构详解、乱码问题以及三层代码流程解析、完善Service和Dao、完善View、优化用户体验、优化三层(加入接口和DBUtil)     1 0.Web调试及bug修复、分页SQL(Oracle、MySQL、SQLSERVER)      11.分页业务逻辑层和数据访问层Service、Dao、分页表示层Jsp、Servlet      12.文件上传及注意问题、控制文件上传类型和大小、下载、各浏览器下载乱码问题      13.EL表达式语法、点操作符和中括号操作符、EL运算、隐式对象、JSTL基础及set、out、remove      14.过滤器、过滤器通配符、过滤器链、监听器      15.session绑定解绑、钝化活化      16.以及Ajax的各种应用      17. Idea环境下的Java Web开发

    5719 人正在学习 去看看 颜群

1.单元测试的好处

  1. 它是一种验证行为
  2. 它是一种设计行为
  3. 它是一种编写文档的行为
  4. 它具有回归性

2.JUnit 

JUnit是一个开放源代码的Java测试框架,用于编写和运行可重复的测试。包括以下特性:

  1. 用于测试期望结果的断言(Assertion)
  2. 用于共享共同测试数据的测试工具
  3. 用于方便的组织和运行测试的测试套件
  4. 图形和文本的测试运行器

3.JUnit常用的断言方法

  1. assertEquals(a,b)   测试a是否等于b
  2. assertFalse(a)   测试a是否为false,a是一个Boolean数值
  3. assertTrue(a)   测试a是否为true,a是一个Boolean数值
  4. assertNotNull(a)   测试a是否为null,a是一个对象或者null
  5. assertNull(a)   测试a是否为null,a是一个对象或者null
  6. assertNotSame(a,b)   测试a和b是否没有都引用同一个对象
  7. assertSame(a,b)   测试a和b是否都引用同一个对象

4.JUnit中的两种设计模式:集成模式+命令模式

5.回归测试

回归测试是指修改了旧代码后,重新进行测试以确定修改没有引入新的错误或导致其他代码产生错误,自动回归测试将大幅度降低系统测试,维护升级等阶段的成本

6.冒烟测试

冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略,是对软件基本功能进行确认验证的手段,并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试,执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过,则不必做进一步的测试。进行冒烟测试之前需要确定冒烟测试的用例集,对用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的门槛用例验证。冒烟测试的执行者是版本编译人员。因此可以说,冒烟测试是预测试。在实际的软件测试工作中,冒烟测试在软件研发的不同阶段有所不同。大体可以分为三类:

  1. 形成集成测试版本以前:验证各个单元能够成功执行,并保证测试版本能够顺利集成;
  2. 形成集成测试版本:以保证新的或者更改过的代码不破坏集成版本的完成性和稳定性;
  3. 后期预测试缺陷的修正:针对每个缺陷所做的缺陷修正都要先在干净的链接环境中进行冒烟测试,测试通过后才能更新相关软件版本。 
2018-07-21 21:49:18 Nessie_zhao 阅读数 88
  • JavaWeb实战开发

    本课程详细讲解了以下内容:     1.jsp环境搭建及入门、虚拟路径和虚拟主机、JSP执行流程     2.使用Eclipse快速开发JSP、编码问题、JSP页面元素以及request对象、使用request对象实现注册示例     3.请求方式的编码问题、response、请求转发和重定向、cookie、session执行机制、session共享问题      4.session与cookie问题及application、cookie补充说明及四种范围对象作用域      5.JDBC原理及使用Statement访问数据库、使用JDBC切换数据库以及PreparedStatement的使用、Statement与PreparedStatement的区别      6.JDBC调用存储过程和存储函数、JDBC处理大文本CLOB及二进制BLOB类型数据      7.JSP访问数据库、JavaBean(封装数据和封装业务逻辑)      8.MVC模式与Servlet执行流程、Servlet25与Servlet30的使用、ServletAPI详解与源码分析      9.MVC案例、三层架构详解、乱码问题以及三层代码流程解析、完善Service和Dao、完善View、优化用户体验、优化三层(加入接口和DBUtil)     1 0.Web调试及bug修复、分页SQL(Oracle、MySQL、SQLSERVER)      11.分页业务逻辑层和数据访问层Service、Dao、分页表示层Jsp、Servlet      12.文件上传及注意问题、控制文件上传类型和大小、下载、各浏览器下载乱码问题      13.EL表达式语法、点操作符和中括号操作符、EL运算、隐式对象、JSTL基础及set、out、remove      14.过滤器、过滤器通配符、过滤器链、监听器      15.session绑定解绑、钝化活化      16.以及Ajax的各种应用      17. Idea环境下的Java Web开发

    5719 人正在学习 去看看 颜群

软件测试的概念:

验证软件功能是否满足用户的需求

需求:你的期望
概念有两层意思:
1.找Bug
2.验证软件是正确的

  • 软件的概念没有错与对,只是在每个不同的阶段有不同的解释
软件测试的发展

1.软件调试
2.独立的软件测试(1950~)
3.软件测试的第一次定义(1973~),软件测试就是对程序能够按预期的要求运行建立起一种信心
4.软件称为专门的学科(1980~)
5.开发与测试的融合(2000~)

  • 许多人会把调试当做成软件测试,但其实两者是完全不同的两个概念

测试与调试的区别:

1.目的不同

测试–发现程序中的缺陷
调试–定位并解决程序中的问题

2.参与角色不同

测试–主要由测试人员的研发人员完成,黑盒测试主要由测试人员完成,单元/集成测试主要由开发人员执行
调试–由开发人员完成

3.执行的阶段不同

测试–贯穿整个软件开发生命周期
调试–一般在开发阶段和集成阶段

软件测试的目的

验证软件有或没有问题

软件测试的原则

以客户为中心,遵循软件测试的规范、流程、标准和要求

质量管理的八项原则:

1.以顾客为关注焦点

组织依存于他们的顾客,因而组织应理解顾客当前和未来的需求,满足顾客需求并争取超过顾客的期望

2.领导作用

领导者建立组织相互统一的宗旨、方向和内部环境。所创造的环境能使员工充分参与实现组织目标的活动

3.全员参与

各级人员都是组织的根本,只有他们的充分参与才能使他们的才干为组织带来收益

4.过程方法

将相关的资源和活动作为过程来进行管理,可以更高效地达到预期的目的

5.管理的系统方法

针对指定的目标,识别、理解并管理一个由相互联系的过程所组成的体系,有助于提高组织的有效性和效率

6.持续改进

持续改进是一个组织永恒的目标

7.基于事实的决策方法

有效的决策是建立在对数据和信息进行合乎逻辑和直观的分析基础上

8.与供方互利的关系

组织和供方之间保持互利关系,可增进两个组织创造价值的能力

什么是需求??

满足用户期望或正式规定文档(合同、标准、规范)所具备的条件和权能,包含用户需求和软件需求

  • 用户需求:该需求一般比较简略。

  • 软件需求:或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。

例:
用户需求
你和爸爸说:“我想买手机。”—这是一个用户需求,比较简略
软件需求
需要爸爸和你反复的沟通了解更加详细具体的需求,来指定解决方案
比如爸爸问你:“想买那个牌子的?”
你说:“某某牌子。”

问题:有一个声控灯,说一下你对这个灯的需求
有的人可能会说声音大于多少分贝灯会亮等等。
但其实这个问题问的就有错误。首先没有说这个声控灯是要安装在哪里,范围太广,需要与用户进行沟通,将用户需求转为软件需求
注:
1.需求要有范围
2.需求不一定是对的,要对需求也进行测试

什么是Bug??

  • 当且仅当规格说明是存在的而且是正确的,程序与规格说明之间的不匹配才是错误

  • 当没有需求规格说明书时,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时就是软件错误

什么是测试用例??

  • 测试用例是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素

  • 测试用例就是为了解决测试过程中可能遇到如下的问题
    1.不知道是否较全面的测试了所有功能
    2.测试的覆盖率无法衡量
    3.对新版本的重复测试很难实施
    4.存在大量冗余测试影响测试效率

软件的生命周期可以分成6个阶段:需求分析、计划、设计、编码、测试、运行维护

开发模型

瀑布模型

适合需求较为稳定的,变更少的
串行的

螺旋模型

采用渐进式的开发模式
对于那些规模庞大、复杂度高、风险大的项目尤其适合

增量、迭代

降低项目风险

敏捷

个体与交互重于过程和工具—人与人之间的沟通
可用的软件重于完备的文档—对文档的依赖度不高了
客户写作重于合同谈判———客户参与开发过程
响应变化重于遵循计划———拥抱变化

敏捷开发有很多种方式,其中scrum是比较流行的一种。
scrum里面的角色

  • Product owner(类似产品经理):负责整理user stroy(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责

  • Scrum master(类似项目经理)敏捷教练:负责召开各种会议,协调项目,为研发团队服务

  • Team(研发团队):由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品
迭代开发

与瀑布不同,scrum将产品的开发分解为若干个小迭代,其周期从1周到4周不等,但不会超过4周。

Scrum的基本流程:

产品负责人负责整理user story,形成product backlog
发布计划会议
迭代计划会议
每日例会
演示会议
回顾会议

软件测试的两种模型

V模型(串行)

这里写图片描述
单元和集成测试:检测程序的执行是否满足软件设计的需求
系统测试:检测系统功能、性能的质量特性是否达到系统要求的指标
(1)环境搭建
(2)数据准备
(3)测试执行
(4)缺陷管理
(5)测试报告编写
验收测试:确定软件的实现是否满足用户需求或合同的要求
V模型的局限性:把测试作为编码后的一个阶段,未在需求阶段就进入测试,让人误以为测试不重要

W模型(并行)

这里写图片描述
验收测试准备:验收计划,需求学习
系统测试准备:编写测试计划,搭建测试用例框架
集成测试准备:细化测试计划,编写测试方案、策略
单元测试准备:完善、细化方案、策略、计划、测试用例框架
编码:编写测试用例(包括单元测试的测试用例)
集成测试:提取编码时写的测试用例并加以完善
(1)系统测试:环境搭建
(2)数据准备
(3)测试执行
(4)缺陷管理
(5)测试报告编写
验收测试:协助客户,可能需要对客户进行培训
W模型的优点:有利于尽早的发现问题
W模型的局限性:无法支持敏捷开发模式。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临着困惑

什么是配置管理??

配置管理是通过对在软件生命周期不同的时间点上的软件配置进行标识,并对这些被标识的软件配置项的更改进行系统控制,从而达到保证软件产品的完整性和可塑性的过程

2020-03-05 10:31:43 weixin_43831728 阅读数 20
  • JavaWeb实战开发

    本课程详细讲解了以下内容:     1.jsp环境搭建及入门、虚拟路径和虚拟主机、JSP执行流程     2.使用Eclipse快速开发JSP、编码问题、JSP页面元素以及request对象、使用request对象实现注册示例     3.请求方式的编码问题、response、请求转发和重定向、cookie、session执行机制、session共享问题      4.session与cookie问题及application、cookie补充说明及四种范围对象作用域      5.JDBC原理及使用Statement访问数据库、使用JDBC切换数据库以及PreparedStatement的使用、Statement与PreparedStatement的区别      6.JDBC调用存储过程和存储函数、JDBC处理大文本CLOB及二进制BLOB类型数据      7.JSP访问数据库、JavaBean(封装数据和封装业务逻辑)      8.MVC模式与Servlet执行流程、Servlet25与Servlet30的使用、ServletAPI详解与源码分析      9.MVC案例、三层架构详解、乱码问题以及三层代码流程解析、完善Service和Dao、完善View、优化用户体验、优化三层(加入接口和DBUtil)     1 0.Web调试及bug修复、分页SQL(Oracle、MySQL、SQLSERVER)      11.分页业务逻辑层和数据访问层Service、Dao、分页表示层Jsp、Servlet      12.文件上传及注意问题、控制文件上传类型和大小、下载、各浏览器下载乱码问题      13.EL表达式语法、点操作符和中括号操作符、EL运算、隐式对象、JSTL基础及set、out、remove      14.过滤器、过滤器通配符、过滤器链、监听器      15.session绑定解绑、钝化活化      16.以及Ajax的各种应用      17. Idea环境下的Java Web开发

    5719 人正在学习 去看看 颜群

软件测试教程之概念篇

本节内容:

  • 软件测试的目的和原则
  • 什么是需求
  • 什么是bug
  • 什么是测试用例
  • 开发模型和测试模型
  • 配置管理和软件测试
软件测试的目的和原则

目的:验证软件有没有问题
原则:以客户的需求为中心,遵循软件测试的规范,流程,标准和要求(不同的公司对软件测试的标注,定位不同,需求也不同,所以我们在做测试的时候首先需要了解这个公司对于软件测试的标准需求以及定位)

1. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
2. 成功的测试是发现了至今为止尚未发现的错误的测试。
3. 测试并不仅仅是为了找出错误。通过分析错误产生的原因、阶段及错误发生的趋势。一、帮助项目管理者了
解当前软件开发过程中的缺陷,以便及时纠错、改进。二、帮助测试人员设计出有针对性的测试方法,改善
测试的效率和有效性。三、让开发人员知道错误产生的重灾区,加强自测试,四、让客户清楚我们专业的质
量保证团队,可以向他们提交一份满意的答卷。。
4. 没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法。
5. 根据测试目的的不同,还有回归测试、压力测试、性能测试、安全测试等,分别为了检验修改或优化过程是
否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。
6. 软件测试为了建立软件的信心。
7. 从测试的目的出发,大概可以分为两类:为了验证程序能正常工作的测试;为了验证程序不能正常运行的测
试
什么是需求

广义上的需要是指由于本身的需要而产生的要求

软件中的需求包含两种

  • 用户需求:可以分为内部用户的要求和外部用户的要求,他是比较简单的
  • 软件需求:对用户需求的分析,形成比较详细的需求实现文档。(所以也可以认为软件需求是用户需求的一个详细实现)
什么是需求的官方概念:

IEEE定义:软件需求是(1)用户解决问题或达到目标所需条件或着权能(不同的人,角色不一样,她所具有的权限也是不一样的)。(2)系统或系统部件要满足合同标准,规范或其他正式规定文档所需具有的条件或者权能。(3)一种反应上面(1)或者(2)所述条件或权能的文档说明。它包括功能性需求(也就是app的显示需求)以及非功能性需求(在功能性需求上做出一些限制),非功能性需求对设计和实现提出了限制,比如性能要求,质量标准,或者设计限制。

用自己的话来说什么是需求:

就是满足用户的期望和规定的合同(标准,规范,流程)所需要的条件和权能,包含用户需求和软件需求

在多数软件公司,会有两种需求,一种为软件需求,一种为用户需求。用户需求转换为软件需求的核心是沟通和分析。

案例:

比如说我要出去吃饭,我说我饿了,这就是用户需求,这是比较简略的,当后厨知道了我饿了这个需求之后,他在经过和我的讨论,知道我要吃什么,他就开始筹备,从而生成了软件需求。

什么是bug
第一个bug :

1945年9月的某天,在一间老式建筑里,从窗外飞进来一只飞蛾,此时Hopper正埋头工作在一台名为Mark Il的计
算机前,并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器(电子机械装置,那时还没
有使用晶体管)。突然,Mark II死机了。Hopper试了很多次还是不能启动,他开始用各种方法查找问题,最后定
位到了某个电路板的继电器上。Hopper观察这个继电器,惊奇地发现一只飞蛾已经被继电器打死。Hopper小心地
用镊子将飞蛾夹出来,用透明胶布贴到“事件记录本”中,写上“第一个发现虫子的实例”。Hopper的事件记录本,连
同那只飞蛾,现在都陈列在美国历史博物馆中。 软件错误的一般定义: 程序与规格说明之前不匹配。(片面的)

注意:

以上说法是片面的,准确的来说:当且仅当规格说明是存在的并且正确,程序与规格说明之间的不匹配才是错误。

当没有需求规格说明书时,判断标准以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时,就是软件错误。

(茶:两个方面,如果有规格说明,那么在规格说明合理的情况下,不符合规格说明的是BUG,如果没有规格说明,就看用户的需求,当然前提是用户需求合理的情况下,我们才做进一步判断)

什么是测试用例

测试用例(TestCase)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环境(到底是在电脑端,那是widows还是mac呢;手机端那是安卓手机还是苹果手机呢)、操作步骤、测试数据、预期结果等要素。

测试用例包含的要素
  • 标题
  • 测试环境
  • 测试设备(是手机端还是pc端,如果是手机端的话,要具体到手机的品牌,因为存在有兼容性的不通)
  • 测试系统(windowsx系统还是mac系统)
  • 测试数据
  • 测试步骤
  • 预期结果
  • 重要性
开发模型和测试模型(一共有五个模型)

随着软件工程学科的发展,人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写,而是扩展到了整个软件生命周期,如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护,直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作,例如过程管理、产品管理、资源管理和质量管理,在这些方面也逐步地建立起了标准或规范。

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。如果把软件看成是有生命的事物,那么软件的生命周期可以分成6个阶段,即需求分析、计划、设计、编码、测试、运行维护。

瀑布模型(瀑布模型每个阶段只执行一次)

瀑布模型在软件工程中占有重要地位,是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次,因此是线性顺序进行的软件开发模式.

优点:

  • 强调开发的阶段性,每个阶段都是独立的
  • 强调早期计划及需求调查
  • 强调产品测试,在瀑布模型中,测试时最后一个阶段,所以需要强调产品的测试

缺点:

  • 依赖于早期进行的唯一一次需求调查,不能适应需求的变化(测试介入的太晚了),也就是说,采用瀑布模型的话,只有在一开始的需求分析阶段才能对用户的需求进行分析等相关的工作,等需求分析结束了之后,如果还需要对需求分析做出改变的话,那么就是不可以的了。因为每个阶段都是独立的。那么从这一点来看什么样的需求适合于瀑布模型—就是需求比较稳定的需求适合于瀑布模型
  • 由于是单一流程,开发中的经验教训不能反馈应用于本产品的过程;
  • 风险往往迟至后期的测试阶段才显露,因而失去及早纠正的机会。

瀑布模型的一个最大缺陷在于,可以运行的产品很迟才能被看到。这会给项目带来很大的风险,尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现,通常会导致前面阶段的工作大面积返工,业界流行的说法是:“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷,例如,在前期阶段未发现的错误会传递并扩散到后面的阶段,而在后面阶段发现这些错误时,可能已经很难回头再修正,从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想,在这个基础上做出自己的修改。例如细化了各个阶段,在某些重点关注的阶段之间掺入迭代的思想。

螺旋模型(一个阶段一个阶段以原型为基础驱开发,而且每一个阶段都有分析)

一般在软件开发初期阶段需求不是很明确时,采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求,它不允许有一段独立的测试时间和阶段,测试必须跟随开发的迭代而迭代。因此,回归测试的重要性就不言而喻了。

为什么需要有风险分析:
当我们的需求不是很明确的时候,我们并不了解我们做这个项目是否有价值的时候,我们开发一个阶段,进行一次风险分析,开发一个阶段,进行一个风险分析,看这个项目值不值得我们继续开发下去

优点:

  • 强调严格的全过程风险管理
  • 强调各开发阶段的质量
  • 提供机会检讨项目是否有价值继续下去

缺点

  • 引入非常严格的风险识别、风险分析和风险控制,这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

适用于什么样的项目:适用于前期需求不明确的项目,有一定风险的项目,可能这个项目还比较庞大。需要一步一步去做的模型

增量,迭代模型

举个例子:比如说系统需要做A,B,C,D四个业务模块,需要在两周之内完成

增量模型:第一周完成A,B模块,第二周完成C,D模块

迭代模型:第一周完成A,B,C,D四个业务模块的基本功能,不考虑复杂业务功能,第二周,在第一周的基础之上,进行功能细化,完成复杂业务功能

抗风险能力:迭代模型的抗风险能力大于增量模型(迭代模型考虑的比较完整,所以抗风险能力大于增量模型)

增量开发能显著降低项目风险,结合软件持续构建机制,构成了当今流行的软件工程最佳实践之一。增量开发模型,鼓励用户反馈,在每个达代过程中,促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此,在这种开发模式下,每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本,意味着测试需要频繁进行,测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈,但是其实两者是有区别的。增量是逐块建造的概念,例如画一幅人物画,我们可以先画人的头部,再画身体,再画手脚……而迭代是反复求精的概念,同样是画人物画,我们可以采用先画整体轮廓,再勾勒出基本雏形,再细化、着色。

敏捷(轻量级开发,轻文档,重目标,重产出)

迭代周期一般是2-4周,参与人员一般为5-9人,重视人与人之间的沟通,强调有问题立刻解决

2001年,以Kent Beck、AlistairCockbum、WardCunningham、MartinFowler等人为首的“轻量”过程派聚集在犹他州的Snowbird,决定把“敏捷”(Agile)作为新的过程家族的名称

在会议上,他们提出了《敏捷宣言》,我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍,我们形成了如下价值观。

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中,后者并非全无价值,但我们更看重前者。

由敏捷宣言可以看出,敏捷其实是有关软件开发的社会工程(SocialEngineering)的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情,这是在软件工程几十年的发展过程中相对被忽略的领域。

敏捷开发有很多种方式,其中scrum是比较流行的一种。

scrum

scrum里面的角色

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

  • 其中productowner负责整理userstory(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责。(PO–整理用户需求,转换为一个个的user story)
  • scrum master 负责召开各种会议,协调项目,为研发团队服务。(负责开发人员,测试,PO之间的事物,负责各种会议,保障敏捷流程能够正常运行)
  • 研发团队则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品。

(自己理解:po是用户的代表,负责和用户沟通,整理用户的需求,,把用户的需求转换为一个个的userstory;SM负责开发人员,测试,po之间的事物,负责各种会议,保障敏捷流程能够正常运行:St由各种各种的开发人员组成,负责迭代。)

迭代开发

与瀑布不同,scrum将产品的开发分解为若干个小sprint(迭代),其周期从1周到4周不等,但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的userstory是固定的。每次迭代会产生一定的交付.

scrum的基本流程如上图所示:
  • 产品负责人负责整理user story,形成左侧的product backlog。
  • 发布计划会议:product owner负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,sprint backlog。
  • 迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,每个任务都明确的负责人,并完成工时的初估计。
  • 每日例会:每天scrum master召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
  • 演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
  • 回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改
    进的效果。

(茶板书):

  • 发布计划会议:PO会把user story进行评审,对user story进行整理排序
  • 迭代会议对一个个的user story进行分解评估排序
软件测试v模型(是瀑布模型的变种)

V模型最早是由Paul Rook在20世纪80年代后期提出的,目的是改进软件开发的效率和效果。是瀑布模型的变种

  • 明确的标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系
  • V模型指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求
  • 局限性:仅仅把测试作为在编码之后的一个阶段,未在需求阶段就进入测试软件
没有更多推荐了,返回首页