如何提高软件测试设计质量.docVIP

如何提高软件测试设计质量 测试用例设计是确定一组发现一个或一类错误的概率极高测试数据。因为穷举测试时不可能的，测试时间和资源是有限的，所以选用哪些测试用例和测试数据是设计过程中要考虑的主要问题。 首先，要明确测试用例设计过程： 用例设计准备→分析数据流、业务流→定义测试用例设计策略→设计系统测试用例→设计集成测试用例→设计单元测试用例 用例设计准备： 测试范围理解了吗？什么样的用户、多少用户使用软件？模拟测试环境理解了吗？系统角色定义了吗？用户的业务流程理解了吗？软件的数据流程理解了吗？测试需求和质量标准定义了吗？软件中的术语有定义吗？测试用例规范定义了吗？做随机测试了吗？是否熟悉软件？ 功能点划分重要程度了吗？（哪些功能是软件的特色？哪些功能是用户最常用的？哪些是软件的核心模块？哪些功能块在销售时最昂贵？哪些功能出错将导致用户不满或索赔？）功能点划分优先级了吗？（哪些程序时最复杂、最容易出错的？哪些程序是相对独立，应当提前测试的？哪些测试难度较大？）哪些模块采用了新的技术？哪些模块是开发者最没有信心的？哪些程序最容易扩散错误？哪些程序是全系统的瓶颈所在？ 测试设计中的系统分析方法： 结构化分析（数据流）：数据流图、数据字典、结构化英语、判定表、判定树 系统动态分析：状态迁移图、时序图、Petri网 用例设计前要将规格说明书细化为输入输出、条件结果；必须画出程序流程图；控制流程图；数据、业务流程图 测试用例设计策略： 客户需求、软件需求设计系统测试用例框架； 软件需求、概要设计设计集成测试用例框架； 详细设计说明书设计系统测试用例框架 关于设计测试用例 单元测试用例设计的主要方法有：规范导出法、等价类划分、边界值分析、状态转移测试、分支测试、条件测试、数据定义（数据流）测试、内部边界值、错误猜测法、声明测试、路径测试、循环测试、循环嵌套、边界值测试、接口测试、确认测试、事务测试 集成测试用例设计： 集成测试（部件测试）是指模块间的组合测试，重点关注模块间的接口；集成测试从程序结构出发，能模拟所有实际情况，发现问题容易定位；集成测试用例设计关键在于模块划分，模块的划分直接影响到测试的工作量。 集成测试考虑的问题：各模块连接起来后穿越各模块接口的数据是否会丢失；子功能的组合能否达到父功能的要求；单个模块功能是否会对另一模块产生不利影响；全局数据结构是否有问题；单个模块的误差积累是否会放大到不可接受的程度 系统测试用例设计的主要方法有：等价类划分、边界值分析、因果图、正交试验设计法、判定表分析法 系统测试内容如下： 确认测试（客户）：有效性测试、配置审查、Alpha测试、Beta测试、验收测试 系统测试（测试人员）：恢复测试、安全测试、强度测试、性能测试、其他测试 在实际设计用例时，需要全面考虑正面测试用例、逆向测试用例、特殊需求测试用例、代码覆盖测试用例，以提高测试用例的覆盖度。 设计软件测试用例需要遵循的原则 　　1. 单个用例覆盖最小化原则。 　　这条原则是所有这四条原则中的”老大“，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。下面举个例子来介绍，假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，可以有下面两种方法来设计测试用例： 　　方法1 ：用一个测试用例覆盖三个子功能 -Test_A1_A2_A3， 　　方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3 　　方法1适用于规模较小的工程，但凡是稍微有点儿规模和质量要求的项目，方法2则是更好的选择，因为它具有如下的优点： 　　测试用例的覆盖边界定义更清晰 　　测试结果对产品问题的指向性更强 　　测试用例间的耦合度最低，彼此之间的干扰也就越低 　　上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容，不要“搂草打兔子”捎带着把啥啥啥啥都带进来，这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven Development：A Practical Guide》曾这样描述，最好一个测试用例只有一个Assert语句。此外，覆盖功能点简单明确的测试用例，也便于组合生成新的测试，在Visual Studio中就引入了Ordered Test的概念。 　　2. 测试用例替代产品文档功能原则。 　　通常我们会在开发的初期(Scrum每个Sprint的头两天)用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识。假设我们在此时达成共识后，描述出来的功能为A，随着产品开发深入，团队会对