软件测试计划要确定测试目标、做好测试需求分析、写好测试计划，更重要的是做好各种风险预防，开发人员用什么样的设计模式和算法？哪些是重点测试，哪些是一般测试范围，哪些可以不测，如果发现Bug少下一步怎么测？如果发现一大堆Bug，下一步又如何测？如何预测缺陷的发展趋势？如同足球赛前的分析，进行各种猜测，对方可能会用什么阵型，433, 442, 4312, …? 哪个前锋是我们紧盯的对象？领先了怎么打?落后了怎么打？如何预测场上局势的变化？我们前面谈到测试执行阶段可以划分为两个子阶段，前一个阶段就是往前冲，目的非常清楚，就是发现缺陷；后一阶段，目的也很明确，减少风险，增加测试的覆盖度。即在软件测试中，要追求效率，同时要降低风险，更重要是平衡。在足球比赛中，前锋目标也很清楚，就是进球，后卫要做好防守而失求，实际就是风险控制，更重要也是攻守平衡。测试执行阶段就是发现缺陷，如果将缺陷都发现出来，风险自然降低了。在足球上，也强调最好的防守是进攻。足球的进攻，也更多获得球迷的喜爱，测试中发现缺陷也很有成就感，比做回归测试更有趣。
　　软件测试经理，有时如同足球教练，看到自己的策略没有得到贯彻，站在场外，无可奈何……因为测试过程没有被组长控制好，如同足球队长没有控制好进攻的节奏；足球队员发挥不好，队长也没办法，有些队员是大牌球星，身价远远超过队长。更何况，世界杯结束，大家各自奔走东西，回自己俱乐部踢球，你又能怎样？测试员发挥不好，测试组长也难控制，IT跳槽也是频繁，测试经理有时还要十分小心呵护我们的工程师，也怕他们一走了之……
　　软件测试，如果最后不认真，往往漏掉几个严重的缺陷而将产品发布出去，后果不看设想，如同日本队和澳大利亚比赛，1：0领先，一不小心，在8分钟内连丢三球，哭的没眼泪…程序代码质量好，发现缺陷不容易，如同碰上足球强队，进一球非常不容易；程序代码质量差，发现缺陷也容易，如同碰上象中国足球队这样菜鸟，可能灌进十来个。测试顺利时，如同西班牙打乌克兰，最后进的一球，和谐、流畅、一气呵成，非常漂亮。测试不顺利时，如同厄哥斯达黎加打瓜多尔，绝妙的好球打到门框上，就是不进球……
　　有经验的球队，首先对如何踢这场球以及每个球员在其中所承担的角色取得共识。足球赛是真正的一个团队工作，巴西球队中的大牌球星无数，但不是人们想象那样可怕，而厄瓜多尔没有大牌球星，两场球赛大捷，不失一球，完全来自于优秀的团队配合。如果一支球队不懂的配合，疲于奔命，却不容易赢得比赛。在测试中同样需要明确的分工又需要默契的配合，测试也是真正的一个团队的工作，任何一个人的失误，会造成前功尽弃。高质量的产品，来自于每个测试人员的兢兢业业。足球的进攻线路，球队需要的紧凑有效的进攻线路，而讨厌拖泥带水的进攻线路，犹如软件测试用例的设计，一定是对程序路径、条件、数据边界等了如指掌，设计出有效、简短的步骤，而不是漫无目的，列出一大堆的操作步骤去碰运气。
　　足球的远距离劲射、冷不丁的射门，相当于软件的例外测试（exception test）,测试系统的容错能力。在对方门前狂轰乱炸，犹如软件测试中的强度测试，测试系统的反应能力，有没有性能瓶颈。足球的倒勾，一般出于灵机一动，可以说是软件的ad-hoc测试。定位球中角球、任意球，可是我们软件的白盒测试啊！成功率很高。点球，软件的白盒测试高手，一出手就知有没有，基本能做到白发百中。

转自：http://hide708.spaces.live.com/

判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

　　条件桩：条件列表
　　动作桩：动作列表
　　条件项：条件取值
　　动作项：动作取值
　　规则：条件项和动作项的对应关系

判定表的化简：
1、删除不存在的规则
2、合并相似规则
 i. 动作完全相同
 ii.该条件项包含所有取值（说明动作与该条件的取值无关）

判定表法的步骤：
1、确定条件和动作
　　条件：输入或环境（可通过分析动作反推得出）
　　动作：输出
2、确定条件项和动作项
　　条件项：输入的取值或环境的真值（T/F）
　　动作项：输出值
3、用判定表列出全排列组合
4、化简判定表
5、针对每条规则设计用例

判定表的优点是考虑了输入的组合情况；缺点是全排列组合数量大，化简困难，用例多。

　　边界值，顾名思义，就是边界上的值。边界值分析方法的理论基础是，假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其他的取值导致程序错误的可能性也很小。

　　边界点的定义：
　　上点：边界上的点，开放区间则在范围外，闭区间则在范围内
　　离点：离上点最近的点，开放区间则在范围内，闭区间则在范围外
　　内点：范围内的点

　　边界值分析是等价类划分的补充，边界值是最好的等价类代表。

　　边界值分析与等价类划分一样，只考虑覆盖，不考虑组合。

划分完等价类以后就要设计用例对划分的等价类进行覆盖。对于有效等价类，要使用例能尽可能多地覆盖尚未被覆盖的有效等价类，对于无效等价类，则每次只覆盖一个。

等价类划分的优点是比较简单，缺点是它并没有考虑组合的情况。

需求评审讲完了，感觉要挖掘隐式需求真不容易。事实也确实如此，如果我们能正确把握用户的所有需求，那就没有风险可言了。。。现实是残酷的，我们不可能把所有的需求都挖掘出来，但是我们可以尽自己全力，从而将风险降到最低。磨炼，从今天开始。

第一次就来个简单点的好了，那就测一个“不锈钢杯子”吧。也欢迎大家参与讨论，共同进步！

失眠。。。

很痛苦的感受，明明很累，可就是睡不着

大概真的是对自己的认识不够吧，连睡觉都如此。。。以为能睡着，却一直醒着。。。

昨天的第一阶段考试才考了70分

回想一下，覆盖率的指令块和判定路径都做错了。。。可能太紧张了

其他能想起来的，填空错了3个空，判断错了1道，SQL错了一个空，不过这点加起来才5分。。。等明天看看卷子再说吧。。

据说班里有20个人不及格（虽然有10个后来被拉及格了。。。）   老师要伤心死了

后面的课自己还要更加努力才行啊！~