软件测试基础

 

软件的组成

 

软件是由数据、程序、文档组成

 

测试的生命周期

测试计划---

测试方案设计---

测试开发---测试用例的编写与执行  

测试执行---

测试评估---对测试结果的分析和报告

 

什么是软件测试？

 

一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
更直接的意思就是：我要一个能吃饭的碗，而你不能给我一个盆子，也不能给我一个杯子，更不能给个有缺口的碗。而这一切就只是为了满足客户的要求。

 

软件测试的分类

 

1)按测试阶段分：单元测试——集成测试——系统测试——验收测试

2)按测试方法分：白盒测试——灰盒测试——黑盒测试

3)按被测对象是否运行的角度分：动态测试、静态测试

4)其他测试分类：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试、压力测试、负载测试、恢复测试、冒烟测试、回归测试、探索性测试

软件测试的目的

 

1）验证软件是否满足软件开发合同或者项目开发计划，系统/子系统设计文档，软件需求规格说明，软件产品说明等规定的软件质量要求

2）通过测试，发现软件缺陷 

3）为软件产品的质量测量和评价提供依据

 

软件测试的标准4个过程，以及对应的解释 

 

1）测试策划：主要是进行测试的需求分析和测试计划的编写

2）测试设计：依据测试需求，分析并选用，已由的测试用例或者设计新的测试用例，在进入下一个阶段工作之前，应该通过，测试就绪评审

3）测试执行，执行测试用例，获取测试结果分析并判定设计结果 

4）测试总结：整理和分析测试数据，评价测试效果和被测软件项，描述测试状态最后完成软件测试报告并通过测试评审

 

 

测试用例的编写流程

 

需求分析

 

①需求就是客户需要的东西和客户对其的要求。如果这款产品的用户就是直接面向大众的，那么就需要自己去分析大众用户需要的是什么，怎样的功能才能让用户喜欢用。

  

②一般需求分为

业务需求---百度上的概念

表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。

行业都有自己的领域系统（行业所处的大环境，包括行业的习惯、北京等），而根据行业的领域系统及领导、客户等的方向及目标。

 

用户需求---百度上的概念

描述的是用户的目标，或用户要求系统必须能完成的任务。

这个范围很广，比如软件的界面是否好看、功能使用是否便捷等都属于用户需求。用户需求可以认为是对业务需求的一个具体目标。比如业务需求提出了这个系统具有语音功能，那么用户需求就可能包含了语音具备的功能，比如可以喊“刘德华的电影”去搜索电影等。

功能需求---百度上的概念

   规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求。

   功能需求是去解决业务需求、用户需求的具体解决方案，也是我们通常说的需求说明书。对用户需求做具体的分析、提出实施方法（需求说明书通常是由软件开发方编写如产品经理，使得用户和软件开发方都对软件的初始的规定有一个共同的理解，是整个开发的基础）。同时，开发方需要对需求说明书进行评估，比如这个需求能不能做，耗费的成本是不是小于带来的收益，还有风险评估等。

 

如果没有需求怎么办？直接给你一个软件直接测试怎么搞？

   我们可以参考市面上同类型的产品。

 

如果需求模糊怎么办？

   产品经理提出来的需求往往只有几句话概况，这时候我们可以整理好已有的需求，把不明白的地方提出来，和相关的负责人确认，又或者参考同类型的产品实现的情况。也可以拿到产品后，进行探索性测试，去探索相关的功能需求，边测试边学习，验证看是否满足了业务，实在不明白再进行确认，但这样会有风险，如果你和开发理解的一样，但恰巧你们都理解错了，那么可能做出来的东西就不是产品经理需要的东西了。

 

提取测试点

①测试点事通过需求分析后对得出的需要测试的具体内容  

②将测试点总结完毕，就可以根据测试点快速的写测试用例，并可以很好的覆盖需求。

 

编写测试用例

 

测试用例设计的基本原则

 

1）基于测试需求的原则

2）基于测试方法的原则

3）兼顾测试充分性和效率的原则

4）执行用例的可再现性原则

 

测试用例的作用

 

1)检验软件是否满足客户的需求

2)体现一个测试人员的工作量

3)展现测试的设计思路，可以通过阅读别人的测试用例学习测试用例的设计方法和思路。

 

测试用例一般包含

 

编号---编号并不是简单的1234，而是可以通过下划线将一些测试用例的信息包含进去，比如：TV-YUYIN-0001，代表着这条测试用例是测试电视语音相关的。

 

用例名称---用例的名字，这个可以不写。

 

测试背景---说明该测试用例的背景，是测试什么项目，什么内容的。也可以不写，有时候测试背景通过测试编号、测试文件的名字、标题等就可以表达出来。

前置条件---测试之前应该满足于什么条件才可以进行测试，一般要写，如果没有前置条件写无就可以。

优先级、重要级---看似差不多，其实关系不大，优先级高并不意味重要级高。

测试数据---输入的数据。

测试步骤---是必须的，可以根据实际情况写测试步骤，可以写的粗糙，也可以写的很详细，比如第一步是什么，第二步是什么等。

预期结果---对应着测试步骤，如果测试步骤写的详细，那么预期结果也要写的详细，比如测试步骤有5步，预期结果有2个，别人怎么知道这个结果是哪一步产生的？最好在编号上实现预期记过和操作步骤的统一。

实际结果---在测试过程中的实际情况，如果一样就写通过、ok等就可以了，如果不一样，需要写明实际结果是什么。有的时候，我们可以再实际结果中写ok、false，然后将实际结果写在备注里

备注

但可以根据实际需要增加、删除、修改部分项，比如：增加分类、子分类等。

 

 

测试用例的评审

①评审就是对测试用例进行检查，包括

同行评审---测试和测试之间的评审

小组评审---组织一个测试小组进行评审

部分评审---整个部门进行评审

三方评审---开发、测试、产品或者用户都会参与进行评审

②评审不是一次性的，每次评审完进行测试用例的修改，再评审修改，直到测试用例通过。

 

测试用例的管理

①原始方式是通过excel表格进行管理，虽然原始但是方便。只不过对于需求进行变更的项目来说，改起来比较痛苦。

②也可以采用一些项目管理工具，比如禅道，对测试用例及bug系统进行统一管理，比较方便。