测试回顾版-零基础学习软件测试

 

 参考教材：

 

http://www.boobooke.com/bbs/viewthread.php?tid=7638&extra=page%3D1

 

一共8个

  

总体评价：入门级----顺便完整回顾下软件测试的基础知识

 

第一讲 软件测试基础知识

软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程.

 

软件测试不等于程序测试.软件测试贯穿于软件定义和开发的整个期间.需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象.

 

黑盒测试 基于软件需求，而不是基于软件内部设计和程序实现的测试方式。
白盒测试 基于软件内部设计和程序实现的测试方式。
单元测试 主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行
集成测试 将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机－服务器程序等等。
功能测试 测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。一般由独立测试人员执行。
系统测试 测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。一般由独立测试人员执行，通常采用黑盒测试方式。
回归测试 指错误被修正后或软件功能、环境发生变化后进行的重新测试。回归测试的困难在于不好确定哪些内容应当被重新测试。
验收测试 由客户或最终用户执行，测试软件系统是否符合需求规格说明书。

负载测试 测试软件系统的最大负载，超出此负载软件可能会失常。（找出系统处理能力的极限）
压力测试 概念上与负载测试相似，叫法不同。（检查系统处于压力情况下，应用的表现，测试系统稳定性）
性能测试 测试软件在各种状况下的性能，如在正常或最大负载下的状况。(验证系统是否有系统宣传的能力)
易用性测试 测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。
安装与反安装测试 测试软件在“全部、部分、升级”等状况下的安装/反安装过程。
安全性测试 测试该系统防止非法侵入的能力。
兼容性测试 测试该系统与其它软件硬件兼容的能力。
Alpha 测试 一种先期的用户测试，此时系统刚刚开发完成。
Beta测试 一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。

 

V模型-W模型-H模型-X模型？？？？

 

 

测试能提高软件的质量，但是提高质量不能依赖测试。
测试只能证明缺陷存在，不能证明缺陷不存在。
每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错
测试应当循序渐进，不要企图一次性干完

 

推荐书：软件测试艺术

第二讲 测试用例设计（这讲很差）

把被测程序当成白盒子，要了解程序内部的结构，来进行用例设计。
主要对程序模块进行如下检查：
对程序模块的所有独立的执行路径至少测试一次；
对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；
在循环的边界和运行界限内执行循环体；
测试内部数据结构的有效性，等。

把被测程序当成黑盒子，不需要了解内部的详细结构，来进行用例设计。
黑盒测试我们常用边界值，等价类，判定表，因果图，错误推测，场景法等等

 

 先用黑盒测试方法来设计用例，然后再看情况使用白盒测试来设计补充的测试用例

 

 

1：逻辑覆盖测试（白盒测试方法）

白盒测试关注的是测试用例执行的程度或者覆盖程序逻辑结构（源代码）的程度。

 

 

public void foo(int a,int b,int x)

{

    if(a >1&& b==0)

   {x = x/a;

   }

   if(a==2||x>1)

   {x=x+1;

   }

}

判断/条件覆盖

多重条件覆盖

 

2：等价划分（黑盒测试方法）

确定等价类

生成测试用例

 

3：边界值分析

 

4：因果图（好难。。）

边界值分析和等价划分的一个弱点就是未对输入条件的组合就行分析

因果图实际上是一个数字逻辑电路

 

生成测试用例

将规格说明分解为可执行片段（因果图不善于处理较大的规格说明）

确定规格说明中的因果关系。因-指一个明确的输入条件或者输入条件的等价类，果，是指一个输出条件或者系统修改（输入对程序或者系统状态的延续影响）。如某个事务引起文件或者数据库记录被修改，系统反馈就确认信息就是一个输出条件

分析规格说明的语义内容，并且将其转换为连接因果关系的布尔图，所谓的因果图

给图上面加上注释符号，说明由于语法或者环境的限制而不能联系起来的因和果

通过仔细的跟踪图中的状态变化情况，将图转换成一个有限项的判定表，表中每一列代表一个测试用例

 

 

错误猜测

 

 

 

第三讲 测试用例设计误区

 

误区一测试输入数据设计方法等同于测试用例设计方法（什么等价法都是数据设计方法）

误区二强调测试用例设计设计的越详细越好

误区三追求测试用例设计一步到位

 

软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。

第四讲 bug知识

提高Bug report的技巧

1.组织structure：小心谨慎并且详细的记录。
2.重现reproduce：必须检查问题是否可重现。如果错误不重现要写明是偶然发生的。一个好的处理原则是在编写bug report前反复尝试3次。
3.隔离isolate：隔离错误。
4.归纳generalize：对常见的错误或问题进行归纳总结和思考。
5.对比compare：
6.总结summarize：在bug report的第一行写上错误的总结是非常关键的。
7.精简condense：bug report写完后要进行修改，做到精简和准确。
8.消除歧义disambiguate：不要有二义性。
9.中立neutralize：不要攻击开发人员。
10.检查review：

第五讲 软件质量基础知识

QA：质量保证
贯穿于整个软件周期中，预防错误的成因，在开发过程的早期检测出来并改之

QC：质量控制
属于QA的一部分，主要是软件测试人员，关注于最后的产品的质量活动

第六讲 软件质量管理杂谈

 

CMM：
质量模型
评估
给你改进建议
ISO：
质量标准
审查
结果有通过和不通过

 

个人观点：
先基于ISO建立一套质量管理体系，提高组织的质量意识。在此基础上选择若干KAP进行改进，逐步达到CMM。

SQA 与TESTER的区别：
SQA重点是对软件开发过程进行监督、管理、控制
TESTER重点是对开发出的产品进行检查

个人过程改进
随时更新test plan和use case
在报告一个bug前，一定要重现一次，再次的确认
要报告RA Spec里的bug。我们测试不仅要关注于软件产品对相关的文档也是关心的

目标 成本 质量
充分考虑三者的关系，有效的保持平衡
目标一定，成本一定，只提供定额的服务质量
为了保证软件测试的质量，在有限的资源成本下，就必须控制目标。
目标一定的情况下，为了达到有效的测试质量，就必须投入更多的测试成本。

 

第一级：初始级——软件过程的特征是无序的，有时甚至是混乱的。几乎没有过程定义，成功完全取决于个人的能力。

第二级：可重复级——建立了基本的项目管理过程，能够追踪费用、进度和功能。有适当的必要的过程规范，使得可以重现以前类似项目的成功。

第三级：定义级——用于管理和工程活动的软件过程已经文档化、标准化，并与整个组织的软件过程相集成。所有项目都使用文档化的、组织认可的过程来开发和维护软件。

第四级：管理级——软件过程和产品质量的详细度量数据被收集，通过这些度量数据，软件过程和产品能够被定量地理解和控制。

第五级：优化级——通过定量的反馈，进行不断的过程改进，这些反馈来自于过程或通过测试新的想法和技术而得到

第七讲 how to build framework

第八讲 初识RUP