下面我们再来看另一份有问题的代码：

　　如果读者对上面我的分析过程能够正确地理解，相信对于这份代码的bug也是不难找到的：问题出在条件判断上面。

　　这个条件判断貌似少点什么！没错，分支只判断c是否等于k，而根本没有考虑(k-c)的奇偶问题；换句话说，代码少考虑情况了！那么Challenge就变得很容易了，只要把代码中缺少的部分提炼出来即可，例如示例中的第三组测试数据originalWord="aaa"， finalWord="bab"，k=4，按照这份代码的结果会是"IMPOSSIBLE"，而实际上(k-c)是偶数，应该返回"POSSIBLE"，这样我们的Challenge又成功了！不过这次与上一次的Challenge是有所不同的，因为这份代码并非所有测试用例都通过不了，例如示例中的第二个测试用例，当originalWord与finalWord相同的时候，代码是可以通过的。因此我们称这种仅能通过部分测试用例的情况为对需求的片面分析或需求项分析不足。

　　我们的Challenge过程很好地阐述了如何针对这种情况设计测试用例：将需求项分析不足的地方提取出来，专门设计这方面的用例。当然，真实应用中，我们会设计大量测试用例，但需求项的覆盖问题依然是重中之重，因为如果测试人员在解读需求的时候不能将其完全覆盖，设计的测试用例必然有所遗漏，可能会造成测试失败。所以，测试用例对需求的完全覆盖，即恰当地进行逻辑测试是测试人员必须加以重视的内容。

　　正确的代码总是相同的，而错误的代码则各有各的问题，我们再来看另一份代码：

　　判断部分似乎真的没什么问题，只是形式和我的例程有所差异，那这份代码是怎么被成功Challenge的呢？细心的读者可能一眼就能发现问题所在，前面的循环有问题！结束条件居然是i<length-1，这就意味着最后一个字符不在循环处理范围内！