产品测试

1、 测试人员需要何时参加需求分析？ 原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加需求分析工作。这样可以带来如下好处： 测试人员全程参与需求分析，对需求了解很深刻，减少了很多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点； 早期确定测试用例的编写思路，为项目（产品）测试打好了基础； 可以获取一些测试数据，为测试用例设计提供帮助； 可以发现需求不合理的地方，降低了测试成本。 测试人员主要的工作之一就是确认系统是否正确实现了需求。测试人要不参与前期的工作，就只能依赖最后形成的需求文档，甚至由开发人员来讲解需求，而这些需求可能发生了“问题”，因为这个需求是已经经过分析的需求，很多的内容可能与用户的真正要求发生了偏差。同时如果只看最后形成的需求文档，对需求也会有理解上的偏差。因此作为测试人员要尽可能的获取到“第一线”的需求资料，才能真正地了解用户的业务，从而更好的对系统进行测试。 当然，如果测试人员不能参与需求环节，一定要通过其他途径保证需求的正确性，例如和开发人员进行集中讨论需求疑问的项目会议，并且一定要加强测试案例评审，甚至于是测试需求的评审。 2、 系统测试阶段低级缺陷较多怎么办？ 在系统测试阶段，如果仍有很多低级缺陷，说明测试对象是不合格的，没有达到测试标准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多

这是敏捷开发绩效管理的第四篇。（ 之一 ， 之二 ， 之三 ， 之四 ， 之五 ， 之六 ， 之七 ） 最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。 敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。 “内向型”绩效及其导向 进度：“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。 质量：“千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下，另外一些次要的如使用不便、不直观等问题则被长期搁置。 成本：“与计划相比的人员超支率”会导致项目经理很不愿意接受变更，即使是那些显然能给客户带来巨大价值的。 功能：“需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识，而不能在整个漫长的开发过程中不断精化需求。 此外还有一些更可怕的数据，比如“每月生产的代码行数”“每月生产的功能点或故事点数”（这个很有迷惑性）“每月修改的缺陷数”等，都是不恰当的绩效。德鲁克“企业内部只有成本”的理念指出，无论是文档，代码

时间总是匆匆，不知不觉，2018，只剩二十来天。 十二月第一周的工作日，回想今年，测试团队的影响力，团队的价值是否较以往得到了有效的体现？ 再见11月，你好12月！ 与产品、研发相比，测试处于作业末梢。很少有产品或者研发团队去谈论他们的价值，因为产品的设计与实现是他们决定的。 有些新创的公司为了节约成本，往往不招聘测试岗，产品研发完成后不经测试即上线，错误的认为经历两三个版本的迭代，产品质量自然就好了。 日常和朋友们聊天时，也经常提到： 1.和一位做研发的朋友聊天，他们的项目中，前期只有研发没有测试，后来又让开发来担任测试。 2.另一位朋友的公司更恨，为了节约成本，公司招了一位UI，即做设计也担测试。 上面的例子，很好的说明了：在外界眼里，测试工作似乎是可有可无的，也是较容易被忽略、被替代的。 但是做测试的朋友们都知道，事实肯定不是这样的，测试人员的价值是不言而喻的，没有测试的产品质量是无法保证的，后期由产品质量而造成的损失也是不可估量的。 偶尔让大家谈谈：你认为测试的价值是什么的时候，却又欲言又止，不知从何谈起。 那么我们测试人员、测试团队的价值，到底是什么呢？ 只有明确测试的价值，才能让测试团队得到外部的认可与重视，才能让测试人员的工作具有成就感。 从成本的角度看，测试的价值体现在 产品发布前期发现并修复问题，减少后需项目或客户发现问题而造成的成本（金钱、名誉等）。

本文介绍企业在敏捷和DevOps的逐步转型过程中，测试如何应对挑战，有的放矢进行测试，建立适合产品自身发展阶段、产品特点的敏捷测试能力。 敏捷和DevOps 敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈，新商业模式的创新和变现时间窗口越来越短，催生更多的企业采取精益创业的方式，捕捉市场需求后，尽量缩短TTM产品面世时间，快速推出MVP产品并快速响应客户需求迭代产品。 以华为为例，在2008年左右的时候，华为的项目还是采用传统的交付方式，例如在年初开始一个项目，在项目立项之初就会把客户的需求全部收集好，包括一些用户的反馈，并把需求做了全年的排序。年中的时候发布产品给用户，两个月之后再出一个补丁，最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的，但是对质量要求比较强。因为产品发布给客户以后，下一个补丁需要两个月，如果用户在这个期间发现产品问题，他们只能再等两个月，而在这期间如果用户不接受我们的产品，会导致项目前功尽弃，所以就对产品的质量有严格的要求。 产品逐渐向敏捷方向发展，这时有一部分研发工具平台已经陆续转到云上去了，一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型

本文着重介绍如何确定测试目的，划定测试范围，制订测试策略，组件测试团队，准备测试工具和环境，制订测试计划。 凡事预则立，不预则废。个人事项，团队协作都离不开计划。外出游玩有出行计划，产品立项有商业计划，下图中是笔者在某博物馆看到的上个世纪老电影的计划表，是不是很像软件项目里分角色的开发计划。同样地，做软件测试，尤其在涉及到团队协作时，需要制定测试计划。 团队开展测试活动之初，制定相应的测试计划，以指导整个测试周期中测试人员的测试活动。测试计划描述了测试目的、测试对象、测试范围、测试策略、测试活动、测试方法、测试资源和进度等，确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。 为什么要制定测试计划 • 确保测试活动围绕测试目的开展工作，服务于明确的测试目标 • 确定测试对象的被测特性和需求清单，框定测试范围 • 选取适合于团队技术能力和工具组合的测试策略和方法 • 尽早识别测试活动开展中可能面临的风险因素，及时解决 • 合理预估测试工作量和人员、资源需求，编制测试项目计划 • 帮助测试人员分解测试活动和任务，编排个人工作计划 • 指导测试执行活动，及时纠正和补救执行偏差 • 作为相关文档，与利益干系人汇报沟通 什么时间做测试计划 测试活动包含测试计划、测试设计、测试执行等。一般而言，测试计划排在首位

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

在万物互联的移动互联网时代，早已没有了纯线下企业，大到国企，小到街边一家卖袜子的供应商都会开网店，甚至开发个微信小程序。 很多小公司都会招聘两三个开发人员，却很少见这些公司招测试人员，因为他们觉得开发就能做测试。 并且，大多数人对软件测试的认知还停留在普通的“点点点”上，他们认为测试的工作就是把开发的产品拿来用一用，测一测登录是否顺畅、点击是否可以顺利跳转、有没有常规性Bug即可。 不仅如此，大家对软件测试岗位甚至还有更深的误解，比如： 误解一：测试的工作没有任何技术含量。 很多人都认为软件测试就是安装程序、运行程序、点点鼠标、按按键盘的工作。但这几年因为用户要求越来越高，产品变得越来越复杂，测试人员的技术知识体系也需要不断更新和完善，并且随着新工具、新流程、新设计方法的出现，软件测试人员也需要像开发一样持续学习。 误解二：测试就是找bug。 找bug、交bug是测试人员最基础的工作，测试工程师需要把控整个产品质量，代表客户的利益去把控产品、验收产品，因此他们需要做得不仅仅是找bug。 误解三：测试只是软件上线前无关紧要的一道程序。 一个项目的完成，基本要经过以下几个阶段：需求分析、概要设计、详细设计、软件编码、软件测试、软件发布。 大多数人都认为测试只是软件开发过程中的最后一步，不需要care前面的种种工作， 其实并非如此，软件测试是一个系列过程，包括软件测试需求分析

　　一个完整的开发流程应该有这四步：分析->设计->编码->测试。很多开发团队往往只有编码这边，弱化了其他步骤，他们拿到需求就开始写代码， 写着写着发现有问题，要么是遇到一个难点解决不了，要么是发现要返回修改以前写过的代码， 要么是发现有大量的重复代码，又不知道怎么封装，只能将错就错。做好了分析和设计编码时就不会有这么多问题， 做好了测试产品bug就少，产品质量才高。 下面我分别详细讲解一下这四步。 分析 　　分析的时候，我们要分析需求和难点。 　　分析需求的方法是做需求陈述处理，前面我提到过， 要区分做什么和怎么做，把这两部分独立出来，做什么是固定不变的， 而怎么做可能会经常变。我们再熟悉一下举的那个例子：我们要做一个成员列表（如图1-44），产品经理告诉我们要按姓名拼音排序。 图1-44 成员列表的例子 　　我们有时候不能直接听产品经理的，如果真写死成按姓名拼音排序就没有可扩展性了，比如某一天产品经理又告诉你需要把VIP会员提前，那么你只能再去修改排序的程序。这个需求始终不变的是排序，按姓名拼音只是排序的一种方法，我们在设计数据库时应该把排序字段设置为数字而不是拼音，再写一个拼音转换为数字的算法即可，这样在后面排序规则变化，比如VIP会员要提前，只是修改对应用户数据库的排序字段数值即可，不用大改程序。 　　我们可以用xmind做需求分析，

一、集成测试概念 集成测试也叫组装测试、联合测试、子系统测试或部件测试，是在单元测试的基础上，将所有函数按照概要设计要求组装成为子系统或系统所进行的测试；它和单元测试所关注的范围是不同的，因此，它们在发现问题的集合上包含有不相交的区域，不能使用集成测试来替代单元测试，反之亦然。 二、集成测试关注点 1.模块间的接口 把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 全局数据结构是否有问题，会不会被异常修改； 2.集成后的功能 各个子功能组合起来，能否达到预期要求的父功能； 一个模块的功能是否会对另一个模块的功能产生不利的影响； 单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。 三、集成测试的层次 四、集成测试策略的主要模式 现有一个模块包含以下几个函数，将以此为例讲解每种模块的运作方式： 1.大爆炸集成方式 *** 这种方式中，首先对每个模块分别进行单元测试，然后再把所有单元组装在一起进行测试，最终得到要求的软件系统，如图所示： 缺点： a.这种一次性组装方式试图在辅助模块的协助下，在模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大； b.在发现错误的时候，其问题定位和修改都比较困难； c.即使被测系统能够被一次性集成

1、问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试可以包括但不限于一下几个方面： 页面是否风格统一，美观 页面布局是否合理