测试设计重要性
设计是测试的灵魂，质量的龙头。
测试设计面临问题
1、测试对象的逻辑路径和测试输入数据的组合几乎是无穷的，而穷尽的测试是不可能的
2、不同利益相关者对软件或者软件产品的质量要求是不同的
3、测试时间和资源有限
4、测试得到的需求和资源不完整
5、测试设计语言规范
穷尽的测试是不可能的
1、如何有效减少测试用例的数目？
2、如何避免测试用例之间的冗余？
3、如何满足测试覆盖率的要求？
如何有效减少测试用例的数目？
1、等价类
（1）有效等价类
（2）无效等价类
2、边界值
如何避免测试用例之间的冗余？
1、规范测试设计
（1）按照一定的设计思路进行测试用例设计
（2）减少热带风暴
2、可复用的测试用例
特性：通用性、有效性、独立性
如何满足测试覆盖率的要求？
测试覆盖率常用的计算公式：
1、 功能覆盖率
至少被执行一次的测试功能点数/ 测试功能点总数（功能点）
2、 需求覆盖率
被验证到的需求数量 /总的需求数量（需求）
3、覆盖率
至少被执行一次的测试用例数/ 应执行的测试用例总数
4、语句覆盖率
至少被执行一次的语句数量/ 有效的程序代码行数
5、判定覆盖率
判定结果被评价的次数 / 判定结果总数
6、条件覆盖率
条件操作数值至少被评价一次的数量 / 条件操作数值的总数
7、判定条件覆盖率
条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
8、上下文判定覆盖率
上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
9、基于状态的上下文入口覆盖率
累加每个状态内执行到的方法数/(状态数*类内方法总数)
10、分支条件组合覆盖率
被评测到的分支条件组合数/分支条件组合数
11、路径覆盖率
至少被执行一次的路径数/程序总路径数
目前采用覆盖策略
1、基于需求的测试覆盖评估
依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保100%的测试用例全部成功地执行。
2、基于代码的测试覆盖评估
是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
基于代码的测试覆盖评估
1、针对于java的项目采用EMMA工具进行分析
2、针对于delphi项目采用工具还没有定
不同利益相关者对软件质量要求是不同的
1、如何获取利益相关者的不同质量要求？
2、如何设计测试用例以满足不同的质量要求？
3、如何分析和评估最终软件产品的质量？
4、如何提高客户对软件产品的满意度？
测试时间和资源有限
1、如何有效的选择测试重点？
2、如何确定测试优先级？
3、如何有效的配置测试资源？
4、如何分析和评估测试的有效性？
如何有效的选择测试重点
1、软件产品的每个功能模块，对于客户而言并不是是同等重要的；
2、用户实际使用过程中的使用频率的分布
基于风险的测试策略
1、选择测试重点：对测试范围进行优先级的划分，将测试设计和执行放在优先级高的区域。
2、将测试资源分配到高风险的地方，从而更加有效的利用测试资源；
3、确定测试对象在哪些地方容易出现错误，并设计相应的测试用例来发现这些错误；
4、基于风险可以更好的对测试状态和测试结果进行报告，从而更好的对测试过程和测试质量进行监控，并根据实际的测试状态对后续测试进行及时调整。
测试得到的需求和资源不完整
1、如何获取尽量多的显现需求和隐现需求？
2、如何利用已有的经验有效设计测试用例？
3、如何应对需求的不断变更？
如何获取尽量多的需求？
1、 站在用户角度出发
（1）了解用户原始需求
目前公司需求来源于需求人员和项目经理的理解，我们如何得到用户的需要和期望
（2）了解行业隐含需求
（3）需求复用
2、 利用逆向思维方式推测问题
用户当前遇到的问题，是否可以在系统中找到解决方案
如何利用已有的经验有效设计测试用例？
错误推测法
（1）基于代码
（2）基于业务
（3）基于代码的编写者
（4）基于系统框架
如何应对需求的不断变更？
1、变更流程的规范
2、测试流程规范
测试设计语言不清晰导致问题
1、执行者的痛苦
2、测试覆盖率下降
3、测试执行效率下降
4、测试设计的工作成果不被认同
测试用例设计语言规范
1、不要采用一些个性化语言或简称来描述用例
2、用例描述必须含有主谓宾
3、预期结果采用smart原则，必须量化、具体
例如：验证数据正确性
4、涉及类似产品，在产品间描述保持一致
5、同一界面的相同实体描述名称必须一致
6、专业术语必须准确一致