基础知识扫盲

1.什么是软件测试

经典定义:在规定条件下对程序进行操作,以发现错误,对软件质量进行评估。

2.软件测试目的

早期:寻找错误,并尽可能寻找更多的错误

测试是程序的执行过程,目的在于发现错误;

一个好的测试用例在于能发现至今未发现的错误;

一个成功的测试是发现了至今未发现的错误的测试。

测试的目的,是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正各种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

3..软件测试遵循的原则

(1)测试显示缺陷的存在,但不能证明系统不存在缺陷

2)穷尽测试是不可能的,应设定及时终止的条件

3)测试应尽早进行

(4)缺陷具备集群特效

测试中发现的大部分缺陷和软件运行失败往往是由少数的软件模块引起的,而一个模块中我们发现了越多的缺陷,那也往往意味着这个模块中有越多的缺陷没有被发现。

(5)测试的杀虫剂悖论

我们不断地用同样的测试用例和方法测试同一个模块,不能再发现新的缺陷。因此测试用例和方法应不定期的评审和修改,并且增加不同的测试方法或用例来测试不同部分,从而发现更多缺陷

(6)测试的二八原则

找出软件中所有的错误和缺陷是不可能的,测试总是存在风险。要把80%的测试实践和资源用在 20%的重点项目上。

4.系统测试流程

5.测试分类按开发阶段分:单元测试、集成测试、系统测试、确认测试、验收测试的区别与联系

单元测试:由开发人员测试,对编写的每个模块进行测试。

集成测试:模块集成后成为组件,对测试单元之间的接口实施/ 单元与组件/ 组件之间的接口实施,验证接口是否与设计相符。

确认测试:在集成测试后,需要监测与正式软件是否满足软件需求说明书中规定的要求

系统测试:经过集成测试后,部署在真实的用户环境下的测试。对硬件、网络、操作系统及平台支撑构成的整体系统进行测试。

验收测试:以用户为主,验收组由项目组成员、用户代表组成。

6.测试分类按实施组织分类:开发方测试、用户测试、第三方测试

开发方测试:验证测试或α测试

用户测试:β测试

第三方测试

7.测试分类按测试技术划分:黑盒测试、白盒测试、静态测试、动态测试、手工测试、自动化测试

黑盒测试:通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子,完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试,他只是建成样序是否按照需求规格说明书的规定正常实现。

白盒测试:也称结构测试。通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的白盒子里,也就是清楚了解程序结构和处理过程,检查是否所有的结构及路径都是正确的,检查软件内部动作是否按照设计说说明的规定正常进行。

静态测试:无需执行被测程序,而是通过评审软件文档或代码,度量程序静态复杂度,检查软件是否符合变成标准,借以发现程序的不足之处,减少错误出现的概率。方式:互审、走查、会议。

动态测试:通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性登。

手工测试:由专门的软件人员从用户视角来验证软件是否满足设计要求的行为。更适用于针对深度的测试和强调主观判断的测试。

自动化测试:使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。

8.具体的黑盒测试用例设计方法:等价类划分、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法。

等价类划分:把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于其他值。、

边界值分析:通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界,而且也必须考虑输出域边界。

错误推测:是基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的测试用例的方法。

因果图:从用自然语言书写的程序规格说明的描述中找出因(输入条件)和果(输出或程序状态的改变),可以通过因果图转换为判定表。

正交试验:使用已经造好了的正交表格来安排试验并进行数据分析的一种方法,目的是用最少的测试用例达到最高的测试覆盖率。

7.功能测试、性能测试、安全测试、兼容性测试、文档测试、可靠性测试、易用性测试、本地化测试、部署测试、无障碍测试

功能测试:对提供给用户的软件功能进行验证。针对功能错误或遗漏、界面问题、性能错误、数据及访问错误、初始化及终止错误。

性能测试:验证系统是否可以满足需求要求的指标。可延伸出负载测试、压力测试、稳定性测试。性能指标:并发用户数VU、每秒事物数TPS、系统响应时间、设备性能。

安全测试:确保其符合产品安全需求和质量标准。注意区别于渗透测试。

兼容性测试:软件本身兼容性、不同平台下的兼容性、软件对运行设备的兼容性、软件互操作性。(web浏览器兼容性)。

文档测试:针对软件产品的交付品,配套的文档类部件的测试。用户手册、使用说明、用户帮助文档等。要点:完整、正确、一致、易理解、易浏览。

可靠性测试:软件可靠性,(更多是)硬件可靠性。主要是硬件产品大河报在设计运行中受气候环境以及机械环境影响下能否正常工作。典型的工作包括老化、温度、湿度、气体的腐蚀性、高雅地区、防尘防水还有包装压力等。

易用性测试:站在用户角度使用是否方便、能否保证用户体验。一般是UI层面的测试,包括鼠标点击次数、页面风格是否一致、业务流程是否复杂、有无误导用户的指引、网站布局等。

本地化测试:针对不同地区用户推出的差异化版本。主要考虑1 语言和书写习惯     2时区、日期格式、货币     3.当地风俗、法律法规      4.政治敏感内容。

部署测试:也叫安装测试,验证系统部署过程,确保软件经过按照测试后可以正常使用。主要测试:在不同环境下的部署验证、参照部署文档执行,确定过程的合理、正确性、基础数据的准备。

无障碍测试:软件需要提供便于特殊人群的使用功能,包括盲人、听障、老人、身体残疾用户等。

8.其他测试概念:回归测试、Monkey测试、冒烟测试、A/B测试

回归测试:软件功能修改后,对软件进行重新测试以确定修改没有引入虚拟的错误或导致其他部分产生错误。最适合用来做自动化测试。

Monkey测试:用一些随机、稀奇古怪的方式来操作软件,以测试系统的健壮性和稳定性。

冒烟测试:和回归测试类似,更多的是针对全流程的关键业务流程的验证,回归测试可以针对具体的功能模块分开进行模块级的测试。

A/B测试:多用于互联网行业,通过为页面提供两个版本给用户使用并记录相关的用户行为数据,来确定更优化设计的一种测试方案。要点:1.多个方案并行  2.每次测试仅改动一个变量  3.按照某种规则进行优胜劣汰。

9.软件失效分类:软件错误、软件缺陷、软件故障、软件失效

软件错误:在可预见的时期内,软件仍有人来开发。在整个软件生存期的各个阶段,都贯穿着人的直接或间接地干预。然而,人难免犯错误,这必然给软件留下不良的痕迹。软件错误是指在软件2生存期内的不希望或不可接受的人为错误,其结果是导致软件缺陷的产生。可见,软件错误是一种人为过程,相对于软件本身是一种外部行为。

软件缺陷:是存在于软件(文档、数据、程序)之中的那些不希望或不可接受的偏差,如少一个逗号,多一句语句等。其结果是软件运行于某一特定条件时出现的软件故障,这时称软件缺陷被激活。

软件故障:指运行过程中出现的一种不希望或不可接受的内部状态,譬如,软件处于一个多余循环过程时,我们说软件出现故障。

软件失效:指软件运行时产生的一种不希望或不可接受的外部行为。

10.缺陷与错误严重性和优先级
给软件缺陷与错误划分严重性和优先级的通用是:表示软件缺陷所造成的危害的恶劣程度、优先级表示修复缺陷的重要程度与次序。
级别:严重、较严重、一般、建议
  严重:系统崩溃、数据丢失、数据毁坏。
  较严重:操作性错误、错误结果、遗漏功能。
  一般:小问题、错别字、UI布局、罕见故障。
  建议:不影响使用的瑕疵或更好的实现。。
优先级:最高优先级、次高优先级、中等优先级、最低等优先级
  最高优先级:立刻修复,停止进一步测试。
  次高优先级:在产品发布之前必须修复。
  中等优先级:如果时间允许应该修复。
  最低等优先级:可能会修复,但是也能发布。
8.错误跟踪管理
(1)bug记录信息
  主要包括以下几项内容。
  • 测试软件名称
  • 测试版本号
  • 测试人名称
  • 测试事件
  • 测试软件和硬件配置环境
  • 发现软件错误的类型
  • 错误的严重等级
  • 详细步骤
  • 必要的附图
  • 测试注释
(2)bug处理信息
  • 处理者姓名
  • 处理时间
  • 处理步骤
  • 错误记录的当前状态
(3)软件错误状态
  • 新信息(new):测试中新报告的软件Bug
  • 打开(Open):被确认并分配给相关
  • 修正(Fixed):开发人员已完成修正,等待测试人员验证。
  • 拒绝(Declined):拒绝修改Bug
  • 延期(Deferred):不在当前版本修复的错误,下一版修复
  • 关闭(Closed):Bug已被修复
(4)错误流程管理
测试人员提交新的错误入库,错误状态为“New”
  • 高级测试人员验证错误
       ①如果确认是错误,分配给相应的开发人员,设置状态为“Open”
       ②如果不是错误,则拒绝,设置为“Declined”状态
  •  开发人员查询状态为“Open”的错误,做如下处理。
       ①如果不是错误,则置状态为“Declined”。
       ②如果是错误,则修复并置状态为“Fixed”。
       ③如果不能解决的错误,要留下文字说明并保持错误为“Open”状态。
       ④对于不能解决和延期解决的错误,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。
  • 测试人员查询状态为“Fixed”的错误,验证错误是否已解决,做如下处理。
       ①如问题解决了,置错误的状态为“Closed”。
       ②如问题没有解决,则置状态为“Reopen”。
 
(5)错误流程管理原则
为了保证错误处理的正确性,需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误,书写的测试步骤是否准确,可以重复。
每次对错误的处理都要保留处理信息,包括处理姓名、时间、处理方法、处理意见、Bug状态。
拒绝或延期处理错误不能由程序员单方面决定,应该有项目经理、测试经理、设计经理共同决定。
错误修复后必须由报告错误的测试人员验证,确认已经修复后,才能关闭错误。
注意:加强测试人员与程序员之间的交流,对于某些不能重复的错误,可以请测试人员补充详细的测试步骤和方法,以及必要的测试用例。

 

posted @ 2017-11-07 13:53  Jenny_Deng  阅读(192)  评论(0)    收藏  举报