走进·测试

作者：CRDE

软件测试发展历史

1957年之前－调试为主(Debugging Oriented)

1957–1978－证明为主(Demonstration Oriented)

1979–1982－破坏为主(Destruction Oriented)

1983–1987－评估为主(Evaluation Oriented)

1988–至今－预防为主(Prevention Oriented)

调试为主

20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本

身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，

测试等所有工作，当然也不会有人去区分调试和测试。然而严谨的科学家们已经在开

始思考 “怎么知道程序满足了需求？”这类问题了。

证明为主

1957年，Charles Baker在他的一本书中对调试和测试进行了区分：

•调试(Debug)：确保程序做了程序员想它做的事情

•测试(Testing)：确保程序解决了它该解决的问题

这是软件测试史上一个重要的里程碑，它标志测试终于自立门户师出有名了。当时计算机应用的数量，成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”。

破坏为主

1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：

The process of executing a program with the intent of finding errors.
测试是为发现错误而执行程序的过程。

这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

评估为主

1983年，美国国家标准局(National Bureau of Standards)发布“Guideline for Lifecycle Validation, Verification and Testing of Computer Software”，也就是我们常说的VV&T。VV&T提出了测试界很有名的两个名词：验证(Verification)和确认(Validation)

Verification: Are we building the product right?

Validation: Are we building the right product?

人们提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。软件测试工程在这个时期得到z了快速的发展：

出现测试经理(test manager)，测试分析师(test analyst)等职称

开展正式的国际性测试会议和活动

发表大量测试刊物

发布相关国际标准

以上种种都预示着：软件测试正作为一门独立的，专业的，具有影响力的工程学发展起来了。

预防为主

预防为主是当下软件测试的主流思想之一。STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型，STEP认为测试与开发是并行的，整个测试的生命周期也是由计划，分析，设计，开发，执行和维护组成，也就是说，测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。我们都知道，没有100%完美的软件，零缺陷是不可能的，所以我们要做的是：尽量早的介入，尽量早的发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越

2008北京奥运会门票系统失效案例

10月30日，北京奥运会门票面向境内公众第二阶段预售正式启动。上午9：00点一开始，不到半小时，网站系统便宣告瘫痪。访问者看到官方票务网站当天上午开始都只是显示“系统繁忙,请稍后再访问.不便之处敬请原谅。”的提示信息。当天官方网站发布了如下的致歉消息，上午9时至10时，官方票务网站的浏览量达到了800万次，每秒钟从网上提交的门票申请超过20万张，票务呼叫中心热线从9时至10时的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请，为此北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意。

失效原因 

1.对意外的输入或条件估计不足 

不少网民在无法正常登录后便不断刷新。不停地刷新网页，也是造成网络拥堵的原因之一。这就相当于一名申购者变成了若干名申购者了，无形中增大到了网站流量。从技术角度讲，网站的流量几乎成几何倍增长，导致其他申购者无法登录。 

2.需求估计严重不足 

根据官方网站公布的数据，技术人员对网站性能进行了粗略地计算： 官方票务网站浏览量平均为：2200次/秒以上。从网上提交的门票申请：200000张/秒以上。打开网站页面加载的字节数为：170.216KB。就是说这个站点每秒钟处理浏览产生的流量就大概是366M。而从打开首页，一直到确认订票如果不重复操作的话，应该是10步。在这之前产生的流量要更大。我们可以这样来理解，一秒钟有2200个用户打开首页。这个是并发的用户数。按比较密集的概率来计划，大概有15000－22000个用户在不同的位置打开这一链接。这一比例应该比较高了。用22000个/秒用户来计算，如果用性能测试工具来做性能测试，按每台机器1G内存来计算，其他配置均不会成为瓶颈，如果一个虚拟用户用600K内存，每台机器拿400M内在来运行用户，也需要近40台机器来实现压力。假设每台机器跑600用户，这是在性能测试中，算比较高的使用率了。每个虚拟用户占用的内存数 需要的机器数600K 37台， 1024K 55台 每秒钟从网上提交的门票申请超过20万张，这些数据显然没有成功处理完。因为前面说截至上午11时，各个销售渠道共售出门票约9000张。这个网站采用的策略是：先到先得。也就是大家一块抢，申请肯定会很多。但是，售出的只有9000张。可见很多数据还没能处理就瘫痪了。

拼多多的充值漏洞案例

100元无门槛优惠券全场通用，用户可以直接通过优惠券进行购买东西抵扣。根据网友曝光，这次拼多多薅羊毛最直接的方式就是直接购买虚拟产品，仅仅需要四毛钱就可以充值100元的话费或者QQ币。有科技媒体报道，这次安全漏洞拼多多预计损失超过200亿元。

软件测试的定义

-保证程序和相应的规范说明一致

-发现软件中的缺陷

-确保软件不做不必要的事情

-确保系统合理地执行

-确保系统失败前可以让系统运行到何种程度

-确保发布给用户的系统中有哪些风险

-ISO9000定义：测试是一种基于机器的，对代码执行测试，确认测试的活动。

软件测试目的与原则

软件测试作用：

-通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。

-测试可以记录软件运行过程中产生的一些数据，从而为决策提成数据支持。

-测试可以降低同类型产品开发遇到问题的风险。

软件测试原则：

-所有的测试都应用追溯到用户的需求

-应当尽早、不断的测试

-测试发现的错误很可能起源于20%的模型中

-设计测试用例时，应该考虑各种情况

-对测试出的错误结果一定要有一个确认的过程（描述缺陷报告）

-制定严格的测试计划

-完全测试是不能的，测试需要终止

-妥善保管一切测试资料

设计测试用例的优缺点

优点：

1、把产品需求转换为一种可操作的步骤，方便以后有步骤有计划的进行测试。

2、验证产品的需求是否合理

3、监督产品对需求做出更加详细的设计

4、记录产品的设计细节，保障以后的查阅

5、加深测试人员对产品的认识和印象

6、反应测试进度

7、帮助发现拓展测试范围，扩大测试覆盖面，发现软件中潜藏的缺陷

8、方便回归测试，复查bug是否还会出现

9、为紧急情况下的测试提供参考信息

10、培训新人，提高新人测试效率，节省对新人的指导时间

缺点：

1、增加了测试的维护成本

2、消耗了时间成本

测试分类

按阶段划分：

单元测试：先静态观察代码是否符合规范，然后动态运行以下代码，检查运行结果

集成测试：通过测试单元模块组装成系统或者子系统，在进行测试，重点测试不同模块的接口部分

系统测试：整个系统集成完毕后进行测试，前期主要测试系统功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等。

验收测试：也称交付测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，有用户、客户或其他授权机构是否接受系统

按是否运行程序划分：

静态测试：不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误

动态测试：实际运行被测试程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程

按是否查看源代码划分：

白盒测试：自动化测试一般使用脚本来进行测试，叫做白盒测试

黑盒测试：

功能测试（web、app）：逻辑功能测试、界面测试、易用性测试、安全测试-权限、兼容性测试、页面性测试、安装卸载测试、软件升级测试、消息推动测试、前后台切换测试、UI测试、网络环境测试、mokey测试

性能测试：

时间性能测试：软件的一个具体事务的响应时间

空间性能测试：软件运行时所消耗的系统资源，比如对内存、CPU消耗

一般性能测试：软件正常运行，不向其施加任何压力的测试

稳定性测试：也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度

负载测试：让被测系统在其能够承受的压力范围之内连续运行，来测试系统的稳定性

压力测试：持续不断地给被测系统增加压力，直到被测系统压垮为止，用来测试系统所承受的最大压力

其他：

回归测试：只是对软件的新版本进行测试时，重复执行上一个版本测试时的用例

冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性

随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误

常用测试用例设计方法

等价类划分法：

有效等价类：1-100整数

无效等价类：

* 所有小数1-100<1>100；

* <1>100整数；

* 字母，汉字，特殊字符，空格

边界值法：

边界  次边界：如（1-100）：0  1  2  ；99  100  101

错误推测法：

正向用例---通过性；

反向用例---异常---容错性处理

正交表法：

正交表能够在因素变化范围内均衡抽样，实现通过少数实验次数到达均衡的测试效果

因果图/判定法：

因（原因）：输入条件

果（结果）：输出结果

因果图：就是通过画图的方式表示输入条件（因）和输出结果（果）之间的关系

因果图就是把复杂的逻辑 关系转化成判定表的系统化方式，其中原因表示输入条件，结果时对输入执行的一系列计算后得到的输出。因果图法最终生成的就是判定表，它适合于检查软件输入

条件的各种组合情况。

     

场景法：

场景业务通常分为基本流、备选流、异常流程

基本流：基本流表示通过业务流程时输入都正确，能达到目标的流程（如：ATM【插卡--输入正确密码--输入金额--取款--取卡】）

备选流：备选流表示通过业务流程是输入错误（或者操作错误）导致流程存在反复，经过纠正后仍能达到目标的流程（插卡--输入错误密码--输入正确密码--输入金额--取款--取卡）

异常流：异常流表示通过业务流程时输入错误（或者操作错误）产生异常终止流程（插卡---输入3次错误密码---吞卡）

        

测试V模型

测试V模型优缺点

优点：

包含了底层测试（单元测试）和高层测试（系统测试）；清楚地表示了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

缺点：

自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；实际工作中，需求经常变化，导致V模型步骤，反复执行，返工量很大，灵活度较低。

内测版（alpha）内部交流版本，可能存在很多bug，不建议用户安装

公测版（beta）面向所有用户，通过用户的反馈再去修改细节

测试W模型

W模型优缺点

优点：

开发伴随着整个开发周期，需求和设计同样要测试；更早的介入测试，可以发现初期的缺陷，修复成本低，分阶段工作，方便项目整体管理。

缺点：

开发和测试依然是线性的关系，需求的变更和调整，依然不方便；如果没有文档，根本无法执行W模型；对于项目组成员的技术要求更高。

定义：开发一个V；测试一个V组合起来的模型（W模型也叫双V模型）

总结：V模型适用于中小企业，W模型适用于中大型企业（因为人员要求高），h模型人员要求非常高，很少有公司使用。

接口测试

什么是接口测试：

所谓的接口测试就是通过测试不同情况下的入参与之相应的出参信息来判断接口是否符合或满足相应的功能性、安全性

为什么要做接口测试：

-通过接口测试可以知道是否进行了前后台数据校验

-做功能或者界面测试的时候，不知道页面上数据展示是否正确（可以发现页面操作发现不了的bug）可以借助于接口测试

-检查系统的安全性（请求及响应的关键敏感数据是否进行了加密）、稳定性（通过接口可以测试服务器性能）

如何做接口测试：

分析接口文档------编写接口测试用例------放到工具（postman、jmeter等）中执行测试