今天完成的事情：任务一提交

明天计划的事情：任务一通过后继续任务二的学习，对Visio这个工具在查一些资料了解下

遇到的问题：测试用例方法中的场景法，不太明白，似乎需要工具辅助  Visio

收获：

一、需求分析的特点和难点

困难：

测试需求不充分，没有明确的测试需求分析过程
产品质量维度关注不全面，测试类型不完整
没有测试规格，测试分解分配比较随意
责任主体不明确
没有系统的工程方法或指导
没有相应的质量评估原则

特点：

完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确地陈述其要开发的功能。

一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use

Case或别的来源。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在系统需求分析中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。  

二、什么是测试用例

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。

三、设计测试用例的方法

等价类：正例和反例（有效等价类和无效等价类）

边界类：对功能值域方面的测试（取最大值和最小值）

因果图：针对有组合（下拉列表）的功能进行设计用例

场景法：基于系统流程的测试（覆盖场景、时间、路径各一次）

正交发：组合过多，用因果图看不清的情况下

错误推断法：需要有经验

注：等价类与边界值不能混合写在一起