站在测试的角度看需求

1、站在测试角度看需求一：需求文档所需要包括的内容二：如何根据需求设计测试用例三:没有需求文档的时候如何来设计测试用例需求文档所需要包括的内容-概述1.更改记录：对需求版本信息的跟踪；2.项目概述：主要描述这个项目产生的背景，以及这个项目所能解决目前面临的问题；3.需求文档编写的目的：阐述该需求文档在项目开发中所起的作用；4.用户和角色：描述项目当中所涉及到的各角色，以及各角色的权限与作用需求文档所需要包括的内容-需求描述1：功能模块1.1 概述：系统所包括的功能模块1.2 模块描述：描述其子模块，子模块下的子功能点1.2.1 业务概述：该子功能所包括的具体业务1.2.2 使用者：该功能的使用者1

2、.2.3 输入要素：数据输入对象的描述1.2.4 处理流程：功能操作的描述1.2.5 输出要素：输出结果的描述需求文档所需要包括的内容-需求描述2：功能性需求2.1 功能点列表2.2 功能项描述2.2.1 功能描述2.2.2 典型操作2.2.3 异常，交叉引用，约束条件，前置条件，后置条件2.2.4 参考界面2.2.5 数据描述：各输入对象是如何产生的需求文档所需要包括的内容-需求描述2：功能性需求2.1 功能点列表2.2 功能项描述2.2.1 功能描述2.2.2 典型操作2.2.3 异常，交叉引用，约束条件，前置条件，后置条件2.2.4 参考界面2.2.5 数据描述：各输入对象是如何产生的2

3、.3 非功能性需求2.4 质量要求需求文档所需要包括的内容-需求描述3 其他描述4 附录如何根据需求设计测试用例整理分析需求文档:仔细将需求文档阅读一遍，记录不明白的地方及关键测试点，简单画出总体流程图。然后再来一遍，仔细分析各个模块的功能，画出模块内流程图，找出所有功能，并列出主要测试点如何根据需求设计测试用例-编写用例1.按照不同的业务规则可将测试用例分为四部分：场景用例、系统用例、功能用例2.场景用例：根据画出的模块内流程图，描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景3.系统各角色的系统用例：结合画出的模块流程图，将系统划分多

4、个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分为正常流程、异常流程，分支流程，以场景的形式描述。4.功能用例：描述单点功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。如何根据需求设计测试用例-报表类功能模块如何编写测试用例1.报表类的模块基本没有业务流，不适用场景法。其实报表类模块主要验证能否依据查询条件正确查询显示数据，并保证数据的正确性。可将测试用例分为功能点测试用例和报表数据正确性验证。2.编写查询功能测试用例a.场景1：默认条件查询结果正确；b.场景2：修改可选择输入条件查询结果正确c.场景3：修改输入条件查询结果正确d

5、.场景4：组合可选条件、输入条件查询结果正确e.场景5：错误、空记录查询结果为空3.编写其他功能点测试用例，同样可将功能点分解多个场景。4.编写数据正确性验证测试用例:找出影响报表的各种数据因素、列举报表展示的各种数据，列举两者编写数据正确性验证用例。没有需求文档的时候如何来设计测试用例一：测试过程中一般没有需求文档的三种情况1、开发人员的意识不足，开发流程不规范，可能是以前做项目一直都是拿到市场可行性分析，然后项目管理人员进行简单模块划分，任务就分配下去了，更不就不写需求文档，或者只是简单书写大体功能点。2、项目进度紧张，后期需求变动可能比较大，来不及书写详细的需求文档3、项目是从原有项目上

6、进行迭代开发，开发人员认为不要再进行需求文档编写。没有需求文档的时候如何来设计测试用例-针对上述情况的个人见解对于第一种情况：1、测试负责人应该坚持开发没出需求文档，就不进行测试，要坚持让开发输出项目需求文档，哪怕是写的不够详细也好，最少都要输出一份简单的功能列表；2、需求文档要进行评审，评审做会议记录，并有专门人员对需求文档进行修改；3、最后就是测试人员进行测试需求分析，再根据测试需求点进行测试用例编写了。没有需求文档的时候如何来设计测试用例-针对上述情况的个人见解对于第二和第三种情况:1、测试人员尽量找到已存在的资料，比如市场调研书，可行性分析报告，收集一切对项目有用的文档。并提出其中的功能点需求；2、如果是迭代项目开发，则找到前期项目的一些需求文档，概要设计，详细设计，测试需求，用例等。提起里面的功能点；3、咨询相关人员，获取项目一些大体功能，最好能知道大体项目的框架，然后记录咨询到的功能点；4、了解项目大体框架后，可以在网上寻找同类产品，把里面的一些亮点功能点进行提起；5、整合上面的几点，测试