第13章节 测试战术.pptVIP

代码走查（Walkthrough） ：人工走查，主要是一个讨论过程，是非正式的。 开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。  当团队成员对代码进行讨论的时候，他们的讨论应该集中到一些重要的话题上，比如算法，基于对象的编程，类设计。 然而，许多代码走查不会做这些事，通常代码走查是枯燥的，烦人的，机械的。 这就是为什么许多开发人员讨厌这些。要使得代码走查变得很有效，那么这个过程就必须是有趣的，有创造性的。 很经常地，代码走查退化成了仅是关注于强制代码标准－－一个可以被自动执行的实践。 代码审查(Inspection)：有一个评审过程，是正式的。 开发组内部进行的，采用讲解、提问并使用编码模板进行的查找错误的活动。一般有正式的计划、流程和结果报告。 1. Comment  　　注释没写，或者格式不对，或者毫无意义  　　2. Coding Standard  　　没遵守代码规范  　　3. Existing Wheel  　　重复现成的代码，或者是开源项目，或者公司已有代码  　　4. Better practice  　　Java或者开源项目，有更好的写法  　　5. Performance bottle and Improvement  　　性能瓶颈和提高  　　6. Code Logic Error  　　代码逻辑错误  　　7. Business Logic Error  　　业务逻辑错误  　　代码审查列出问题的类型，并有解决情况报告 技术评审(Review) 开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用编码模板进行的查找错误的活动。一般有正式的计划、流程和结果报告。 测试产品说明书属于静态黑盒测试 * A.输入条件的约束有以下4类： ① E约束（排他）：a和b中至多有一个可能为1，即a和b不能同时为1。 ② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。 ③ O约束（唯一）；a和b必须有一个，且仅有1个为1。 ④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。 B.输出条件约束类型 输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。 4.因果图 如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。 因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。 用因果图生成测试用例的基本步骤 分析软件规格说明描述中，哪些是原因 (即输入条件或输入条件的等价类)，哪些是结果 (即输出条件)，并给每个原因和结果赋予一个标识符。 分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系? 根据这些关系，画出因果图。  用因果图生成测试用例的基本步骤 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。 把因果图转换成判定表。 把判定表的每一列拿出来作为依据，设计测试用例。 因果图 在因果图中出现的基本符号通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值“0”或“1”。“0”表示某状态不出现，“1”表示某状态出现。 主要的原因和结果之间的关系有: 因果图 表示约束条件的符号为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。 因果图 例如，有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下： 若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。” 因果图 (1) 分析这一段说明，列出原因和结果原因: 1. 售货机有零钱找 2. 投入1元硬币 3. 投入5角硬币 4. 押下橙汁按钮 5. 押下啤酒按钮 建立中间结点，表示处理中间状态11. 投入1元硬币且押下饮料按钮12. 押下〖橙汁〗或〖啤酒〗的按钮13. 应当找5角零钱并且售货机有零钱找14. 钱已付清 因果图 结果： 21. 售货机〖零钱找完〗灯亮 22. 退还1元硬币 23. 退还5角硬币 24. 送出橙汁饮料