david_wang1984/
共17个网摘 [
1 ] |
访问david_wang1984的个人空间
david_wang1984收录，使用标签：经验之谈，时间：2007-10-25 15:03:19 | 相关网摘，我也收藏
来源：中国IT实验室
最近公司的产品一直忙于测试，看着每天的Bug不断的增加和修正，真是痛并快乐着，痛苦是因为Bug不断的出现，快乐是看着Bug一个一个的被消灭，把这些天的测试开发过程总结一下。
1、测试要尽早
公司的产品已经修订一段时间了，但是由于任务繁忙和人手不足，因此测试一直拖后，因此当进行集中测试的时候Bug集中爆发，因此感觉更加的繁忙，另外由于很多功能和修订，都已经修改了很长的时间，因此程序员再次进入修改的时候，往往需要重新分析和理解，造成Bug的修复周期延长了很多。
建议当完成功能修订后，要尽快进入测试状态，以缩短Bug的存在时间，降低程序员修订成本。
2、使用好的缺陷管理工具
之前公司只是使用一个BBS作为缺陷的跟踪和管理工具，但是，效果很不理想，虽然缺陷管理的工具很多，但是都有自己的长处和短处，后来使用了TD，效果的确好的多。
3、缺陷描述要准确
很多测试人员反馈的缺陷，程序员读起来十分的费劲，甚至比理解缺陷本身还要难懂，因此，如果缺陷后，在登记的时候，一定要尽量描述准确和清晰，以免造成错误的理解，反而更加干扰缺陷的修订。如果缺陷的确很难描述，可以将缺陷的发生过程录制下来，或者干脆手工给程序员演示一遍，效果就更好了。
4、缺陷描述不完整
很多缺陷都是有前世和今生的，因此把缺陷产生的出发条件描述的完整，对解决缺陷起着很重要的作用。
5、缺陷要分等级
缺陷都是要优先级别的，严重的当然要尽快解决，低级别的放一放。
6、开发和测试最好不同步
公司是早上8：30上班，一般是9：00左右才能给测试部一个新的测试版本，而如果Build出现意外，则新的版本发布就会推迟，因此开发和测试一定要有个时间差，开发部最好在早上第1时间给测试部一个最新的测试版本。一种是开发部早点来，一种是晚点走，最后我们的约定是下午4:30分开发部Build版本给测试部明天使用。
7、优先验证Fixed状态的缺陷
测试部每天最优先的任务就是验证新版本中Fixed状态的缺陷是否正确，这个很主要，因为开发部刚刚修正，如果没有验证通过，程序员可以立刻进行修订，如果过了很长时间才通知没有通过，那么可能程序员还得重新理解和分析代码。
8、一个缺陷报告包含多个缺陷
有些时候测试人员在一个测试报告中，包含N（N>=1）个缺陷，结果程序员修订了其中一个，另一个需要拒绝掉，结果缺陷的状态就失去效果了，因此一个缺陷记录只能包含一个缺陷，如果存在多个就是测试人员的责任了。
9、交叉测试的重要性
我们最初安排测试的时候，是某个测试人员只测试其中一部分，另外的测试人员测试另外一部分，过了几天后发现，每个测试人员的Bug检测数量都下降了，原来，测试人员对自己部分已经发现不出来缺陷了，后来采用了交叉测试的方式，就是测试人员交换测试工作，结果不同的人从不同的角度进行测试，结果一些缺陷又发现了，因此交叉测试很重要。
10、测试经验的总结
测试的过程很枯燥，而测试过程中发现的测试经验是十分重要的，不断的调整测试的策略、流程，多总结和借鉴别人的测试经验，会更好的提高测试质量。
http://testing.csdn.net/page/430f4a41-3ef8-4591-a825-1796caaa4c9a
david_wang1984收录，使用标签：学习的目标，时间：2007-10-25 14:47:57 | 相关网摘，我也收藏
来源：实用性测试 - CSDNBlog
陈能技
2007-9-4
软件测试是一门需要不断学习补充新知识的学科，要想成为一名优秀的测试员就必须像成为一名武林高手一样不断研习武艺，博采众家之长，消化吸收后据为己有，这样才能最终称霸武林，并且立于不败之地。
测试的各种理论知识就像武功中的内功心法，各种测试技巧和测试工具则像招式和兵器，如果忽略了内功心法的修炼，即使招式和兵器熟练使用，也可能只是花拳绣腿，没有很强的杀伤力。
对待测试理论的辨证态度
测试理论对于一个测试员来讲是必不可少的，就像前面讲的，它是内功心法，是基础。
但是有些人对测试理论不屑一顾，认为测试理论不过是那些学院的教授挤尽脑汁想出来唬人的东西。有些人认为测试理论都是大公司、大规模的测试团队才能应用得上。
实用主义测试员是功利的，没有好处的事情是不会做的。但是实用主义测试者会辨证地看待这些问题，实用主义测试者分几步来看待这些理论：
1、首先看这些理论是否有它的道理，它的应用条件是什么。
2、然后看是否能马上应用到自己的测试过程中。
3、如果不能照搬使用，再看是否能通过修改、调整来达到自己适用的目的。
但是，实用主义测试者不会迷恋于测试理论，他们不会像收集各家武功秘籍一样疯狂地寻找各种新奇的概念。
真正优秀的实用主义测试者会在上述步骤之前加上一个初始步骤：分析自己测试过程中存在的问题，然后有选择性地寻找相应的测试理论来支持和充实自己的测试策略。
实用性测试理论的“用武之地”
对于测试理论，我们的目的是学以致用。
使用的地方主要有两个，一个是用于改善测试过程、测试方法、测试策略，从而保证产品质量。这个是主要目的，也是最直接的目的。例如：学习用户交互设计理论，是为了把理论知识用到用户界面测试、可用性测试、用户体验检查上，提出这些方面的缺陷，促使开发设计人员进行界面交互上的修改，从而提高这些方面的质量。
第二个是武装你自己，在你与项目组成员发生冲突时，能很好地使用你学习到的东西武装你自己，坚守质量的阵营。“书到用时方恨少”，这句话同样适用于测试理论的积累。如果平时没有注意积累，在关键时候是没办法“捍卫”你自己的，武林高手总是在陷入困境时能应用奇招脱险。
例如：界面测试发现的问题，往往修改率不高，原因当然有很多了，有考虑设计更改工作量的原因，有项目进度压力的原因。但是主要原因还是开发人员对待这些问题的态度。界面问题往往在某些公司认为是小问题，不值一提的问题，有些公司甚至禁止测试员录入这种类型的bug。有时开发人员也会对界面设计有自己的理解，虽然未必恰当，但是至少他们对这些问题进行了考虑，这是好事。但是问题是你作为测试员是否能说服他们按你的“界面规范”修改呢？
这些问题的解决都需要我们的测试员拥有深厚的“内功”，知道某些界面规范制定出来背后的支撑依据是什么？为什么要尽量使用非模式的方式反馈信息，而不是弹出消息框？为什么要按一定的逻辑顺序排列界面元素？为什么要了解用户技能水平并对用户进行分类？这些都需要我们在平时就去多想想，多找相关的理论知识充实自己，这样在跟开发人员“切磋”时才不至于哑口无言，适当时还能抛抛书袋，嘴角冒出一两个术语，将自己置于不败之地。
实用测试理论分类
对于实用主义测试者而言，测试理论可以按以下方法进行分类。
按理论化的程度划分：
1、可直接使用类
2、可借鉴概念类
3、研究类
可直接使用的理论知识是我们测试过程与使用条件相符合的情况，这种情况下，拿来即用。例如冒烟测试的理论可直接应用在所有项目的测试中。
可借鉴概念类的理论知识是我们不具备使用的条件，但是理论提出的概念很好，我们可以借鉴或加以改造，从而为我所用。例如：AEP（Automated Error Prevention）自动错误预防的概念可以部分地用在我们的测试过程，把每日构建、自动化冒烟测试整合在一起构成初步的AEP框架。
研究类是理论化程度很深东西，或者对于软件测试来讲还不是很成熟很实用的理论。这些理论我们只作了解，不深入研究，更不会去应用它。
对于测试理论，我们要把握学习的度，不要迷失在理论中不能自拔。例如，对于正交表测试用例设计理论，我们只需要了解正交表的基本原理，使用方法，应用范围即可把正交表试验法应用到测试用例的设计中来，而不需要深入探讨正交表的数学原理。
按测试理论涉及的领域分：
1、 测试方法类
2、 项目管理类
3、 开发心理类
测试方法类是我们最需要掌握，也是最常接触的。包括如何进行各种类型的测试，例如安装包测试、用户手册测试、性能测试、GUI自动化测试等等。这些是我们要修炼的“硬气功”。
项目管理类包括测试过程方法、质量管理、配置管理等关系开发人员和测试人员一起工作的管理流程方面的理论，多看看CMM、MSF、RUP等软件过程管理的理论知识，可以让你的测试过程更好地进行，为你的测试争取更好的工作氛围。多点掌握这些知识可能在适当的时候让项目组的其他成员对你刮目相看。这是我们要修炼的“正气心法”。
开发心理类，包括软件过程心理、开发人员心理、测试人员心理、用户心理等。平时多想想，尤其是换位想想，则会使它对你的测试工作如虎添翼。这是我们要修炼的“静心法”。
http://testing.csdn.net/page/d4ad4203-6b28-43f6-b5e7-33a651e8208a
david_wang1984收录，时间：2007-10-25 14:26:38 | 相关网摘，我也收藏
一个家庭主妇在微软当软件测试员，《软件开发的科学与艺术》一书中讲述了这个真实的故事。那位妇女四十多岁了，高中毕业，非常初级的计算机水平还是跟着自己的女儿学到的。让一个大学都没有上过的家庭妇女做测试人员是多么不可思议的事情！不过，她思维独特，怪点子很多，能很快的发现一些问题。微软最终决定聘用她，而她也成为了一名优秀的测试员。
在IT圈里做技术的人群里，测试员可能是一个特殊的群体。他们之中计算机专业 “科班出身”的并不多，毕业于其它专业的大有人在，什么建筑、中文、营销专业的都有。另一方面，相对那些做研究开发、项目管理、软件实施甚至是售前售后技术支持的技术人员，测试工作给人的感觉总是技术性低，因此测试员的薪酬水平与其它同等资历的研发人员相比总有一些差距，甚至在重视测试的外资软件公司也是如此。测试不过是每天重复一些操作来发现Bug（错误）。事实的确如此，哪怕是非常热爱这项职业的人也承认它的枯燥。
H做专业的测试工程师已经有一年多的时间了，目前仍然在做较为底层的测试。有时候也会写写测试需要的代码，但还没有开始设计整个项目测试案例。目前H正在为微软的某一软件做测试，工作的流程非常严谨而明晰，这自然也意味着枯燥的重复。枯燥并没有淹没H的工作激情，发现一个Bug带来很大的成就感，特别是想到每天将会有几百万人通过使用没有这个Bug的软件准确无误的达到他们的目的。
前途在H心目中是非常明朗的，颇有一些“随需”择业的味道。曾经有媒体报道过近来软件测试工程师在职场需求中的风光景况，尽管IT行业的总体需求仍然疲软。在北京和上海等地，测试员的需求量占到了招聘总量的近 1/3。另一方面，H认为从测试员成长为软件项目管理者是更有优势的。例如微软的开发方式本来就是“测试驱动”的，在测试过程中发现了墙角还有没涂到油漆的小块，开发则根据这个思想再补上那一块。测试的经历恰好让人更能从用户的角度来考虑问题，更能深入了解程序开发过程中可能出现的问题，这都是成为一个优秀的项目管理者的必要条件。尽管可能一整天都为了一个小控件“循规蹈矩”地反复测试并撰写测试文档，这样的重复被H当作了重要的积累。H喜欢新东方学校的徐小平新书《骑驴找马》中的一句话：“重复做汉堡，就是麦当劳；重复煮咖啡，就是星巴克；重复教托福，就是俞敏洪；重复做好事，就是活雷锋。”
不过，乐观的情况并不具有普遍性。在另一家软件公司做测试的L对工作感到厌倦。这是一家国内著名软件公司的子公司，整个公司测试员就只有两个人。公司不久前才刚刚把测试作为一个单独的部门划分开，尽管建立了测试管理流程，但是没有代码测试，也没有测试工具。测试案例并没有完全规范化，很多测试都是随机的手工操作。这样的测试部门更像是一个辅助性的、服务性的部门，测试员的收入也比开发人员低一个档次。在这样的工作环境下，L觉得是为了生活而忍受枯燥，最痛苦的是这种得不到锻炼和进步的状况。
L所在公司对测试的态度在国内具有一定的代表性，将测试部门独立都只是最近的事情。更一些公司仍然停留在开发人员自行测试的阶段。可是如果开发者自己能找到Bug，谁还会在开发时犯下这样的错误呢？在软件业发达的国家，软件测试工程师地位丝毫不亚于程序开发员，一些公司对测试员的要求甚至是曾经做过程序开发的。对测试的重视更体现在人员的配置上，以微软Windows 2000产品团队中最主要的三类人员为例，项目经理约250人，开发人员约1700人，测试人员则是3200人左右。
国内软件业的测试员大都与L一样困惑。选择离开并不能解决问题。整个测试环节成熟起来，才将意味着测试员地位的改善
http://testing.csdn.net/page/f768b38c-a2bc-4c91-805e-a79dc6ea7d7e
david_wang1984收录，时间：2007-10-25 14:22:26 | 相关网摘，我也收藏
来源：中国IT实验室
软件测试设计属于“近忧”；软件测试件管理属于“远虑”。测试团队应同时做好这两方面工作，以使测试工作更加高效。
针对某个特定的软件项目而言，测试团队应该如何合理地统筹安排软件测试工作？测试团队在完成一定数量的软件项目测试工作后又该如何快速提升下一软件项目测试工作的水平？这两个问题对于成立不久的软件测试团队而言是很棘手也是很现实的。
做好软件测试设计，排除“近忧”
过度测试会造成测试成本上升，而测试不够又会造成项目中遗留某些重要缺陷。但针对于某个特定的软件项目量身定做相应的软件测试方案是需要足够的技术能力和实战经验的。在软件测试活动的生命周期中，测试设计实际上是对前面所做测试计划进行进一步细化、具体化从而形成针对特定项目的测试策略、测试方案及测试用例的过程。
测试策略设计
测试策略要解决的问题是根据测试需求、资源配备及工程环境，因地制宜剪裁测试技术，形成测试工作的技术路线。对于一个小项目做大测试是得不偿失的，同样，对一个大项目做小测试也是不负责任的。通常，对于工作量小于5个人月的普通商用软件，重点应该抓系统测试（包括功能测试、性能测试及GUI测试等）及验收测试，而不宜铺排开来，面面俱到。而对于一个工作量接近30个人月的中型商用软件而言，一般应该认真完成需求验证、设计验证、单元测试、集成测试、系统测试及验收测试，而不宜只关注系统测试。但这并不绝对，譬如，用户希望软件有好的人机交互界面，这时，就应该考虑采用快速原型生成工具来进行用户界面设计的确认测试; 又如用户希望软件有较好的健壮性，这时，就应该考虑进行相应的负载测试和可恢复性测试。
一个好的测试策略设计应能清楚地回答下列问题：是否在测试成本与测试预期效果之间达到了最佳平衡？是否在测试需求与测试活动安排之间达到了最佳平衡？策略设计形成的技术路线是否在工程实际与企业质量承诺之间达到了最佳平衡？策略设计形成的技术路线是否具有可行性？有无设计依据？
测试方案设计
测试方案是对测试策略设计形成的技术路线的进一步细化。如某一技术路线规定了某小型软件项目测试工作要重点围绕“功能测试与验收测试”展开。那么测试方案设计阶段就必须具体定义哪些功能需要被测试到，以及如何去测试，哪些部分需要做验收，以及采用什么形式做。
测试方案的设计除了要明确定义各个测试活动的对象、执行人员、测试进度、放行标准等一系列属性外，还要充分考虑到成本与技术可行性。一个好的测试方案总是遵循以下设计原则：测试成本与测试工作产生的效益处于最佳比值; 各具体测试活动描述清晰，目标明确，内容完备; 测试手段是可行的; 测试产生的结果是可以用于指导产品质量改进的。
在进行测试方案的具体设计时，常常也暴露出来一些难题和障碍。最常见的就是角色安排多，测试人员少。解决这一问题的根本途径是招募测试人才，建设高效测试团队。然而，远水解不了近渴。那么，就需要考虑一下变通之策：外包和外协都是不错的处理办法。另外，建议适当考虑自动测试工具，某些工具的确能减少工作压力。除了人手的问题，了解测试团队各成员的专业技能也是很重要的，避免无人担当相应角色。除此之外，设计人员还应多多参考软件开发管理类文档，在测试的时间进度安排上与开发保持同步，如果开发进度有变动，应及时调整相应的测试进度安排。
测试用例设计
测试用例设计是对测试方案实现技术部分更为细致描述，相关设计技术已经相对成熟。本文选取了几个有代表性的方法进行介绍。
其中，黑盒测试中常用的等价类划分方法是先把程序的输入域划分成若干区间，然后从每个区间中选取少数代表性数据当作测试用例（由于数量太大，穷举测试一般情况下不可能实现）。在使用等价类划分方法时，通常会涉及到两种等价类：有效等价类和无效等价类。顾名思义，有效等价类就是对程序的规格说明是有意义的合理的输入数据集; 无效等价类就是对程序规格说明书不合理或无效的输入数据集。我们在设计测试用例时，要兼顾这两种情况。同时要注意一个测试用例只能覆盖一个无效等价类。这样便于错误定位，防止一个错误表征掩盖了另一个错误。例如，程序的规格说明中规定了“……每类科技图书10至50册，……”，若一个测试用例为“小说5册”，在测试中很可能只检测出书的类型错误（小说不是科技类图书），而忽略了书的册数错误（5不在10至50之间）。
黑盒测试中另一个常用的测试用例设计方法是边界值分析，它是一种补充等价类划分的测试用例设计技术，它选择一组测试用例检查边界值是否符合相应规格说明。因为输入域的边界比中间更加容易发生错误，所以引进了边界值分析方法往往能发现更多的软件缺陷和错误。
而不管黑盒测试多么全面，它都可能忽略类似于逻辑性错误、潜在破坏性执行流程、冗余程序代码乃至于简单打字错误等，而白盒测试则可以进一步发现它们，查找出代码层次的错误和缺陷。白盒测试用例设计包括的门类也相当繁多，这里限于篇幅不再赘述。
做好软件测试件管理，消除“远虑”
测试件泛指一切手工测试和自动测试活动中必须受控或值得纳入测试团队知识库的所有输入和输出数据，包含团队自主开发的测试自动化工具。如何有效地管理好测试件，是影响测试团队效率与整体水平的重要因素之一。在待测项目规模小、功能点少的情况下，测试工作或许能正常进行。但如果测试团队要同时测试多个项目，各项目规模都相对较大，涉及的测试人员较多时，测试工作的效率可能会大为降低。除此之外，测试件管理对于团队的整体水平提高亦具有不可估量的长远意义，将有代表的测试用例、测试方案等积累起来，可避免团队长时间在一个较低水平上徘徊。
在测试件中，除了测试用例自动化管理、测试缺陷（报告）跟踪管理已经有较好的自动化管理工具外，其他测试件目前尚未发现有对应的专用管理工具，笔者建议采用配置管理工具（如CVS）。
测试用例管理系统
测试用例设计人员需要了解目前已经设计了哪些模块或部件的测试用例，还需要完成哪些设计工作，而测试执行人员需要被明确地告知今天要测试什么，需要执行多少个测试用例。基于这些需求，人们开发了测试用例管理系统，其目的是为了对项目的测试用例的设计、执行及执行结果进行统一管理，提高测试活动的效率。
测试用例管理系统市面上有很多（如微创测试用例管理系统等）。典型的工作流程如下：设置基本参数→登录系统→选择项目→新增模块节点→新增需求→新增测试用例→审核测试用例→新增测试组→新增测试计划→执行测试→测试结果查看→统计分析。该流程涉及到的角色包括测试组长、测试设计人员、测试执行人员、系统管理员、测试评审员等。其中，测试设计人员拥有写入测试用例的权限，测试执行人员负责测试用例的执行，二者是测试用例管理系统的主体。
配置管理
除测试用例、测试缺陷报告之外的测试件均可以使用配置管理的方式进行管理。这里有两个可选择的配置管理方式。一是将测试件的逻辑集合（称为测试件组）作为配置项保存在配置库中。每个测试件组有自己的版本信息，而组成测试件组的各个测试件没有自己的版本信息。测试人员可以根据需要随时从配置库中取出任何版本的测试件组（包含已修改的和未修改的测试件）。由于其操作简单，且出现版本错误的可能性较小，所以适用于配置管理体系不成熟的情况。
另一种方式是把单个的测试件作为配置项，每个测试件有自己的版本信息。这种方式需要在测试件组或多个测试件组上进行基线化。通过基线化操作，方便测试人员能取出对应于不同版本系统的所有测试件。这种方式如果使用不当，可能导致使用的测试件版本错误，所以其适用于有较完善的配置管理体系的情况。
不管采用哪种方式，都要注意控制测试件的更新，但要避免两个或更多的人同时试图修改同一配置项。关于测试件的存放，需要注意的是，必须规定好各测试件在配置库中的物理位置。
测试件的复用与迁移
测试件管理工作的另一个更为重要的价值就在于测试件可以被复用，测试件蕴含的经验和知识可以被后来者获取并迁移到当前项目中。测试团队的整体水平的提高很大程度上在于团队内部知识传递的充分有效。由于测试件管理库记载了各个项目采用的测试技术以及获得的经验教训，这对于团队中的新手而言，是很宝贵的资源，即便是对于从业多年的老手来说，也应该多多参考这个知识库，因为测试件的复用能有效规避重复劳动。另外，建议测试团队负责人通过多种方式，让团队成员多多了解、学习和利用测试件库，鼓励团队成员对测试件提出改进意见。
http://testing.csdn.net/page/ed7ffa7c-951c-44f2-9fea-23af22e57e81
david_wang1984收录，时间：2007-10-25 12:16:16 | 相关网摘，我也收藏
你知道哥德堡号是怎样沉没的吗？07年第8期的《读者》上有篇文章引起了我的兴趣。哥德堡号是18世纪瑞典人的希望：他们需要从海上贸易来充实因为战争而濒临枯竭的国库。建造哥德堡号动用了瑞典当时15%的国内生产总值，船坚炮利不在话下。然而在最后一次返航途中离码头900米的地方撞上了当地人再熟悉不过的一块暗礁，在欢迎人群的注视下满载着从中国运来的瓷器、茶叶和丝绸沉入海底。
你的开发工作中也会有平时再熟悉不过的暗礁：
你不会在工作目录少放一两个文件，特别是开发了半年后；
你不会在调试上个星期的版本的时候，心里以为是最新的版本；
你不会把产品的名字都写错...
是的，谁都不会撞上这样的暗礁。不过考虑一下临交货前一天可能发生的事情：
发现一个小bug，顺手改了一把；
bug都改完了，开始兴冲冲的写下一个版本；
客户发个email来说某些显眼处的标题要改，他们也很抱歉，说是上头今天异想天开...
如果这时候就打包刻盘，明天交货时会发生哪些事情呢？
出现了一些以前出现过的bug，但是dev说早就改好了；
有些问题在自己的环境里面总没法复现出来，客户那边100%出现，直到有一天发现少了个文件；
被问到“为什么这里说的和那里不一致呢？”...
在把发布测试当一回事来抓之前，客户拿到手的产品可能会有这些问题：
产品安装/上线之后不是多了就是少了些东西；
好像是调试版本；
文档和产品不一致；
有些承诺修改过的bug还在...
所有这一切，都源于开发人员和客户关注角度的差别。作为测试人员，应该站在客户的位置上，可惜他们还是开发团队的一部分，往往还是以开发人员的眼光去看bug。发布阶段的bug，拥有许多不一样的地方：
这不是/这里没有客户需要的东西；
这不影响使用，但影响客户的生意（比如把人家的logo都搞错了）；
你会用，但客户不会用；
在你的环境好用，但和客户环境不太兼容；
触了客户的霉头（别笑，你见过主版本号是13的产品吗？）...
成熟的软件工业会进行一系列的发布阶段测试：
安全漏洞测试；
各个语言版本的界面内容（文本，图片，多媒体资源等），用户文档，发布说明的复核，确保没有违反法律和地缘政治文化（想想十字军东征的画面被放在阿拉伯文版里面）；
数字签名校验；
病毒扫描（想想熊猫烧香是怎样传播的）；
再一次基本功能测试。
噢，忘了说为什么哥德堡号撞上暗礁的根本原因：航海多年的水手看见陆地和欢迎人群，兴奋起来所以提早在船上开庆祝party；舵手的位置在二楼，需要甲板上的人指示方向；本来每条船上都有当地向导作为领航员，但是他去参加party了。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1592452
http://blog.csdn.net/papercrane/archive/2007/04/30/1592452.aspx
david_wang1984收录，时间：2007-10-25 12:13:04 | 相关网摘，我也收藏
很久以前看到的一则笑话，有个小bug，不过意思我倒是弄懂了。大意是爱迪生耳朵不好使（实际上是一只耳朵不好使而不是两只），听不到电话铃声；好钻研的朋友为他发明了一套闪光装置，来电话的时候除了铃响还有闪光；问题是就算爱迪生知道有来电，拿起话筒的时候还是什么都听不到。
人们时常会犯类似的错误，付出的代价还不小，事实上在动手之前就应该找到这些问题。软件测试也是一样。千里之行，始于足下。计划和设计阶段的测试，才是测试工作的第一步。人们通常认为的编码结束才开始的测试，已经太晚了。
计划和设计阶段程序员和项目经理分别会非常关心两件事情：技术上如何实现，能否引起客户的使用意欲。那么测试人员会关心什么事情呢？
我的答案是：假设上述事情都能按计划完成，还有什么事情会让产品失败？
你可能会想，还能有什么事情？
我先讲一个别人告诉我的故事：
有个产品是识别纸上指定图案的，技术上没法100％场合都能识别，但还在客户容许范围之内，而且客户也的确相当欢迎这项技术。不过原型出来之后客户反馈相当差，很多人试了几下就不用了。究其原因，一旦识别算法觉得无法识别，比如因为光线、角度等原因，就会弹出一个对话框说识别失败。想象客户被弹了两次之后，还会充满信心的认为这个产品一定能用吗？没有这么自虐的吧？
就是有这么自虐的。想想是谁说没问题啦可以见人的
解决方案也挺简单，只要改用一个温和一点的方式表达“难以识别”，而不是用弹对话框这种方式来打断用户调整光线角度的过程就可以了。
现在你同意还是有一些事情会让产品失败的吧。我们来看看都有哪些。
客户表达的需求，开发团队所理解的需求，以及客户真正使用时的需求，有重大的差别；
完成产品所依赖的条件中，有些现在就知道无法或难以具备；
有导致无法或难以按计划完成的因素。
测试人员在计划和设计阶段的任务之一，就是尽可能找到这些问题。
你可能想，明显的问题谁都看得到，还用得着专人检查吗？事实上大问题不一定明显。我下面要讲的例子就是一个设计阶段成功避免的大问题。
有个设备用于拍摄参加小型会议的所有人，放在桌子中间。用户普遍使用笔记本电脑并通过与设备相连的软件看到网络另一端的与会者的视频。在进行用户场景（user scenario）讨论时测试人员发现了一个问题：笔记本电脑的屏幕把用户的脸挡住了。所以最终定型的设备比最初调高了5厘米。
面对一堆文字描述的测试人员如果不能发现这个问题，后果将会是：大量设备召回，或者流传一个笑话“开会时记得带本厚书”。
你不会愿意成为这种笑话的主角的。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1609200
http://blog.csdn.net/papercrane/archive/2007/05/14/1609200.aspx
david_wang1984收录，时间：2007-10-25 12:08:45 | 相关网摘，我也收藏
陈能技
2007-9-23
原文：Why Do we write a test plan – Ainars Galvans
我们不应该把测试计划写得冗长以致让人畏惧，也不能写得很短以致毫无意义，被忽略。
模板是个好东西，但是模板会把作者的注意力从计划的目标转移-目标会因项目不同而不一样。
计划可以是非常复杂，不精确和耗费时间的过程，但是写出来的测试计划不会把这些反映出来。
计划是关于如何做某样事情的思考。
缺乏计划，授权给大家，依赖他们的技能、承诺、团队协作，这不仅不是银弹，而且有很多缺点。例如，没有历史记录的保持，更难衡量和评估每个人的工作成绩。
测试计划通常作为关于质量的重要文档呈现给管理层。项目的4个因素由不同的文档来覆盖：时间-由项目计划覆盖，成本-由合同覆盖，范围-由需求文档覆盖，质量-由QA计划或测试计划覆盖。
测试计划的内部作用和外部作用。外部是给顾客一个信心，关于测试过程、技能、资源、工具等的信息。
内部作用有3个：
作为测试计划的结果，让相关人员和开发人员来评审。
存储计划执行的细节，让测试人员来进行同行评审。
存储计划进度表、测试环境等更多的信息。
http://testing.csdn.net/page/b2603c2f-f0c1-4189-a4e4-488a263e8741
david_wang1984收录，时间：2007-10-25 12:05:54 | 相关网摘，我也收藏
来源：51Testing软件测试网
软件测试工程师是软件行业中一种即年轻又古老的职业，进入二十一世纪以来，随着中国加入WTO以后，从事这项职业的人也越来越多。一个公司在组建一个测试队伍的时候如何分配人员结构，从而使公司软件测试工作水平得到提高，是大家比较关注的问题。本人依照自己的经验提出自己的观点：
我们首先来看一下测试人员的纵向结构
1、测试经理
测试经理主要负责测试队伍的内部管理以及与其他外部人员，客户的交流，详细说来主要包括进度管理，风险管理，资金管理，人力资源管理，交流管理等等，测试经理需要具有项目经理的知识和技能。同时测试工作开始前项目经理需要书写《测试计划书》，测试结束需要书写《测试总结报告》
2、测试文档审核师
测试文档审核师主要负责前置测试，包括在需求期与设计期间产生的文档进行审核，比如《业务建模书》，《需求规格说明书》，《概要设计书》，《详细设计书》等等。审核需要进行书写审核报告。当文档确定后，需要整理文档报告，并且反映介绍给测试设计师。
3、测试设计师
测试设计师主要根据需求期与设计期间产生的文档设计各个测试阶段的测试用例。（往往测试文档审核师，测试设计师可以有相同的一组人来完成）
4、测试工程师
测试工程师按照测试用例，来完成测试工作。
但是测试人员应该有哪些人来组成呢？也就是测试人员的横向组成，让我们再来讨论讨论：
1、需要具有一定开发经验的计算机专业人员
由于具有一定开发经验的计算机专业人员即懂得计算机的基本理论，又有一定的开发经验。所以对于软件中哪里容易出错，哪里不容易出错他们了如指掌；他们可以分析程序的性能，软件性能差是否是占有内存空间太多，或者是占有CPU时间太多引起的，还是其他原因，他们往往是专家。尤其是进行非功能测试的时候，他们可以更好的搭建系统测试平台。这种人员应该占测试队伍中一半以上。
2、需要具有本软件业务经验的人员
测试队伍中需要有这样的人员的目的在于，这些人员由于对业务非常熟悉，软件质量的前提又是满足用户的需求。专业业务知识是计算机专业人员达不到的，所以这方面人才可以利用它们的业务知识和专业水平，参与系统需求期间的文当审核，可以发现软件中存在的业务性错误。比如专业用语不准确，业务流程不规范等等，这种人才对于专业性比较强的软件测试工作尤为重要，比如税务，法律，艺术，CAD,CAM…
3、只需要会操作计算机的人员
由于软件一旦卖出去之后，使用软件的人各种各样，各种各样的人带来各种各样的操作情况，请一大部分人员在软件测试工作后期进行测试工作是十分重要的，他们往往会发现专业测试人员测试不出的东西和一些希奇古怪的错误。这就是软件测试学中所谓的猴子测试法。
对于一个软件公司来说，并不是说所有的测试队伍都需要这三种人员，实际中可以一组人代替多个角色，但是要遵循以下原则：
1、对于业务不是很专业的软件，具有一定开发经验的计算机专业人员与具有本软件业务经验的人员可以合并；
2、只需要会操作计算机的人员，可以由公司行政人员来充当。
http://testing.csdn.net/page/344296b2-a36c-42a2-b52e-a23db288dc4c
david_wang1984收录，时间：2007-10-25 12:00:13 | 相关网摘，我也收藏
来源：无为 - BlogJava
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
本文将 web 测试分为 6 个部分：
1. 功能测试
2. 性能测试（包括负载/压力测试）
3. 用户界面测试
4. 兼容性测试
5. 安全测试
6. 接口测试
本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。
1 功能测试
1.1 链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
采取措施：采用自动检测网站链接的软件来进行。
推荐软件：
Xenu Link Sleuth 免费 绿色免安装软件
HTML Link Validator 共享（30天试用）
1.2 表单测试
当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3 数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。
1.4 cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。
采取措施：
1 采用黑盒测试：采用上面提到的方法进行测试
2 采用查看cookies的软件进行（初步的想法）
可以选择采用的软件
IECookiesView v1.50
Cookies Manager v1.1
1.5 数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
采取措施：暂时没有更好的测试方法
考虑结合到1.2和1.3的测试中
1.6 应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
采取措施：深刻理解需求说明文档
1.7 设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
暂时没有方法测试，可以多参考一点讨论组内的更新信息
2 性能测试
2.1 连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
2.3 压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。
每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?
长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
采取措施：采用测试工具WAS、ACT协助进行测试
3 用户界面测试
3.1 导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2 图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到 30k 以下
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。
3.3内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。
3.4 表格测试
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?
3.5 整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
采取措施：手动测试，参与人员最好有外部人员
4 兼容性测试
4.1 平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
4.2 浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
4.3 分辨率测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?
4.4 Modem/连接速率
是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。
4.5 打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。
4.6 组合测试
最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。
采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵
5 安全测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5.1 目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
5.2 SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
5.3 登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
5.4 日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
6 接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到
6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。
7 结论
无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。
http://testing.csdn.net/page/dcb60329-c646-4630-9ac6-5dbef1733b56
david_wang1984收录，使用标签：难题，时间：2007-10-25 11:47:01 | 相关网摘，我也收藏
质量衡量标准 (标尺)
可清晰量化的衡量产品质量
测试覆盖率-代码块覆盖,功能覆盖,用例覆盖.... 这么多覆盖率,每个覆盖率,合理的目标是多少? 50%? 80% 100%
按照找到的缺陷数目,多少是被用户找到的,多少是被内部非测试团队找到的,多少是被测试团队找到的,以此为衡量质量的标尺之一?
重复发生的回归性缺陷数目
补丁和Service package数量,来衡量质量
我们有这么多可以用来衡量质量的标准,那么,哪些应该是核心的标准,最重要的普遍标准.怎么把各个标准和质量关联上?
制定发布的质量指标,怎样才是正确的指标,可以指导我们决定发布还是延迟发布产品直到我们达到该指标.
怎么定义测试效率?包括怎么衡量s变化对测试的影响..
怎么定义测试"完成"了?
复杂领域产品测试:
音频和视频质量测试
"看起来效果对吗?"
"听起来效果对吗?"
效果"好"吗?
各种主观类型的测试判断
测试工具对系统本身的影响(测不准原理?):
性能测试工具本身对机器性能的影响所导致的测不准效果.
测试要素的各种组合(测试范围庞大):
测试要素组合, 覆盖各种可能组合,将变得庞大: 操作系统 vs. 调试/发布 vs. 硬件配置 vs. 各种语言 vs. etc. vs. etc.
无穷无尽的用户可能输入.
有时间相关性的产品的测试.各种时间可能的穷举是无限的.
整个产品范围测试中的问题
整个产品的压力测试
这个产品性能测试 vs. 各个开发组对自己模块所作的性能测试
集成测试.
测试集优选:
由时间和进度影响决定?
由用户影响决定?
由平均测试用例所找到的缺陷数决定? (或者考虑其他投资回报因素而决定)
挑选测试用例覆盖了所更改的代码,依此决定?
由所要测试的代码复杂度决定?
项目计划安排:
准确估计测试所需要的时间.
测试团队如何参与决定项目整体进度计划.
敏捷快速迭代测试的计划安排.
测试对项目的影响:
争取修复缺陷– i.e. 比如要求开发组修复缺陷,而他们回答"没人会这么做!", 这个时候怎么有理有据的坚持要求修复缺陷.
设计阶段的测试团队参与 – 可测试性的分析/设计.
是否该拥有对发布/不发布的决策的影响.
测试自动化:
自动化测试用例的后期维护梦魇.
怎么模拟人眼人耳来做自动化测试(音频/视频测试)
产品代码中缺乏足够的接口来支持自动化测试(比如开发人员自己画出来的控件)
模拟N用户操作的自动化测试(N非常大)
模拟真实的用户-- [随机的用户行为]
集成测试:
集成测试中的自动化测试
调试的责任,谁做集成测试,谁负责调试整个产品中的问题?
集成测试应该包含哪些测试用例?
其他普遍的难题:
几个版本发布之后,积累的测试代码变得臃肿和难以维护.
设计不好的测试代码,重复的测试代码,各个测试自动化队伍之间缺乏总体的设计和架构避免冗余工作
冗余的测试用例
留住有经验的测试人才
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1646233
http://blog.csdn.net/omomo/archive/2007/06/10/1646233.aspx
david_wang1984收录，使用标签：the, risk, of, regression，时间：2007-10-25 11:46:25 | 相关网摘，我也收藏
陈能技2007-10-11
原文：The Risk of Regression – Alan S.Koch
“但是，它仅仅是一个很小很小的改动！我们怎么会预先想到它会造成这么大的问题？”
怎么会，确实！
回归（向后追溯）是软件系统的现实生活。即使之前是很好地工作的，但是不能确保它会在最近的“很小”的改变后也能工作。是的，模块设计和充分的系统架构可以减少这种问题的出现，但是不能完全消除。
回归测试是永远都需要的。但是我们在非常有限的时间里测试一个“很小”的改动，我们怎么进行充分的回归测试呢？我们怎么知道查找哪些方面？我们怎么减少出现问题的风险？
回归的问题
回归的问题根源是软件系统的内在复杂性。随着系统的复杂性的增加，更改产生难以预见的影响的可能性也增加了。即使开发人员使用最新的技术也不可避免。
随着系统构建的时间越长回归的问题也会增多。在几年后，可能已经被更改了很多次，通常是由那些原本不在开发组中的人来修改的。即使这些人努力理解底层的设计和结构，更改与原本设计主题思想非常匹配也是很难做到的。这样的更改越多，系统变得越复杂直到变得非常脆弱。
脆弱的软件就像脆弱的金属。被弯曲和扭转了这么多次以致你对它做的任何事都可能导致它的破裂。当一个软件系统变得脆弱，人们实际上会很害怕改变它。他们知道他们做的任何事情都可能导致更多的问题。易脆（不可维护）是旧的软件系统被替换的主要原因之一。
回归测试的困难
因为任何系统都需要回归，所以回归测试非常重要。但是谁有时间对每一个小的更改都完全地重新测试系统呢？对一个只是1周多点的开发，我们肯定不能承受1个月的完全重新测试整个系统。我们有一个星期的时间测试就很幸运了；更通常的情况是，只允许几天的时间。
既然完全的重测不可能，我们必须决定如何使用很好的时间来进行测试。但是我们怎么知道怎么做呢？我们怎么预见这些不可预见的问题呢？（就像老板要求你把这些会出现的意外情况做个列表一样可笑！）
现实中，我们总是有测试压力，即使当测试一个新的系统时。总是不够时间去完成所有应该完成的测试，因此我们必须充分利用可用的时间，用最好的方法去测试。我们在这种情况下我们必须使用“基于风险的测试方法” 。
基于风险的测试
基于风险的测试的本质是我们评估系统不同部分蕴含的风险，并专注于我们的测试在那些最高风险的地方。这个方法可能让系统的某些部分缺乏充分的测试，甚至完全不测，但是它保证了这样做的风险是最低的。
“风险”对于测试与风险对于其他任何情况是一样的。为了评估风险，我们必须认识到它有两个截然不同的方面：可能性和影响。
-“可能性”是可能出错的机会。不考虑影响程度，仅仅考虑出现问题的机会有多大。
-“影响”是确实出错后造成的影响程度。不考虑可能性，仅仅考虑出现的问题的情况会有多糟糕。
假设一个会计系统，我们更改了分期付款的利息。更改会用3天的时间，我们会用2天的时间来测试。因为我们不能在两天时间内完全充分测试这个会计系统，我们需要评估所作的更改给其它系统部分带来的风险。
-分期付款模块的功能会很可能出错，因为这些是更改的部分。它们同时是对系统来说相对影响重大的部分，因为它们影响收入。既是高可能性的，又是高影响程度的，意味着系统的这部分必须投入充分的测试。
-应收款模块拥有中等程度的错误可能性，因为改变的功能是这个模块的一个紧密组成部分。因为收款模块影响收入，因此出错的影响程度是高的。所以收款模块也需要投入足够的测试关注，因为它拥有中-高程度的风险。
-总账模块拥有低程度的错误可能性。但是如果错误会对公司有重大的影响。因此总账模块拥有低-高程度的风险。
-最后，应付款出错的可能性很低，因为更改功能与它没有什么关系。而且这个模块错误后的影响最多也是中等程度的。因此拥有低-中程度风险，不需要投入太多的测试。
使用这些风险信息，我们可能选择这样分配我们的测试：
-50%的测试专注于新改的分期付款模块
-30%的测试放在应收款模块
-15%的测试放在总账模块
-5%的测试时间放在应付款模块
使用基于风险的测试策略不能保证没有回归。但是会显著地减少对一个大系统进行的小更改的风险。
http://testing.csdn.net/page/5bb9fe49-8756-42d6-8de0-da4dc3d6e49c
david_wang1984收录，使用标签：徐宏革-X模型介绍，时间：2007-10-25 11:40:43 | 相关网摘，我也收藏
来源：徐宏革的软件测试教育专栏 - CSDNBlog
X模型的基本思想是由Marick提出的，但首先是Marick不建议要建立一个替代模型。Robin F·Goldsmith引用了一些Marick的想法，并重新经过组织，形成了“X模型”。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（exploratory testing）这样的亮点。
Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。
Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。
由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而V模型也并没有限制各种创建周期的发生次数。
Marick和Graham都一致认同，应该在执行测试之前进行测试设计。Marick建议：“在你掌握相关知识时进行设计，在你手头有交付内容时进行测试。”X模型包含了测试设计的步骤，就象使用不同的测试工具所要包含的步骤一样，而V模型没有这么做。但是，Marick的例子提示，X模型在这层意义上看也并不是一个真的模型，取而代之的是，应该允许在任何时候选择使用测试设计步骤。
Marick对V模型提出质疑，也因为V模型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。
尽管很多项目缺乏足够的需求，V模型还是从需求处理开始。V模型提示我们要对各开发阶段中已经得到的内容进行测试，但它没有规定我们要取得多少内容。如果没有任何的需求资料，开发人员知道他们要做什么吗？我主张在X模型和其它模型中都需要足够的需求并至少进行一次发布。虽然在没有模型的情况下也必须正常工作，但一个有效的模型，可以鼓励很多好的实践方法的采用。因此，V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。
Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。我已经尽自己的努力把Marick的关于需要很多具有可伸缩性的行为的期望结合进了X模型，这样，X模型并不要求在进行作为创建可执行程序（图中右上方）的一个组成部分的集成测试之前，对每一个程序片段都进行单元测试（图中左侧的行为）。但X模型没能提供是否要跳过单元测试的判断准则。
X模型填补了V模型和X模型的缺陷，并可为测试人员和开发人员带来明显的帮助。
http://testing.csdn.net/page/283ab949-f530-42c5-96fb-883c3c8372f1
david_wang1984收录，使用标签：前置测试模型，时间：2007-10-25 11:39:40 | 相关网摘，我也收藏
来源：徐宏革的软件测试教育专栏 - CSDNBlog
前置测试模型是由Robin FGoldsmith等人提出的，是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以使你的项目加快速度。
前置测试模型体现了以下的要点：
（一）开发和测试相结合
前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。并且表示了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的可能性就会因此而有所降低。如果有业务需求，则系统开发过程将更有效率。在没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计和开发之前就被正确定义。
（二）对每一个交付内容进行测试
每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是唯一需要测试的内容。在图中的绿色框表示了其它一些要测试的对象，包括可行性报告、业务需求说明，以及系统设计文档等。这同V模型中开发和测试的对应关系是相一致的，并且在其基础上有所扩展，变得更为明确。
前置测试模型包括2项测试计划技术:
其中的第一项技术是开发基于需求的测试用例。这并不仅仅是为以后提交上来的程序的测试做好初始化准备，也是为了验证需求是否是可测试的。这些测试可以交由用户来进行验收测试，或者由开发部门做某些技术测试。很多测试团体都认为，需求的可测试性即使不是需求首要的属性，也应是其最基本的属性之一。因此，在必要的时候可以为每一个需求编写测试用例。不过，基于需求的测试最多也只是和需求本身一样重要。一项需求可能本身是错误的，但它仍是可测试的。而且，你无法为一些被忽略的需求来编写测试用例。
第二项技术是定义验收标准。在接受交付的系统之前，用户需要用验收标准来进行验证。验收标准并不仅仅是定义需求，还应在前置测试之前进行定义，这将帮助揭示某些需求是否正确，以及某些需求是否被忽略了。
同样的，系统设计在投入编码实现之前也必须经过测试，以确保其正确性和完整性。很多组织趋向于对设计进行测试，而不是对需求进行测试。Goldsmith 曾提供过15项以上的测试方法来对设计进行测试，这些组织也只使用了其中很小的一部分。在对设计进行的测试中有一项非常有用的技术，即制订计划以确定应如何针对提交的系统进行测试，这在处于设计阶段并即将进入编码阶段时十分有用。
（三）在设计阶段进行计划和测试设计
设计阶段是做测试计划和测试设计的最好时机。很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之间才飞快地完成测试计划和设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。
测试有2种主要的类型，这2种类型都需要测试计划。在V模型中，验收测试最早被定义好，并在最后执行，以验证所交付的系统是否真正符合用户业务的需求。与V模型不同的是，前置测试模型认识到验收测试中所包含的3种成份，其中的2种都与业务需求定义相联系：即定义基于需求的测试，以及定义验收标准。但是，第三种则需要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成，这些定义包括：如何判断验收标准已经达到，以及基于需求的测试已算成功完成。
技术测试主要是针对开发代码的测试，例如V模型中所定义的动态的单元测试，集成测试和系统测试。另外，前置测试还提示我们应增加静态审查，以及独立的QA测试。QA测试通常跟随在系统测试之后，从技术部门的意见和用户的预期方面出发，进行最后的检查.同样的还有特别测试。我们取名特别测试，并把该名称作为很多测试的一个统称，这些测试包括负载测试、安全性测试、可用性测试等等，这些测试不是由业务逻辑和应用来驱动的。
对技术测试最基本的要求是验证代码的编写和设计的要求是否相一致。一致的意思是系统确实提供了要求提供的，并且系统并没有提供不要求提供的。技术测试在设计阶段进行计划和设计，并在开发阶段由技术部门来执行。
（四）测试和开发结合在一起
前置测试将测试执行和开发结合在一起，并在开发阶段以编码-测试-编码-测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。普通情况下，先进行的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。但也可参考X模型，即一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。对于一个特定的程序片段，其测试的顺序可以按照V模型的规定，但其中还会交织一些程序片段的开发，而不是按阶段完全地隔离。
在技术测试计划中必须定义好这样的结合。测试的主体方法和结构应在设计阶段定义完成，并在开发阶段进行补充和升版。这尤其会对基于代码的测试产生影响，这种测试主要包括针对单元的测试和集成测试。不管在哪种情况下，如果在执行测试之前做一点计划和设计，都会提高测试效率，改善测试结果，而且对测试重用也更加有利。
（五）让验收测试和技术测试保持相互独立
验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行，也可以在开发阶段的最后一步执行。
前置测试模型提倡验收测试和技术测试沿循2条不同的路线来进行，每条路线分别地验证系统是否能够如预期的设想进行正常工作。这样，当单独设计好的验收测试完成了系统的验证, 我们即可确信这是一个正确的系统。
（六）反复交替的开发和测试
在项目中从很多方面可以看到变更的发生，例如需要重新访问前一阶段的内容，或者地跟踪并纠正以前提交的内容，修复错误，排除多余的成分，以及增加新发现的功能，等等。开发和测试需要一起反复交替地执行。模型并没有明确指出参与的系统部分的大小。这一点和V模型中所提供的内容相似。不同的是，前置测试模型对反复和交替进行了非常明确的描述。
（七）发现内在的价值
前置测试能给需要使用测试技术的开发人员、测试人员、项目经理和用户等带来很多不同于传统方法的内在的价值。与以前的方法中很少划分优先级所不同的是，前置测试用较低的成本来及早发现错误，并且充分强调了测试对确保系统的高质量的重要意义。前置测试代表了整个对测试的新的不同的观念。在整个开发过程中，反复使用了各种测试技术以使开发人员、经理和用户节省其时间，简化其工作。
通常情况下，开发人员会将测试工作视为阻碍其按期完成开发进度的额外的负担。然而，当我们提前定义好该如何对程序进行测试以后，我们会发现开发人员将节省至少20%的时间。虽然开发人员很少意识到他们的时间是如何分配的，也许他们只是感觉到有一大块时间从重新修改中节省下来可用来进行其它的开发。保守地说，在编码之前对设计进行测试可以节省总共将近一半的时间，这可以从以下方面体现出来：
针对设计的测试编写是检验设计的一个非常好的方法，由此可以及时避免因为设计不正确而造成的重复开发及代码修改。通常情况下，这样的测试可以使设计中的逻辑缺陷凸显出来。另一方面，编写测试用例还能揭示设计中比较模糊的地方。总的来说，如果你不能勾画出如何对程序进行测试，那么程序员很可能也很难确定他们所开发的程序怎样才算是正确的。
测试工作先于程序开发而进行，这样可以明显地看到程序应该如何工作，否则，如果要等到程序开发完成后才开始测试，那么测试只是查验开发人员的代码是如何运行的。而提前的测试可以帮助开发人员立刻得到正确的错误定位。
在测试先于编码的情况下，开发人员可以在一完成编码时就立刻进行测试。而且，她会更有效率，在同一时间内能够执行更多的现成的测试，她的思路也不会因为去搜集测试数据而被打断。
即使是最好的程序员，从他们各自的观念出发，也常常会对一些看似非常明确的设计说明产生不同的理解。如果他们能参考到测试的输入数据及输出结果要求，就可以帮助他们及时纠正理解上的误区，使其在一开始就编写出正确的代码。
前置测试定义了如何在编码之前对程序进行测试设计，开发人员一旦体会到其中的价值，就会对其表现出特别的欣赏。前置方法不仅能节省时间，而且可以减少那些令他们十分厌恶的重复工作
http://testing.csdn.net/page/5b9d6783-07eb-4876-adbb-65125c76441e
david_wang1984收录，使用标签：V, W, X, H, 前置模型五种测试模型，时间：2007-10-25 11:38:42 | 相关网摘，我也收藏
前几篇的文章里介绍了5种典型的测试模型，这些模型对指导测试工作的进行具有重要的意义。但任何模型都不是完美的。应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则就没有实际意义。
在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地指出应该对软件的需求、设计进行测试，而这一点在W模型中得到了补充。W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试，但W模型和V模型一样也没有专门针对软件测试的流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发部的组织，就每一个软件测试的细节而言，它都有一个独立的操作流程。 比如，现在的第三方测试，就包含了从测试计划和测试用例编写，到测试实施以及测试报告编写的全过程，这个过程在H模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始进行测试了。当然，X模型和前置测试模型又在此基础上增加了许多不确定因素的处理情况，因为在真实项目中，经常会有变更的发生。
在实际工作中，要灵活地运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立地测试，并同时将测试和开发密切结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。
http://testing.csdn.net/page/b3ba50ef-a968-4504-94c2-174c7fe366d9
david_wang1984收录，时间：2007-10-25 11:34:50 | 相关网摘，我也收藏
来源：51Testing软件测试网
软件测试是软件开发的重要、必要部分，是通过找出缺陷和问题评估产品质量并间接改进产品质量的手段。从软件工程的观点看，预防程序问题要比改正问题重要得多，因此，必须首先把软件测试看做是检验预防程序错误的机制是否有效的主要手段，同时又是找出程序异常的手段。
从一段对话谈起
甲、乙、丙三人对“所有奇数都是质数”这个假设进行测试。
甲说：“3是质数，5是质数，7是质数。看起来这个假设没错。”
乙说：“3是质数，5是质数，7是质数，9是质数，11是质数……”
丙说：“错！9就是一个非质数奇数。”
软件测试就是从一个错误陈述（“系统能正常运行”）开始，从无限种可能中选出与该陈述矛盾的输入。必须避免甲犯过的错误（没有验证合适的值），也要避免犯乙犯过的错误（验证了合适的值，但是没有发现矛盾之处），需要像丙那样，用最小工作量找出合适的反例。
IEEE把软件测试定义为:从通常是无限大的执行域中恰当地选取一组有限测试用例，对照程序已经定义的预期行为，动态地检验程序的行为。
从这个定义可以看出软件测试的四个特点：首先是“动态”，软件测试总要通过一组输入执行程序。但是，单靠输入值并不总能充分地确定一个测试，因为对于复杂、非确定的系统，由于系统会处于不同的状态，因此对于同样的输入可能产生不同的响应。所以，特定的输入通常还要指定系统的特定状态。其次是“有限”，在测试中实际能够观察的执行数量是有限的。测试永远都意味着有限资源和计划进度与本质上是无限测试需求之间的折衷：正是这种矛盾带来了大家经常提到的技术（测试充分性评判准则）和管理（测试工作量估计）两个方面的测试问题。接着是“选取”，很多测试手段的本质区别就是如何选择有限的测试集。针对特定条件确定最合适的选取准则是一个非常复杂的问题，在实践中需要运用风险分析技术和测试工程专门知识。最后是“预期”，必须能够确定所观察到的程序执行输出是不是可接受的，否则测试工作就是无用的。
软件测试通常要在不同层次上执行，大体上划分为三大阶段：单元测试、集成测试和系统测试。单元测试检验独立软件模块的机能，软件模块可以是独立子程序，也可以是由紧密相关的数个单元组成的较大构件，单元测试一般需要对被测代码进行访问并借助调试工具的支持，并且可能需要被测代码编程人员的介入; 集成测试检验系统各部件间的交互性。经典的集成测试策略有自顶向下或自底向上两种，用于传统的、分级的结构化软件系统。现代的集成测试策略更多是结构驱动的，这意味着对软件部件或子系统的集成是基于确定的功能线程，因此集成测试是一个连续活动，在每一阶段测试人员必须抽象出低一级的情况并集中于正在处理的这一级的状况; 系统测试关注的则是整个系统的行为，它需要将系统与非功能性系统需求进行比较，非功能性系统需求指系统的安全性、速率、精确性、可靠性等。系统与其它软件、应用程序、硬件设备或操作环境的外部接口评估也在系统测试中进行。
测试技术分类
从软件生产发达国家来看，20世纪60年代，软件测试主要以代码调试为主；70年代主要以演示软件系统的正确性为主；80年代到90年代中期，主要以检查程序错误为主；90年代中期以后，软件测试开始更注重软件质量特性的整体评估。目前软件测试最主要的目标是评估软件功能，但一般也要测试软件的非功能属性。
目前应用于软件测试领域的技术有很多，而且差别很大，大致有两种分类方法。
第一种是按测试的生成来源划分，即基于测试人员的直觉和经验（即兴测试）、需求规格说明（包括等价类划分、边界值分析、判定表、基于有限状态机、形式化语言转换和随机测试等）、代码结构（基于流程图、调用关系图等参考模型、基于控制流标准、基于数据流的标准）、发现的错误（以过去经验为基础的错误推测法、增加一个被测程序变种的变异测试）、被测程序的使用领域（操作剖面、软件可靠性工程测试）和被测程序类型（面向对象、基于构件、网站、GUI、并发程序、协议一致性、分布式系统、实时系统、科学计算软件测试）的测试技术。
第二种是经典的分类方法，即黑盒测试和白盒测试。依赖于被测软件设计及编码信息进行的测试称为白盒测试（基于代码测试的参考模型、基于控制流标准、基于数据流标准和变异测试等），只依靠被测软件输入/输出行为而没有关于输入/输出之间信息状况的测试称为黑盒测试（等价类划分、边界值分析、判定表、基于有限状态机、源于形式化需求规格说明、错误推测法、随机测试、操作剖面和软件可靠性工程测试等）。
在实际测试中，往往综合采用这些技术。
测试过程有章可循
过程是一组把输入转换为输出的相关活动。不同层次上的测试活动必须与人员、工具、政策、度量一起组织于一个良定义的过程中，这一过程是软件生命周期的完整组成部分。测试过程需要加以控制并进行持续改进。
软件测试过程的决定性因素是人。对于成功的测试来说，一个必要条件是人员对测试活动所采取的积极和相互协作的态度。另外，应该使软件产品涉及的所有人员都认识到：及早发现软件错误是大家共同的目标，而不仅仅是测试人员的责任。
文档是测试过程规范化的一个完整组成部分。IEEE 829完整描述了各种测试文档、文档间关联及文档与测试过程间的关联。测试文档包括测试计划、测试设计说明、测试过程说明、测试案例说明、测试日志和测试事件或问题报告等。用于测试过程控制与改进的度量包括:设计的测试用例数、执行的测试用例数、通过的测试用例数、失败的测试用例数等。
测试管理的一个关键性任务是决定什么样的测试是充分的，某个测试阶段何时可以终止。对此，充分性度量和错误密度估价、操作可靠性评估都可提供有益支持，但只有这些还不充分。决策还应考虑潜在的遗留失效可能造成的损失和风险，并将之与进一步测试所需成本进行对比。为使测试和维护工作有组织、成本效益高，应将各测试手段系统化地加以重用。为此，应在测试的各个层次，对测试脚本、测试用例和预期结果进行精心定义并记录。
用于特定环境、特定类型程序的测试方案，以及决策动机，构成了测试模式。测试模式本身也可文档化，并可重用于以后的类似项目。
http://testing.csdn.net/page/68a2ad39-cc64-48c5-a245-19ac00e8bb7f
david_wang1984收录，时间：2007-10-25 11:33:59 | 相关网摘，我也收藏
陈能技
2007-9-10
原文：Building Better Test Teams – Johanna Rothman
不管你是在组建一个项目组还是在组建一个测试组，你都需要发现你认为能干的测试员是否如你所愿地能干。
不仅仅要考虑测试，还要考虑这份工作所需要的技能：
1、 选择满足项目的测试技能
2、 适应项目的条件（在项目中改变测试或测试技巧的能力）
3、 在项目过程中评估和报告风险
4、 知道什么时候继续工作，什么时候转移到其他地方
5、 对测试员认为应该在发布前修正的缺陷进行建议修改
6、 编写好的缺陷报告
这里是一些你可以在判断你的测试应聘者是否适合你的项目组的问题，尤其是应聘者之前没有在与你类似的项目组工作过。
选择测试技术
“在你最近的项目中，你是如何决定使用某个测试技术的？”（等待这个测试员的回答）“告诉我关于项目的事情，还有你是怎样做出你的决定的。”随后的问题是，“你是否曾经工作在一个项目，在里面你所选择的技术没能帮助你评估产品？为什么？”最后的问题可以是，“你学到了什么技术是可以应用到你的工作中去的？”
适应性
“你是否碰到过在测试过程中需要改变调整的情况？你是怎样做的？是什么情况导致了要改变？”（确保等待每个问题的回答，清楚地得到每个问题的答案）。
尤其是当我要招聘的是高级测试员，我需要的是那些碰到问题并且能有效解决问题的人。
风险管理
“在你最近的项目中出现过什么风险没有？你能否预料到这些风险？你计划了什么风险措施？最近一次感到惊讶的风险是什么？”（在你倾听这些回答时，允许你自己调整问题的顺序，或基于测试员的答案调整问题。）
风险总是会出现，最好的解决方法是管理并风险提前计划。如果你知道什么是令测试员惊讶的风险，则了解到了他的风险意识的盲点。如果一个测试员很久没有对风险感到惊讶了，我会认为他没有为他所在的团队的成功很好地工作。
改变任务
“你是如何完成你最近的项目的？你能否完成你要做的所有测试？你怎样权衡这些测试要不要做？是否有中间过渡的交付？他们是什么？”
我需要知道这个测试员是否考虑了测试产生的各种信息，是否应用什么方法来判断测试的进展情况。我想知道他在什么时候会坚持工作，什么时候会转移到其他工作任务。
促进BUG的修改
“你是否曾经要求开发人员修改某个缺陷？最近一次是什么时候？你怎样做的？最终发生了什么事情？”
促进BUG的修改不是一个技术性的问题，但是会对项目造成重大的影响。
编写好的缺陷报告
我通常不直接问测试员他写缺陷报告的能力如何，我使用审核的方式。在一个正在开发的项目或一个存在缺陷的产品，要求这个测试员用20-30分钟去测试这个产品。给他几张白纸，让他把测试发现的缺陷写在上面。最后我们一起来看缺陷报告，并让这个测试员解释。我会从这些缺陷报告中判断测试员的缺陷报告能力。
另外，我还会问应聘者快速学习的问题，例如“你是否曾经到了一个项目，里面的人你完全不认识的？你是怎样做的？”如果应聘者没能很快地学习，那么你也不敢确定他是否能很快地学习需要的技能。如果应聘者能很快地在不同的环境学习，则判断那个环境是否与你的项目相近。然后判断这个应聘者是否能适应你的项目。
这些行为描述（behavior-description）的问题和审核能帮助你发现一个测试员是否适合你的项目。
如果你需要的是更好的测试员，则寻找他的类似的经验和跨越学习曲线的能力。确保你了解他之前所在的项目的方方面面，帮助你决定应聘者能否很好地完成相关的工作。
剔除招聘的风险。把测试和审核加入到你的面试流程中会帮助你构建更好的团队
http://testing.csdn.net/page/cfecda55-5040-4807-ac81-50b2b204618a
david_wang1984收录，时间：2007-10-25 11:26:15 | 相关网摘，我也收藏
单元测试的测试数据可以用两个基本的方法系统地构建：白盒测试与黑盒测试。白盒测试需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能；而黑盒测试是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。这一白一黑两种测试，各有其优缺点，同时也是相辅相成的两种方法。
本专题就对这两种测试方法的相关文章进行了整合，希望能对测试人员有所帮助。
·概念及其相关内容
◇白盒测试与黑盒测试
本文首先介绍了白盒测试与黑盒测试的概念，然后分别讨论了两种测试的可行性。作者提出：“在使用将尽可能多揭示错误的技术的同时，没有方法保证已经检测出全部错误，一个继续下去的合理的办法是首先使用黑盒测试用例，然后使用白盒测试开发额外的测试用例。”
◇白盒测试&黑盒测试
这篇文章全面介绍了两种测试技术各自的应用领域，测试环境，适用语言等等，清楚地讲解了两种测试方法的优缺点。虽然文章略显散乱，但是非常全面，值得研究。
·黑盒测试
◇黑盒测试方法揭密
在对软件的质量监督中，黑盒测试起着重要的作用；而随着软件开发平台及软件设计思想的进步和发展，特别是rad技术的发展，对黑盒测试提出了更明确的要求，人们发现，必须遵循一定的测试理论，依赖于优秀的测试工具，才能进行科学、完备的测试。
◇黑盒测试
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
·白盒测试
◇白盒测试的六种覆盖准则
对于不同复杂度的代码逻辑，可以衍生出许多种执行路径，只有适当的测试方法，才能帮助我们从代码的迷雾森林中找到正确的方向。本文介绍六种白盒子测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
◇白盒测试的六种覆盖准则
白盒测试做不好，已成为众多嵌入式厂商在质量保证活动中最难克服的焦点问题，主要表现在两方面：一是嵌入式领域的白盒测试缺少合适的方法论指导，二是缺少有效的测试工具。本文就讨论了嵌入式白盒测试的现状与问题，并提出了解决方法。
◇静态白盒测试技术
◇动态白盒测试技术
技术的提升是永无止境的，要想成为一个优秀的测试人员，在掌握技术的同时，也需要在不断实践中，在恰当的时机中，来合理地运用这些基本技术。这两篇文章就从静态和动态测试方面理解白盒测试，并提出了应该注意的问题。
wayne_chan的博客有一个系列化的文章，从基本概念入手，全面介绍了第四代白盒测试方法的所有内容。相关的文章链接如下：
◇第4代白盒测试方法介绍--理论篇
◇第4代白盒测试方法介绍--VcTester实践篇
◇第4代白盒测试方法通俗释义
◇第4代白盒测试方法之“为什么要做白盒测试”
◇第4代白盒测试方法之“企业如何推行白盒测试”
◇第4代白盒测试方法之“实施白盒测试的几个误区”
◇第4代白盒测试方法之“如何选择嵌入式白盒测试工具”
◇第4代白盒测试方法实践之“VcTester持续集成框架的应用价值”
◇第4代白盒测试方法实践之“使用VcTester实施持续集成的组织管理模式”
◇第4代白盒测试方法实践之“如何在VcTester集成自动构建功能”
◇第4代白盒测试方法实践之“使用VcTester构造持续集成及每日构建平台”
◇第4代白盒测试方法实践之“内存泄露检查工具VLD如何与VcTester配合使用”
◇第4代白盒测试方法实践之“如何将Pclint嵌入到VcTester中使用”
◇第4代白盒测试方法实践之“VcTester插装原理与各种覆盖率配置”
◇通信软件白盒测试的三种境界
·对比和总结
◇黑盒测试和白盒测试之间的区别
◇测试方法的辩证统一
◇白盒测试与黑盒测试两类方法对比
任何一种测试方法都有其优点，在特定的测试领域能得到充分发挥。同时，任何一种测试方法都不能覆盖所有测试的需求，在某些场合存在一定的局限性和不足。软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。所以多种测试方法结合使用才能保证测试工作的顺利进行。
◇更多软件测试相关文章>>>
http://testing.csdn.net/page/14a9cad2-0d07-49bc-95a1-30b95dc7fdeb
共17个网摘 [
1 ]