最近抽空读了《编写有效用例》的几个章节，对软件测试有了更加深刻的理解。全书紧紧围绕对需求层面的剖析，对软件测试的方方面面进行了阐述；而这一点我在曾经参加TopCoder周赛Challenge他人代码时候便深有体会，下面便以一次亲身经历来说说设计测试用例的几大要点吧。
首先说说基本背景。TopCoder是一个对全世界程序开发爱好者开放的平台，在上面可以讨论、交流、竞赛。这里真的是汇聚了世界上最顶尖的算法高手。TopCoder周赛也就是SRM(Single Round Match)，平均每十天左右一次，赛前4个小时内报名的注册人员皆可参加，而每个成功报名的人将被随机分配在一个20人左右的Room里。一般情况是75分钟内面对3道难度和分数分别递增的算法题目，使用C++、Java等编程语言解决，比赛过程中提交后会有分数，这个分数是根据从打开题目到提交答案的时间确定的，是一个很复杂的算法，不过通常时间越短分数越高；不过真正的得分要在比赛结束后系统用大量测试用例评判，如果不通过那么该题最终得分仍然为0。SRM最有意思的一点是75分钟的答题时间结束后，经过短暂的休息，有一个15分钟的Challenge环节；这期间每位选手被允许查看同一个Room内的其他选手的代码，如果觉得有问题，那么可以设计测试用例Challenge该代码。如果结果是代码的返回值与预期确实不同，那么Challenge成功，Challenger获得额外奖励的50分，Defender该题目分数当场被扣掉；不过如果代码的返回值与预期相同，那么Challenge失败，Challenger被扣掉25分，Defender分数不变。Challenge环节应该说是十分刺激的，据说在TopCoder的某次高水平比赛中，一位选手3道题目都没有答出来，但却通过12次成功Challenge他人的代码获得600分而获得了所在Room的第一名，这是多么神奇的事情！
言归正传，Challenge别人代码的本质是设计有效的测试用例找出软件bug，以下我以某一次有典型意义的SRM的Challenge环节来讲述如何设计出针对软件bug的测试用例。
题目描述：现有两个字符串originalWord和finalWord，仅由字母'a'或'b'组成，我们把将originalWord中的某个字符由'a'变作'b'或者由'b'变作'a'称为一次move；另有整型数k，问能否通过恰好k次move将originalWord变为finalWord？如果能够实现，返回字符串"POSSIBLE"，否则返回"IMPOSSIBLE"。
用例：
1） originalWord="aababba"， finalWord="bbbbbbb"，k=2，由于originalWord中有4个字符与finalWord不同，因此2次move不可能使originalWord变为finalWord，故返回"IMPOSSIBLE"；
2） originalWord="aabb"， finalWord="aabb"，k=1，由于originalWord与finalWord已经相同，因此1次move反而会使originalWord与finalWord不同，故返回"IMPOSSIBLE"；
3） originalWord="aaa"， finalWord="bab"，k=4，应返回"POSSIBLE"；move的步骤可以是：aaa -> baa -> bab -> aab -> bab；
分析：很明显，题目很水，其实只要统计originalWord与finalWord中不同字符的个数diff，然后将diff与k作比较即可。如果diff大于k，那么一定返回"IMPOSSIBLE"，因为需要move的步数不够；如果diff等于k，显然应返回"POSSIBLE"；如果diff小于k，那么应考察(k-diff)的奇偶性，如果(k-diff)为偶数，应该返回"POSSIBLE"，因为此时多余的move可以通过将某个字符连续move（即由'a'变作'b'后再由'b'变回'a'）消化掉，但如果(k-diff)为奇数，则要返回"IMPOSSIBLE"，因为最后会有一次move变不回原来的字符了。
通过分析，我们知道只要一次循环和一次判断就可搞定该题目，下面给出我写的例程：
不过，自己写代码是一回事，看别人代码又是另外一回事，下面看一份被成功Challenge的代码：
这份代码的问题其实一目了然，事实上它与我提供的例程很接近，但作者犯了一个十分愚蠢的错误，那就是把结果搞反了！这虽然可能是笔误、不小心等原因造成了，但在实际应用中会归结为对需求的分析解读错误。而对这份代码设计Challenge用例是轻而易举的，因为它连示例中给出的用例都过不了，之前的三组测试用例任何一组都可以成功将之Challenge。对这份代码的Challenge过程告诉我们，认真细致地做需求分析十分重要，而对于测试人员亦是如此，因为正确地理解需求可以有针对性地设计功能测试用例找出待测软件的bug。
