测试需求分析与测试用例设计

测试用例需求分析怎么写

1.做过软件测试各位大神们帮忙看下,怎么根据这个需求分析写测试用例

1、首先根据需求写出测试用例大纲（很重要：测试大纲的目的在于罗列出所有的测试点。

当你测试大纲写完之后和项目组的人员讨论、研发、设计都需要参加、以确定不会因为理解偏差导致的遗漏或者是方向不对）2、然后根据测试大纲开始编写完整的测试用例3、在用例编写的时候进行分类（如：业务流程测试，安装测试，功能测试，兼容性测试，安全性测试等等）4、设计测试用例的方法（等价类，边界值，因果图，流程分析，等等）5、用例编写的时候需要考虑到用例的复用性。6、设计用例的时候最好在有疑问的时候找人讨论（一个人的思维决定了你的用例颗粒度、换个思维你会发现用例有很多地方不足）以上是我在做软件测试过程中的一点点经验、祝你好运。

2.怎样才能写好测试用例

我觉得做好以下三点就是一个好的用例。

第一：依据分明

众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。

假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么 ok，我们就要写5000个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。

第二：目的明确

用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。

第三：便于统计

测试用例对整个测试过程的质量控制和评估有很重要的意义。

一，可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。

二，做用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多。那么你做的用例成功率还有什么意义？

你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。

三，做缺陷分析。用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候，这几个测试点也有回归，有些可能与缺陷毫无关系的测试点，都被你回归了。

还有更详细的，介绍你去中国IT实验室的网站看看，里面有很多资料。

3.软件测试需求分析的主要步骤是什么

软件测试就是在软件交付用户使用或投入运行前，对软件需求规格说明、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生命周期中横跨两个阶段：通常在编写出每一个模块之后就需要对它做必要的测试（称为单元测试）。编码和单元测试属于软件生命周期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，如集成测试、系统测试、性能测试和配置测试等，这是软件生命周期的另一个独立阶段，即测试阶段。

软件测试的目的：

1、测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效的运行；

2、好的测试用例在于发现至今未发现的错误；

3、成功的测试是发现了至今未发现的错误的测试；

4、好的测试工程师应该做到不仅发现问题，还能够帮助开发人员分析问题；

软件测试的原则：

1、应把“尽早和不断地进行软件测试”作为软件开发者的座右铭，实践证明单元测试能够尽早发现问题，减少后期测试的错误量。可以采用Junit和Jtest来辅助进行单元测试。

2、测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。

3、应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试）

4、测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的，临界的，可能引起问题的输入条件。

5、充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。

6、严格执行测试计划，排除测试的随意性。

测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准。

7、应当对每一个测试结果做全面的检查。

8、妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

软件测试的对象：

软件测试并不单纯等同于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试（评审）的对象。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来希望对你有用

4.如何写一份漂亮的测试用例

我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。

回到测试用例中来，我觉得做好以下三点就是一个好的用例。

第一：依据分明

第二：目的明确

第三：便于统计

测试用例对整个测试过程的质量控制和评估有很重要的意义。

一，可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。

三，做缺陷分析。用例失败了，就生成一个缺陷。

5.怎么写好测试用例

测试用例是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。以上可以看出测试用例在整个测试工作中的地位和作用，以下编写了关于如何写好测试用例的一些个人建议：

1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。

2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。

3、尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。

4、要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。

5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。

6、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。

7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个操作步骤。比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。

8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。

9、测试用例级别要划分清楚，这样在测试执行时有主次之分。

11、评审用例很关键，因为经过测试用例的评审可以发现：用例设计的结构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。

12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。

13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。