测试用例分析的一点心得
由于所在的项目是客户划出一个迭代的几个story，story是客户已经划分好的。
根据story验收标准逐条分析需求点，列出提纲。 分析的过程可以多种多样。如果需求分析人员人数多的话，可以头脑风暴，让做什么清晰化。怎么做更多是开发，设计人员考虑的。也是接下来才要考虑的内容。头脑风暴的时候，先由一个人说出他对这个story的理解，然后其他人提出各种问题，自己的见解。针对某些需求点，客户的信息太少时，很可能会发生激烈的讨论，甚至争论。讨论是很有必要的。首先团队人员之间彼此信任，才会有争论。其次讨论甚至争论增加了看事情的角度，讨论者为了在讨论中获胜，会想尽办法去维护自己的观点。并不一定只是在两人之间争论。事情就会越来越清晰。 结果是对于这些信息量不够的需求点，会有一个最接近客户期望的猜测。
根据提纲，把它们转化成测试用例文档。
整体的角度把握需求，补缺遗漏点.
尤其是异常情况的测试用例。 那些没有发生，尽可能的坏事情，思考起来并不那么令人喜悦。 成功学上总说人要思考那些积极的东西，就会吸引来好的事物。这似乎不太适用于需求分析人员。