4.需求文档理解、提出有效测试点

4.需求文档理解、提出有效测试

1.软件测试人员越早介入测试，越早发现问题，就能越早的修复问题，越早发现问题，修复的成本越低，越晚发现问题，修复的成本越高。

2.软件测试人员测试需求文档，有几个路径，其中的一个方法，就是需求评审。

需求评审通常是由产品人员组织的，由相关人员参加，相关人员指的是参与这个项目的人员；项目经理，开发管理人员，测试管理人员也会参与，以便对项目有所了解，更好的安排排期，及工作；如果此项目涉及到不同部门，有条件的情况下，可邀请不同部门的相关人员来讲解这个需求的背景。并不是所有的项目都必须要兴师动众地进行需求评审，有些很小的模块或者项目，可以由产品人员召集项目的参与者，如测试人员或者开发人员，如果发现有疑问的地方，也可以召集产品，开发，进行小范围的需求评审。

需求评审前的几点准备：

1、在需求评审会前，先看需求文档，有时，会有几个项目同时在进行测试，而没有时间看需求文档的现象，这个要测试管理者在项目排期时，考虑到这种情况，而预留一定的看文档的时间。

2、在读需求文档的时候，记录下对文档不同的异议，或者，不明白的地方。

3、了解该项目的需求背景。

4、了解该项目所涉及到的原理。

5、了解该项目所涉及的知识点。

需求评审会的几点注意事项：

1、产品人员要解读需求，以便相关人员，更好地理解需求。

2、需求评审会上，有争论的歧义点，要做好记录。

3、做好会议记录。

4、会后，将会议记录发送给相关人员。

5、及时的更新需求文档。

因为一些原因，需求文档，会有一些遗漏的点，比如，这个需求未召开需求评审；或者，由于，时间紧迫，未充分解读需求文档；或者，参加需求评审会的测试人员与实际执行测试的人员不同，且测试人员经验不同等情况。此时，在写测试用例时，或者，在测试时，也可以去发现需求文档不合理或者遗漏的点。

测试用例流程

1、[测试](javascript:;)前首先明确测试范围（特别是要明确哪些是不需要测试的）；

2、详细分析需求和开发文档，了解这个产品功能的来源（可站在用户的角度考虑问题），为什么要做这样的功能（可扩展思维，考虑一些反向用例），希望最后的结果是什么（可明确输入结果是否正确），还有行业常识和计算机知识、约定俗成（属于隐藏的需求）这些都需要考虑清楚。

3、划分测试功能点

4、根据不同功能点分别考虑各种输入条件、对应的输出表现，还需考虑用户实际使用的情况（有效的进行测试）、与其他部分关联使用的情况、非正常情况（不合理、非法、越界以及极限输入数据）操作和环境设置（方便复现问题）等。

5、我一般通过功能图分析法，场景法来分析测试需求并转换成功能点；通过域分析方法【等价类、边界值】、因果图（输入条件的各种组合判定，相互制约情况）、判定表法来进行[测试用例](javascript:;)的转换，通过错误推测法进行补充；

要求主次分明，注意功能点间逻辑层次，不能走哪测试到哪，要有明确的目标（即时碰到不好复现的问题，也能通过分析推测出现问题点）。

6、最后抛开用例，发散思维，在出现问题多的地方进行探索性测试。(有时间的话多了解一下行业动态，包括熟悉竞争对手的软件，会对你考虑用户实际情况的思维有提高)

总体思路：先正常，后异常，这样可以确保正常情况下功能能够走通。