(一)需求的简述

软件需求

1、对于用户:

需要解决的问题，希望达到的目的所需条件和一种需求更改的权利

2、对于开发者:系统需要满足需求文档的相关功能标准

3、对于需求:是一种条件和职权的文档说明。

包括功能性需求(系统应该提供的哪些功能)及非功能性需求，非功能性需求(系统的特定性和约束)对设计和实现提出了限制（性能要求，质量标准，设计限制，相关功能等）

我们当前需求的缺点

1、需求经常变更

需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。）

2、需求不明确

3、测试与开发需求不一致

如何面对需求

熟透整个需求(系统)的每个功能和流程(建立思路),后续的工作都是依照需求进行操作，所以熟透需求文档是一个很重要的一步。

对于初次进行需求审查，看完每一个模块，将每个模块的功能流程做成流程图。依次扩大，就将整个需求流程了解清楚，每次将流程图(需求建

模)多浏览几次。

提取更好的需求点

一般的需求文档都是按照每个功能进行提供需求，所以可以在每个功能模块中细分需求点。将每句话理解透就能够更好的得到需求点

需求的分析重要性

需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。(拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。)，需求的分析是链接用户和开发者的桥梁！

如何把握更好的用户需求

熟透需求文档，将文档转化成开发人员更懂的流程图(需求建模),并在与用户交谈时候改变需求内容，随时与用户沟通，更好的把握用户的需求和改变！将开发过程修改的需求，及时反馈与用户，让需求更加灵活化。

测试人员如何进行测试

1、对需求文档的分析

2、提取需求点

3、对每个需求点提取测试点

4、对测试点细分，得到测试用例

5、用测试用例在已经完成的功能模块上测试

6、记录测试点结果，得到缺陷报告

7、将缺陷报告交于测试老大或者直接交于开发人员

8、确认缺陷是否修复

测试点在什么地方，测试员一般测试哪一块

1、从测试用例中提取测试点

2、界面的布局和文字的校验

3、正常业务的校验

4、输入框的校验(比输入项的校验)

5、日期校验

6、查询信息的校验等等

我们的测试过程中涉及的技术（对应到相应模块）

1、需求的审查

2、测试点提取

3、测试用例的设计

4、缺陷报告

(二)对于整个系统，综述测试人员如何测试

测试时注意什么?

1、从用户的角度出发

2、从开发者的角度出发

3、确保测试用例覆盖所有流程

4、设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态。

5、一定要注意测试中的错误集中(集群性)发生现。

6、对测试错误结果一定要有一个确认的过程。

7、制定严格的测试计划，不要希望在极短的时间内完成一个高水平的测试。

8、回归测试的关联性要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

9、妥善保存一切测试过程文档。

如何正确与开发人员做沟通(主写缺陷发现后与开发人员沟通反映，缺陷报告的流通(测试人员和开发人员之间的交互))

与开发人员沟通主要有一下几点

一位有故事的测试者对开发者的忠告