2.对行业的特性、现状及将来发展目标，也要了解、分析
3.对用户群也要分析 学习下 站在客户立场上看问题！
和客户多交流！
没技巧可言！ 这个问题有太多的场景，针对不同的场景也有不同的答案。我就选择其中一种和大家探讨一下：
项目开发过半，项目组内部已经开始集成，集成测试在即，尚未组建测试团队。在这种情况下，测试团队如何快速熟悉系统需求？
在这种情况下火烧眉毛，肯定是要从人和管理上去下功夫。
首先是团队的组成，最理想的方式是选择有相应行业经验的或者相对资深的测试人员组成核心测试团队负责测试设计工作，系统组和需求组人员协助指导和评审测试策略和测试设计；
其次，最快的知识传递的方法肯定不是看文档/使用和学习系统，肯定是人类最原始最直接的方式：口头沟通。一般建议组织系统设计或需求人员讲一下系统结构和主要功能点；
第三，在工作中学习，现实的压力加速了解需求。在初步掌握系统结构和系统的主要功能后，按照功能模块划分让各测试人员列出测试要点，在逐步的测试设计中了解需求；
第四，基于初步的测试要点开始测试工作，同时开始补充设计测试case和交叉评审测试设计。对于E2E的case，可以由需求人员协助先整理一些场景。
拿把刀
小样...你不说清楚今天就别想走着出去...回复 25# 的帖子
老罗失踪好久了。。 如何學習/快速掌握用戶需求?我覺得,這個問題主要的解決在學習,快速掌握這幾個字上面.
看了上面眾多樓的回覆,注意到大家都忽略了一個問題,就是測試人員自身的知識范圍,理解能力,學習能力,知識搜索速度,知識學習速度等等各種很難處理的人自身的問題,在很多的時候,文檔也有,客戶也會比較的配合,但局限於測試人員自身的能力的問題,會出現很多的問題.
引用<<咨詢的奧秘>>一書中的結論"在整個系統的行為裡面,一般情況下,都是人的問題"
掌握一種學習方法,或者從自己多年的學習經驗中不斷的總結出自己的學習方法,有些人習慣於一目一行的看,有些人習慣於一目十行的看,至於是一行的效果好,還是十行的效果好,因人而異.
掌握準確的理解的方法,這個最常見的例子就是口令快速傳遞的時候,經常會發現第一個傳出的人與最後一個收到的人有千奇百怪的差別,中間為什麼會出錯?百分之九十九屬於理解準確率的問題,所以這就有一點,用更準確的詞語來描述自己碰到的問題及向客戶提出的問題,更快的找出客戶語言或文檔中的不明確,不準確的位置,並進行尋味.
掌握準確的表達方式,如何更有效的表達?如何更準確的表達?有一本書名字叫<<談話的力量>>,同一件事情,不同的表達方式可能會造成天地之別,選用更合適的表達,會更容易掌握到用戶的需求
很多人提出說看需求文檔的效果不如與用戶口頭交流的效果,在某種程度上確實是這個樣子.但是有沒有想過一個問題,A(客戶)腦袋裡面想的需求是A,口頭表達出來的是A-,接收人接收到的信號為A--,當接收人經過自己的大腦處理之後,很有可能變成了A---,再由接收人寫成文檔的時候會變成A----,這個時候,可能已經與客戶的原始需求相差很多,我只是想說明,很多時候,並不是從文檔交流變換為面對面交流是一種更好的方式,如果客戶更擅長於面對面交流,那需要選一個擅長面對面交流的需求分析人員去,如果客戶更擅長於用文檔表達自己的需求,那麼可能選一個擅長面對面交流的需求分析人員,會造成很大的問題...
借一句古話,工欲善其事,必先利其器,在學習/快速掌握用戶需求這個事情上面,我們的器就是測試人員,或者是我們自身,提高自身的種種能力,素質,才會善於學習/快速掌握用戶需求這個事情. 1 找到真正的操作员，了解她的工作流程，工作方式
2 尽可能全面的搜集相关的纸质表单
3 与用户领导协商召开例会，最好每周一次，进行软件实施情况的反馈，具体的操作人员或用户代表需要参加。如果领导太忙不能参加，最好多利用其他时间与其沟通。理解领导想要达到的真正的目的。
4 不要一下子做的东西太多，从最基本的东西，不会变的东西，一点点做起。这个可以和具体的操作人员沟通。这样在对业务逐步熟悉的过程中，逐步完善系统。
5 最初的需求讨论会议，每周的例会，测试人员参与旁听。
6 开发人员开的概要设计、详细设计讨论会议测试人员也尽量参加。
7 测试人员深入需求的理解，个人认为了解系统的数据库结构很重要。以及数据流的走向，最好能自己画画图，这样可以比较快的深入到系统内部。
当然认真学习需求分析文档这些事情，就不再赘述了。 :handshake 阿七的和老罗的说的不错，学习了 perfect 初学者：总结的好。支持 学习了，我是个初学者，大家讲的很好
页:
1
[2]
