软件测试

对于经典瀑布模型，软件的生命周期为可行性分析->需求分析与说明->软件设计->编码与单元测试->集成与系统测试->软件维护。

那这次就来说说测试吧！

先是对单个模块进行单元测试，然后是部分系统测试(包括集成测试和有效性测试)，最后是系统测试。

why分成3步测试？模块不可能在很短时期内都准备好；便于及时发现错误，纠错有针对性。

(1)单元测试的2中方法

1)白盒测试：根据设计或代码的知识

  语句覆盖：程序的每个语句至少执行一次。

  判定覆盖(分支~)：每个判断(分支)都轮流使用T/F。

  条件覆盖：每个判断的每个条件都轮流使用T/F。

  判定-条件覆盖：

  条件组合：所有可能条件的取值。

  路径测试：覆盖程序中所有可能的路径(最强覆盖)。

*可参考：http://blog.csdn.net/hellofeiya/article/details/21829059

2)黑盒测试：根据输入/输出值得检验

  等价类划分：有效等价类(valid)，无效等价类(invalid)。

  边界值分析：输入/输出的边界值。

  错误推测法：列出可能犯错的情况，赋数据。*可参考：http://blog.csdn.net/hellofeiya/article/details/21826097

  因果法：输入条件的组合(针对程序接口，而不是内部)，会生成判定表。*可参考：http://luyongxin88.blog.163.com/blog/static/925580720108252526831/

  之前在编程实习中有写不少小的功能模块，为了查看功能是否实现，也做了许多尝试，但大多都是随意给的测试数据。与上面的两种测试相比，我发现之前用的都是黑盒测试，这种测试并没有体现出我作为编码者对程序很熟悉的优势，并且考虑测试数据也不全面，大多都是有效数据，人为忽略了其他数据。看了白盒测试，觉得还是很有道理的，有时感觉一些好的想法被提出后都觉得是理所当然，但是我们就是提不出来。

(2)部分系统测试包括集成测试和确认测试(有效性测试)。

(3)系统测试的3种类型：

1)Alpha-testing:在开发环境下的单个用户会公司用户在模拟条件下的测试。

2)Beta-testing:当1)达到一定程度时，软件的多个用户在实际使用中进行的测试，开发者不在现场因而无法控制。

3)接收测试：由用户执行的系统测试，决定是否接收系统。

eg：单元测试

语句覆盖：{(50,50),(20,10),(10,20)};

分支覆盖：{(10,10),(10,20),(30,40),(40,30)};

条件覆盖：{(10,10),(10,20),(50,30),(80,20),(80,90),(40,70)}.

等价类划分：{x,y|x,y属于{20,70,-50,200,12.5};

边界值分析：{x,y|x,y属于{0,-1,100,101}};

错误推测法：{x,y|x,y属于{空格,负数}};

因果法：

要求：输入的2个变量必须是属于[0,100]的整数，结果输出为Right；如果只有1个变量是属于[0,100]的整数，就输出one Wrong；否则输出all Wrong。

1)根据题意，原因和结果如下：

原因：

1—x是属于[0,100]的整数；

2—y是属于[0,100]的整数。

结果：

21—one Wrong;

22—all Wrong;

23—Right。

2)其对应的因果图如下：

 

11为中间节点；在因果图(a)中，考虑到原因1和原因2不同时为1，因此在因果图上施加E约束(即原因1和原因2最多有一个为1)。

3)根据因果图建立判定表：

表的最下面一栏给出了4种情况的测试用例，这是我们所需要的数据。

 

注：因果图是否正确性值得进一步考证，我只是用它把我的想法表达出来。欢迎大家提意见!!

 

转载于:https://www.cnblogs.com/QFighting/p/5452702.html