软件测试之测试用例设计[-3].pptVIP

测试用例设计;测试体系结构和工程设计;测试系统的构成;测试系统体系结构原理;测试件一团混乱是很平常的事情，当创建新的测试系统时，要同时考虑功能和格式。严谨的工程创造功能，而设计决定生成格式。 好的测试系统体系结构意味着有设计良好的测试件和测试环境。 测试人员通常要维护测试系统，特别是测试用例和测试包。;测试系统的基本构件：测试用例;测试用例的基本格式;其它测试用例;测试用例执行;IEEE 829测试用例模版;功能测试用例 ;用例的组织方式 用例首先应当以功能进行分类，然后按照系统工作方式，依据主工作流程和辅助工作流程进行组织。用例可以进行归纳整理，整理的最小单位为最小不可拆分模块。如：登陆模块，包含的用例可能为密码校验，帐户合法性校验，系统掉线处理等子测试用例，但是可以认为登陆操作是个不可再分的最小测试用例模块，其中包含很多的子测试用例。 争论： 在测试用例的组织过程中，应当将测试用例流程化，按照系统工作流程将所有测试用例分派完毕，达到可对系统检验的目的。 测试用例只组织到最小不可拆分模块，当书写测试方案的时候再组织相应的测试用例。由于在此期间需求或者由于其它因素的变化，可能会造成人力的浪费。 ;用例与其它材料的关联方式，即如何解决用例追踪的问题 一致认为对测试用例的追踪，最好有工具来完成。 可以使用ID进行跟踪，ID的编号规则，应该与相互关联的文档有追踪关系，前提是其它相关文档有自己的编号规则。 建立测试和其它相关文档的关联对应表，达到对测试用例追踪的目的。 ;由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。 ;性能测试的目的：个人认为下面的应该是测试的目的，不是性能测试定义 为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。;性能测试指标的来源： 用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验） ;主要的性能指标： 服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。;BUG观点： 1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）； 2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）； 3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。;HTTP观点： 负载测试是正常情况下持续的加压； 压力测试是直接加压达到一个极限值。 大家统一的观点： 性能测试、压力测试、负载测试密不可分，可统称为性能测试。;性能测试要点： 性能测试是在功能测试完成之后进行。 性能测试计划、方案一般与测试用例统一在一个文档里。 测试环境应尽量与用户环境保持一致。 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。 性能测试的重点在于前期数据的设计与后期数据的分析。 性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。）;学习经验教训：测试用例递增改进;