软件测试技术：软件测试的目的和原则

软件测试的目的和原则目的建立软件的信心理件软件测试目的验证（Verfication）：软件生命周期的各个阶段，用下一个阶段的产品来检查是否满足上一个阶段的规则确认(Validation)：软件生命周期的各个阶段，检查是否满足需求阶段定义的各项规格和要求。原则GoodEnough原则：投入与产出平衡Pareto原则：二八原则尽可能早的开展测试错误多的地方多投入同化问题：交叉测试，利用不同人的观点问题:软件测试的目的？软件测试是否发现所有的BUG？测试人员在进行测试的时候遵循什么原则？软件测试开始的时间？软件测试的过程测试需求的分析和确定测试计划测试执行测试记录和缺陷跟踪回归测试测试总结报告测试需求对需求文档的测试或评审需求的测试是重点需求可能存在的问题需求文档编写有问题、功能不明确，流程不清晰，不正确占50%余下50%是需求的遗漏造成的检查的要点对于需求文档，应该遵循尽早测试的原则完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性：每一项需求都必须准确地陈述其要开发的功能。一致性：一致性是指与其它软件需求或高层(系统，业务)需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如UseCase或别的来源。可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性：每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(fine-grained)的方式编写并单独标明，而不是大段大段的叙述。另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度需求文档检查步骤尝试理解需求规格说明书原始需求文档检查列表讨论、评审、修订需求文档检查列表序号检查项检查结果说明1是否覆盖了用户提出的所有需求项是〔〕否〔〕NA〔〕

2用词是否清晰，语义是否存在有歧义的地方是〔〕否〔〕NA〔〕

3是否清楚地描述了软件系统需要做什么及不做什么是〔〕否〔〕NA〔〕

4是否描术了软件使用的目标环境，包括软硬件环境是〔〕否〔〕NA〔〕

5是否对需求项进行了合理的编号是〔〕否〔〕NA〔〕

6需求项是否前后一致，彼此不冲突是〔〕否〔〕NA〔〕

7是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系是〔〕否〔〕NA〔〕

8是否清晰描述了软件系统的性能要求是〔〕否〔〕NA〔〕

9需求的优先级是否合理分配是〔〕否〔〕NA〔〕

10是否描述了各种约束条件是〔〕否〔〕NA〔〕

编写测试用例需求规格说明书测试用例虚拟软件产品测试人员开发人员“预演”测试测试用例编号：Input_001测试优先级：中测试目的：验证业务单据数据的查询正确性标题：业务单据查询步骤：1.打开查询界面2.输入查询条件3.确定并提交查询4.查看并验证返回的信息还有...除了文档检查和测试用例外，可以通过用户调查和利用现存产品对需求进行测试一些技术建议熟悉UML测试前了解软件系统对应的