一、软件测试概述

　　软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。

　　软件质量是由几个方面来衡量的：一、在正确的时间用正确的的方法把一个工作做正确（Doing the right things right at the right time.）。二、符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、质量也代表着它符合客户的需要（Quality also means “meet customer needs”.）。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。

　　测试人员在软件开发过程中的任务：

1、寻找Bug；

2、避免软件开发过程中的缺陷；

3、衡量软件的品质；

4、关注用户的需求。

　　总的目标是：确保软件的质量。

二、常用的软件测试方法

（一）、 黑盒测试

　　黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档，看是否能满足需求文档中的所有要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。

　　黑盒测试的优点有：

1）比较简单，不需要了解程序内部的代码及实现；

2）与软件的内部实现无关；

3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

5）在做软件自动化测试时较为方便。

　　黑盒测试的缺点有：

1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；

2）自动化测试的复用性较低。

（二）. 白盒测试

　　白盒测试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。它需要知道程序内部的设计结构及具体的代码实现，并以此为基础来设计测试用例。如下例程序代码：

HRESULT Play( char* pszFileName )

{

if ( NULL == pszFileName )

return;

if ( STATE_OPENED == currentState )

{

PlayTheFile();

}

return;

}

　　读了代码之后可以知道，先要检查一个字符串是否为空，然后再根据播放器当前的状态来执行相应的动作。可以这样设计一些测试用例：比如字符串（文件）为空的话会出现什么情况；如果此时播放器的状态是文件刚打开，会是什么情况；如果文件已经在播放，再调用这个函数会是什么情况。也就是说，根据播放器内部状态的不同，可以设计很多不同的测试用例。这些是在纯粹做黑盒测试时不一定能做到的事情。
　　白盒测试的直接好处就是知道所设计的测试用例在代码级上哪些地方被忽略掉，它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

　　白盒测试的缺点有：

1）程序运行会有很多不同的路径，不可能测试所有的运行路径；

2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；

3）系统庞大时，测试开销会非常大。

（三）、模型测试

基于模型的测试是一个轻量级的，形式化的验证软件系统的方法。为什么这么说呢，

1、因为首先，基于模型的测试对待测软件系统（通常被称为System Under Test，简称SUT）进行形式化的建模，设计出机器可读的模型；

2、其次，和其他形式化方法比，基于模型的测试并不致力于让待测软件系统与规格说明在所有可能情况下都保持一致，而是系统化的从模型生成一组测试用例，使用这组测试用例测试待测软件系统，得到充分的证据说明待测系统的行为与模型期望是一致的。

轻量级和重量级的方法的根本区别在于一个是充分证明，一个是完全证明。目前完全验证一致性的代价非常高，重量级的形式化方法往往难以被应用到实际工程中，而基于模型的测试在这方面体现了优势，并已被运用到很多大型项目中。

　　下面是一个基于模型测试的简单图解：

　　基于模型的测试从一组需求开始，这组需求可以是文字，草图或者仅仅是团队成员的一些想法。

　　首先，我们需要创建一个机器可读的模型（#1），该模型表述了需求所表述的所有可能行为。这一步是由人工完成，并且是整个流程中工作量最大的一步。模型设计工作的关键点在于正确的抽象，一个建模者应该专注于系统的待测试的某一方面，而不需要关心系统的其余部分。不同部分可以被不同模型覆盖，但是每一个模型都确保自己在清晰的抽象层面上。

　　我们具体到Spec Explorer为例，模型被表述为一组规则，这些规则可以使用主流程序开发语言C#开发，不需要再学习其他特定的形式化建模语言，降低了学习难度。同时，Spec Explorer是一个Visual Studio集成开发环境的插件，所以提供了诸如语法颜色标记，自动补全和代码重构等功能。 Spec Explorer还提供了一种小型的配置语言Cord（Coordination Language的简称）用于结合不同模型，生成代码以及选择特定的测试场景。

　　虽然创建模型的工作量很大，但是回报也是巨大的。通过把非形式化的需求转化为形式化的模型，你将很容易发现需求中遗漏的部分（譬如：如果我连按两次ESC键，系统到底应该怎么样？）。上图中的#2表明仅仅通过分析模型，就可以得到关于需求的反馈。

　　当模型成型以后，就到了Spec Explorer这种工具发挥作用的时候了。它能够通过分析模型自动生成测试用例（#3），包括提供给待测试系统的输入以及期望的输出，我们称之为测试预期。自动生成的测试用例一旦生成，就可以在一个标准的单元测试框架中（例如Visual Studio的测试框架或者NUnit）独立于模型运行。这些测试用例提供了测试序列（#4）去控制待测试系统，同时观察（#5）待测试系统的返回值，并与生成预期值进行比较，然后做出判定（#6）测试是通过还是失败。测试用例可以被反复执行以重现bug，最后找到问题所在。

　　对测试结果的判定是对待测试系统的一个重要反馈（#7），但是找到待测试系统的bug并不是我们的唯一目标。一个失败的测试用例也有可能表明待测试系统的行为是正确的，但是模型的预期行为是错的！或者更进一步，模型本身是正确的反映了需求，但是需求本身从一开始就错了！如果真的如此，你也不用特别悲观，基于模型的测试与传统人工测试相比的最大优势就在于维护方便，你需要的仅仅是让失败的结果作为有效的反馈给模型或者需求（#8），修改模型使其能反映系统的预期行为，然后重新生成测试用例。

（四）、风险测试

https://www.cnblogs.com/mikeyond/p/9347333.html

1、基于风险的测试定义

基于风险的测试定义：根据软件产品的风险度通过出错的严重程度和出现的概率来计算，测试可以根据不同的风险度来决定测试的优先级和测试的覆盖率。

2、基于风险的测试分析流程

1 列出软件的所有功能和特性 
2 确定每个功能出错的可能性 
3 如果某个功能出错或欠缺某个特征，对顾客的影响有多大 
4 计算风险度 
5 根据可能出错的迹象，来修改风险度 
6 决定测试的范围，编写测试方案