《软件测试心得入门分享》由会员分享，可在线阅读，更多相关《软件测试心得入门分享（16页珍藏版）》请在金锄头文库上搜索。
1、,测试软件标准,随缘领悟,时间：2019-7-3,测试你应该懂得概述-你得 知道我说什么,概述-重点 （要考试）,是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期结果），并利用这些测试用例去执行程序，以发现程序错误的过程 是验证程序正确并符合用户需求的过程,测试的定义,软件未达到产品说明书标明的功能 软件出现了产品说明书指明不应该出现的错误 软件功能超出产品说明书指明范围 软件未实现产品说明书虽未明确指出但应该实现的目标,缺陷（BUG）定义,软件测试的目的就是发现程序中的错误并进行修正，将软件不工作的风险
2、程度降低到一个可以接受的程度,测试的目的,白盒测试 基于被测应用程序的内部逻辑的测试，通过语句，分支，路径和条件进行全面覆盖，类似于西医看病，通过X光、CT扫面等手段 黑盒测试 不是基于内部代码和设计的知识，而是基于需求和功能 灰盒测试 是介于白盒测试和黑盒测试之间的一种测试模式，重点关注模块接口、接口函数的逻辑,3种盒子测试方法,软件需求-用户：我要做什么 需求规格说明-分析：我可以提供什么 设计规格说明-分析：我要怎么去展示 源程序-程序猿：我该怎么去实现 运行结果-最终呈现：符合预期达到需求吗,开发流程,单元测试：对软件中的基本组成单位进行的测试，如一个模块、一个过程等等 集成测试：在软
3、件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确 系统测试：对已经集成好的软件系统进行彻底的测试 确认测试（验证测试） 旨在向软件的购买者展示该软件系统满足其用户的需求,测试术语,可以出去吹NB的重点,测试那些倔强原则,40%,60%,80%,100%,基础重点,缺陷等级分类,黄金比例：二八原则,这辈子都不能忘记原则,边值测试 极值测试 不完全测试 随机测试,P1：最严重的：流程不过，死机，不运行基本功能，构建问题 P2：功能失效、不执行、缺失、频繁地异常/性能差 P3：功能有错误，结果不正确，偶尔异常/性能差 P4：UI及提示信息错误，不完美，不严重但应该修改的 P5
4、：意见性的、建议性的,测试用例的编写20%重点要覆盖需求的80%，在分析、设计阶段的复审和测试工作能够发现和避免80%的bug，而系统的完整的软件测试能够找出其余bug中的80%。,Zero bug是一种理想，不要强行过分投入的测试，权衡投入/产出比的原则，测试既不要不充分，也不要过分,打死不改的原则,耗死脑细胞的测试模型,蒙骗萌新模型-V,V,V模型的优点：是最具代表意义的测试模型。V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 V模型的局限性：它仅仅把测试过程作
5、为在需求分析、概要设计、详细设计及编码之后的一个阶段。不能体现“尽早地和不断地进行软件测试”的原则。,不明觉厉模型-W,W,W模型的优点： W模型实际上开发是“V”，测试也是与此相并行的“V”，基于“尽早地和不断地进行软件测试”的原则。测试者可以在项目中尽可能早地面对规格说明书的挑战。这意味着测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。 W模型的局限性：它和V模型一样，都把软件的开发和测试保持一种线性的前后关系。这样无法支持迭代、自发性以及变更调整。对于当前很
6、多文档需要事后补充，或者根本没有文档的做法下，开发人员和测试人员都面临着同样的困惑,一脸懵逼模型-H,H,这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。 H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。,好的测试用例是测试的
7、成就 感来源,一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息，如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步骤和期望结果。,“需求说明”及相关文档 与开发组交流对需求理解的记录（可以是开发人员的一个解释） 已经基本成型的UI（可以有针对性地补充一些用例） 功能说明文档（尽量详细） 简而言之，所有你能得到的项目文档，都尽量拿到。从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。,作为测试执行的标准，指导测试执行 测试量化管理的基础 提高测试的透明度 降低测试成本 提高团队测试水平的重要条件之一,设计原则 结构层次清晰 覆盖全面 设计方法 按模块 按功能点 按菜单 按业务逻辑,自己 看吧,说完这一章你们就解脱了,THX,误人子弟的经验分享,
