软件测试交流学习V100.docx
《软件测试交流学习V100.docx》由会员分享，可在线阅读，更多相关《软件测试交流学习V100.docx（12页珍藏版）》请在冰豆网上搜索。
软件测试交流学习V100
一、软件测试的常识与理论
1、什么是软件测试？
测试目的什么？
定义：
为了发现错误而执行程序的过程。
目的：
是为了发现尽可能多的缺陷，而不是为了说明软件中没有缺陷。
推论：
成功的测试在于发现了迄今为止尚未发现的缺陷。
所以测试人员的职责是设计这样的测试用例。
它能有效地揭示潜伏在软件里的缺陷
2、一些常识与经验之谈
◆测试能提高软件的质量，但是提高软件的质量不能依赖测试。
◆测试只能证明缺陷存在，不能证明缺陷不存在。
“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。
◆测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。
◆每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。
◆80-20原则：
80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错
◆测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。
二、测试的分类与比较
1.基于是否关注软件结构与算法
黑盒测试
不基于内部设计和代码的任何知识，而是基于需求和功能性。
白盒测试
基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
2.基于是否执行被测试软件
静态测试
不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
动态测试
通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：
构造测试实例、执行程序、分析程序的输出结果。
3.基于测试的不同阶段
单元测试
最微小规模的测试;以测试某个功能或代码块。
典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。
这个工作不容易作好，除非应用系统有一个设计很好的体系结构;还可能需要开发测试驱动器模块或测试套具。
集成测试
一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。
部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。
这种类型的测试尤其与客户服务器和分布式系统有关。
系统测试
基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件
验收测试
按照任务书或合同或其它验收依据进行的整个系统的测试与评审，决定是否接收或拒收系统。
4.基于软件测试的内容
回归测试
指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
功能测试
对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能
负载测试
通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。
压力测试
通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。
性能测试
为获取或验证系统性能指标而进行测试。
易用性测试
安装与反安装测试
恢复测试
安全性测试
兼容性测试
兼容性测试将验证软件与其所依赖的环境的依赖程度，包括对硬件的依赖程度，对平台软件、其他软件的依赖程度等。
内存泄露测试
比较测试
指与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。
来取长补短，以增强产品的竞争力。
Alpha测试
Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
开发者负责记录发现在错误和使用中遇到的问题。
总之，Alpha测试是在受控的环境中进行的。
Beta测试
Beta测试由软件的最终用户们在一个或多个客房场所进行。
与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。
用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。
接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品
（就测试内容的分类和方法会后续会细化分析和交流）
三、测试人员的组织
1.了解开发人员的测试心理
测试的目的是找出尽可能多的缺陷。
所以测试是“破坏性”的，而开发却是“建设性”的。
开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。
让开发者去做“蓄意破坏”的测试，就像杀自己的孩子一样难以接受。
开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。
倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.
开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。
2.测试人员应具备的素质
他们是群探索者。
软件测试员不会害怕进入陌生环境。
他们喜欢拿到新软件，安装在自己的机器上，观看结果。
他们故障排除员。
软件测试员善于发现问题的症结。
他们喜欢解迷。
他们不放过任何蛛丝马迹。
软件测试员总在不停的尝试。
他们可能会碰到转瞬即逝或者难以重现的软件缺陷。
他们不会当做是偶然而轻易放过，而会想尽一切可能去发现它们。
他们具有创造性。
测试显而易见的事实，对软件测试员来说还不够。
他们的工作是要设想出富有创意甚至超常的手段来寻找缺陷。
他们是群追求完美者。
他们力求完美，但是当知道某些无法企及时，不去苛求，而是尽力接近目标。
他们判断准确。
软件测试员要决定测试内容，测试时间，以及看到的问题是否是真正的缺陷。
他们注重策略和外交。
软件测试员常常带来的是坏消息。
他们必须告诉程序员，你的孩子（程序）很丑。
优秀的软件测试员知道怎样策略和职业地处理这些问题，也知道如何和不够冷静的程序员合作。
他们善于说服。
软件测试员找出的缺陷有时被认为不重要，不用修复。
测试员要善于清晰的表达观点，说明软件缺陷为何必须修复，并推进缺陷的修复
他们善于提问。
要有打破砂锅问到底的精神，勇于提出问题。
他们拥有编程知识。
需要有一定的编程知识，可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评估BUG。
他们拥有业务知识。
了解业务知识，能更好的了解软件的目的，有助于查找该领域软件的缺陷。
他们还应具备“五心”：
自信心：
测试者必须对自己的观点有足够的自信心。
自信心是现在多数测试者都缺少的一项素质。
尤其在面对需要编写测试代码等工作的时候，往往认为自己都做不到。
要想获得更好的职业发展，测试者应该努力学习，建立能“解决一切测试问题”的信心。
责任心：
责任心使做好工作必备的素质之一，测试者更应该将其发扬光大。
如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。
专心：
测试者在执行测试任务的时候要专心，不可一心二用。
高度集中的精神不但能够提高效率，还能发现更多的软件缺陷。
业绩最好的往往是团队中做事精力最集中的那些成员。
细心：
执行测试工作时候要细心，认真执行测试，不可以忽略一些细节。
某些缺陷如果不细心很难发现。
例如一些界面的样式、文字等。
耐心：
需要有难以置信的耐心。
有时候你需要花费惊人的时间去分离、识别和分派一个错误。
很多测试工作有时候显得非常枯燥，需要很大的耐心才可以做好。
如果比较浮躁，就不会做到“专心”和“细心”，这样让很多软件缺陷从你跟前逃过。
3.避免开发人员与测试人员产生矛盾
开发人员的注意事项
不要敌视测试人员。
要理解测试的目的就是发现缺陷，是测试人员的工作职责。
不要以为测试人员吃饱了没事干，存心找茬。
不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。
测试人员的注意事项
发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。
在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。
请留意另一种极端：
如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。
四、测试用例的设计方法
目前我们完全是黑盒测试，黑盒测试用例设计方法包括等价类划分法、边界值分析法、场景法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
（下一次培训就如何使用这些方法设计有效的测试用例进行详细交流，希望大家培训前各个去了解，但是下次能做到有效交流和互动甚至结合我们工作内容做案例分析）
五、测试策略
理念
企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。
用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。
如何合理地减少测试工作量
减少冗余的测试
白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。
在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
在集成测试、系统测试阶段，可能要执行多次“回归测试”。
每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
减少无价值的测试
无价值的测试通常是由于不懂得测试技术引起的。
例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
如何“偷工减料”
有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。
为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。
偷工减料的途径无非就是减少测试的内容和频度。
但不能砍得太狠，否则软件拿不出手。
基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。
“偷工减料”方法的测试优先级：
哪些功能是软件的特色？
哪些功能是用户最常用的？
如果系统可以分块卖的话，哪些功能块在销售时最昂贵？
哪些功能出错将导致用户不满或索赔？
哪些程序是最复杂、最容易出错的？
哪些程序是相对独立，应当提前测试的？
哪些程序最容易扩散错误？
哪些程序是全系统的性能瓶颈所在？
哪些程序是开发者最没有信心的？
测试何时结束
在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。
软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论!
测试结束点由以下几个条件决定：
1.基于“测试阶段”的原则：
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。
每个测试阶段符合结束标准后，再进行后面一个阶段的测试。
举个例子来说：
单元测试，我们要求测试结束点必须满足“核心代码100%经过CodeReview”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。
集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。
2.基于“测试用例”的原则：
测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。
比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。
在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。
但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。
3.基于“缺陷收敛趋势”的原则：
软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。
我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。
4.基于“缺陷修复率”的原则：
软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：
严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。
那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。
对于测试建议的问题，可以暂时不用修改。
5.基于“验收测试”的原则：
很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。
如果通过用户的测试验收，就可以立即终止测试部门的测试;如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。
6.基于“覆盖率”的原则：
对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。
如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。
如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试”和“随机测试”。
对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。
7.基于“项目计划”的原则：
大多数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结束点。
如果项目的某个环节延迟了，测试时间就相应缩短。
大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。
很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。
8.基于“缺陷度量”的原则：
这个原则也许大家用的不是很多，了解比较少。
我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。
我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。
我们也可以把“测试期缺陷密度”和“运行期缺陷密度”作为一个结束点。
当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。
比如说：
一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。
9.基于“质量成本”的原则：
一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。
至于这三方面哪一项占主要地位,就要看是什么软件了。
比如说是：
人命关天的航天航空软件,那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。
如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。
一般来说，最主要的参考依据是：
“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。
具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。
如果找到bug的成本比，用户发现bug的成本还高，也可以终止测试。
10.基于“测试行业经验”的原则：
很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。
比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。
如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。
因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。
六、测试规范
测试流程
第一步：
制定测试计划。
该计划被批准后转向第二步。
第二步：
设计测试用例。
该用例被批准后转向第三步。
第三步：
如果满足“启动准则”，那么执行测试。
第四步：
撰写测试报告。
第五步：
消除软件缺陷。
如果满足“完成准则”，那么正常结束测试。
测试启动准则
同时满足以下条件，允许开始测试：
（1）测试计划已经制定并且通过了审批；
（2）测试用例已经设计并且通过了审批；
（3）被测试对象已经开发完毕并等待测试。
测试完成准则
对于非严格系统可以采用“基于测试用例”的准则。
同时满足以下条件允许结束测试：
（1）功能性测试用例通过率达到100％；
（2）非功能性测试用例通过率达到90％时。
对于严格系统，应当补充“基于测试期缺陷密度”的规则：
（1）相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。
例如n大于10，m小于等于1。
七、软件系统的主要测试内容及技术
接口与路径测试
数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。
每个接口可能有多个输入参数，每个参数有“典型值”、“边界值”、“异常值”之分，所以输入的组合数可能并不少。
根据接口的定义，可以推断某种输入应当产生什么样的输出。
输出包括函数的返回值和输出参数。
如果实际输出与期望的输出不一致，那么说明程序有错误。
白盒方式的接口测试和黑盒方式的功能测试，其方法十分相似。
一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。
想遍历测试几乎是不可能的，不测试或者胡乱找几条路径测试却又不行。
对于非严格系统而言，在分析路径方面化费很多精力是不值得的。
我认为在构造接口测试的同时已经建立了测试路径。
因为每一种输入将产生唯一的输出，输入与输出之间的路径也是唯一的。
由于接口测试中的输入是有代表性的，因此相应的路径也具有代表性，不用费煞苦心地去找测试路径。
路径测试的检查表
数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理
由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没有被测试。
预防措施有：
观察是否有程序语句从来没有被执行过。
如果发生在这种情况，要么是程序有错误，存在无用的代码；要么是接口测试不充分，漏掉了一些路径。
要特别留意函数体内的错误处理程序块（如果存在的话），这是最易被人疏忽的路径，隐患最多。
功能测试
功能测试的基本方法是构造一些合理输入（在需求范围之内），检查输出是否与期望的相同。
如果两者不一致，即表明功能有误。
也有例外的情况，如《需求规格说明书》中的某个功能写错了，而实际上软件的功能却是正确的，这时要更改的是《需求规格说明书》。
功能测试看起来比较简单，只要看得懂《需求规格说明书》，谁都会做。
难点在于如何构造有效的输入。
由于输入空间通常是无限的，穷举测试显然行不通。
那么随便输入一些东西，碰运气行不行？
功能测试有两种比较好的测试方法：
等价划分法和边界值分析法。
等价划分是指把输入空间划分为几个“等价区间”，在每个“等价区间”中只需要测试一个典型值就可以了。
等价划分法来源于人们的直觉与经验，可令测试事半功倍。
“缺陷遗漏在角落里，聚集在边界上”。
边界值测试法是对等价划分法的补充。
如果A和B是输入空间的边界值，那么除了典型值外还要用A和B作为测试用例。
例如测试函数。
凭直觉，等价区间应是（0,1）和（1,+∞）。
可取典型值x=0.5以及x=2.0进行“等价划分”测试。
再取x=0以及x=1进行“边界值”测试。
健壮性测试
健壮性是指在异常情况下，软件还能正常运行的能力。
健壮性有两层含义：
一是容错能力，二是恢复能力。
容错性测试通常构造一些不合理的输入来引诱软件出错，例如：
（1）输入错误的数据类型。
如“猴”年“马”月。
（2）输入定义域之外的数值。
如上海人常说的“十三点”
粗暴一些方式俗称“大猩猩”测试法。
除了不能拳打脚踢嘴咬外，什么招术都可以使出来。
例如在测试客户机－服务器模式的软件时，把网络线拔掉，造成通信异常中断。
恢复测试重点考察一下几项：
（1）系统能否重新运行；
（2）有无重要的数据丢失；
（3）是否毁坏了其它相关的软件硬件。
性能测试
性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。
有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。
有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。
在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。
例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。
性能测试的一些注意事项：
不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。
应当测试软件在标准配置和最低配置下的性能。
为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。
不同的输入情况会得到不同的性能数据，应当分档记录。
例如传输文件的容量从100K到1M可以分成若干等级。
由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。
用户界面测试
绝大多数软件拥有图形用户界面。
图形用户界面的测试重点是正确性、易用性和视觉效果。
在评价易用性和视觉效果时，主观性非常强，应当考虑多个人的观点。
信息安全测试
信息安全性（security）是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
信息安全性测试有如下步骤：
（1）为非法入侵设立目标，例如“盗窃某个文件”或“更改数据库记录”等。
（2）邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”。
（3）如果有人成功了，请他详述入侵的过程。
别忘了给予奖励。
压力测试
压力测试也叫负荷测试，即获取系统能正常运行的极限状态。
了解“极限”是很有价值的，例如潜艇下潜极限深度…。
压力测试的主要任务是：
构造正确的输入，使劲折腾系统却让它刚好不瘫痪。
u压力测试的一个变种是敏感测试。
在某种情况下，微小的输入变动会导致系统的表现（如性能）发生急剧的变化。
敏感测试目的是发现什么样的输入可能会引发不稳定现象。
可靠性测试
可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。
由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠性测试可能会花费很长时间。
比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。
计算出相邻故障的时间间隔，注意要去掉非工作时间。
这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。
其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。
安装/反安装测试
安装/反安装测试的目的：
避免“大风浪都挺过来了，却在阴沟里翻了船”。
目前市面上有非常流行的、专门制作安装/反安装程序的一些工具，如InstallShelled。
制作安装/反安装程序不再是件难事，关键是不要麻痹大意。
主要测试工作：
（1）至少在标准配置和最低配置两种环境下测试；
（2）如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。
升级会员 