(一)需求的简述
软件需求
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、妥善保存一切测试过程文档。
如何正确与开发人员做沟通(主写缺陷发现后与开发人员沟通反映，缺陷报告的流通(测试人员和开发人员之间的交互))
与开发人员沟通主要有一下几点
