软件测试相关概念
-
什么是软件?
从开发的角度:软件=数据结构+算法
从测试的角度:软件=程序+文档
问: 所以软件测试的对象是什么?
答: 程序和文档(都要测试)
拓展内容:
软件开发分为哪几个阶段?
-
需求分析阶段
由需求分析人员完成
产出物:需求规格说明书
-
设计阶段
由系统架构师(系统分析师)完成
产出物:概要设计说明书和详细设计说明书
-
编码阶段
由开发人员完成
产出物:程序
问: 哪个阶段产生的bug最多?哪个阶段产生的bug最少?
答:
- 产生bug最多的阶段是需求分析阶段,大约占总缺陷的55%左右;
- 其次就是设计阶段,大约占总缺陷的25%左右;
- 最少的就是编码阶段,大约占总缺陷的15%;
- 还有约5%的缺陷来自于配置或者是兼容性的问题。
得出的结论:
- 软件测试不能只测程序,还要测文档;
- 测试工作应该尽早介入,并且应该贯穿整个项目的始终;
从上面我们可以得出两个原则:尽早测试原则和不断测试原则。
-
-
如何定义软件缺陷?(什么样的情况才算是软件缺陷)
凡是符合以下条件都属于软件缺陷:
-
需求中要求要实现的功能没有实现;
-
实现了需求中没有要求的功能(画蛇添足);
-
软件中出现了指明不应该出现的错误;
-
需求虽然没有明确说明,但是应该实现的功能没有实现;
说明: 需求并不是完美,有可能遗漏,所以测试人员不能够因为需求的错误而造成测试的错误。
-
程序运行缓慢,不宜于操作,要站在用户的角度上,一切不好的地方都是缺陷。
根据美国电子和电器协会对软件缺陷的定义:
-
从软件产品的内部看
要求测试人员对专业技能比较高(白盒);
-
从软件产品的外部看
要求测试人员对专业技能不高,只要懂得操作软件的功能即可(黑盒);
-
-
什么是软件测试?
简单来说,软件测试就是从现有的软件中尽可能多的查找软件缺陷的过程。
说明:
- 软件不是完美的,测试人员的职责不是消灭缺陷,而是尽可能多的查找缺陷;
- 软件测试是查找缺陷的过程,只要完成查找缺陷的过程就是测试,无论找到还是没有找到bug。
-
软件测试的基本步骤(简单、部分步骤)
-->设计、编写《测试用例》;
-->执行测试;
-->记录测试结果,将预期结果和实际的结果进行对比,如果发现结果不一致,发现bug;
-->编写一个《缺陷报告》:记录缺陷,提交给开发人员进行修复。
缺陷报告
-
软件的测试流程(步骤)
- 对被测项目进行详细需求分析(阅读需求,分析整理:功能组成,业务实现,规则);
- 制定测试计划 (测试组长、测试经理制定测试计划,测试人员主要阅读测试计划和执行测试);
- 设计测试,比如编写测试用例;
- 执行测试,记录测试结果;
- 记录缺陷,跟踪和管理缺陷(编写缺陷报告);
- 分析结果,记录缺陷(《缺陷报告》);
- 缺陷的跟踪、管理 ;
- 测试总结(《测试总结报告》)。
-
缺陷报告
-
什么是缺陷报告?
缺陷报告是指测试人员在发现缺陷之后,将缺陷记录在缺陷报告中并提交给开发方进行修复,通过缺陷报告可以对缺陷进行跟踪和管理。缺陷报告是测试人员与开发人员之间重要的沟通方式。
-
缺陷报告如何编写?
说明:其实缺陷报告的编写,并不是使用文档或者表格的形式进行记录缺陷:在企业中,有专业的缺陷管理工具,不同的企业,缺陷管理工具也可能是不一样的,但是,基本的内容写的大体都是相同。
比如:目前互联网测试使用的缺陷管理工具有(禅道(中文版),免费使用; qc(英文版) HP公司;bugzilla)
-
如何编写缺陷报告?
案例:被测项目“计算器”的“除数为0”的时候,点击错误消息提示框的确认按钮,程序退出(bug)
-
缺陷编号(DefectID)
-
说明:缺陷编号是记录缺陷的序号,在管理工具中是自动生成的。缺陷编号 并不是记录你当前所测功能的id,它是整个项目缺陷的ID
-
缺陷标题(Summary):概要说明bug。
-
缺陷发现者 (Detected by)
-
提交缺陷时间(Detected on date)
-
缺陷指派给谁(Assigned To)发现缺陷的功能模块(Subject)
-
缺陷所属的版本(Detected in version /release )
-
缺陷状态(缺陷的生命周期)
- 新的缺陷(new)
- 激活缺陷(open)
- 已修复的缺陷(fixed)
- 关闭的缺陷(closed)
- 被拒绝的缺陷(rejected)
- 重新激活的缺陷(reopen)
-
缺陷的严重程度 (severity)
常用的缺陷严重程度分为:
- 致命的缺陷(urgent)通常这类缺陷不解决,直接影响到后续的开发
- 非常严重(very high)
- 严重的缺陷(high)
- 中等严重(medium)
- 建议性的小问题(low)
-
缺陷的优先级
- 立即解决(bug-urgent)
- 可以在本版本中解决(very high)
- 可以在下一个版本中解决(bug-high)
- 可以在软件在发布之前解决(bug-medium)
- 尽量在产品发布之前解决(bug-low)
-
缺陷的描述(description)
将发现缺陷的过程,数据记录下来,使开发人员可以重现该缺陷(开发人员要能看明白);
要求:逻辑清晰、用语要专业、准确、易于理解、不要有任何评价性的语言出现。
-
-
总结:
问题1: 缺陷报告的跟踪处理过程(步骤、生命周期)?(重要面试题)
步骤1:测试人员将新的缺陷报告提交给开发方负责人(开发经理)
步骤2:开发经理验证缺陷报告,
- 情况1:验证通过,将缺陷报告激活,并指派给相应的开发人员。
- 情况2:验证未通过,将拒绝该缺陷。如果测试方最终确定是假缺陷将关闭该缺陷。如果最终确定是缺陷,那么谁拒绝的,谁负责激活缺陷,将缺陷重新纳入缺陷处理流程中。
步骤3:开发人员修改缺陷,修改完成后,将缺陷报告设置为已修复的状态。
步骤4:测试人员对已修复的缺陷进行返测,
- 情况1:返测通过,测试人员将缺陷关闭(可归档)。
- 情况2:返测未通过,测试人员将缺陷重新激活,由开发人员再次修改缺陷,直到返测通过,缺陷关闭为止。
问题2: 被拒绝的缺陷,测试人员要怎么处理?
- 测试人员应该要自己先确认一下是不是由于操作失误,或配置问题,造成假缺陷。
- 测试人员应该分析bug被拒绝的原因,例如:由于需求理解不同,造成bug被拒,可以通过与开发人员、产品经理沟通,讨论解决;如果由于bug不能重现造成被拒,应该与开发人员沟通,讨论解决等。
- 如果与各部门沟通讨论后依然无法解决问题,可以上报测试组长(经理),由组长出面,沟通解决问题。
- 得到最终结论后,如果是假缺陷,测试方负责将假缺陷关闭。如果最终认定是缺陷,那么谁拒绝谁负责将缺陷激活,重新纳入到缺陷处理流程中。
问题3: 影响缺陷优先级制定的因素有哪些?
- 缺陷的严重程度,一般越严重的缺陷,优先级越高。
- 开发人员的开发压力,开发压力越小,优先级越高。
- 缺陷影响的范围,影响范围越大,优先级越高。
- 解决缺陷所花费的成本(时间),成本越低,优先级越高。
问题4: 缺陷的优先级和缺陷的严重程度一定是成正比的关系吗?
不是严格正比关系,例如:界面中有错别字,虽然严重程度低,但是优先级却较高。
问题5: 缺陷的严重程度和优先级确定后还能修改吗?
-
缺陷的严重程度一般确定后是不能更改的;
-
缺陷的优先级可以修改,开发方根据实际情况经常会做拖延处理。(delay)
问题6: 在发布的软件产品中,是否会有发现但没有解决的bug?
-
有可能会有发现但没解决的bug存在于发布的软件产品中;
-
在实际应用中,对于该类缺陷需要开bug讨论会,权衡解决bug的成本,和不解决bug是否会给用户带来严重影响,以及法律纠纷后,才能最终确定;
-
对于该类bug,软件公司会在后期,通过版本升级或打补丁的方式给予解决。
第三讲 等价类划分和边界值法
-
测试用例
定义: 在测试执行之前,由测试人员编写的用来指导测试过程的重要文档。主要组成有:用例编号,测试目的,测试步骤(用例描述),预期结果(期待结果)等。
说明:不同公司使用的测试管理工具不同,所以用例的模板也有可能不同,但是核心的部分是大同小异的。
- 功能(黑盒)测试的主要测试方法?(核心)
- 等价类划分法
- 边界值法
- 因果图法
- 判定表法
- 正交排列法
- 测试大纲法
- 场景法
- 编写测试用例的参考资料(说明:参考资料在实际工作中常常不齐全,测试人员应利用一切能利用的资源参考来测试。)
- 参考软件的需求相关文档。
- 核心的技术类文档(在实际测试中常常没有,例如:开发和测试不是同一家公司的。)
- 已经开发出来的被测程序。(在实际工作中经常会参考被测程序进行测试,如果只参考需求文档大概只能编写30-40%左右的用例)
- 与产品部门、开发部门、客户进行沟通讨论。(还可以参考相似的软件系统,网络上的相关资源等)
- 功能(黑盒)测试的主要测试方法?(核心)
-
等价类划分法
-
应用场合
在程序中,有数据输入的地方可以使用等价类划分法。就是将大量数据划分若干范围,再从每个范围中挑选少量代表数据进行测试的测试方法。(抽样测试)
-
测试思想
-
“穷举测试”思想:将所有可能的数据全都测试一遍。穷举测试是最全面的测试,但是在实际应用中不能采用,因为穷举测试的测试效率极低,而成本高。
-
理想的测试思想:使用最少的测试数据,达到最好的测试质量。但是毕竟没有测试所有数据,有可能有遗漏缺陷的风险。所以如果测试时间允许时,应该进行“补充测试”,以降低遗漏缺陷的风险。(纠结的,随机挑选的,甚至第六感觉得有风险的都可以补充测试)
-
等价类划分法的测试思想
将大量数据划分若干范围(等价类),再从每个范围中挑选少量代表数据进行测试。每个等价类中的代表数据是可以代表整个等价类的测试结果的。
-
-
等价类划分法的测试步骤:
按照被测程序的需求分析,首先要认识两个概念:
-
有效等价类:对于程序来说,正确的,合理的数据。
-
无效等价类:对于程序来说,输入不正确的,不合理的数据。
根据分析出来的等价类画等价类图
-
-
-
边界值法
说明:在程序开发中,边界是非常容易产生bug的地方,所以应该重点测试,为了保证测试质量,可以使用边界值法测试边界。
-
应用场合
在程序中,有数据输入的地方常常使用边界值法,边界值法通常与等价类划分法一起配合使用,以形成一套较为完善的测试方案。
等价类和边界值法通常一起使用,但是某些特殊情况也有可能不是这样,例如:输入性别 ,有效:男、女 无效:男、女以外的 ,不需要边界值法。
-
如何使用边界值法
-
边界值点(2个)
有效等价类和无效等价类之间的分界点。(最大值、最小值)
-
次边界值点(4个)
-
边界值两边相邻的点是次边界值。
名称
(有效、无效)最小次边
(有效、无效)最大次边界
-
-
问题:
Q1:如果测试时间紧张,优先测试哪个边界值?
最大值和最小值 (边界值点)
Q2:边界值在需求中开始就确定好了吗?
不一定,有些边界值在开始时没有确定,可能逐渐才能明确。
练习:
1)年龄:18-60之间的整数
2)账号:3-20个字符
测试方法之因果图和判定表法
-
应用场合
界面中有许多个控件,控件之间存在组合和相互限制的关系。不同的输入条件的组合会有不同的输出结果。为了理清每个输入条件的组合和输出结果,因此要使用因果图和判定表法。
说明:因果图和判定表比较适合用于测试控件比较少的被测项目中。(一般控件少于20种)
-
对因果图基础认识
-
因果图的因是什么? 果是什么?
因:输入条件 果:输出结果
-
什么是因果图法?
是用画图的方式,表示因与果之间的关系。
-
因果图的图形符号
因果图的基本图形符号 用来表示因---果之间的关系
-
因果图的限制图形符号 用来表示因--因 果--果之间的限制关系
-