网络通信产品测试

  汉柏科技 网络通信产品测试 王智民 汉柏科技有限公司 Agenda ? ? ? ? ? ? 新产品开发常用管理体系 IPD与华为IPD介绍 测试基本概念 测试用例设计技术 通信设备测试 测试管理 产品开发常用管理体系 ? PACE –Product And Cycle-time Excellence,产品及周期优 化法 ? IPD –Integrated Product Development,集成产品开发 ? SGS –Stage-Gate System,门径管理系统 ? PVM –Product Value Management,产品价值管理 Agenda ? ? ? ? ? ? 新产品开发常用管理体系 IPD与华为IPD介绍 测试基本概念 测试用例设计技术 通信设备测试 测试管理 IPD介绍 ? 基本思想 –(1)新产品开发是一项投资决策 –(2)基于市场的开发 –(3)跨部门、跨系统的协同 –(4)异步开发模式 –(5)重用性 –(6)结构化的流程 ? 适用性 –IPD适用于技术复杂度较高 –管理能力相对成熟的企业 华为IPD介绍 产品IRB/公司IPMT 公司高层 财务 营销与销 售 研发 制造 采购 产品线 · 无线 `安全 销售执行周审视例会 供需/器件承诺决策 质量评审 客户满意度委员会 财务预测 产品线IPMT 行销 大客户 行销 财务与 计划 开发 IPMT主任 制造 采购 测试 销售 服务与 支持 测试 IT 技术支持 投资组合管理 团队PMT 技 研 术 发 财 务 支 制 销 持 造 行 售 销 财务 采购 销售 行销 采购 资料 测试 PDT 开发 制造 技术 支持 概念 阶段 计划阶 段 开发阶 段 验证阶 段 GA 停止 服务 和支 持 销售 行销 采购 财务 采购 开发 PLIPMT 资料 测试 制造 技术 支持 停止 销售 停止 生产 发布阶 段 在适当的时间向市场推出适当的产品,满 足客户需求并实现业务目标 监控市场情况并管理已经发布产品的投 资组合直到生命周期终止,优化投资组 合方案以实现业务目标 华为IPD流程与MM流程 市场管理MM 市场信息 客户反馈 竞争对手信息 技术趋势 当前产品组合 了解 市场 市场 细分 组合 分析 制定业务策 略和计划 融合并优化各业务部分 的业务计划 管理业务计划 评估绩效 IPD 产品线业务计划 产品线项目组合 产品线路标 是 概念 计划 开发 验证 发布 生命 周期 组合分析 à竞争?竞争对手信息 à了解能够进入的细分市场 à分析细分市场中的市场机制 à支持产品线组合与产品的销 售预测 à收集并分析市场需求 项目任务书 否 组合管理 责任主体:产品线IPMT -à分析组合 -à制定产品线业务计划 -à制定产品线路标 华为IPD流程 集成产品开发IPD 生命周期阶段 概念阶段 计划阶段 开发阶段 验证阶段 发布阶段 停止销售 停止生产 停止服务 和支持 概念 DCP 重新 确定 计划 DCP 继续 可获得性 DCP 停止销售 DCP 停止生产 DCP 停止服务 与支持 DCP 中止 华为IPD流程与产品测试 TR4 TR1 TR2 TR3 TR5 TR6 SIT TR4A SVT SRT 概念阶段 计划阶段 开发阶段 验证阶段 发布阶段 生 命 周 期 阶 段 集成产品开发IPD 华为产品测试 测试类型 对应产品开发阶段 关注点 ? ? ? ? ? ? ? ? 系统功能 系统稳定性 系统鲁棒性 系统性能 系统规格 系统性能 系统易用性 文档测试 SIT TR4~TR5 SVT TR5~TR6 SRT TR6~发布阶段决策评审点 ? 系统配套 ? 出厂检验 ? 装备测试 Agenda ? ? ? ? ? ? 新产品开发常用管理体系 IPD与华为IPD介绍 测试基本概念 测试用例设计技术 通信设备测试 测试管理 测试基本概念 ? 测试定义 –IEEE在1983年提出:“使用人工或自动手段来运行或测定 某个系统的过程,其目的在于检验它是否满足规定的 需求或是弄清预期结果与实际结果之间的差别。” ? 测试目标 –检验它是否满足规定的需求 –发现错误 测试基本原则 ? ? 所有的测试都应追溯到用户需求 应该在测试工作真正开始的前较长时间内就进行测试计划 ? Pareto原则应用于软件测试 – Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。当然,问题在于 如何孤立这些有疑点的模块并进行彻底的测试。 ? 测试应从“小规模”开始,逐步转向“大规模” – 最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找 错误,最后在整个系统中寻找错误。 ? 穷举测试是不可能的 – 在测试中不可能运行路径的每一种组合, – 充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。 ? 为了达到最佳效果,应该由独立的第三方来构造测试 – “最佳效果”指最可能发现错误的测试(测试的主要目标) – 创建系统的软件工程师并不是构造软件测试的最佳人选 什么是好的测试 ? 一个好的测试发现错误的可能性很高 – 为了达到这个目标,测试者必须理解软件,并尝试设想软件如何才能失败 ? 一个好的测试并不冗余 – 测试的时间和资源是有限的,没有必要构造一个与其他测试用途完全相同的测试,每一个测试 都应该有不同的用途(哪怕是细微的差异) – 例如,有一个模块被用来识别用户密码以决定是否启动系统,为了测试密码输入的错误,测试 者设计了一系列的输入密码测试。在不同的测试中输入有效与无效密码(四个数字),然而,每 一个有效/无效密码将检测一种不同错误模式,例如,一个将8080作为有效密码的系统将不会 接受非法密码1234,如果接收1234,将产生错误,另一个测试输入1235,与1234的测试意图相 同,因此是冗余的,然而,非法输入8081或8180就有些细微的差异,即对与有效密码相近但并 不相同的密码该进行测试。 ? 一个好的测试应该是“最佳品种” – 在一组目的相似的测试中,时间和资源的限制可能只影响其某个子集的执行,此时,应该使用 最可能找到所有错误的测试。 ? 一个好的测试既不会太简单,也不会太复杂 – 每一个测试应该独立执行 – 适当的组合测试是必要的 有关测试的“金科玉律” ? 木桶原理 – 产品质量的关键因素是分析、设计和实现,测试应该是融于其中 的补充检查手段,其他管理、支持、甚至文化因素也会影响最终 产品的质量 – 测试是提高产品质量的必要条件,也是提高产品质量最直接、最 快捷的手段,但决不是一种根本手段。反过来说,如果将提高产 品质量的砝码全部押在测试上,那将是一个恐怖而漫长的灾难 ? Bug的80-20原则 – 一般情况下,在分析、设计、实现阶段的复审和测试工作能够发 现和避免80%的Bug,而系统测试又能找出其余Bug中的80%,最后 的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来 – 测试只能够保证尽可能多地发现错误,无法保证能够发现所有的 错误 测试分类(22种) ? 根据测试设计技术 – 黑盒测试 – 白盒测试 ? 从测试完备性 – 累积综合测试 – 功能测试 – 端到端测试 – 健全测试 – 衰竭测试 – 接受测试 ? 从测试过程看 – 单元测试 – 集成测试 – 系统测试 – 负载测试 – 强迫测试 – 性能测试 – 可用性测试 – 安装/卸载测试 – 恢复测试 – 安全测试 – 兼容测试 – 比较测试 ? 从产品角度看 – Alpha 测试 – Beta 测试 容易混淆的概念 ? 性能测试与压力测试 – 综合性能=负载指数*性能指数 – 一般对一台设备来说,综合性能是固定的 – 压力测试是为了得到性能指数最小时候(可以接受的最小指数)最大的负载指数 – 性能测试是为了得到负载指数确定下的性能指数 ? Alpha测试与Beta测试 – 都不是研发人员或者测试人员完成,由最终用户或者第三方来完成 – Alpha测试接近开发完成时所做的测试,测试后,设计可能有少许改动 – Beta测试时开发基本完成后所作的测试,在最终发布前所有发现的问题需要更正 ? 兼容测试与比较测试 – 兼容测试是测试软件或者设备在用户要求的环境下的适应性 – 比较测试是与竞争伙伴的产品做比较,找出优劣势 测试过程常见模型 ? V模型 ? 缺陷:把测试作为在编码之后的一个阶段,是针对 程序进行的寻找错误的活动,而忽视了测试活动对 需求分析、系统设计等活动的验证和确认的功能 测试过程常见模型 ? W模型 ? 缺陷:在W模型中,需求、设计、编码等活动被视为串行的, 测试和开发也保持着一种线性前后关系,上一阶段完全结束, 才可正式开始下一阶段工作。无法支持迭代开发模型 测试过程常见模型 ? H模型 ? H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期, 与其他流程并发地进行。H模型指出软件测试要尽早准备,尽早执行。不同的测 试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达 到准备就绪点,测试执行活动就可以开展 测试过程常见模型 ? 其他模型 –X模型 ? X模型提出针对单独的程序片段进行相互分离的编码和测 试,此后通过频繁的交接,通过集成最终合成为可执行 的程序 –前置测试模型 ? 前置测试模型体现了开发与测试的结合,要求对每一个 交付内容进行测试 对测试的常见误解 ? 测试是保证产品质量的充分必要条件 ? 测试就是发现错误 ? 测试工作是没有技术含量的工作 ? 测试无法发现重要的问题 ? 测试能够发现100%的错误 ? 测试不需要设计 ? 所有测试都能够实现自动化 Agenda ? ? ? ? ? ? 新产品开发常用管理体系 IPD与华为IPD介绍 测试基本概念 测试用例设计常用技术 通信设备测试 测试管理 测试用例设计技术 ? 白盒测试 – 若了解产品的内部构造,则构造测试,以确保“所有齿轮吻合”, 即内部操作依据规约执行,而且所有的内部构件被充分利用一个 好的测试并不冗余 ? 黑盒测试 – 若了解产品的特定功能,则构造测试,以证实各功能完全可执行, 同时在各功能中寻找错误 ? 灰盒测试 – 若既能够了解产品的特定功能,又了解产品的内部构造,则可以 构造测试,结合白盒和黑盒进行测试 测试用例设计技术—黑盒测试用例设计方法 ? ①第一步是理解软件所表示的对象及其关系 ? ②第二步是定义一组保证“所有对象与其他对象 都具有所期望的关系” 的测试序列 ? 换言之,软件测试首先是创建对象及其关系图, 然后导出测试序列以检查对象及其关系,并发现 错误 测试用例设计技术—黑盒测试用例设计方法 ? 等价类划分方法 – 等价划分的测试用例设计基于输入条件的等价类评估 ? 设计指南 – 如果输入条件代表一个范围,可以定义一个有效等价类和两个无 效等价类 – 如果输入条件需要特定的值,可以定义一个有效等价类和两个无 效等价类 – 如果输入条件代表集合的某个元素,可以定义一个有效等价类和 一个无效等价类 – 如果输入条件是布尔式,可以定义一个有效等价类和一个无效等 价类 测试用例设计技术—黑盒测试用例设计方法 ? 边界值分析方法 – 边界值分析是一种补充等价划分的测试用例设计技术 – 不是选择等价类的任意元素,而是选择等价类边界的测试用例 – 不仅注重于输入条件,而且注重输出域 ? 设计指南 – 如果输入条件代表以a和b为边界的范围,测试用例应当包含a、b、略大 于a和略小于b的值 – 如果输入条件代表一组值,测试用例应当执行其中的最大值和最小值, 还应当测试略大于最小值的值和略小于最大值的值 – 指南1和2也适用于输出条件,例如,工程分析程序要求输出温度和压强 的对照表,测试用例应当能够创建包含最大值和最小值的项 – 如果程序数据结构有预定义的边界(如数组有100项),要测试其边界的数 据项 测试用例设计技术—黑盒测试用例设计方法 ? 错误推测方法 –基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例 ? 设计指南 –在单元测试时曾列出的许多在模块中常见的错误 –以前产品测试中曾经发现的错误等经验的总结 –输入数据和输出数据为0的情况 –输入表格为空格或输入表格只有一行 测试用例设计技术—黑盒测试用例设计方法 ? 因果图方法 – 等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之 间的联系, 相互组合 – 输入条件之间的相互组合,可能会产生一些新的情况 – 适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例 ? 设计指南 – (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那 些是结果(即输出条件), 并给每个原因和结果赋予一个标识符 – (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应 的关系. 根据这些关系,画出因果图 – (3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不 可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件 – (4) 把因果图转换为判定表 – (5) 把判定表的每一列拿出来作为依据,设计测试用例 测试用例设计技术—黑盒测试用例设计方法 ? 判定表驱动分析方法 – 判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具 – 判定表通常由四个部分组成: 条件桩(Condition Stub):列出了问题得所有条件.通常认为列出得条件的次序无关紧要. 动作桩(Action Stub):列出了问题规定可能采取的操作.这些操作的排列顺序没有约束. 条件项(Condition Entry):列出针对它左列条件的取值.在所有可能情况下的真假值. 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作. ? 设计指南 – 规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条 规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列. – 判定表的建立步骤: ①确定规则的个数.假如有n个条件.每个条件有两个取值(0,1),故有 种规则. ②列出所有的条件桩和动作桩. ③填入条件项. ④填入动作项.等到初始判定表. ⑤简化.合并相似规则(相同动作). 测试用例设计技术—黑盒测试用例设计方法 测试用例设计技术—黑盒测试用例设计方法 ? 正交实验设计方法 – 利用因果图来设计测试用例时,作为输入条件的原因和输出结果之间的因果关系, 有时候很难从软件规格说明中得到,而且即使是对于一般中小规模的软件,给出 其因果图也可能是很庞大,以至于据此因果图的得到的测试用例数量将达到惊人 的程度,这给软件测试工作带来了沉重负担 – 所谓“正交实验法”是从大量的实验中挑选适量的、有代表性的点,应用依据伽 罗瓦理论导出的正交表,合理安排实验的一种实验设计方法 – 利用该方法可以使所有因子和水平在实验中均匀的分布与搭配,均匀规律的变化 ? 设计指南 – 利用正交实验设计测试用例的步骤: ①提取功能说明,构造因子--状态表. ②加权筛选,生成因素分析表 ③利用正交表构造测试数据集 ? 实例 测试用例设计技术—黑盒测试用例设计方法 ? 正交实验设计方法实例 – 为了提高某化学产品的转化率,选择了三个有关因素进行条件试验,反应温度 (A),反应时间(B)用碱量(C),并确定了它们的试验范围如下: A:80——90℃; B:90——150分钟; C:5%——7%。 – 试验目的是搞清楚因子A、B、C对转化率有什么影响,哪些是主要的,哪些是次要 的,从而确定最适生产条件,即温度、时间及用碱量各为多少才能使转化率高。 试制定试验方案。 这里,对因子A,在试验范围内选了三个水平;因子B和C也都取三个水平: A:Al=80℃,A2=85℃,A3=90℃ B:Bl=90分,B2=120分,B3=150分 C:Cl=5%,C2=6%,C3=7% – 这个三因子三水平的条件试验,通常有三种试验进行方法: (Ⅰ)取三因子所有水平之间的组合,即AlBlC1,A1BlC2,A1B2C1, ……,A3B3C3,共有 33=27次实验 (II)简单对比法,即变化一个因素而固定其他因素,如首先固定B、C于Bl、Cl,使A变化 (III)考虑兼顾这两种试验方法的优点,从全面试验的点中选择具有典型性、代表性的点, 使试验点在试验范围内分布得很均匀,能反映全面情况 测试用例设计技术—黑盒测试用例设计方法 ? 功能图分析方法 – 一个程序的功能说明通常由动态说明和静态说明组成,动态说明描述了输入数据的次序或转移 的次序,静态说明描述了输入条件与输出条件之间的对应关系 – 功能图方法是用功能图DFD形式化地表示程序的功能说明,并机械地生成功能图的测试用例 – 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的 输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用 于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输 出数据仅由输入数据决定.测试用例则是由 测试中经过的一系列状态和在每个状态中必须依靠 输入/输出数据满足的一对条件组成 – 功能图方法其实是是一种黑盒白盒混合用例设计方法 ? 设计指南 – 从功能图生成测试用例的过程: 1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数 据)组合与对应的结果值(输出数据或状态)构成 2)测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径 3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状 态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合 ? 实例 测试用例设计技术—黑盒测试用例设计方法 ? 场景设计方法 –现在的软件几乎都是用事件 触发来控制流程的,事件触发 时的情景便形成了场景,而同 一事件不同的触发顺序和处理 结果就形成事件流。 –比较适合于通信产品的测试 ? 设计指南 –基本流和备选流 测试用例设计技术—黑盒测试用例设计方法 ? 各种用例设计方法综合策略 –在任何情况下都必须使用边界值分析方法,经验表明 用这种方法设计出测试用例发现程序错误的能力最强 –必要时用等价类划分方法补充一些测试用例 –用错误推测法再追加一些测试用例 –对照程序逻辑,检查已设计出的测试用例的逻辑覆盖 程度,如果没有达到要求的覆盖标准,应当再补充足 够的测试用例 –如果程序的功能说明中含有输入条件的组合情况,则 一开始就可选用因果图法 测试用例设计技术—黑盒测试用例设计方法 ? 测试用例的类型 – 1)构造根据设计规格得出的基本功能测试用例 – 2)边界值测试用例 – 3)状态转换测试用例 – 4)错误猜测测试用例 – 5)异常测试用例 – 6)性能测试用例 – 7)压力测试用例 – 8)易用性测试用例 – 9)安装/卸载测试用例 – 10)恢复测试用例 – 11)安全测试用例 – 12)兼容性测试用例 – 13)比较测试用例 – 14)强迫测试用例 – 15)接受/验收测试用例 – 16)端到端测试用例 测试用例设计技术—黑盒测试用例设计方法 ? 优化测试用例的方法 –1)利用设计测试用例的8种方法不断的对测试用例进行 分解与合并 –2)采用遗传算法理论进化测试用例 –3)在测试时利用发散思维构造测试用例 Agenda ? ? ? ? ? ? 新产品开发常用管理体系 IPD与华为IPD介绍 测试基本概念 测试用例设计常用技术 通信设备测试 测试管理 通信设备/产品的特点 ? 系统运行以数据触发为最重要的特点,实时性要 求高 ? 系统复杂,涉及硬件芯片、嵌入式操作系统、数 据处理、应用软件、用户界面等各个方面 ? 设备必须24×365不间断运行,一旦出现故障,影 响面较大,在线调试困难 ? 运行环境复杂,80%时间用到20%的功能 通信设备/产品测试常用策略 ? 尽早测试,但不是尽早全面测试 ? 产品开发的不同阶段,测试关注不同的重点 ? 硬件测试先行: – 指标测试 – 功能测试 – 容限测试 – 容错测试 – 长时间验证测试 – 可靠性测试(EMC、环境、安规、老化) – 一致性测试 通信设备/产品测试常用策略 ? 功能测试 – 测试实时系统的第一步是独立地测试各个功能 – 功能测试能够发现逻辑和功能错误,但是不能发现时间和行为错误 ? 行为测试 – 按照外部事件的序列检查其行为,这些分析活动可作为创建实时系统时 设计测试用例的基础 – 使用类似于等价划分技术,可以对事件(如中断、控制信号和数据)分类 测试 – 每种事件都可以独立测试,并且检查可执行系统的行为以检测是否有与 事件处理相关的继发性错误 – 测试每种事件以后,以随机顺序和随机频率将事件传给系统,检查系统 行为看是否有行为错误 – 尽量模拟真实的环境进行行为测试 – 测试在各种极限、边界情况下的行为测试 通信设备/产品测试常用策略 ? 时间测试 – 在隔离了功能内部和系统行为错误以后,测试就要转向时间相关的错误 – 用不同的数据率和处理负载来测试 – 在不同的时间点进行测试 – 长时间的压力测试 ? 全面测试 – 集成软件和硬件,进行大范围的系统测试,以发现软件/硬件接口间的错误 – 单板在允许的高温和低温状态下的测试 – 兼容性测试 – 模拟各种流量进行压力和负载测试,特别是异常流量 – 最常用功能的反复测试 – 内存泄漏测试 – 易用性测试 – 设备本身受到攻击情况下的行为测试(安全测试) – 恢复测试 通信设备/产品测试经验总结 ? ? ? ? ? ? ? ? 随机难以复现的问题在网络上运行时一定会出现 尽量模拟真实的网络应用环境进行测试 模拟各种特征的流量进行测试 极限压力测试一定要做,而且常常是认为不太可能出现的极限负荷 长时间测试一定要做 常用的功能务必要测试,不常用的功能至少要进行基本功能测试 控制版本节奏相当重要,每个版本要做到彻底测试,测试思路要清晰,测试用例可以 不详细,但一定要清楚测试的目的 测试人员需要熟练掌握各种测试仪器 ? ? ? ? ? ? ? 兼容性/互通性测试一定要做 一定要熟悉被测试产品的常用调试手段,能够根据一些调试信息做初步分析和判断 根据研发人员设计和编程时经常出现的问题,猜测设计用例 学会抓包分析 一定要做对比测试 设备本身的安全一定要重视 资源相互竞争的测试 通信设备/产品测试十大秘诀(来源:新浪博客) – 懂得使用工具 – 尽早发现内存问题 – 深入理解代码优化 – 不要让自己大海捞针 – 重现并隔离问题 – 以退为进 – 确定测试的完整性 – 提高代码质量意味着节省时间 – 发现它,分析它,解决它 – 利用初学者的思维 Agenda ? ? ? ? ? ? 新产品开发常用管理体系 IPD与华为IPD介绍 测试基本概念 测试用例设计常用技术 通信设备测试 测试管理 测试管理 ? 过程管理 – 选择过程管理模型 – 需求把握 – 问题报告描述 – 测试用例管理 – 变更控制 – 度量与分析 – 测试节奏控制 – 过程持续改进 ? 人力资源管理 – 绩效评估 – 技能培养 ? 沟通管理 – 测试与研发的沟通 – 测试内部沟通 测试管理—如何有效描述所发现的问题 ? 测试人员不仅仅是努力发现问题,还需要对发现的问题进 行分析,甄别,初步判断和定位 ? 测试人员的一个重要职责是敦促研发人员及时解决所发现 的问题 ? 对发现的问题要与研发人员充分的沟通,遇到严重致命问 题,最好找研发人员当场定位或者初步判断一下 ? 在描述发现的问题的时候,要把问题发现的“上下文”描 述清楚,比如当前的配置、采用的组网环境、操作顺序、 流量特征、需要研发特别注意的环节等 测试管理—如何有效描述所发现的问题 建议模板 ? 你是否觉得测试是没有技术含量的工作? ? 你是否曾经有过测试人员让人比较烦的感觉? ? 你是否觉得测试工作在多数企业中不受重视? ? 你是否觉得测试职业没有前途? ? 你是否从骨子里看不起测试工作? 测试工程师并不亚于研发工程师 ? ? ? ? 需要的知识面非常广 需要很高的悟性和直觉 需要很强的动手实践能力 需要很强的发现问题、分析问 题、解决问题的能力 正确认识测试与研发 ? 研发是“建立”系统的过程 ? 测试是“验证”和“破坏” 系统的过程 ? 两者从不同的角度向相同的 目标努力:质量! 研发与测试一定是水火不相容吗? 测试管理--测试与研发的沟通 “建立”与“破坏” 共同目标:质量! 测试管理--测试与研发的沟通 “The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.” --《Testing Computer Software》, Cem Kaner 最好的测试人员不是发现最多BUG或是使得大多 数开发人员不自在的人,而是能够“说服开发人 员”修正最多BUG的人! 发现BUG是测试人员的责任,敦促BUG得到解决 是测试人员更重要的责任! 测试管理--测试人员“五要”与“四不要” ? 五要 –要耐心和细心 –要懂得尊重对方 –要能设身处地为对方着想 –要有原则 –要主动承担 ? 四不要 测试管理--测试人员“五要”与“四不要” ? 五要 ? 四不要 –不要嘲笑 –不要在背后评论开发工程师 –不要动辄用上层来压制对方 –和开发人员的沟通不要只有BUG

时间

2019-08-04 20:28


栏目

通信产品


作者

admin


分享