从测试的角度来重新反思我们自己的程序以及我们的程序员之路——“通过追本溯源来进行前瞻性思考”

　　最近比较忙，而且情绪上有些浮动，但控制的非常好。这几天协会搞一个编程比赛，部分的题目是我出的，所以最后大家决定让我做测试人员，对协会的比赛进行评测。我虽然已不担任协会职务，却毅然接受了。

　　首先，我了解了测试相关的概念，阅读了《软件测试》、《软件测试的艺术》、《微软的软件测试之道》、《软件测试经验与教训》等，并结合自身的测试经历来做一些记录，希望抛砖引玉。

　　虽然协会测试用不上这些，既然让我做了，我就应当力求公正公平，准确有效。在做好这个工作的余下时间里，作了一些浅薄的思考，现在拿出来跟大家一起分享。

　　微软虽然有很多不足，制作的程序漏洞不少，但不可否认，在其快速开发的进程中，将测试放在比较重要的位置，也是其获得较多正面评价的原因之一：

　　微软的组织结构：

　　微软的“大公司小团队”战略，小团队布局：

　　以下是读书心得，摘抄：

　　软件测试或系统测试大约占用50%的项目时间和超过50%的总成本。

　　测试是为发现错误而执行程序的过程。（人类的行为总是倾向于具有高度的目标性，确立一个正确的目标有利于实现这一目标，这里我们确立我们的目的是发现错误）

　　软件测试的大多数问题都是心理学问题。

　　程序员应当避免测试自己的程序。

　　一个测试用例必须包括两个部分：1、对程序的输入数据的描述2、对程序在上述输入数据下的正确输出结果的精确描述。

　　黑盒测试主要将重点集中放在发现程序不按其规范正确运行的环境和条件。

　　白盒测试主要是对程序的逻辑结构进行检查，从中获取测试数据。

　　检查程序是否“未做其应该做的”仅仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。

　　程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。

　　至少编写足够的测试用例，使得每一种可能均被测试，每个入口点都至少被调用一次。

　　经验证明，考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相比，具有更高的测试回报率。所谓边界条件，是指输入和输出等价类中那些恰好处于边界、或超过边界或在边界以下的状态。