《The art of software testing》的一个例子

     这几天一直在看一本书，《The art of software testing》，里面有一个例子挺有感触地，写出来和大家分享一下：

[问题]

     从输入对话框中读取三个整数值，这三个整数值代表了三角形三边的长度。程序显示提示信息，指出该三角形究竟是：不规则三角形/等腰三角形/等边三角形。

[测试]

     下面是一个测试人员要想得问题，你测试一下自己，如果是你设计测试用例，你可以想到多少个测试用例？每想到一个1分。看答案之前最好先想想。

[答案]

1，是否有这样的测试用例，代表了一个有效的不规则三角形？234

2，是否有这样的测试用例，代表了一个有效的等要三角形？223

3，是否有这样的测试用例，代表了一个邮箱的等边三角形？222

4，是否至少有三个这样的测试用例，代表有效的等腰三角形，从而可以测试到两等边的所有三种可能情况？223 232 322

5，是否有这样的测试用例，某边的长度等于0？ 012

6，是否有这样的测试用例，某边的长度等于负数？-123

7，是否有这样的测试用例，三个整数都大于0，其中两个整数之和等于第三个？123

8，是否至少有三个第七类的测试用例，列举了一边等于另外两边之和的全部可能情况？123 132 312

9，是否有这样的测试用例，三个整数都大于0，其中两个整数之和小于第三个整数？124

10，是否至少有三个第9类的测试用例，列举了一边大于另外两边之和的全部可能情况？124 142 412

11，是否有这样的测试用例，三边都是0？000

12，是否有这样的测试用例，输入的边为非整数?2.5 3.5 5.5

13，是否有这样的测试用例，输入的边的个数不对？

14，对于每一个测试用例，除了定义输入值之外，是否定义了程序针对该输入值得预期输出值？

[分析]

作者说：高水平的专业程序员平均得分7.8。 这只是一个衡量标准，你可以达到更高的水平。

[小结]

作者在书中还挺出了几个测试的原则，记录以下，以更好的鞭策自己：

•  测试用例中一个必须部分是对预期输出或结果进行定义
•  程序员应当避免测试自己编写的程序
•  编写软件的组织不应当测试自己编写的软件
•  应当彻底检查每个测试的执行结果
•  测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
•  检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
•  应避免测试用例后即弃，除非软件本身就是一个一次性的软件
•  计划测试工作时不应默许假定不会发现错误
•  程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
•  软件测试是一项极富创造性，极具智力挑战性的工作

[感悟]

什么都有一个刚刚开始，我也是刚刚开始，所以在认真做事的基础上，不要着急，慢慢学习，相信会有所获。

                                                              如果青春一场固执的游戏，而你就是我最在乎的坚持

                                                                                    TT