转眼又过了一周了，没有上来与大家进行交流，今天没有课，感觉很轻松，所以上来写点东西。马上就要讲解如何设计测试用例了，所以借备课之际，总结些东西。设计程序的用例，主要是根据软件的需求，测试用例覆盖软件的需求，在设计测试用例时，要划分测试用例设计的粒度，也就是如何把需求划分成一个个需求点，这时保证每个需求点都是可测的。而在实际写测试用例时，很多时候是按照程序本身来设计测试用例，边运行程序边设计测试用例，对发现问题的地方设计测试用例，其实这种方法是不太科学的，会导致遗漏测试用例，无法做到功能覆盖，无法进行测试确认。所以最好根据需求设计测试用例。
在设计测试用例时所根据的依据是测试需求，测试需求除了依据软件需求规格书外，还有很多隐含的需求，例如：业务规则、用户特点等，应该还有客户支持部门的反馈，竞争对手的产品等。测试需求不一定写成文档，而是贯穿在我们设计测试用例的过程中，包括在设计测试用例之前的准备阶段。
我们在设计测试用例时，对所设计的每一个测试用例，都指定了预期结果，没有预期结果的测试用例是无法验证和度量被测试软件的。也就是对每一条需求指定了质量测度标准，我们接受满足测度标准的解决方案，同时拒绝任何不满足测试标准的解决方案。这个测度标准就是我们从测试需求中提取出来衡量测试是否通过的依据。
在需求设计阶段，我们测试人员介入进行测试用例设计，这时设计测试用例主要是对需求进行检查，发现需求中的缺陷，防止这些缺陷遗留到后续阶段，导致后期修复成本的增加。这时我们主要检查需求的正确性和完整性。正确性检查主要是根据用户需求进行检验。检验需求描述是否正确的反映了用户的需要。而完整性检查主要是保证需求中没有遗漏用户的需求。在进行测试性需求检查时，也要注意非功能性需求，对于用户的需求使用功能性需求描述程序所要完成的功能，同时也要描述非功能性方面的用户需求，例如：性能，安全性等。在检查需求时还要确认每一条需求是否都是可测试的，也就是需求的可测试性。如果一条需求不能验证，那么他的实现正确性就得不到保证。
在需求阶段设计测试用例检查需求后，在软件设计阶段、代码实现阶段都要补充、修改所设计的测试用例，在这些阶段用户的需求是变化的，测试用例也需要进行补充和修改。在这个过程中，还要确保软件的需求变化能够进行有效的管理，保证每个相关部门都要及时收到需求变化，根据需求变化做出调整。
