测试方法的选择
• 通常在确定测试方法时，有以下几条参考原则：
• （1）拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现， 考虑使用场景法。
• （2）需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价 划分，将无限测试变成有限测试。
• （3）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错 误的能力最强。
• （4）如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图 和判定表法。
测试用例的力度
• 测试用例可以写的很简单，也可以写的很复杂。
• 最简单的测试用例是测试的纲要，仅仅指出要测试的内容。
• 测试用例写的过于简单，则可能失去了测试用例的意义。过于简 单的测试用例设计其实并没有进行“设计”，只是需要把测试的 功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个 简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。
• 最复杂的测试用例则会指定输入的每项数据，期待的结果即检验 方法，具体到界面元素的操作步骤，指定测试的方法和工具等。
• 测试用例写得过于复杂或详细，会带来两个问题：一个是效率 问题，另一个是维护成本问题。另外，测试用例设计的过于详 细，留给测试执行人员的思考空间就比较少，容易限制测试人 员的思维。
缺陷报告
如图所示
报告注意：不能一次性报告几条错误，报的的名字要用别名
缺陷统计
• 对软件问题的功能域分布进行分析，找出系统的薄弱环节。
• 要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。
• 二八定理：80%的软件问题总是发生在大约20%的功能模块中。
• 对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶 段详细采集缺陷的数据。
• 应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。
• 应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。
• 应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的 工作情况。
