Day04

总结:

 测试用例的评审和变更

         首先要清楚是组织内部评审，还是项目组内部的评审，评审的定义不同，内容也会不同

                测试组内部的评审，应该着重于

                    1.测试用例本身的描述是否清晰；

                    2.是否考虑到测试用例的执行效率，由于测试用例的不断重复执行，造成测试设计的冗余性，                        造成了 效率的低下；

                    3.是否针对需求文档，测试文档是否覆盖了所有软件需求；

                    4.是否完全遵守了软件测试需求的规定   

项目组内部的评审，需要评审委员会来做，监督不同，评审的标准也不同

一.需要评审的原因：

      测试用例是软件测试的准则，但由于用例开发人员的设计经验和需求理解的深度不同，所以用例的质量会有不同的差异

 二.进行评审的时机

      一般会有两个时间点，第一是初步设计完成之后进行评审，第二是在整个详细用例全部完成后进行的二次评审

三.参与评审人员

    1.部门评审，测试部门全体成员参与的评审。

    2.公司评审，这里也包括项目经理，需求分析人员，架构设计人员，开发人员和测试人员。

    3.客户评审，包括了客户方的开发人员和测试人员

四.评审内容

   1.用例设计结构是否清晰合理，是否有利于高效对需求进行覆盖

    2.优先级安排是否合理 

   3.是否覆盖测试需求上的所有功能点

  4.用例是否具有很好可执行性

  5.是否已经删除了冗余的用例

  6.是否包含了充分的反面测试用例

 7.是否从用户层面来设计用户使用场景和使用流程的测试用例

 8.是否简洁，复用性强

五，评审的方式

  1.召开评审会议

编写测试计划

   一：测试计划的主要内容：

       测试计划是有测试组长编写，主要里面包括了测试背景，测试的目的，人员的安排，时间的分配，测试环境情况还有就是风险评估

   二：测试计划工作的主要目的是什么？测试计划文档的内容应该包括什么？

       1.主要目的：测试管理人员可以明确测试任务和测试方法，保持测试实施过程中的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更

       2.编写测试计划六要素         

            1.测试目标：功能 、可用性、安全性等。

            2.测试对象：被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等；

            3.测试环境：测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议 等单机或网络环境。

            4.测试前提：测试用例运行时所处的前提或条件限制。

            5.输入数据：在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。

            6.操作步骤：执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等