搜索
软件测试测试的基本理论及方法公司测试工作的规划自动化性能和压力测试测试的基本理论及方法对软件测试的误解如何理解软件测试软件测试的定义软件测试的对象软件测试分类和比较软件测试的目的软件测试组织软件测试规范软件测试的内容和技术WEB应用测试对软件测试的误解如果发布出去的软件有质量问题,那是软件测试人员的错.软件测试技术要求不高,至少比编程容易多了.软件测试随便找一个能力差的人就能做.有时间就多测试一些,来不及就少测试一些.软件测试是测试人员的事,与开发人员无关.设计-实现-测试,软件测试是开发后期的一个阶段如何理解软件测试软件测试是一种有效的提高软件质量的手段,但即使在投入上有所保证,测试也不能百分为百发现所有质量隐患.况且软件质量并不仅仅是测试出来的.很多人认为软件测试就是运行一下软件,看看结果对不对.但实际上,如何在有限的投入下,提高软件测试的效率和产出是一件很见功底的事.好的测试人员不仅要掌握各种测试技术,还要具备丰富的编程经验和对BUG的敏感.测试的复杂之处,除了测试技术问题之外,还有测试管理问题.测试不是可有可无,随心所欲的.规范化的软件开发需要对软件测试早做计划,分配必要的时间,人力和财力等资源,并将其作为项目管理的一个部分加以控制和协调.开发和测试是软件项目相辅相成的两个过程,人员间的交流,协作和配合是提高整体效率的重要因素.软件产品开发完毕,再进行测试的观念是有悖于生命周期理论的.软件产品质量问题越晚发现,修复的代价越大.需求设计编程内部测试外部测试发布修正BUG的代价一些常识和经验之谈测试能提高软件的质量，但是提高质量不能依赖测试。测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。软件测试的定义软件测试是为了发现错误而执行程序的过程软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现程序错误的过程.软件测试不等于程序测试.软件测试贯穿于软件定义和开发的整个期间.需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象.软件测试的对象软件生存各个阶段间的确认和验证用户要求用户：我要什么？需求说明书分析员：我可以提供什么？设计说明书设计员：我要软件做什么？源程序程序员：我要让计算机怎么做？运行结果计算机：程序运行得到的结果理解正确性表达正确性理解正确性设计正确性表达正确性理解正确性编码正确性运行正确性输入正确性相符吗？12345软件配置：包括软件需求规格说明、软件设计规格说明、源代码等；测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。测试工具：为提高软件测试效率，可使用测试工具支持测试工具。例如：测试数据自动生成程序、测试结果分析程序等。测试的目的测试是程序的执行过程,目的在于发现错误;一个好的测试用例在于发现至今未发现的错误;一个成功的测试是发现了至今的错误的测试.测试的种类名称说明黑盒测试基于软件需求，而不是基于软件内部设计和程序实现的测试方式。白盒测试基于软件内部设计和程序实现的测试方式。单元测试主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。集成测试将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机－服务器程序等等。功能测试测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。一般由独立测试人员执行。系统测试测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。一般由独立测试人员执行，通常采用黑盒测试方式。回归测试指错误被修正后或软件功能、环境发生变化后进行的重新测试。回归测试的困难在于不好确定哪些内容应当被重新测试。验收测试由客户或最终用户执行，测试软件系统是否符合需求规格说明书。名称说明负载测试测试软件系统的最大负载，超出此负载软件可能会失常。压力测试概念上与负载测试相似，叫法不同。性能测试测试软件在各种状况下的性能，如在正常或最大负载下的状况。易用性测试测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。安装与反安装测试测试软件在“全部、部分、升级”等状况下的安装/反安装过程。恢复测试测试该系统从故障中恢复过来的能力。安全性测试测试该系统防止非法侵入的能力。兼容性测试测试该系统与其它软件硬件兼容的能力。比较测试通过与同类产品比较，考察该系统的优点、缺点。Alpha测试一种先期的用户测试，此时系统刚刚开发完成。Beta测试一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。测试的分类与比较测试方式白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档测试阶段单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。软件测试过程模型V模型是最具有代表意义的测试模型。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系。从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。软件测试过程模型相比于V模型，W模型更科学。W模型可以说是前者自然而然的发展，它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。测试内容接口与路径测试。功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试…测试阶段主要依据测试人员、测试方式主要测试内容单元测试系统设计文档由开发小组执行白盒测试接口测试、路径测试集成测试系统设计文档需求文档由开发小组执行白盒测试和黑盒测试接口测试、路径测试功能测试、性能测试系统测试需求文档由独立测试小组执行黑盒测试功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试验收测试需求文档由用户执行黑盒测试黑盒测试与白盒测试的比较测试方式特征依据测试人员测试驱动程序黑盒测试只关心软件的外部表现，不关心内部设计与实现。软件需求任何人（包括开发人员、独立测试人员和用户）一般无需编写额外的测试驱动程序白盒测试关注软件的内部设计与实现，要跟踪源代码的运行。设计文档由开发人员兼任测试人员的角色需要编写额外的测试驱动程序问题1：有了“黑盒”测试为什么还要“白盒”测试？黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。问题5：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢?所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。问题6：能否将系统测试和验收测试“合二为一”？系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。回归测试回归测试是指对某些已经被测试过的内容进行重新测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，不仅要对新内容进行测试，还要对某些老内容进行回归测试。测试人员的组织了解开发人员的测试心理测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这类错误.开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。如何组织测试人员：应当视企业的人力资源而定条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完