常用测试理论知识

常用测试理论知识

软件生命周期

软件测试流程

测试策略／测试类型

测试类型

测试策略

扩展区分

测试用例设计方法

等价类划分法

边界值分析法

判定表法

常见测试问题及解决办法

如何协调沟通

如何有效保证测试用例覆盖度

如何预防／处理线上问题

如何提高测试效率

软件生命周期

软件生命周期，定义什么的百度百科都有，重点指出以下的就是：软件生命周期不是某一个节点，功能什么的，它是一个过程（从软件开始到结束的这一整个过程）

典型的软件生命周期模型：

 

瀑布模型（百度一大堆）

重点说一下特点：线性的模式，只有上一阶段完成了，下一阶段才能继续。

优缺点显而易见：流程很简单，每个阶段工作内容和产出很明确，但是容错性地，一个阶段出问题，后面的都得等着。而且只有等到最后才能看到结果，如果一旦产生致命性问题，修复问题的代价太大。

 

tips：这里说一下这个是因为瀑布模型是一个基础模型，虽然基本上不会用到，但是后续的模型基本上是以此衍生的。

 

迭代式模型

一般情况下，整个产品功能都是比较复杂，一下载把全部的功能开发完成，耗费的时间／人力成本太多。基本上现阶段各个公司都在抢风口，谁家的产品快上线，谁家就能占领第一份市场。因此，把整个产品需求由粗到细进行划分，划分成几个阶段（就是所谓的1期功能，2期功能，3期功能）分别上线就能在市面上快速占领先机。

可以看出迭代模式特点：

1）风险暴露早／修复问题成本低

2）时间周期短

3）项目能快速上线

4）持续迭代的过程

 

tips：迭代式模型中每一个迭代其实就是一个瀑布模式

 

软件测试流程

国内的软件测试从无到有，从不被重视到被重视，从开发兼职到形成软件测试工程师这一职业，经过了多年的沉淀，整个行业早已经形成了一套大同小异的软件测试流程。但测试流程往往会与开发流程挂钩，所以一般都统称为“软件开发测试流程”。同理，一套符合自己公司的且完善的软件开发测试流程会大大提高软件开发／测试的速度，从而缩短软件开发／测试的时间。在这里，本文只对于常规的软件开发测试流程来进行描述。（具体的测试流程可能会因公司而异，且本文旨在说明测试在整个软件开发过程中的测试这一部分的流程）

 

如上图所示，整个流程的参与者大致有三方【产品】【开发】【测试】。流程图相信还是比较通俗易懂的，基本上测试小白都能够理解。这里可能重点说明2个关注点：

 

1）第一个开发／测试工作节点对应关系

大家仔细看一下流程图，会发现开发测试流程节点上下对应是不是很工整？哈哈，这是有原因的。

如：

第一阶段：开发在概要设计阶段，测试的工作就是在做测试计划（此阶段都是在根据需求进行开发测试估时，根据概要设计进行测试计划编写等等）

第二阶段：开发的详细设计阶段，测试工作就是制定【测试方案】。不过，根据我的了解，现实中大多公司对于【测试计划】和【测试方案】这两个阶段都没有特别的区分，即合二为一称为一个【测试工作计划】阶段。

第三阶段：开发在写代码的同时，我们测试的工作就是在进一步研究需求，细化需求，来编写测试用例。

第四阶段：开发进行单元测试之后，就是到了我们进行测试执行了。

此处特别说明一下，测试计划 和测试方案。

【测试计划】：基本上是从管理者的角度上来说的。如：对于本次测试如果进行人员分配，资源如何协调，有啥测试规定，如何应对测试过程中出现的各种风险等等）

【测试方案】：这个就是从技术角度上来说，对于本次测试，采取那些测试策略，测试方法，测试用例设计，测试工具选择等等。

 

2）Alpha(α)测试／Beta(β)测试

定义都可以看百度百科，这里说一下重点

α测试：

1）公司内部的一种验收测试（即：代码还未上线）

2）不对外的，模拟实际用户的操作进行测试

3）人员没有相关的经验（也有可能给外包）、PM（产品经理）／运营人员、也可以是实际用户来公司进行测试。一定不能是开发者或测试者

4）这是一种非正式验收

5）实际工作中通常用作产品验收阶段（此点为本人实际工作得出的结论）

 

β测试：

1）对外的，少量的实际用户的操作（把实际用户当作测试反馈来源）

2）测试场所都是不可控制的真实用户场景（即：所有代码已经上线）

3）这也是一种非正式验收测试

4）实际工作中通常是被称为“灰度测试”阶段

 

tips：β测试的问题修改完成之后且验证无误之后，才会全量。

 

测试策略／测试类型

测试类型

软件测试类型还是比较好理解了，百度也有很多，基本上大部分人都知道一些，也没有什么争议，这里也就不再过多介绍，只列出基本的几种类型，以共了解

 

白盒测试

1）静态测试

2）动态测试

黑盒测试（俗称功能测试）

性能测试

1）负载测试

2）并发测试

3）稳定性测试

4）基准测试

安全测试

兼容性测试

1）浏览器兼容

2）操作系统兼容

3）手机厂商兼容

其他（UI测试／安装、卸载测试／本地化测试／文档测试等等）

测试策略

测试策略这个有点难理解，很多人和测试计划／测试方案弄混了，但其实测试策略与测试计划、测试方案又有区别，有的时候本人也是一知半解，因此在这里对于测试策略的解释只是我个人的理解，如有问题欢迎大家指出。

测试策略指的就是：为了达到预期上线标准，根据项目的功能结构，测试的环境，人力资源，时间等整体情况，采取的最合理一系列测试指导性措施。（tips：这里既然是一系列那么就不是所谓的单一的测试方法，所以说测试方法=测试策略是不准确的）

测试策略的目的：提高测试效率，降低测试风险，在有效的资源里达到上线目标。

测试策略内容：测试资源安排，风险评估，测试方法评估，测试方法，测试技术选择等。

需要注意的是测试会经过几个阶段：单元测试-集成测试-系统测试-验收测试

那么理论上来说对于这几个阶段其实都会有相对应的一些测试策略，但实际上一般的中小厂单元测试是开发兼职，然后集成测试-系统测试这一块中小厂区分并不明显，大厂才会有明确的分工。因此我们这里重点举例说明集成测试、系统测试阶段的测试策略

举例说明：

1、基于风险（优先级）：首先评估项目功能的优先级，如果没有优先级区分，此策略省略。如果有优先级区分，那么优先测试优先级高的功能，或者将优质测试资源(包含：人力／物力)分配到优先级高的测试功能上，甚至如果时间很紧急，那么优先级低的功能先不做，下个版本做。

2、基于项目特点：

1）假如该产品功能结构很清晰，底层接口经常变动或者是短时间不能开发出来，api／客户端实现完成时间早，并且希望尽早的看到产品的功能，那么就可以采取自顶向下集成。底层接口通过mock数据返回，优先测试功能。等到底层接口开发完成之后，在测试接口或者集成后测试。

2）如果底层接口比较稳定或变动较小，但api和客户端功能实现很复杂，短时间不能完成，那么就可以采取自底向上集成的方式。优先测试底层接口逻辑，等后续api／客户端开发完成，在测试功能。

 

通过上面的的描述，大家至少可以大致的理解所谓的测试策略其实就是根据整个项目的情况来进行一些列的测试分析，选择，最终决定如何进行本次测试的一系列决策。

（tip：测试策略对于测试过程具有指导性意义）

 

扩展区分

测试策略与测试计划的区别：一个比较显著的区别就是，测试计划具有时间节点，测试策略就没有。（共性就是：都有计划性，指导性）

测试策略与测试方案的区别：这里也列出一个本人认为比较显著的区别就是，测试方案具有各种解决方案（测试执行方案，风险评估解决方案等），测试策略只有测试执行方案（中间的风险评估只是为了确定功能优先级）。（共性：都有指导性）

 

参考文章链接：究竟什么是软件测试策略

 

测试用例设计方法

这个估计也是大伙儿们听的最多的一个点。网上也有很多，这里只列举出常用的集中测试用例设计方法：

 

等价类划分法

等价类划分，就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，理论上来看每一个子集里面的输入条件都是等效，如果某一个子集里面输入条件不会发生错误，那么该集合中其他的输入条件发生错误的概率也比较小，鉴于此，那我们可以从每个子集选出1个或者若干个有代表性的值作为测试用例。

等价类划分法有两个概念：有效等价类，无效等价类

有效等价类：正常的输入，合法的输入

无效等价类：无效的输入

举例：一个文本输入框，只支持英文，且输入长度在5个字符

那么我们就可以划分5个子集，每个子集任选1个或者多个代表性的即可

1）5个英文字母：sssss（有效等价类）

2）5个非英文字母：11111，！@#¥%，中国第一人 （无效等价类）

3）1-4个英文字母 （无效等价类）

4）6个或6个以上英文字母：sssss（无效等价类）

5）空（无效等价类）

 

边界值分析法

采用该方法设计测试用例的缘由：

因为长期大量的测试工作得出来的一个结论：80%以上的错误都会发生在输入或者输出的边界上，而不是正常的范围之内。因此针对于正常范围之外的各种边界值以及大于小于边界值进行测试用例设计会帮助我们发现大量的测试问题。

例子：一个文本输入框，输入长度在10-15个字符。边界值有2个：10，15个字符（用区间表示[10，15]）

那么边界值分析法设计测试用例，就需要考虑，小于左边界(只小一点点)，刚好等于左边界，大于左边界(只大一点点)，小于右边界(只大一点点)，等于右边界，大于右边界(只大一点点)，除了边界之外，通常也要检查一下出于正常范围之内的值：

1）输入9个字符长度 （小于左边界）

2）输入10个字符长度 （等于左边界）

3）输入11个字符长度 （大于左边界）

4）输入13个字符长度 （正常范围）

5）输入14个字符长度 （小于右边界）

6）输入15个字符长度 （等于右边界）

7）输入16个字符长度 （大于右边界）

 

判定表法

判定表法一般适用于某个需求有多个逻辑判断，会有多个条件，各个条件之间还能够进行组合，得到不同的结果。通过判定表法会穷举所有的情况，测试用例覆盖非常完整。

判定表法中有2个特定的名词：桩（条件桩／动作桩），项（条件项／动作项）

举一个用户裂变例子：

用户在参与某个活动的时候会引流打开app，在打开的时候会根据是否已安装app／登陆情况分别会有不同的处理

且已经安装了app，未登陆，那么就会提示登陆

且已经安装了app，已登陆，安么就会跳转到app中的活动页

如果未安装app，那么就会进入下载页进行下载

 

优点：

1）比较简单，易于操作，只需要列出条件，结果，然后就进行组合。

2）用例覆盖很完善，有效用例很明确

缺点：

1）从上图就可以看出，无效用例／冗余用例太多

2）条件过多的话，判定表会很庞大

 

常见测试问题及解决办法

大家在测试过程中以及面试的时候都会遇到很多问题，不管是实际出现的，还是面试官问的。问题那肯定是多种多样。对于这些问题，可能也是仁者见仁，智者见智，也许每个公司的实际处理方式也都不一样。但是这些问题都会有一些共性，以及一些常见的处理方法。本文列举出几个很常见且实际工作中需要面对的问题，以及相关的解决办法。

（tips：当然了，这里只是抛砖引玉，有更好的解决方案欢迎大家提出，咱们共同学习）

 

如何协调沟通

软件开发测试过程都避免不了沟通，但人与人之间沟通并不是都是和谐的、合乎心意的，因此也会出现各种意外。（俗话说啊，人生不如意者十之八九也适用于此，哈哈～～）。那怎么避免这些问题呢，或者出现问题该怎么去解决呢（至少比较合理的解决），来继续往下看：

 

测试leader与测试工程师之间的沟通

大多数测试leader与测试工程师之间产生交集的地方在与分配测试任务，反馈测试进度，测试过程指导（如果是其他的私下交流那不在此列，哈哈）

那么会出现哪些问题呢：

1、测试人员对于leader分配的工作有异议。

2、leader／测试人员对于需求理解不到位

3、leader对于员工的工作情况不满。

解决／预防办法：

1、测试leader必须要对于本次需求有充分的认识，要不然如何谈合理分配呢？必须要确定好此次需求的功能范围，需求的各个时间节点，然后结合其他的需求来进行优先级排序，定好优先级。（毕竟不可能只有一个需求在做，基本上都是多个需求并行）

2、测试leader要明确组内成员目前手上的工作任务饱和度。

3、根据功能优先级，测试人员的工作饱和度，来进行分配。

4、测试人员在测试之前如果有疑问，或者有难度一定要和leader提出来，不能闭门造车，到最后吃亏的还是自己。（提倡一点：提早暴露）

5、测试人员如果在测试过程中出现了不可力抗因素，那么也必须要及时的反馈给leader，由leader出面协调。

哎呀，这里唠叨一下，顺便说一下测试任务分配基本规则：

1）优先级高的需求（基本上都是要快速上线的），优先分配给空闲测试资源；

2）本次重要功能／核心功能，优先分配优质的测试资源（但不是指的固定人员）；

3）每个大模块中的需求，尽量安排2个测试资源，如果资源充分也可以更多，当然了不一定是同时，有可能是间歇性，也有可能一下子一整个项目那需要的资源就多了；（这里旨在突出“背靠背”扶持原则，假如某个大需求／项目来任务了，熟悉的人都请假了，那就呵呵哒了～～

 

测试和开发之间的沟通

测试和开发之间沟通的最多的时候基本上都是在bug提出与修复阶段。那么可能会出现哪些问题呢？

1、开发对于此bug拒不承认

2、开发怠于修改bug

3、开发改的bug反复出现问题，以至于拖延了测试工期

4、开发的态度非常恶劣

 

解决及预防办法：

1、我们在发现问题的时候，不要不管不顾就给开发提bug（除非此问题毫无争议），如果出现不确定的问题，那么首先和开发确认，如果还不能确认，就去找产品。产品肯定是能够最终确认此问题是否有效的。

2、开发一直不改bug，怎么办？首先，善意提醒，如不接受，可以向测试leader反馈。由测试leader出面和开发的上级沟通，或者和产品沟通

3、如果由于开发的问题，导致了测试延期。这个得要及时和测试leader，或者和产品反馈，说明延期原因，如果产品能够接受，那么就会顺延；如果产品不能接受，就需要测试leader协调资源紧急处理（or 适当加班）。

4、在测试过程中，如果开发的态度非常恶劣，那么如果遇到问题，可以请求测试leader或者产品经理一同前往和开发理论。

 

测试和产品之间的沟通

测试和产品之间的沟通基本上都会贯穿整个测试过程，不管是从需求分析，测试用例编写，测试执行中都会有沟通，那么一般出现哪些问题呢？

1、产品的需求文档写的不明确

2、对于测试提出的疑问产品反馈不及时

3、产品觉得测试问得问题很低级／很烦

解决及预防办法：

1、在需求分析的时候就尽量提出相关的功能疑问，要求PM记录并且后续详细的更新在需求文档上面，并且尽量让PM出一个功能交互原型（这个非常有助于需求理解）。

2、有些胆子小的同学，在需求分析或者编写用例的时候，向PM发出了需求疑问，但是PM一直没有反馈，他就一直等。这是不行的，及时的找到PM，如果不在本地，那么询问联系方式，或者请求测试leader帮助（请求leader帮助，这个优先级低哈，毕竟自己分配的工作尽量独立完成较好，实在是沟通不好那还是可以的，总比一直等待的好）

3、测试在问问题的也是有技巧的：首先得要将需求功能尽量细化，详细阅读需求文档以及交互原型。如果发现1个问题，也不用第一时间就问PM，有可能后续还会有（如果PM时间充分那也是会解答的，但如果PM时间不充分，我们一个接一个的提问题，也不好）。一般情况下都是先记录下来，等到将需求完整的理解一遍之后，在统一汇总反馈给PM。

如何有效保证测试用例覆盖度

这个应该很多同学面试的时候都会被问到，一般都是问得“你们的测试用例覆盖度是多少？，如何保证测试用例的覆盖度呢？”。当然了，这个话题不只是面试会用到，其实我们实际工作中在设计测试用例的时候也需要考虑。只有保证了用例的覆盖度，才能够保证测试的覆盖度。（tips：测试用例覆盖率不可能100%，只能尽量的提高，但是测试用例执行的覆盖率肯定是100%，除非特殊情况）

那么如何保证测试用例的覆盖度？有哪些措施？

1）详细的对于需求文档进行分析，并且将需求功能进行详细的模块划分。（这个就是网上说的功能切片）。这样子操作，第一有助于需求理解，第二有助于用例设计。

2）理解需求的时候除了显性需求，也要理解隐形需求。（这个根据需求文档／自身经验／行业规范／询问PM来获取）

3）采用合理的测试用例设计方法。（一般都是边界值+判定表法+经验法。具体情况具体分析）

4）进行测试用例评审（这个很重要）。测试用例写完之后请求开发+PM+测试相关人员共同进行测试用例评审。因为每个人的思维都不一样，就会有不同的想法。比如：开发可能从单元测试的角度上看待测试用例是否完整；其他测试人员由于经验问题也能够看出用例的疏漏；PM会从用户以及产品大局观来看到用例是否完整。

以上4条都是能够有效的提高测试用例的覆盖率。

 

如何预防／处理线上问题

人有失手，马有失蹄。人无完人嘛，任何事情都不能保证100%不出问题。测试也是如此，不可能保证100%线上零bug（那是不现实滴～～）。那么我们能够做的就是保证尽量不出bug，假如出现bug，我们也要能够迅速响应：快速定位、修复bug，将损失减到最低才是王道。同时呢需要进行总结，保证该类问题下次不再出现在线。

具体方案如下：

1）首先为上线之前，测试质量一定要把好关，测试用例覆盖度，需求理解，开发人员的自身技术都重视起来。

2）核心功能，必须要重点验证。（可以安排优质测试资源进行测试或者上线前回归）

3）上线之前的灰度测试一定要重视，这是发现线上问题的最后一道关卡了。

4）如果线上已经出现问题了，那么需要迅速定位（这里的定位包括定位问题，定位开发责任人，测试责任人），将在短时间内快速修复问题，并且反馈安抚线上用户。

5）对于线上出现的问题进行专门的汇总，上线前可以专门进行检查。

6）总结线上问题出现的原因，吸取教训，保证此类问题不再有下次。

 

如何提高测试效率

这个问题是从始至终都在谈的话题，而且今后也会一直谈论下去，没有最好，只有更好，因为这都是我们所追求的。

那么就目前而言，如何提高测试效率呢？

1）首先从流程上说，一个合理的测试开发流程是能够提高整个软件开发的效率的，通常每个公司的的测试开发流程都是通过大量的项目经验积累，不断的优化形成的。（所以，此项虽然很重要，但是大部分问题不大）。

2）合理的安排测试资源（含：人力／物力／时间）。（比如：安排一个熟悉功能的人，和一个不熟悉功能的人那效率肯定是不一样的）

3）bug的管理以及回归这一块也有提高空间。我们在测试的时候，会提很多bug，开发基本上都是改完1个就指回给我们了（除非是严格正规流程，比如华为内部就是有明确规定测试阶段、修复bug阶段、回归阶段，并且各个阶段都有时间节点，在测试阶段，开发改完bug也不允许指回，只有到了修复bug阶段才允许指回），此时我们可以先不着急这回归（除非是核心功能，导致流程卡死才优先回归），因为如果没测完就回归会，要是开发没改好，后者引起其他问题了，又要将bug打回给开发（这中间就已经浪费了一些时间了，偶尔还会反反复复浪费大量时间），一般都是测试完一轮了，统一进行回归，然后将回归过程中发现的问题再次反馈给开发。这样子一轮接一轮。（这样子开发也一直有事情做，测试也不用浪费一些时间）

4）合理的利用一些测试工具来提高测试。比如一些功能可能需要一些前置业务产生的数据为条件才能够进行，如果手动去走业务完前置流程会耗费一部分时间，那么就可以利用工具编写一个脚本将前置流程脚本化，直接执行脚本就能够产生前置流程数据，我们就可以直接验证功能从而提高效率。

5）利用自动化来提高测试效率。目前自动化大致分为接口自动化、UI自动化。其中接口自动化更好实施，效果更好。UI自动化成本有点高，产出不是很明显，除非是稳定的项目。

 

呼～～好了，到了这里，测试常用理论知识部分基本已经介绍完了，大家可以消化消化。

后续呢，还是会继续更新测试相关的其他内容，内容会涵盖作为软件测试人员需要掌握的大部分常用的技术以及相关知识，欢迎大家讨论。