软件构造课程心得——测试与测试优先的编程

软件构造课程心得——测试与测试优先的编程

初学编程，我们往往会根据给出的要求，直接向目标发起“冲击”，但这样直接的编程很有可能会导致各种各样的问题——bug频出但找不到问题所在，找到bug并修改后却又引发了更多的bug……程序猿们很有可能在找bug-改bug的循环中苦苦挣扎，正所谓代码五分钟，bug两小时。那如何才能改变这一状况呢，测试优先的编程应运而生。

测试优先的编程的中心思想就是：将在写程序时通过合适的测试，确保程序的每个组成部分的bug数量降到尽可能低，减少程序整体的bug数量，从而减少程序编写完成后返工的难度和工作量，提高工作效率。

下面我们就来了解一下测试与测试优先的编程。

一、静态测试与动态测试：

静态测试是静态地分析代码的语法的正确性，而不实际地运行程序；动态测试是给定测试用例，让程序按照给定的输入进行运行，将得到的运行结果与期望的运行结果进行比较，得出是否通过测试，从而判断编写的代码是否满足编程者和用户的需求。

注：测试与调试不同，测试是通过运行程序来判断程序是否有错误，而调试则是发现程序的错误后通过运行程序来寻找错误到底出现在什么地方。通常来说，调试是测试后的步骤。

二、黑盒测试与白盒测试

黑盒测试，顾名思义，在这种测试中，程序是对于测试者来说处于一个黑盒状态，测试者只知道从输入到输出的结果，而不知道程序对输入的处理过程，因此黑盒测试是对程序外部表现出来的行为的测试。测试者可以通过程序的规约，在程序编写前就完成黑盒测试的编写，从而可以为程序猿在编写代码时起到指导作用。

白盒测试，与黑盒测试相反，是对程序内部代码结构的测试，是已经编写出程序后，对程序内部实现细节的测试，在程序编写前是无法进行编写的。

三、代码测试的难度

代码测试难吗？难也不难。写测试代码的过程远没有编写程序本身困难，但难在如何使构建出的测试用例用最少的代码覆盖更多的情况，检查出更多的错误。我们知道，程序的bug往往出在最不引人注意的地方，bug的出现往往不符合特定概率的分布，边界点往往使bug发生的“重灾区”。因此选取合适的测试用例非常关键，也是测试的难点所在。什么样的测试用例才可以称之为合适呢？应当满足下面几个标准：①最可能发现错误；②不重不漏；③测试效率高；④简单易懂但要测试全面。

四、测试优先的编程

1、测试优先的编程的过程：

①为函数或者方法写规约，明确要写的内容的行为特征，对什么样的输入应该有什么样的输出。

②编写符合规约的测试用例，确保全面。

③编写程序，执行测试，发现问题后改写程序，在进行上述过程，直到通过用例。

通过了设计良好的测试用例的程序，我们几乎可以保证，它是合格的了！

2、单元测试：针对软件的最小单元模型开展测试，隔离各个模块，从而容易定位错误进行调试。

五、选取测试用例

上文提到过，设计测试用例是测试的难点所在，那么应该如何对测试用例进行设计呢？

我们可以将一个程序看作一个从输入到输出的映射，那么我们可以将输入域划分为不同的等价类，其中程序对同一个等价类中的输入的行为是相同的，因此只要将输入域划分为不同的等价类，在每一个等价类中选取一个“代表”进行测试，就可以不重复地对程序的不同行为进行测试，减少测试量。同时由于输入域的边界是“事故高发区”，值得我们的格外照顾，应当对其进行分析。

当有多个维度的输入时，应当对不同的可能进行组合，每个组合至少要进行一次测试，从而覆盖到每一种可能的情况。

以上是黑盒测试的测试思路，其主要考虑的是覆盖不同的输入可能，而白盒测试主要的要求测试代码尽可能地覆盖程序所有的代码。

以上是我对测试这一技术的理解，以后会写一篇文章专门介绍一下Junit的基本用法。