一、测试流程与生命周期

1、软件的生命周期

生命周期包括:软件定义及规划,需求分析,软件设计,软件编码,软件测试(单元测试,集成测试,系统测试,验收测试),运行维护

 

2、软件测试的基本流程

开发流程:需求分析--功能组成+具体逻辑--编写代码--单元测试--打包提交测试--测试提交bug--修复bug--回归测试--...N轮--版本上线--面向用户使用

测试流程:需求分析+原型图--编写测试用例--评审测试用例--开发出接口,进行接口自动化--开发出功能,进行功能测试--测试提交bug-修复bug--回归测试--...N轮--版本上线--面向用户

 

3、各阶段介绍

软件定义及规划:此阶段是软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性

需求分析:在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析

软件设计:此阶段主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计,数据库设计等等

程序编码:此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一,符合标准的编写规范。以保证程序的可读性,易维护性,提高程序的运行效率

软件测试:在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性

运行维护:软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面

 

二、测试的分类方法

1、黑盒测试

概念:在完全不考虑程序内部结构和内部特性的情况下,针对可见的功能进行测试

优点:容易实施,不需要关注内部的实现;更贴近用户的使用角度

缺点:测试覆盖率较低,一般只能覆盖到代码量的不到40%;针对黑盒的自动化测试,复用率较低,维护成本较高(程序功能变化快)

  

黑盒测试主要关注什么?

是否有不正确或遗漏的功能?在接口上,输入是否能正确的接受?能否输出正确的结果?是否有数据结构的错误或外部信息(例如数据文件)访问错误?性能上是否能满足要求?(长时间测试,并发测试,响应测试)

 

黑盒测试的主要设计方法?

等价类划分法:针对很多输入条件,等价的归为一类,会形成典型的代表性的输入,根据典型的输入编写用例

边界值分析法:关注各种各样边界条件

错误推测法:基于经验或直觉判断程序中可能出现错误的地方,针对性的设计用例

因果图法:需求规格说明书,根据规格语义说明编写用例

正交试验分析法:通过正交性从一组数据中筛选典型代表性数据的设计方法

状态迁移图法:通过梳理软件功能点中的软件状态变迁关系设计用例

流程分析法:梳理程序逻辑执行路径

  

2、白盒测试

概念:又称结构化测试和透明盒测试,针对程序的逻辑结构设计用例

优点:迫使测试人员去仔细思考软件的实现,理解原理;可以检测代码中每条分支和路径;揭示隐藏在代码中的错误;对代码的测试比较彻底

缺点:昂贵(较高的覆盖率);无法检测代码中遗漏的路径和数据敏感性错误(数据处理的有问题);不能直接验证需求的正确性(从代码层面进行验证)

 

白盒测试的主要设计方法:代码检测法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法

 

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

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

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

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

7、UI测试:用户界面测试是指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,操作是否对用户友好,人性化,易操作性测试等

8、冒烟测试:冒烟测试的对象是新编译的每一个需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作

9、随机测试:随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程

10、本地化测试:本地化就是将软件版本语言进行更改,比如将英文的windows改成中文的windows就是本地化

11、安装测试:安装测试是确保软件在正常情况和异常情况下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装的测试。异常情况包括磁盘空间不足、缺少目录创建权限等场景

 

三、测试用例设计 

等价类划分法:顾名思义就是将测试的范围划分成几个互不相交的子集,他们的并集是全集,从每个子集选出若干个有代表性的值作为测试用例。

边界值分析法:长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此为了查出更多的错误,设计的测试用例应选取正好等于、刚刚大于、刚刚小于边界的值。

错误推测法:在测试程序时,人们可以根据经验或直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误的测试用例的方法。这种方法没有固定的形式,依靠的是经验和直觉,很多时候,我们都会不知不觉的使用到。

判定表法:又称为策略表,基于策略表的测试,是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景,通过穷举条件获得结果,对结果再进行优化合并,会得到一个判断清晰的策略表。

正交实验法:用语言描述正交实验法会很抽象难懂,简单说,就是在各因素互相独立的情况下,设计出一种特殊的表格,找出能以少数替代全面的测试用例。其中,上面所说的特殊表格就是正交表,是按照一定规则生成的表。

 

四、Bug提交

1、Bug有效性

交付过程中测试者需按照设定好的模块,对Bug进行归类提交;

Bug的类型确认为UI问题、功能问题、崩溃问题,提交Bug时不能弄错;

需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清楚、Bug是否唯一性;

避免提交设计如此、操作错误、重复的、已知的Bug;

尽量少花时间在边界值、页面显示问题上,多提业务逻辑功能、交互测试方面的问题。

2、Bug标题

Bug标题要求简明扼要的阐述问题本质,使查看人员能快速了解Bug内容。需要写明在哪个页面执行什么操作出现什么现象。

3、测试设备

提交Bug要表明测试使用的设备、设备操作系统版本、测试环境、网络类型等等。

4、前提条件

明确指出所提交的Bug是在怎么样的情况下出现的,当所发现Bug前提条件为空时,需要填无。

5、测试步骤

要简明清晰分步骤描述如何复现Bug问题,步骤用序号编排。
要按照自己的操作的实际步骤写清楚每一步是怎么操作的,最后操作到哪个页面或者点击哪个按键。
如在特定情况下发生的问题,还需明确提供以下信息:

准确写出连续点击次数,点击时长与上下滑动屏幕时长。
对于特定数据产生的问题,提供具体数据。
精准描述bug产生的路径后,再描述现象。

6、期望结果

按照测试步骤应当得到的正确结果,按照产品需求的期望清晰准确的填写预期结果。而且结果必须是肯定无疑义,可判定性的结果。

7、截图和附件

UI类型:Bug需要上传截图,并且增加相应的红框标识;
功能类型:问题必须上传视频文件,上传格式MP4为主;
崩溃类型:bug则需要上传视频和log并且log不得超过10分钟。

 

五、测试报告编写

1、什么是测试报告

测试报告是产品部与技术部进行沟通的主要手段;是一个测试活动的总结,项目是否结项的重要参考和依据;软测试报告是对测试过程和测试结果进行分析和评估,确认测试计划是否得到完整履行、测试覆盖率是否达到预定要求以及对产品质量是否有足够信心,并最终在报告中给出测试和产品质量的评估结论。

2、测试报告的内容

测试项目的版本,测试项目内容的概述

测试的时间、地点、人员

测试环境:测试环境的描述,包括客户端和网络环境

测试资源:测试过程中的测试资源使用

缺陷统计:包括bug数,解决数,遗留数,bug模块分布

测试用例的执行情况:测试的覆盖率

测试评估:基于软件缺陷的质量评估,写明在这一版本中,哪些功能被实现了,哪些还没有实现,这里只需写明和上一版本不同之处即可

规避措施

急待解决的问题:写明当前项目组中面临的最优先的问题,可以重复提出

附件

3、测试报告的注意事项

两个核心内容:一、评估测试覆盖率;二、基于软件缺陷的质量评估。

内容简洁:说话抓住重点,不说废话,简单易懂,精益求精,简单明了,能用图形、表格的尽量用图形、表格展示,这样更加直观。

分析结论一定要给出,并且明显的位置。让项目经理清楚你的测试结论是什么,当时间比较紧的时候他看到结论心里就有数了。

测试报告写完后,把其他的详细数据付成附件,可供想得到详细数据学习的人去学习理解。

在测试报告中的问题,要有优先级