"测试用例设计与jUnit单元测试" 实验心得

实验内容

l  针对Lab4评审和优化过的程序,设计白盒测试用例;

l  针对Lab1中包含的需求,设计黑盒测试用例;

l  在jUnit环境下撰写测试代码并执行测试;

l  私用Infinitest进行持续测试;

l  使用EclEmma统计测试的覆盖度;

l  让自己的GitHub项目具备持续集成的能力(Travis CI)

实验心得

(1)   “编写测试代码”指的是在刚编写完程序或者程序的某一个单元时，通过编写代码、使用软件的方式，来测试程序或者其中某一单元的性能。而“编写代码”则是一个更加宽泛的概念，作为一个程序员，我们需要编写的代码种类会有很多，测试代码只是其中之一，还有诸如实现程序功能的代码等。可以说，因为“代码”中包含了“测试代码”，所以“编写代码”包含了“编写测试代码”。

(2)   “设计测试用例”是指我们针对被测试的代码段或程序，设计出的一系列方案，尽可能的通过少量有代表性的输入数据，来模拟现实中的所有输入种类，然后通过比较实际输出和期望输出，来评判程序是否符合要求。而“编写测试代码”就是把我们所设计的测试用例，用代码的形式表现出来，以便使用JUnit等工具进行更加专业的代码测试。可以说，“设计测试用例”是我们关于如何测试程序的想法，而“编写测试代码”就是把我们的想法翻译成能被测试工具识别的语言。

(3)   黑盒方法中，我们并不关心具体的代码，因此我们设计的测试用例仅仅依靠于我们事先划分好的测试等价类，我们尽可能的让我们的测试用例覆盖所有的测试等价类。对于每一个等价类而言，我们往往只选取少量具有代表性的测试用例，但是可能在某一些等价类内部，不同的输入在程序内的运行方式可以大相径庭，可能某一等价类中的部分输入可以被正确执行，而其它输入则会引发错误，这是我们在黑盒测试中难以避免的。

而在白盒测试中，我们可以看到程序的代码实现。因此，我们可以以代码为根据来设计测试用例，使得测试用例尽可能覆盖每一行代码，甚至是每一个分支、每一种判定等。这会导致我们的测试用例数量大大增加，但也会让我们的测试结果更加全面、更加有效。

总的说来，黑盒方法中的测试用例，覆盖的是我们设计的各个输入等价类；而白盒方法中的测试用例，覆盖的是程序代码中的语句、分支、判定及其组合。相对而言，白盒测试中的测试用例的“测试覆盖度”应该更高一些，但是黑盒方法无疑更加简洁。

(4)   我愿意养成主动设计测试用例、编写测试代码，并让我自己的代码通过测试的习惯。在我看来，这是十分重要的，看似耗费了更多的时间，但却可以时刻保证我们所写下的每一段代码的正确性。当我们最终将所有代码拼接在一起，实现一个复杂的功能时，可以更加方便快速完成整个程序的整合，而不是每发现一个错误，再去每个代码段中挨个排查。总体而言，我相信这可以为我们节省大量的时间，也可以为我们避免很多不必要的麻烦。

我不认为代码测试应该是专职的测试人员的工作，我认为代码测试应该是程序员在编写完代码时同步完成的。首先，如果测试人员不是代码的编写者，他需要先去理解代码的逻辑，才能去更加有效的设计测试用例，这会浪费大量的时间，更会产生很多误会；其次，如果两个人的编码习惯不同，这会给测试人员带来很大的麻烦，同时，测试人员不断提出代码的漏洞和错误，也会导致测试人员和编写者之间产生矛盾；最后，如果每次编写好代码之后不参与测试，将会很难记住自己代码中的错误，难以获得提升，甚至他们的代码中会重复出现相同的错误，浪费很多的人力物力。所以，我认为代码编写人员应该进行代码测试，至少是参与代码测试。

(5)   从实验过程来说，我认为“白盒测试”的难度相对更高一些，因为在设计测试用例时，我们需要考虑代码实现的细节，根据每一条代码，来设计具体的测试用例，尽可能的覆盖更多地分支和判定以及其组合。而在黑盒测试中，我们只需要根据输入的要求，划分不同的输入等价类，然后依据等价类设计测试用例即可。无论是从复杂程度上，还是测试用例的数量上，“白盒测试”的难度会更高一些。

(6)   通过这次实验，我们对自己编写的代码进行了测试，了解了黑盒测试和白盒测试的流程，也熟悉了jUnit等工具的使用，掌握了设计测试用例、编写测试代码的技能。我们认识到，测试代码也是一个复杂的过程，甚至可以说是一门艺术，好的测试用例可以用最少的代价覆盖最多的可能性，既可以很高效的完成测试代码的工作，让自己更加清晰的了解我们的作品，也可以为我们节约更多的时间。因此，我们需要在平时编写代码时就坚持进行代码测试，提高我们的代码测试水平。