测试理论基础

在自己实际工作中,经历很多种测试流程,各种情况都存在,参考下面的知识,对照公司现行的流程,会思考更深入的问题,从而夯实理论基础,提升测试水平。

应了解的概念:

测试testing和QA(quality assurance):软件测试员的目标是尽可能找出软件缺陷,并确保缺陷得以修复

                                                                QA主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法

软件测试的概念:

软件缺陷的概念(软件测试原书第2版):软件缺陷即bug,满足以下五个规则之一的才称发生了一个软件缺陷:

                                                                                                                                          1.软件未实现产品说明书要求的功能;

                                                                                                                                        2.软件出现了产品说明书指明不应该出现的错误;

                                                                                                                                         3.软件实现了产品说明书未提到的功能;

                                                                                                                                         4.软件未实现产品说明书虽未明确提及但应该实现的目标

                                                                                                                                         5.软件难以理解、不易使用、运行缓慢---或者从测试人员的角度看--最终用户会认为不好 

bug的生命周期

软件测试的工作流程:瀑布模型:原始需求--项目计划--需求文档--概要设计--详细设计--编码--测试--运维

                                   双V模型

                                   敏捷scrum

软件测试的方法分类

测试策略

软件测试常用的工具

软件测试技能:沟通能力、自我驱动能力、学习能力、快速的适应能力、责任心、态度。。。

                        功能测试、自动化、接口、性能、安全。。。

一、功能模块的测试过程
1.需求问题
1.作为一名测试,不是拿到需求后立刻想用什么用例的设计方法,马上设计用例,而是先分析讨论需求有哪些不明确的地方
2.需求评审会后,如果还有需求不明确的地方,可以和产品经理进行确认沟通,只有需求明确后,才可以继续进行需求分析,设计用例
2.需求分析
1.对输入参数进行分析
1.确定输入参数的个数和名称
2.确定每一个输入参数的组成规则——类型、长度、取值范围、是否允许为空、是否允许重复、其他规则
3.根据输入规则,构造测试数据
1.符合规则的数据--有效数据
2.不符合规则的数据--无效数据
3.数据太多,如何挑选数据?等价、边界值等等,,,
2.对处理进行分析
1.正常处理--正常操作
2.异常处理--错误的操作,不按规定操作,例如超时操作
--正确的操作+环境异常(网络异常,服务器异常)
3.对输出结果进行分析
1.正常的结果输出--可见输出,成功或失败的提示
--不可见的输出,增加一条新的记录
2.错误的结果输出提示--各种错误提示
3.用例编写
1.正常的用例--一条正确的用例要尽量包含多个有效的测试数据--正常输入+正确处理
2.异常的用例--一条异常的用例,只能包含一个无效的测试数据--错误的输入+正确的处理
--正确的输入+错误的处理
4.用例评审
组内人员进行用例的评审,进行用例的补充或查错
测试/开发/产品一起讨论用例,进行用例的补充或查错
补充:用例的评审标准是什么?
1.设计的用例覆盖所有的测试点
2.选择的测试数据要精炼
3.一条异常用例只能包含一个无效数据
4.一条正确用例要尽量包含多个有效的测试数据
5.用例的可读性

二、测试方法:
1.等价类方法
由于测试数据多,测试时间有限,找出具有代表性的数据进行测试,提高测试效率
适用范围:输入框类元素
2.边界值法
边界上的数据更容易出bug
例如:[1,2] 上点--边界上的点1、2
离点--离边界最近的点--0、3 例如(4,8)离点--5,7
内点--边界内的任意点
3.输出域覆盖法
由输出结果倒推输入是否正确,可以进行用例的补充
适用范围:界面默认显示数据
4.判定表法
条件桩-判定条件
动作桩-根据不同的条件产生的相应结果
设计步骤:1.列出所有要判断的条件-条件桩 n个
2.列出所有可能产生的结果-动作桩
3.列出所有条件桩组合 2的n次方个
4.分析每条组合产生的结果--符合条件记为0,不符合条件的记为1
5.编写用例-一列对应一条用例,筛选出符合条件的,不符合的删除即可
适用范围:多个条件,条件之间还有逻辑关系
5.正交实验法
1.确定输入参数名称-因子
2.确定每个参数的取值-状态
3.画因子状态表
4.借助工具--allpairs(或者PTCA)
--将allpairs工具解压至D盘根目录
--在allpairs文件夹下新建一个test.txt,将因子状态表中的内容复制到test.txt中
--打开DOS窗口,进入allpairs文件夹下
--画因子状态表,并且用符合代替
--输入命令 allpairs.exe test1.txt -> test2.txt
--将生成的txt中的test case下的用例复制到excel中,并且用中文替换
--每一行表示一条测试用例
适用范围:存在多个输入,输入中参数取值固定,输入之间没有逻辑关系
6.流程分析法
1.从需求中提取判定条件--如果、假如。。
2.先从基本流开始--正常情况
3.再开始备选流--异常情况
4.从开始到结束,每条路径对应一条测试用例
7.状态迁移法
1.从需求中提取所有的状态
2.根据需求画状态矩阵图--如果有n个状态-n*n矩阵
--将所有状态可达--用√表示
--不可达不表示
3.将状态矩阵转换为状态迁移图--广度优先
--深度优先
4.设计用例--从开始到结束,每条路径都是一条测试用例
--进行用例的筛选和补充
适用范围:一个状态可以到达其他多个状态
8.因果图法--用图解的方法分析输入参数和输出结果之间的关系
适用范围:输入与输入之间有一定的关系,输入和输出之间有因果关系,输出与输出之间有一定关系
9.异常分析法--认为让系统出现故障,检查系统故障的恢复能力,断电、断网、强退、内存。硬盘空间不足等。。
10.错误猜测法--根据以往的测试经验或对系统业务的了解,列出可能出现异常错误的操作
11.输入域覆盖法--根据输入类型判断,例如:输入框允许输入10位字符串,设置类型为整型长度为5位--类型长度会越界
12.ET探索测试法
13.MFQ&PPCDS
后面详细介绍12、13

三、其他测试理论知识点

1.缺陷管理的流程
1.测试提交bug,开发修复bug,测试回归
2.测试提交的bug可能不是bug,测试经理审核是不是bug,bug是否重复
3.测试提交了bug但开发拒绝修复,项目经理开缺陷评审会议确定bug是否需要修复,是-fixed;否-丢弃或延期
4.测试提交的bug较多,开发优先修复某些bug,开发经理判断:重要bug--分配、不重要bug--延期
2.缺陷报告标题:缺陷编号、描述、重现步骤、修复优先级、严重程度、附件、测试用例编号、提交人、提交时间
3.bug严重程度:致命--系统卡死、闪退、崩溃
严重--主要功能存在缺陷
一般--界面、性能
轻微--易用性
建议

四、网络基础

HTTP协议:

请求:请求行--

           消息报头

          请求正文

响应:状态行

           消息报头

           响应正文

 

posted @ 2018-07-28 21:41  迷迷糊糊的礼物  阅读(522)  评论(0编辑  收藏  举报