[其它] 软件测试中的过度设计

说明：中国有句老话：过犹不及。软件开发中也有一个概念：“过度设计”，说的是为了实现一些简单的功能需求，设计出非常臃肿的结构，代码间的继承、依赖、调用非常复杂，开发工作量大并且难以维护。在软件测试工作中，也存在类似“过度设计”的问题，特别是大中型的软件企业，人数比较多，各方面工作流程趋于稳定和规范，问题更容易发生。　　出现“过度测试”的原因非常简单：忽视了软件测试工作的终极目标与核心价值，而过于关注测试活动过程。这里我列出一些“过度测试”的案例，我们一起分析一下。　　测试工作必须依赖完整规范的需求文档　
<weixin_38663733> 上传 | 大小：78kb

[其它] 一种行之有效的软件测试策略

说明：在最近的一个大型项目中，我们在早期就定下了一个目标：不会在软件中使用大量QA人员专注于手工测试。通过手工测试发现bug极其耗时且成本高昂，这促使团队尝试尽可能的将质量内嵌 　　在最近的一个大型项目中，我们在早期就定下了一个目标：不会在软件中使用大量QA人员专注于手工测试。通过手工测试发现bug极其耗时且成本高昂，这促使团队尝试尽可能的将质量内嵌到产品内部。但这并不意味着手工测试毫无价值，因为人们总能在怎样使用软件上给你一些特别的惊喜。 　　这是一个为期18个月左右，周期很长的项目，并且后续也会
<weixin_38551205> 上传 | 大小：119kb

[其它] 如何有效提高软件测试效率的方法探讨

说明：软件测试是保证软件质量的重要手段。如何组织软件测试，耗费最少时间与最小工作量完成软件测试，使软件质量满足用户要求，是软件研发单位需要解决的问题。本文结合工程实践， 　　摘要：软件测试是保证软件质量的重要手段。如何组织软件测试，耗费最少时间与最小工作量完成软件测试，使软件质量满足用户要求，是软件研发单位需要解决的问题。本文结合工程实践，从软件的可测试性及测试组织等方面探讨提高软件测试效率的方法。 　　关键词：可测试性;软件测试;测试人员; 　　引言 　　自从上世纪七八十年代全面爆发软件危机起，软件
<weixin_38652058> 上传 | 大小：72kb

[其它] 软件测试用例设计方法之边界值分析方法

说明：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。 一.方法简介 1.定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充
<weixin_38658564> 上传 | 大小：355kb

[其它] 软件测试用例实例之常见功能测试点

说明：软件测试用例实例之常见功能测试点1.登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　　1.登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　　1)登陆 　　①用户名和密码都符合要求(格式上的要求) 　　②用户名和密码都不符合要求(格式上的要求) 　　③用户名符合要求，密码不符合要求(格式上的要求) 　　④密码符合要求，用户名不符合要求(格式上的要求) 　　⑤用户名或密码为空 　　⑥数据库中不存在的用户名，不存在的密码 　　⑦数据库中存在的用户名，
<weixin_38717896> 上传 | 大小：58kb

[其它] 如何设计可复用的测试用例

说明：软件测试的关键环节是设计和执行测试用例。测试用例的质量与测试人员的技能、经验以及对被测软件的理解密切相关。如果测试人员对被测软件不甚了解，很难在短时间内设计出有效 　　0、引言 　　软件测试的关键环节是设计和执行测试用例。测试用例的质量与测试人员的技能、经验以及对被测软件的理解密切相关。如果测试人员对被测软件不甚了解，很难在短时间内设计出有效的测试用例;有的测试用例虽然面面俱到，但冗余现象严重，浪费时间、人力和物力。 　　随着软件复用技术的发展，测试复用引起了人们的极大关注，特别是对测试用例复用
<weixin_38735887> 上传 | 大小：62kb

[其它] 测试用例的设计心得

说明：入行软件测试行业2年，从事过自动化的测试和手工的功能测试。两年来一直没有总结过自己的工作。每当一听人问起一个简单的问题，如何编写好的测试用例?如此简单的问题一 　　入行软件测试行业2年，从事过自动化的测试和手工的功能测试。两年来一直没有总结过自己的工作。每当一听人问起一个简单的问题，如何编写好的测试用例? 　　如此简单的问题一问，仔细一想，思绪凌乱无章。这就是没有好好思考过的原因。 　　今天在博客总结下自己的看法，如何编写测试用例： 　　1、了解软件的原始需求(测试目的) 　　在编写一个软件或者
<weixin_38517095> 上传 | 大小：61kb

[其它] 测试用例实例--常见功能测试点

说明：1.登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　　1.登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　　1)登陆 　　①用户名和密码都符合要求(格式上的要求) 　　②用户名和密码都不符合要求(格式上的要求) 　　③用户名符合要求，密码不符合要求(格式上的要求) 　　④密码符合要求，用户名不符合要求(格式上的要求) 　　⑤用户名或密码为空 　　⑥数据库中不存在的用户名，不存在的密码 　　⑦数据库中存在的用户名，错误的密码 　　⑧数据库中不存在
<weixin_38744803> 上传 | 大小：60kb

[其它] 测试需求分析

说明：一、获取测试对象也就是我们最初的工作:测试需求的分析 　　测试需求的分析为四个部分: 　　1、明确需求的范围 　　2、明确每一个功能的业务处理过程 　　3、不同的功能点作业务的组合 　　4、挖掘显式需求背后的隐式需求 　　二、分别阐述： 　　1、明确需求的范围(目标：需求中包括了多少功能点) 　　1.RTM中的SRS列表(粒度) 　　2.QC中的需求描述(不同层次) 　　3.UML的用例视图(ActorUsecase) 　　2、明确每一个功能的业务处理过程 　　1.拆点:对应的每一个功能点将其对
<weixin_38688956> 上传 | 大小：44kb

[其它] 测试用例的设计心得

说明：入行软件测试行业2年，从事过自动化的测试和手工的功能测试。两年来一直没有总结过自己的工作。每当一听人问起一个简单的问题，如何编写好的测试用例?如此简单的问题一 　　入行软件测试行业2年，从事过自动化的测试和手工的功能测试。两年来一直没有总结过自己的工作。每当一听人问起一个简单的问题，如何编写好的测试用例? 　　如此简单的问题一问，仔细一想，思绪凌乱无章。这就是没有好好思考过的原因。 　　今天在博客总结下自己的看法，如何编写测试用例： 　　1、了解软件的原始需求(测试目的) 　　在编写一个软件或者
<weixin_38514872> 上传 | 大小：61kb

[其它] 从用例到代码：用例分析

说明：自从1992年IvarJacobson发表了关于如何使用用例，从系统用户的角度来提取软件需求的方法的论文之后，这种方法已经逐渐流行起来。但是有一个最常见的问题是：当我得到了用例之后， 　　自从1992年IvarJacobson发表了关于如何使用用例，从系统用户的角度来提取软件需求的方法的论文之后，这种方法已经逐渐流行起来。但是有一个最常见的问题是：当我得到了用例之后，如何才能把他们用代码实现出来?本文由两部份组成，将会用一个实际的案例来说明这一点。如何从用例中提取需求，并加以分析，进一步将其转化
<weixin_38609089> 上传 | 大小：129kb

[其它] 黑盒测试的测试用例设计方法

说明：目前黑盒测试的测试用例设计方法有5种：等价类划分边界值分析错误推测法 　　目前黑盒测试的测试用例设计方法有5种： 　　等价类划分 　　边界值分析 　　错误推测法 　　因果图 　　功能图 　　一、等价类划分 　　等价列划分设计方法是把所有可能的输入数据，即程序的输入域划分成若干部分(子集)，然后从每一个子集中选取少量具有代表性的数据作为测试用例。 　　等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试
<weixin_38679277> 上传 | 大小：86kb