项目的思维导图，收货地址的思维导图测试用例，登录的测试用例

测试用例  定义：

      要素：  用例编号  所属模块  前提条件  测试输入   预期结果 实际结果

                        备注   版本  测试人  测试日期 

     测试方法：  

                   等价类划分   因果图  边界值  正交法   错误推断法   场景法

测试用例的评审：

评审内容

评审的内容有以下几个方面

1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

2)优先极安排是否合理。

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

4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。

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

6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。

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

8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤

 

   分为组内和组外评审：

组内评审的人员：  测试Leader 和 测试人员

组内评审着重与   1.用例的冗余性

                            2. 用例的准确性

                            3.  用例的覆盖度   70%-80%

                            4. 用例满足需求 

 

 组外评审：   测试leader  测试人员  项目经理  产品经理 

        1.是否满足软件的需求 

        2. 用例覆盖率

        3. 用例的执行性

        4. 用例的复用性

        5. 用例是否具有正反的用例

        6. 编写用例的模板

        7. 非功能性测试用例的编写

        8. 缺陷率在执行的测试用例中的占比

 

 

 

开发团体人员：   5：1

                       10人开发团队      1 UI  5个后台开发   2个移动端    1个测试/运维   1产品

项目开发周期：  6个月   

版本迭代：  大版本   1个半月    小版本 1周    

测试分工：   功能界面   性能+接口   自动化