前面说了开始我们是怎么写软件测试需求。
因为是已成型的软件，所以基本上需求就是根据成型软件+adobe软件+加个人对软件的熟悉程度+PDF参考资料提取出来的。
对于我们各自提取分析出来的测试需求，先是测试组人员之间进行评审因为文档是通过vss管理的大家先通过vss评审文档，评审以后对于不对的地方及不清楚的地方会加上批注，最后大家一起开会讨论评审，定出评审结果各自在按照评审结果进行修改。本来计划要与开发人员一起评审文档的，可是无奈天下的开发似乎都不喜欢看文档，最好只能是我们自己内部评审通过了，以后由开发的头头稍稍过了一下我们的文档，也没说什么，默认就算是通过了外部评审。
有了需求以后我们就按照需求文档设计测试用例，设计测试用例的方法基本上就是一些什么边界值、等价类、因果图、错误推测之类的方法。需要说的一点是我把自己平时在测试过程中测试出来的问题感觉比较重要的都写进了测试用例中。用例模板的格式就是我在上篇中附上的途中的格式，在设计测试用例的过程中主要的是测试步骤和预期结果部分，关于如何设计测试用例这是一个很难的事情不是一两句话可以说的完，我主要想说的是我们在设计测试用例的过程中主要完成的事情就是使用例能覆盖所有的需求，至于我们设计的用例能否测试出很多bug，后来我们在实施的过程中，按照用例执行发现的问题并不是很多，相反习惯了自由测试的前辈们不按照用例发现的问题反而比较多。所以说我们设计的用例在开始只满足了覆盖需求，在接下来我们也逐渐的设计了一些特殊的用例包括一些不常出现的问题、用户反馈回来的问题等。
由于在设计出来的用例要覆盖所有的需求，所以我们在测试的时候，第一个版本会按照用例全部走一遍而且是每个人变化这测试不同的模块，用例走完以后我们基本上就是按照自己的经验来进行自由测试这个阶段发现的问题也比较多，到了版本比较稳定了以后准备上线的时候，我们先做回归测试然后做上架测试也就是版本发布测试，此时时间比较紧没办法走所有的用例，我们选择按照一条的条件筛选出本次测试的“上架测试用例”，基本上每个版本发布我们都会选择不同的“ 上架测试用例”来满足大部分的需求，觉得比较主要的模块就会拿出来重点测。
责任编辑：小草
