对于经典瀑布模型，软件的生命周期为可行性分析->需求分析与说明->软件设计->编码与单元测试->集成与系统测试->软件维护。
那这次就来说说测试吧！
先是对单个模块进行单元测试，然后是部分系统测试(包括集成测试和有效性测试)，最后是系统测试。
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种情况的测试用例，这是我们所需要的数据。
注：因果图是否正确性值得进一步考证，我只是用它把我的想法表达出来。欢迎大家提意见!!
