软件测试基础___测试理论篇

前言

       高手,是避免失败,而不是追求成功

目录

前言

       高手,是避免失败,而不是追求成功

1.为什么要写测试理论篇

2.软件测试的目标,模型及核心

3.软件测试目标案例

4.软件测试的策略

5.软件测试的依据1

6.软件测试的依据2

7.软件测试的依据的案例总结

8.软件测试的不可穷尽性1

9.软件测试的不可穷尽性2

11.Bug的汇报和处理流程

12.Bug的汇报的原则与案例

13.错误的思想实现 和 [目标-差异]思想

14.错误的设计和缺失的设计

15.测试计划和测试用例

 

---

1.为什么要写测试理论篇

 

 

当前,我们在网络上可以轻易搜到大量软件测试理论知识.然而事实上,国内当前的测试理论领域可以说是一片空白,你能搜到的理论知识有以下几个特点:

1.过时 2.绝对化 3.碎片化

1.过时

软件测试理论始于20世纪中后期,然后在后面几十年里,几乎没有更新.举个例子:软件测试用例设计方法里有一个因果图法,一个判定表法,这两个方法我接触测试行业以来从来没有用过,也没有见人用过.

可以说,根本没用.在大量资料中作者到处引用那些过时理论,给学习软件测试的人造成了巨大困扰.过去几十年里,软件项目的管理流程发生了变化.从瀑布模型到V模型,W模型,迭代模型,甚至develops模型.

不同模型下软件测试人员的工作方式方法完全不同,怎么会有防止四海皆准的测试理论呢

 

2.绝对化

不同的项目有不同的要求,在这个项目里可以用的方法,在那个项目里可能不行,而大量过时的测试理论资料可不管这些,上来就给你一个明确定义,即使这个定义很可能只适用于某一种类型的项目.

"看看书上是怎么写的"这种就是典型的教条主义,测试人员不应被测试理论资料所局限,即使把定义背的滚瓜烂熟也没有用,不能理解以发挥作用,没有任何现实价值.

要清楚明白对于学习过的任何理论知识,保持怀疑态度,并谨记,他们既可能随时会过时,也可能只是用于特定时期的特定项目

 

3.碎片化

通过网络搜索来学习,需要读者有信息筛选的能力,信息筛选需要通过实践来跟练,过于碎片化的知识影响学习效果.很可能你搜索出来一大堆资料里只有一小部分是真实有用的

这对新入行或转行过来的测试人员来说,是非常痛苦的

结语

   本篇宗旨是给大家介绍从事软件测试行业所需要的理论知识

致力于解决如上三个问题,提供一套系统化的,可以根据项目灵活把握的,符合当下新时代特点的软件测试理论知识,同时也善告大家不要犯教条主义错误

结合自己遇到的项目实际情况,具体问题,具体分析.

---

2.软件测试的目标,模型及核心

 

 

---

3.软件测试目标案例

 

 

在理解了软件测试的目标,模型及核心之后,我们需要知道,每个实际项目乃至于一个项目的每个时期,做软件测试的目标都会发生变化,都可能有所不同.

项目:某B2B电商平台网站改版

简介:对一个正在运营中B2B电商平台做改版,主要修改了前端页面风格,并作一些后台逻辑修改.优化了一些诸如测试流程等的用户操作流程.增加了一块让用户可以通过短视频做营销的功能

项目时间:1个月后就是领导拍板敲定的上线日期

项目人员:2开发1测试

项目特点分析:时间紧 任务重 在了解实际想要交付功能后 我就知道项目绝对做不完的,或者绝对来不及的,可以预见以下结果:

1.一开始领导不会面对现实,只会安排加班

2.然后会发现功能始终无法正常交付,即使交付也用不了

3.最终会有三种可能  a)强行上线 b)砍掉一块功能 c)推迟上线

 

这和我们测试目标有什么关系?

1.这种项目大概率需要测试人员对项目是否被发布提供建议.  我们需要提前分析每一块功能模块对项目来说重要程度,重点功能重点测,次要功能可能后期就被砍掉了.时间是被挤出来的

软件测试的核心问题就是效率.我们遇到最大问题不是不能测全测好,而是在有限时间内,难以测全,于是就要划分优先级.重要的先做,多做.如此项目,前端页面改版比做,必上线的.

值得一提的是,我们一般不提正面建议,也就是说只跟领导讲还有什么风险,即不说不能发布,也不说能发布,非要问我们,就说因为什么什么问题还没有修复好/或什么功能到现在还没开发完

,未来按时发布的风险较大. 而开发一般会把功能拖到最后一天才给测试.因此我们必须做到:每天催,每天向领导汇报进度(不是我没测完,是开发压根没开发好),防止背锅.

2.因为时间太紧,赶工肯定有很多Bug,我们不需要找到所有Bug,这是不可能的,但我们为了效率,工作必须有个重点,我们的重点是要找到所有重要的或者严重的Bug.特别核心业务模块中的

严重Bug.这是测试策略的问题.这些严重Bug通常是指用户在完成主要操作或常用操作时,会遇到的导致操作不下去的Bug,导致金钱等受损或有重大风险的Bug,其他安全方面的Bug等等.

而不是那些边边角角的细枝末节.据我所知有些测试同学因为早期从等价类,边界值等古典测试用例设计方法开始学,导致他们特别喜欢钻牛角尖.一个待测功能的主要用户操作流程没测过.

先去测各种边界值.然后很高兴地向开发提一堆"当某个文本框输入65536个字符时,系统不能给出有意义的错误信息"之类的边边角角Bug,且不说这种情况下出问题算不算Bug,请想一下用户

遇得到这个Bug吗.这种Bug,只在你能明确证明他会有严重影响的时候,才算一个有意义的Bug.更多时候,他只是一个改进点.在这种时间紧任务重的项目里,就不要去找那些改进点了

有限时间多花在主要用户流程上吧.

3.砍掉一块功能或推迟上线大家见多了.再讲讲强行上线是怎么做的吧.所谓强行上线.就是非那天不可.领导又不愿意砍掉功能.比如有时候为了赶某个特殊时间节点.此时开发被迫日夜加班

.可是开发最后还是没有交给测试.测试时间可能压缩到了原计划的几分之一.这时候就只能加人了.也就是让开发一起测.还不够的话,把其他部门的人.比如产品.前台.财务.人事.客服等等

,全叫过来一起执行测试用例.要做到全体一起赶工.测试人员必须提供测试用例.所以在这种项目里,测试用例必须写,而且最好写详细点.

---

4.软件测试的策略

 

 

测试策略是你所做的计划,其目的是实现你的测试目标.前提条件是必须根据你的项目实际情况来采取不同的测试策略.

---

5.软件测试的依据1

 

 

当我们做测试时,我们需要判断软件的功能是否正确,或者说是否符合预期.但问题是,我们怎么判断一个功能是否正确呢.这就需要一个依据

软件测试的依据指我们用来判断待测软件的功能,性能等指标是否符合预期的一个标准

这个标准是且不限以下这些:

• 一份标准的需求文档
• 一份不标准需求文档或电子邮件等
• 一份需求讨论会的会议纪要
• 用户给出的反馈
• 企业标准,行业标准,国家标准,国际标准等标准
• 相关法律法规
• 竞争对手的产品的类似功能
• 常识
• 安全
• 性能

为什么需要依据?

软件工程是一个复杂活动.往往需要多人协作.不同人对于同一句话,同一个事物,往往有不同的理解

绝大多数项目要么没有需求文档,要么需求文档不完整或不是最新的.不建议在没确定测试依据之前就开始测试,测试一句不明确