这几天一直在看一本书，《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