25、根据用例设计方法来设计一个模块的测试用例，如果该模块最后有300条用例，那么一般设计这些用例需要多长时间？

　　专家分析：排除设计人员本身技术高低或用例管理工具难易程度等其他因素，就用例本真而言，用例设计时间通常被两个因素影响：

　　（1）功能复杂程度

　　（2）用例粒度（也可以简单理解为用例个数）

　　所以，建议比较合理的是自己先试验一次，然后再通过考虑其他因素影响，评估出贴近实际的时间。

　　26、在项目紧急，没有需求文档，没有用例评审，又只能独自完成测试的情况下，如何保证测试用例不会漏测呢？

　　专家分析：严格来说，这个问题只看”测试用例不会遗漏”已经是伪命题。 至今没有哪个公司敢宣称：咱们的测试用例覆盖率100%。

　　所以，这个问题还是回到了实际环境分析出发，建议先分析以下几点得到大致的测试标准：

　　（1）客户对产品的质量要求程度。简单可以理解为： 客户使用什么样的方式来验收产品。常见的方式为：3个月试用、1个月客户测试团队复检、1天客户体验…不同的验收的方式在很大程度上决定了产品的预期质量目标。

　　（2）产品的功能覆盖和2级交互测试，一般被作为满足产品输出的最低质量保证。单黑盒方面来说，这部分可考虑自己设计功能结构图，然后通过1次功能点分类得到。

　　（3）再补充一个常用的用例设计信息：用例设计的时间通常不会超过测试周期总时长的1/3，用例遗漏的部分，最快速的方式是使用探索测试完成。（当然，测试人员或开发人员的实际使用测试也能为补充测试泄露提供一定程度的帮助）

　　27、对于一个复杂的java管理系统，功能中主要以增删改查、新增-审批-发布，类似这些重复的功能特性，请问在设计测试用例时，如何保证设计的全面性？

　　专家分析：（1）先按照流程图或场景法先清理测试点的思路框架。

　　（2）提取多次被重用的子功能测试点单独设计公共用例组。公共用例组保证为子功能的最大合集，并注意分类方式，方便被提取时，可快速删选。需要注意公共用例组的粒度，可能它不仅仅只是一个小功能，比如编辑框；在某些情况下，也可以考虑将一小段流程整个作为公共用例组，如审批过程。

　　（3）由于ERP系统完整流程运行一次的时间较长，且可被中断的测试点较多，通常会将交互用例组单独分割出来，然后逐个重新加载到需要模块基础功能测试用例组中。

　　（4）NFT的部分，可参考交互用例组的处理方式。

　　（5）最后，留下设计用例整个周期约1/4左右的时间评审和完善用例组。

　　（6）至于黑盒外的测试用例组，除使用标准的白盒用例设计方法外，在测试数据选择方面，建议考虑以量的方式来补足。毕竟白盒测试的运行速度远远高于黑盒用例。

　　28、对于一些特殊的项目，比如说时间短，开发文档不齐全，我们是不是非要执着于去编写测试用例？如果写，时间从何而来；如果不写，如何保证测试的全面和保证测试人员测试的情况？

　　专家分析：除了经常涉及的简化测试用例的方法外，针对极限条件（无需求，无测试用例），提供一些相关信息，供参考：

　　必要条件：

　　（1）测试领导者对测试原理有较深刻认识（至少需要达到裁剪测试流程水平）

　　（2）测试团队具备较高的可控性（至少能理解测试领导者每个测试任务的实际内容，并且能”踏实”的完成执行测试）

　　（3）测试团队仅限于单个site。（跨Site测试团队合作项目，可考虑每个独立测试团队分派不同的任务）

　　测试策略：

　　极限测试条件下，首先需要高度保证测试过程的运行策略的易操作性。

　　虽然复杂的测试策略的风险更小，但是它需要消耗更多的时间去理清信息和调整。在极限条件下不可能有那么多的时间和资源完成，所以，把握测试的核心，以己之力，牵动整个团队的步伐，达到最终的目标。（这里并不是说决策者不会失误，只是单个决策者比多个决策者的效率更高而已。）