拥有多年互联网和银行系统性能测试开发经验,对性能瓶颈诊断定位和优化领域有较多研究。 重回互联网行业,性能测试开发、自动化测试开发、Java开发

发布新日志

  • 云服务测试服务笔记 - 测试的原则、过程以及方法

    2015-10-27 11:43:39

      这本书给出的方法让测试者和测试经理能够知道如何在云计算背景下执行自己的任务。书中的技术、提示和范例给我们提供了所需的云测试的全部信息,如可维护性、可持续性和安全性。面对这些不同的风险,需要有不同的测试。
      本书的主要内容包括:云计算的基本特征、实施模型、测试经理角色、端到端测试、选型阶段、实施阶段、众包测试、从风险到测试、性能风险、安全性风险、可维护性风险、测试方法、决定选型需要考虑的云计算相关方面、性能测试、负载测试、建立测试用例、耐力/容量测试的测试用例、测试弹性的测试用例、为性能测试设置测试、测试安全性、测试可管理性、可用性和可持续性、功能性测试、测试web服务、多平台测试、测试迁移、在生产环境中进行测试。
     
     
    【目  录】
      第1章  介绍 1
      第2章  什么是云计算 5
      2.1  云计算的基本特征 7
      2.2  服务模型 8
      2.3  实施模型 12
      第3章  测试经理角色 15
      3.1  一般任务 17
      3.1.1  风险分析 17
      3.1.2  获取供应商信息及与供应商达成一致 19
      3.1.3  端到端测试 20
      3.1.4  给出建议 25
      3.2  选型阶段、实施阶段和生产阶段的任务 25
      3.2.1  选型阶段 25
      3.2.2  实施阶段 26
      3.2.3  生产阶段 27
      3.3  借助云的帮助进行测试 27
      3.3.1  使用TOGA将测试外包给云计算 28
      3.3.2  众包测试 32
      3.3.3  云端的测试环境 33
      3.3.4  生成负载 34
      第4章  从风险到测试 35
      4.1  性能风险 37
      4.2  安全性风险 40
      4.3  可用性和可持续性风险 42
      4.4  功能性风险 44
      4.5  可维护性风险 46
      4.6  法律和法规风险 48
      4.7  供应商和外包风险 49
      第5章  测试方法 51
      5.1  选型阶段的测试 53
      5.1.1  决定选型需要考虑的云计算相关特征 54
      5.1.2  确认选择标准的完整性和可控性 54
      5.1.3  评估服务和供应商 56
      5.1.4  给出选型建议 62
      5.1.5  选型标准清单 63
      5.2  性能测试 66
      5.2.1  负载测试 68
      5.2.2  压力测试 69
      5.2.3  耐力测试或容量测试 69
      5.2.4  测试弹性和手工操作的可扩展性 70
      5.2.5  建立测试用例 71
      5.2.6  针对特定瓶颈的测试用例 75
      5.2.7  在测试用例中包含云的特征 75
      5.2.8  压力测试的测试用例 77
      5.2.9  耐力/容量测试的测试用例 77
      5.2.10  测试弹性的测试用例 77
      5.2.11  设置性能测试 81
      5.2.12  代表性的测试环境 82
      5.3  测试安全性 83
      5.3.1  网络安全性 86
      5.3.2  列出供应商安全性清单 86
      5.3.3  列出客户安全性清单 88
      5.3.4  测试加密 90
      5.3.5  测试认证 90
      5.3.6  测试授权 91
      5.3.7  测试面对互联网攻击时的安全稳定性 92
      5.3.8  测试日志文件和审计跟踪记录 93
      5.3.9  对及时应用安全性补丁进行测试 93
      5.3.10  执行审计 93
      5.4  测试可管理性 94
      5.4.1  供应商侧的规范 95
      5.4.2  客户侧的规范 96
      5.4.3  用户文档 97
      5.4.4  测试环境可用性 98
      5.4.5  测试文档 101
      5.4.6  事故管理流程 102
      5.4.7  变更流程与版本控制 104
      5.4.8  软件可管理性 104
      5.5  测试可用性/可持续性 105
      5.5.1  失效模式影响分析 107
      5.5.2  架构的作用 108
      5.5.3  硬件可靠性 109
      5.5.4  软件可靠性 110
      5.5.5  承诺和SLAs 112
      5.5.6  可用性机制的影响 113
      5.5.7  因特网与因特网连接 114
      5.5.8  测试失效恢复 115
      5.5.9  测试在离线状态下工作 121
      5.6  测试功能性 122
      5.6.1  服务与业务过程的兼容性 124
      5.6.2  测试服务质量 126
      5.6.3  测试用户友好性 127
      5.6.4  测试与其他系统的接口 127
      5.6.5  测试服务配置 129
      5.6.6  供应商定制化 130
      5.6.7  客户的定制 130
      5.6.8  测试Web服务 131
      5.6.9  多平台测试 133
      5.6.10  测试应用本身,以及使用应用来测试服务 136
      5.6.11  测试离线功能 137
      5.6.12  回归测试 137
      5.6.13  创建测试依据 137
      5.7  测试迁移 141
      5.7.1  迁移测试策略 142
      5.7.2  最小化业务中断 143
      5.7.3  IaaS和PaaS中正确的数据迁移 144
      5.7.4  SaaS中正确的数据转换 145
      5.7.5  迁移的性能 148
      5.7.6  数据清理 149
      5.7.7  测试环境迁移 149
      5.7.8  并行运行与模拟运行 150
      5.8  测试法律法规 151
      5.8.1  法律法规清单 152
      5.8.2  检查法律法规 156
      5.9  在生产环境中的测试 157
      5.9.1  变更情况下生产的持续性 157
      5.9.2  度量供应商的承诺 161
      5.9.3  原有选型标准评估 164
      5.9.3  实践中的注意事项 165
      第6章  结束语 167
      术语表   171
     
     
    几年前,云服务还处在口号和概念的阶段,但如今,已经有越来越多的企业和个人开始使用,甚至是构建自己的云服务平台。例如,在SaaS层面,不少中国互联网用户开始使用"云盘"、"云播放";在IaaS层面,不少新创的互联网企业开始使用国内和国外公司提供的云端存储和主机方案,这些方案极大地降低了新创企业的运维成本,缩短了服务的部署时间。甚至,由于越来越多的产品开始在背后使用云服务,用户在"无意"中使用云服务的情况也越来越多。
      云服务的普遍应用为用户和使用云服务的公司带来了便利,但与此同时,云服务也带来了一些额外的风险。例如,最近由OpenSSL的安全性缺陷导致的互联网"心脏出血(heart bleed)"就是一个明显的例子。而对于将自己的业务建立在云服务之上的公司,云服务带来的风险就更加明显:提供云服务的公司不再提供服务了;云服务突然处于不可用状态了;云服务的服务接口更新导致公司对外提供的服务不可用了……但是,即使考虑到云服务带来的额外风险,从成本和收益的角度来说,完全把云服务排除在选择范围之外肯定是不可能的。唯一可行的方法就是,彻底地分析云服务带来的风险,针对这些新的风险和挑战给出合理的解决方案。
      《测试云服务》这本书详尽地分析了在组织内引入云服务所面临的各种风险,同时从测试的角度提供了应对每种风险的可操作建议。在这个快步转向云服务的时代,本书的出现可以说恰到好处。《测试云服务》从测试视角介绍了不同云服务的层次(IaaS、PaaS和SaaS),将组织应用云服务分成了选型、实施、生产等多个阶段,分析了每个阶段面临的风险和风险分析方法,并针对每种风险给出可行的测试方法对其进行覆盖。此外,本书还提供了详细的检查表,以便组织内负责测试的测试经理角色能够快速应用风险评估技术和测试技术,在使用云服务的决策中发挥价值。本书的篇幅并不长,也没有特别针对某种测试工具进行描述,但我相信它给出的全面分析和具操作性的建议能够为读者提供足够的信息。
     
    Martin和Kees对我而言,亦师亦友。他们帮助华为引入了TMap(结果驱动的测试)方法论,使我们逐步理清测试的原则、过程以及方法;同时,也帮助我认识了测试的真正魅力,在这个独特的职业道路上不断前行。
      2012年6月上旬,西安,我和Kees以及Polteq的另一位高级顾问Ruud为一个产品做测试过程改进咨询。那一段时间天气非常炎热,我们每晚都会在**背后的小花园里喝上几罐啤酒,聊聊天。有一次,我问Kees:"您觉得对于测试人员而言,最重要的技能是什么?"Kees沉吟了一下后回答到:"我觉得最重要的就是批判性思维,测试无法穷尽,只有用更严格的思维来帮助识别风险,才能向我们的利益干系人提供更大价值。"
      从华为开始与Polteq合作,已经6年了,每次合作过程中,我都会对这些"Polteq人"的理性思维产生深刻的印象。
      任何一个测试人员都会有这样的困惑:我要测的内容太多了!周边对我的要求太多了!我该怎么办?
      任何一项测试工作,首先应该考虑的问题就是"缩小"测试的范围,如何来"有理有据"地缩小范围,这是关键的难题。
      在TMap中提供了一种可行的方法:基于风险的测试,它指出了测试的第一原则:没有风险,没有测试。
      我们在所有产品线都推进了基于风险测试的方法,这项工作使我们获益匪浅。我们向利益干系人收集风险、设计实验、证明风险的影响,再向他们反馈得到的信息。一切以风险作为基础,建立快速的测试循环。
      我所在的产品线并非云计算领域,但正如本书中所指出:"不管是什么项目,测试经理首先要考虑风险。"
      云计算提供了方便和低成本的服务,但也让更多风险"隐藏"了起来,不为测试人员所见,这是我们在测试云服务中的最大挑战。
      幸运的是,Polteq团队已经为我们做了深入的洞察和实践,他们从各种维度,用批判性的眼光,给出全面和简洁的风险启发式,这些启发式可以帮助我们更好地识别风险,聚焦于最重要的部分,从而也为我们所服务的利益干系人提供更大的价值。
      2007年11月11日,Martin和Kees第一次来到华为,为我们的一个产品进行测试过程改进咨询,我在蛇口码头接他们。一坐上车,这个银发红鼻的老"顽童"立刻从包里拿出厚厚一叠打印的文件,那是我寄给他的华为测试流程中的主要指导书,他举着那些文件"严肃"地问:"你们是这么做的吗?如果是,你们绝对是测试界的 No.1!",我谦虚地说:"咱们评估一下看看吧。"随后的几天,Martin拿着那些文件访谈了很多人,他把文件放在测试经理的面前:"你是按照这个文件做的吗?",我们的测试经理看了半天,摇摇头问一旁做翻译的我:"这是什么?"我汗!
      在我和Polteq的合作中,让我深刻地认识到:如果没有切实的实践,再完美的文档也是浮云。
      让我们就像本书最后一句话所言:热身已经结束,开始全力比赛吧!
      我已经大力向华为的云产品开发部门推荐这本书,无论您是云的客户,还是云的供应者,如果您有志于创造更**值,本书不容错过!
  • 性能测试进阶指南—LoadRunner 11实战(第二版) 简介

    2015-10-27 11:36:27

     
    性能测试进阶指南—LoadRunner 11实战(第二版)
    基础篇
      第1章  性能测试基础 1
      1.1  性能测试工程师的标准及挑战 1
      1.1.1  性能测试工程师的考评指标 1
      1.1.2  性能测试工程师的挑战 3
      1.2  性能测试基础 4
      1.2.1  性能定义 4
      1.2.2  性能指标 13
      1.2.3  单机与网络性能测试 14
      1.2.4  性能测试的流程 15
      1.2.5  性能测试招聘要求 15
      1.2.6  性能测试学习阶段 16
      1.3  性能分析与调优 17
      1.3.1  性能分析及调优原理 19
      1.3.2  常见系统性能瓶颈 27
      1.3.3  性能测试的注意要点 35
      1.4  本章小结 36
      工具篇
      第2章  LoadRunner综述 37
      2.1  LoadRunner简介 37
      2.2  LoadRunner工具组成 38
      2.3  性能测试原理 38
      2.4  自动化测试工具和性能测试工具的区别 40
      2.5  协议分析 40
      2.5.1  HTTP详细介绍 41
      2.5.2  HTTP报文结构 41
      2.5.3  HTTP请求 42
      2.5.4  HTTP应答 43
      2.5.5  HTTP捕获 44
      2.5.6  HTTP回放 46
      2.6  安装 47
      2.6.1  在Windows下安装LoadRunner 50
      2.6.2  安装Load Generator 51
      2.6.3  附加组件 54
      2.6.4  LoadRunner License 55
      2.7  LoadRunner性能测试操作流程预览 56
      2.8  本章小结 59
      实战篇
      第3章  教学项目实战 60
      3.1  计划测试 61
      3.1.1  分析系统阶段 61
      3.1.2  定义测试目标 67
      3.1.3  明确定义及概念 87
      3.1.4  编写性能测试计划 88
      3.1.5  编写性能测试方案 92
      3.1.6  编写性能测试用例 96
      3.2  搭建测试环境 97
      3.2.1  测试平台评估 97
      3.2.2  数据生成 98
      3.2.3  测试环境搭建手册 106
      3.3  创建脚本 113
      3.3.1 用户注册 113
      3.3.2  用户查询 115
      3.3.3  用户看帖 116
      3.3.4  用户回帖 117
      3.3.5  脚本业务报告(Business Process Report) 121
      3.4  创建场景 125
      3.4.1  场景设计 126
      3.4.2  负载监控 127
      3.5  运行场景 133
      3.5.1  场景运行Checklist 133
      3.5.2  场景运行记录 134
      3.6  分析性能数据 135
      3.6.1  性能调优原理 135
      3.6.2  前端性能分析 141
      3.6.3  后端性能分析 149
      3.7  性能测试报告 171
      3.7.1  平台对比性能测试报告 173
      3.7.2  Phpwind 85性能分析报告 181
      3.7.3  Discuz X2和Phpwind 85性能对比报告 203
      3.7.4  Phpwind 85验收指标性能测试报告 213
      3.7.5  Phpwind 85压力测试报告 217
      3.8 本章小结 221
    第4章  企业项目实战 222
      4.1  某金融系统异步贷款项目(WinSocket-8583) 222
      4.1.1  方案设计篇 222
      4.1.2  测试实施篇 234
      4.1.3  测试报告篇 248
      4.2  MQ队列 255
      4.2.1  方案设计篇 255
      4.2.2  测试实施篇 264
      4.2.3  测试报告篇 272
      4.3  本章小结 279
      第5章  高级脚本开发 280
      5.1  ExtJS 280
      5.2  Flex 283
      5.3  Silverlight 296
      5.4  Web Service 302
      5.4.1  基于WSDL的调用 302
      5.4.2  基于SOAP的调用 306
      5.4.3  基于HTTP的调用 309
      5.4.4  基于Windows Sockets的调用 311
      5.4.5  扩展Oracle数据库性能测试 315
      5.5  Windows Sockets 319
      5.6  .NET Vuser 327
      5.6.1  使用.NET Vuser测试SQL Server 2008数据库性能 328
      5.6.2  使用.NET Vuser测试C# 类库 330
      5.7  Java Vuser 331
      5.7.1  使用Java Vuser测试MySQL数据库性能 332
      5.7.2  使用Java Vuser测试JAR包 334
      5.8  iPhone 4 Vuser 336
      5.9  本章小结 339
      第6章  系统监控 340
      6.1  监控的目的和意义 340
      6.1.1  性能测试监控的意义 340
      6.1.2  性能测试监控指引 340
      6.2  中间件监控 342
      6.2.1  WebLogic监控 342
      6.2.2  TUXEDO监控 351
      6.2.3  MQ监控 355
      6.3  数据库监控 357
      6.3.1  DB2监控 357
      6.3.2  Oracle监控 369
      6.3.3  Informix监控 374
      6.4  操作系统监控 376
      6.4.1  Windows操作系统监控 377
      6.4.2  Linux系列操作系统监控 383
      6.5  网络监控 402
      6.5.1  网络流量监控 403
      6.5.2  网络状态监控 407
      6.5.3  网络通信监控 409
      6.6  本章小结 409
      第7章  行业总结 410
      7.1  数据库调优之SQL Server简介 410
      7.1.1  索引 412
      7.1.2  锁(LOCK) 417
      7.1.3  CPU消耗定位 422
      7.2  挡板在性能测试中的应用 424
      7.2.1  环境准备 425
      7.2.2  Socket挡板开发 426
      7.2.3  HTTP挡板开发 429
      7.2.4  对挡板进行性能测试 429
      7.2.4  挡板系统的性能优化过程 430
      第8章  几款性能测试工具入门速成 432
      8.1  性能测试团队 434
      8.2  性能测试流程分工 435
      8.3  配置管理 436
      8.4  性能测试自动化 442
      8.4.1  基于Windows的自动化性能测试 444
      8.4.2  基于Linux的自动化性能测试 446
      8.5  小结 446
      第9章  几款性能测试工具入门速成 448
      9.1  Silk Performer 448
      9.2  JMeter 455
      9.3  VSTS 2010 462
      9.4  Apache Bench 466
      9.5  LoadRunner 12 470
      附录A常见HTTP请求返回简介 472
      附录B常用计数器表 475
      附录C常见LoadRunner问题索引 486
      附录D常见性能测试工具 500
      附录E常用文档模板 509
      附录F基于XAMPP测试环境搭建 524
      F.1  搭建XAMPP 524
      F.2  搭建Phpwind测试环境 527
      参考资料 529
      LoadRunner工具使用详解(见光盘)
      第A章 用户行为模拟 1
      第B章 负载生成及监控Controller 156
      第C章 数据收集分析Analysis 194
  • How to clarify a concept in precise way

    2015-10-21 17:43:41

    At its most general, a business model is a general plan for converting new technology or an innovative idea into actual economic value, such as liquid money or market share. It differs from a business strategy in its level of generality. While strategy is aimed at specific distributions of wealth (e.g. to shareholders), business models are abstract visions of the mechanism that will create wealth and profit.
     
    Features
    A gap analysis is the first entity in a business model. A new technology or idea exists, therefore, a market must be found for it. There is a specific problem that will be solved by this specific innovation. From this, customers must be targeted. A specific segment of the market must have a specific problem solved by the existence of the innovation. For example, an inventor is working on a new outboard engine for boats that operates with less gas than the normal engine. The problem is high gas prices, and the market is boaters and fishermen.
     
    Function
    The purpose of a business model is to translate innovation into profit. Therefore, the value chain must be laid out at some level. The value chain is made up of five elements: inputs such as raw materials; operations, including the actual shop floor activities; outbound value, including delivery to customers; marketing, or getting the word out about the innovation; and service, or maintaining the value of the product over time, after it is in the hands of the customer. The value chain is a subset of the business model and specifically deals with the day-to-day functioning of the firm.
     
    Benefits
    The business model is meant to rationalize the nature of the innovation, that is, to place the innovation into practical, production terms. It is particularly useful when applying for financing, since the plan exists in abstract form, easily visualized by those who are interested. In other words, the idea is not enough. A practical plan is necessary to attract investors.
     
    Considerations
    Several other important features are necessary to round out the concept of a business model. The most important are the product and the identification of the market. But beyond this, complementors must be identified. These are firms and products that can help your own innovation actually work. If you are working on a new, more efficient type of outboard engine, then working with firms that provide outboard oil or propellers might serve to give the new firm a leg up on the competition. From the identification of complementors, the business model should also have something that shows how the firm will supersede its competition. This is often called competitive advantage.
     
    Effects
    The basic effect is to put an idea into the heads of all who see the plan, or model. The idea is one thing, seeing it come to life is another. Therefore, the model must explicitly show the product filling a need, making profit and being part of the "value chain" that can make rational sense out of the plan. The writing of a business model should also show the viability of the product and the market niche it is meant to fill.
     
    References
    Quick MBA: The Business Model
    Quick MBA: The Value Chain
    Comments
  • 我们的测试为什么不够敏捷-翻译成英文

    2015-09-25 16:44:15


    测试是为了保证软件的质量,敏捷测试关键是保证可以持续、及时的对软件质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代

    都会增加功能、修复缺陷或重构代码,所以在完成当前迭代新增特性测试工作的同时,还要通过回归测试来保证历史功能不受影响。为

    此我们期望:
    测试范围足够广:

    测试用例要覆盖所有功能;
    要在各种可能的环境下作兼容性测试;
    系统的稳定性、性能都要测试;
    测试频率足够高:

    每日构建产生的版本要保证可用;
    每个迭代都需要对历史功能做回归测试;
    释放前或上线后如果打了补丁,就需要回归;
    但实际情况往往不遂人愿:

    实际测试周期变短:

    上线时间提前确定,研发进度延期,测试计划被迫延后;
    最后阶段经常会临时增加测试任务;
    所有人都知道还需要再经过一轮测试,但时间没有了;
    有效测试资源稀缺:

    临时从其他项目抽调的测试人员不能立刻有效的开展测试工作;
    “搞不清楚”本项目的研发人员到底是不会做测试还是不愿做测试;
    因此由于客观上的资源和时间限制,完整的、及时回归测试在人工测试情况下,往往是不可能完成的任务。团队内部也会产生各种争执

    提交给测试的版本为什么研发人员不先做通过性测试?
    这次代码改动量不大,有必要再花那么多时间回归么?
    当初不是承诺这次修改肯定不会影响以前的功能么?
    怎么不早说要支持 Chrome 浏览器,现在哪还有时间测试啊?
    怎么能让现场出现这种低级的 Bug,打补丁后为什么不仔细回归一遍?
    争执越演越烈,最终有团队成员爆发了:“这简直不是人干的活!”。

    您怎么看待这句话呢?

    其实话糙理不糙,用更理性的语言翻译一下就是“有些工作不应该以人工的方式来完成”,比如:

    大量机械的、重复性的回归测试;
    结果的正确性不依赖主观判断的测试;
    需要模拟大量数据、大量并发量的测试;
    需要不间断执行的测试(比如7*24 小时持续执行);
    需要短时间内完成的大量测试用例执行(比如完整的功能回归测试);
    通过自动化测试可以极大的提升回归测试、稳定性测试以及兼容性测试的工作效率,在保障产品质量和持续构建等方面起到举足轻重的

    作用。特别是在敏捷开发模式下,自动化测试是必不可少的。

    目前业界的商业/开源自动化测试工具有很多,比如,功能测试工具有 QTP、Selenium 等,性能测试有 LoadRunner、JMeter 等。其工

    作原理无非都是通过“测试脚本”和“测试数据”来完成“测试过程”,并比较“测试结果”,进而形成“测试报告”。

    本文不对这些测试工具的差异或优劣进行对比,只以作者目前采用的 Selenium 为例进行分析:敏捷开发模式需要自动化测试,但自动

    化测试本身的敏捷性又如何呢?

    Selenium 是针对 Web 应用的开源自动化测试工具,通过编写模拟用户操作的脚本,它会打开浏览器对 Web 应用进行黑盒测试。可以方

    便的用于功能测试、兼容性测试、 稳定性测试及并发测试。目前已被主流浏览器厂商广泛支持,同时也是很多其它自动化测试工具(比

    如,RobotFramework)的底层核心技术。Selenium 由 IDE、Remote Control(简称 RC)、WebDriver、Grid 四个工程组成:

    Selenium IDE
    是一个用于录制/回放测试脚本的 Firefox 附加组件,录制的脚本可以生成基于 Selenium RC 的测试代码(Java、Ruby、C#等)。适用

    于快速入门,不太适用于实际较大的测试项目;

    Selenium RC
    RC 由 Server 和 Client 组成两部分组成,Server 负责加载/关闭浏览器以及作为 HTTP 代理来访问 Web 应用,Clinet 支持多种编程

    语言和测试框架(TestNG、JUnit、NUnit 等)。

    Selenium WebDriver
    WebDriver 作为 Selenium2 的核心特性提供比 RC 更简洁易用的 API,是官方推荐的 RC 替代方案。可以更好的支持动态网页,不需要

    再额外启动一个独立的 Server。

    Selenium Grid
    是 Selenium 的一个扩展工具,可以很方便地同时在多台机器上和异构环境中并行运行多个 RC 或 WebDriver 用例。

    Selenium RC 是通过在浏览器加载时“注入”JS 函数来操纵后续的浏览器行为,Selenium WebDriver 则通过直接调用各个浏览器内置的

    本地事件来达到这一目的。WebDriver 目前已经作为 W3C 规范草案,提交由 Google、Mozilla 等浏览器厂商讨论。

    WebDriver 规范定义一组与平台、语言无关的接口,包括发现和操作页面上的元素以及控制浏览器行为,主要用于支持 Web 应用的自动

    化测试。WebDriver 的核心是通过 findElement 方法返回 DOM 对象(WebElement),通过 WebElement 可以对 DOM 对象进行操作(获

    取属性、触发事件等)。其中 findElement 方法需要的元素定位器(Locator)支持 ID、XPath、CSS、超链接文本等多种方式。

    “WebDriver”顾名思义就是“Web 浏览器驱动”,它专注于解决如何通过外部命令(通常为测试用例)操作浏览器的问题。至于测试用例按

    照什么顺序执行、执行过程中如何传递数据、测试结果如何断言、如何报告,则可以通过集成其它优秀的专业测试框架(比如,TestNG

    )来实现(WebDriver 没有必要重复造轮子)。

    通过上面的脚本就可以实现“用户增加、删除”的自动化测试,并且可以跨浏览器。看到这里您会不会觉得整体还不错,如果测试脚本再

    能通过录制的方式自动生成就更好了!

    “看”起来确实还不错,但在实际项目中用起来就没那么爽了。这其实是在技术/工具选型时普遍存在的现象:在验证/试用阶段的评价很

    高,但在投入生产使用时会遇到各种各样的问题,因此大家在选型阶段除了考虑功能,还要考虑技术/工具本身的开放性和可扩展性。

    上面的方案单纯从技术的角度来讲是很不错的:开源、社区活跃、标准化程度高、支持跨浏览器、脚本回放稳定、可集成性高,等等。

    但是如果就这样应用在实际项目中,会从过程的角度暴露一些棘手的问题:

    测试脚本是“代码级”的,那么应该由谁来编写呢?
    测试人员和开发人员好像都有编写这些测试脚本义务,但似乎又都有不写的理由。

    测试脚本必须不断的修改才能在最新版本上跑通,谁该为此买单?
    在敏捷开发过程中需要快速响应需求的变化(新增、变更),这一点整个团队都好理解。因此如果需求发生变化,开发人员修改代码、

    测试人员修改测试 脚本,一切顺理成章,大家相安无事。但是在用户需求没有变化时,开发人员频繁修改代码的情况也很常见:比如,

    修改 Bug、针对“坏味道”做重构、调整页面布局或样式。于是在“毫无征兆”的情况下,测试脚本又无法执行了!

    这时候测试人员可能会质问开发人员:“做之前怎么不想清楚?都已经测试完成的功能,为什么还总是反复修改?什么时候代码才能稳定

    ?”。

    而开发人员此时也会非常理直气壮:“有 Bug 能不改么?页面布局不合理导致用户体验差,能不改么?而且敏捷中的一个重要的实践就

    是重构啊”。

    大家又是似乎都有道理、也都有苦衷。我虽然作为测试人员,但是在这个问题上还是“偏向于”开发人员的: 在软件生命周期的各个阶段

    (需求、设计、开发、测试)中,后面的阶段对前置阶段是有一定依赖的,所以越往后期响应变化的难度越大。比如,在“开发”环节不

    仅需要响应“需求”的变化(新增、变更),而且需要响应“设计”的变化。从这个角度来看,“测试”本就应该响应“开发”的变化。

    对于在实际项目自动化测试过程中遇到的上述问题,归根到底是因为“自动化测试方案本身的敏捷程度不够”,主要体现在如下三个方面

    1、 学习成本高

    测试人员除了要掌握 WebDriver 接口之外,还要掌握 XPath、TestNG 的用法,甚至还需要对功能的前台实现有一定了解。

    2、 脚本维护困难

    敏锐的开发/测试人员从上面的示例脚本中,可以马上嗅出一些“坏味道(Bad Smell)”: 代码相似度非常高、可能变化的数据被硬编码

    在测试代码里、代码可读性差、测试代码与页面源码耦合度大,等等。这些坏味道的出现,通常意味着需要进行重构, 否则会愈演愈烈

    ,最终变得尾大不掉。

    【注】业界常见的测试工具本质上还是针对页面源码来编写(或生成)测试脚本的,即使提供了录制工具,此类脚本的可读性和后期可

    维护性还是非常差的。

    3、 断言条件繁琐

    业界常见的测试工具即使提供录制脚本的功能,但是对于“断言”还是需要人工插入的(工具做不到智能的判断我们想要在哪里设置断言

    ),于是断言就成了自动化测试人员的“噩梦”。

    断言对象可能很“多”,页面的信息量往往很大,需要在测试脚本中为每个断言对象(比如,页面某个文本框的值)补充断言语句。

    预期结果是可能“变”化的,甚至是动态的,因此预期结果的值如果与脚本逻辑耦合在一起,将来极难维护。 断言机制比较“呆”板,对于

    未设为断言对象的字段,如果发生错误也是无法感知的,并且难以对于 UI 样式或 UI 逻辑(比如,翻页图标应该灰显)进行断言。

    换个角度可以理解为,如果这样的断言条件“多”的话,整个测试用例集会“变”的非常“呆”板!

    想要有效的改善这些问题,就必须让自动化测试变得“敏捷”起来!

    在本系列后续的文章中会就“如何让测试脚本易写、易读、易维护”、“如何让断言不再成为测试的负担”、“如何通过持续集成让测试用例

    发挥更大的价值”进行详细的介绍,敬请关注!

    作者简介

    殷坤,东软集团资深测试经理、技术讲师,10 年软件研发、实施、测试及项目管理工作经验。 目前专注于敏捷项目管理及质量控制、

    过程改善、自动化测试、持续集成、用户体验提升等方面

     

  • 关于测试人员的职业发展

    2015-09-17 14:32:43

    近期由于项目组人手不够,需要招聘一些测试人员。本周及上周陆陆续续面试了十多个应征者,工作年限在2年~9年之间,但无一满意。期间,种种感叹,回想起去年面试六十余人仅有3人满足要求,如有鲠在喉,还是吐槽一下。如有不对请大家也狂喷我。

    我的要求高么?

    我的要求其实是:有还算不错的沟通能力,熟悉常见软件开发流程,有一定的需求分析、用例设计能力,会基本的linux和sql操作能力。有一些代码能力会加分。这是长期与现实妥协的结果。如果人还算机灵,其实我很愿意花时间来培养他们。

    面试结果

    令人惋惜的是,一个合适的人真的很难找。更令人惋惜的是,我看到好多入行很多年的同行,能力并没有跟随工作年限一同增长,有些做了五六年的人有时候给人感觉竟然还不如一个入行一两年的年轻人。最令人遗憾的是,大部分同学竟然没有一个明确的职业发展思路,即使有,也没有经过深入一些的思考,而是人云亦云。

    面试的一些细节:  

    因为从事的工作是业务密集型的,有的业务逻辑非常复杂,我们特意准备了一份不错的需求(考虑到应试者没有行业背景,给出了详尽的专业说明和例子),并根据这份需求出了几道用例设计的题。只有不到四分之一的应试者给出了让人相对满意的答案。我们内部评估这份需求的时候,认为只要有过一两年的用例设计经验,应该能答的不错。

    我一般会根据简历问一些问题,看看简历的真实性。也会问一些基础的测试知识,查看应试者的专业素质。

    常见的问题:

    说说你常用的测试方法? 百分之九十的人只能答出等价类和边界值。只有少数人可以讲出其它测试用例设计方法,但深入问,从没有一个人能有令人满意的回答.

    给一个非常简单的小例子,例如登陆操作,让应试者回答如何使用等价类方法设计用例。但让人吃惊的是仍然只有不到五分之一能够给出比较满意的答案。

    陈述一个缺陷的生命周期(你们是怎么管理bug的?)有一多半人能够说出常见流程,但深入问一些问题:如缺陷如何同版本、测试轮次等结合起来,一些特殊情况如何处理等,很多人就懵了,而这些基本上都是工作中常用的。

    你做的最长的一个项目是什么?在这期间你遇到了什么问题让你最头疼?你如何解决它?十个人里大约只有一人能给出还算不错的答案(能够识别出问题,提出它带来 的不利影响是什么,并能够给出一定的解决方案就算是不错的答案了)。

    你感兴趣的测试工作是什么,你想在哪方面有所发展?十个人里有4个会说是自动化测试,3个会说性能测试,2个会说是管理,一个会说是白盒测试。并希望提供相应培训。只有极少数人能够说出具体的思路和技术项。

    如果继续追问:你说的是性能测试吧?你有过这方面的学习么?一半会说看过一些网站上的技术文章,一半会说看过loadrunner的书。如果继续追问,是哪本书?是哪类文章?有哪些具体的知识点能讲一下么?90%答不上来。

    问:你有看过哪一本测试书籍?哪些技术博客?哪些网站?50%的人会说看过QTP的书(QTP的真正使用率已经快赶上诺基亚的使用率了,国内主流自动化的书竟然还是这个!),并且没有真正在工作中使用过,然后就没有别的了。有少一半人最近几年一本技术书籍也没有看过。

    如果有管理经验的应试者,我会问一些测试过程管理相关的问题,如给一个最简单的题:如果测试时间不够如何?十个人中只会有两三个提到排定优先级和测试裁剪,大部分人的回答竟然是加班也一定要搞完。

    我想说的:

     1.为了你的前途,请多明确一些个人能力思路吧。你五年后,十年后是个什么样子?有没有一个明确的想法?有没有你五年后想达到的某个人的程度?如果这些思路不清楚,请多看看外面的世界,看看一些测试做得非常好的人是如何工作的,他们掌握了什么能力?学习他们,追赶他们并尝试超越他们。最好认识他们,可以侃侃大山,志同道合抱团前进很好。另外目标别定太抽象,一定要是可以分解,可以检查的。

    2.多读一些测试书籍,测试的书并不是只有QTP!看看微软测试专家史亮推荐的书单,这些都是不错的好书:http://www.cnblogs.com/liangshi/archive/2011/03/07/1973525.html 有些书能够帮助你把测试知识框架搭建起来,比照一下你还缺点啥?

    3.多读一些其它书籍,不限于技术书籍。如果想读的书有利于工作,推荐一些如何做思辨思维的书。《思考的艺术》《六顶思考帽》《你的灯亮着么》 《学会提问》是我喜欢的4本书。它们会教你怎么独立思考,养成提问的习惯,而提问的习惯是我们现在的测试人员最缺乏的一件事情。人们往往拿了被测物就开始忙着写用例,忙着测试。而不是先探索它、研究它。当然IT技术也要掌握,如果你的IT技能能够赶上开发,你发现你做测试的思路会非常的宽广:)

    4.把书籍中的东西跟你的工作对比,把好的东西引入工作(这点是检验书本质量的好方法,也是促进你思考,促进你能力提高的好方法。

    5.关注大牛们的技术博客。国内写好测试博客的人不是很多(很多人其实很有水平,但是不喜欢写blog),但是国外有很多,有人整理了一个list也推荐给大家:http://ssnlove2008.blog.163.com/blog/static/3788942020093284842381/。

    6.搞定你所在行业的领域知识:如常见IT技术,常见业务知识,这些知识掌握的越深,你的价值越高。测试技术是内功,但是你能直接为企业带来价值的最大之处是你对被测物熟悉程度,也就是你的领域知识!!!

    7.没有方向?从你的工作入手,比如,你遇到的最大的难题是什么?我怎么解决它?我需要掌握什么样的技术解决他?我要推动什么样的组织改变来解决它?别人怎么解决它?有没有更好的方法?使用后我改进了那些?google一下别人有没有同样的问题?尝试作对比,如果觉得他做得好,尝试联系那个人讨论一下。看看对方的进展。尝试把活儿干得特别漂亮。你能解决10个中等问题以后,你的能力会有大幅度提高。

    8.尝试做笔记。最好是在线的,推荐印象笔记和有道云笔记。

    9.坚持。

    10.保证身体健康,岁月会给你带来别人的信任感(当然能力要随着岁数增长)。

    能做到这里面的一半,两年后你就能在专业上有高分通过我的面试:)当然肯定你也不见得会看得上我们的offer了。

    11.对于没想好就跳槽,换行业的同学说:你再想想!你的很大价值是与你企业、行业绑定的。如:做了5年保险业务,你的领域知识至少值5w每年,换领域就没了。你在一家公司证明了你自己,到新公司要重新证明你一遍,有的时候外部环境、机遇等会让证明过程很痛苦,成本很高。

    另外的吐槽:

    野蛮生长没有经过系统训练的同学非常多。这其实有很多因素,分析起来觉得有以下几点:

    1.大学或者职业教育没有非常好的课程体系(有些培训机构还行,但是也需要提高),其实测试技能需要系统训练和长时间磨练才能有根本的增长,我们的职业教育或者再教育体系其实还是有很大空白的。

    2.说句实话,大家的读书氛围不够浓厚。大家不喜欢看书。而读书是再教育成本最低,又非常有效的途径。相比于程序员,测试同学喜欢读技术书籍的比率明显的低,这是一个让人悲伤的事实。真希望这种现象能够改变。

    3.很多人是不喜欢coding才转测试,或者是因为IT产业普遍薪水高才来做测试。不是真正热爱这份工作,不热爱其实做不好,因为兴趣是最好的老师。

    4.很多人认为测试门槛低,young talent 不愿意干,测试吸引人才有点儿困难(我初入行的时候也有这种想法,也是当时被强拉来做测试的,当时想做的是coding和数据DBA相关工作并已经有了一些积累,(我没说我是啥人才啊))。说实话测试的入门门槛的确有一点点低,但是做好测试的门槛确是相当的高,随着系统越来越复杂,测试逐渐会比开发还难做,更有挑战性,我这么说你信么?

    5.专业化社区还没有形成规模,测试人员没有能有效交流的平台。这是跟美国和欧洲的一个挺大的差距。他们的社区做得挺好的,我们也有了一些很好的起步。如一些热衷测试公益的同学,一些不错的会议,一些不错的线下活动,但还需要大大的发扬光大。

    真心希望测试行业的整体水平能够逐渐提高起来。

  • 美国众议院对华为和中兴的调查报告

    2013-04-18 15:15:05

    转:http://www.valleytalk.org/2013/04/15/%e3%80%8a%e5%af%b9%e4%b8%ad%e5%9b%bd%e7%94%b5%e4%bf%a1%e5%85%ac%e5%8f%b8%e5%8d%8e%e4%b8%ba%e4%b8%8e%e4%b8%ad%e5%85%b4%e5%bc%95%e5%8f%91%e7%9a%84%e7%be%8e%e5%9b%bd%e5%9b%bd%e5%ae%b6%e5%ae%89%e5%85%a8-3/

    系列目录 美国众议院对华为和中兴的调查报告

    1. 《对中国电信公司华为与中兴引发的美国国家安全问题的调查报告》(概述)
    2. 《对中国电信公司华为与中兴引发的美国国家安全问题的调查报告》-报告部分
    3. 《对中国电信公司华为与中兴引发的美国国家安全问题的调查报告》-调查部分
    4. 《对中国电信公司华为与中兴引发的美国国家安全问题的调查报告》-华为部分 (上)
    5. 《对中国电信公司华为与中兴引发的美国国家安全问题的调查报告》-华为部分 (中,下)
    6. 《对中国电信公司华为与中兴引发的美国国家安全问题的调查报告》-中兴部分(全)

    (五) 华为没有提供关于中国政府1999年对于公司税务欺诈调查材料。委员会认为这加深了人们对华为不透明化的看法;华为很轻松的摆平了中国政府的此项调查损害了其声称的中国政府认为华为是一个不受欢迎的电信解决方案提供商的说法。

    华为官员声称,在华为90年代从农村区域(的交换机市场)开始成长并取得了很大的发展后,华为官员认为,那次调查是华为公司的竞争者在后面指使的。这些电信公司都是一些国有企业。华为的胡厚锟先生指出那次调查是华为公司的一个历史转折点。华为从此进军海外市场就是那次调查的结果。华为这些官员试图通过这次调查来解释华为不是一个中国国家扶持的企业。

    既然那次中国政府的税务调查对华为后来的战略转变是如此的重要,委员会随后的问题和相关文件的请求就聚焦在关于事件的具体信息和记录上。委员会尤其试图得到中国政府对于华为的调查结论。当我们发现华为在深圳的一些官员对他们当时如何利用关系网来摆平政府的调查引以为豪的时候,这个调查结论对于调查委员会就显得特别重要。华为这些官员的能量让调查委员会觉得华为不是象他们所说的那样没有政治背景或者政府的影响。

    尽管这个事情的来龙去脉是如此重要,华为没有针对调查委员会的问题提交书面材料。华为也没有能够提供材料来证明针对华为的那次调查在法律层面已经完全结案,或者没有任何附加的条件。

    (六) 华为未能解释其与西方咨询公司的关系,公司的成功是得益于这些关系而不是中国政府的支持的声称缺乏信服力。

    华为官员声称,公司成功的原因之一是其对西方咨询公司,如IBM、埃森哲、普华永道会计师事务所等提供的咨询服务的遵从和依赖[82]。华为试图说服委员会,其在最近的几年里奇迹般的增长得益于这些公司的建议,而不是中国政府的支持。[83]

    由于华为强调其对这些咨询公司给出的建议的重视,委员会试图寻求更多的信息和证据以表明过去的这些建议对公司有重要影响。委员会明确表示不会探究华为与咨询公司在商务合约方面的信息,而是会调查这些公司对华为的哪些信息进行了评审及为华为提供了何种建议。委员会承诺将对这些信息保密,以避免产生对泄露公司商务信息的担忧。

    华为仅对这些公司提供的建议做出了一个比较模糊的回应。具体而言,尽管“自从1997年起,华为依靠西方管理咨询公司帮助其改善运营能力,建立流程,并根据客户需求的驱动开发了一个综合管理系统”,华为未能提供详细资料说明这些公司如何改革华为,还是这些咨询公司仅仅提供了几句提到标准商业行为的建议,包括从线索到回款的合同周期管理(LTC),集成产品开发(IPD),问题解决(ITR),以及综合金融服务(IFS)。华为“拒绝提供关于其和咨询公司关系更多的细节”,表达了对关于在这些建议中存在专(私有)有信息的担忧[84]。委员会解释说,其最关心的是那些华为对这些咨询公司的建议作出了什么反映的证据,特别是财务或其他证据,以用来证实华为的声明:这些改变提高了公司的效率、增长和市场成功[85]。华为其实可以在不透露公司机密的情况下回答这些问题[86]. 委员会也表示愿意与各方签署保密协议,但这项提议被华为拒绝接受。[87]

    通过将其快速成功归因于由这些咨询公司提出的建议,华为认为这些咨询建议的细节与这次调查相关。那么对华为而言,对委员会隐瞒这些可以令其评估那些声明的信息就是不合情理的。如果华为拥有那些信息和文件,可以证明这些由咨询公司提供的协议对华为的成功具有关键作用,那么华为应当提供这样的信息88。委员会愿意并将继续愿意与各方讨论机密协议,以解决关于专有信息泄露的担忧。华为未能接受这一提议。华为的拒绝显示了华为在整个调查过程中缺乏合作。

    (七 ) 华为没有回答关键问题或提供证明文件以表明其在财务上独立于中国政府。

    作为一家对中国具有战略重要意义的公司,华为的地位可以从其来自于中国政府和中国共产党的财政支持和接受的政策指导体现出来[89]。检视一家公司受国家的支持和引导的方法之一就是看该公司的资金来源。许多业内专家和电信公司都描述华为产品通过低于市场价格的方式销售[90]。因此,委员会试图寻求更多关于华为融资的信息,包括其客户的财务情况。这样的财务信息也能够有助于更多地了解一家在很大程度仍不透明的公司的财务结构。

    在委员会的听证会上,丁先生表示他不理解或不知道“国家龙头企业”的称号. 这个称号经常在关于中国的经济文献中被用来描述受国家青睐的公司[91]。委员会认为丁先生说他不理解这个称号是不可信的,华为自己在2011年11月向美国国会办公室提供了一个幻灯片,里面就多次使用了“国家龙头企业”的字眼[92]。在回答委员会提出的有关在那份文件中使用了该术语的问题时,华为并未否认其使用了该文档并提供了包含该术语的文档[93]。然而,华为声称那份包含在其他更多的文件里面的那个幻灯片是由第三方撰写的,因此不是华为的责任[94]。然而, 委员会认为,华为在与美国调查委员会的代表讨论时知道自己曾经使用该文档表明了足够的证据显示华为是了解这个术语的意义的。

    丁先生一直坚持拒绝回答哪家公司被认为是中国电信业的“国家龙头”的问题被认为是(对调查的)蓄意阻挠。事实上,他在回答委员会这个问题时说“华为在此前没有关注过 ‘国家龙头企业’这个称号” 显然是不真实的,这与该公司之前在其幻灯片中使用了这个术语背道而驰[95]。此外,他的回答还表明,他并不想解释为何华为作为中国第一大电信服务提供商在中国不是一个具有战略重要意义的公司。而这是世界众所周知的。

    华为官方也否认收到了来自中国政府的任何特殊的财务激励或资金支持[96]。华为声称,该公司只是和中国的银行的进行了正常的合作,但并没有去试图影响或协调中国发展银行和进出口银行这样的国有银行。在之前的陈述中,华为已表明,它只是作为国家金融信贷和客户之间“中介和桥梁”[97]。然而华为拒绝提供关于这些信贷额度如何被使用的更多细节。华为也拒绝回答其与中国银行所建立的正式关系的具体情况,而只是选择回答了它与中国进出口银行只是保持着“正常商业联系”的问题[98]。

    在2月份的会议期间提交给委员会的陈述中,华为提供了一系列谅解备忘录,关于其已为相关客户与中国银行签订了信贷额度[99]。华为承认它的客户有1000亿美元的可用信贷,但华为声称从2005年到2011年期间信贷金额只有58.67亿美元。此外,在书面答复中,华为声称 “这是给客户提供的融资机会,而不是华为的”[100],然而,在2012年2月23日的与委员会调查员的会面中,华为解释说中国的银行支持大额度的可用信贷的目标是让人觉得中国的市场是“吸引力的和印象深刻”, “华为不得不参与其中否则将不再能够”从中国的银行获得贷款101。在回应委员会重复的问题和对文件的要求时,华为未能就公司从这些融资安排所得到的利益提供进一步的书面解释,也没有提供内部文件或任何可审计的信息,来证实其对从中国的银行的贷款的范围和流程。

    同样,华为也拒绝详细描述其与中国国有银行的关系。例如,在丁先生的备案声明中,他解释说华为从10家中国银行获得贷款,但丁先生拒绝回答这10家银行中有多少家是国有银行[102]。正如上一节所描述的那样,华为也拒绝提供额外的“咨询关系”的细节,因为它可能涉及已经签署了的含有“高度敏感的专有信息”的保密协议[103]。在回应委员会关于华为的成功及其是否归功于中国政府的支持的问题时,华为再次向委员会说明,它在全球的成功得益于华为与咨询公司的关系以及从这些公司得到的建议[104],由于华为拒绝提供关于这些关系和所得到的咨询意见的细节信息,委员会无法评估它声称成功是源于这些关系。因此,委员会不完全相信这些咨询公司所起到的作用,并继续认为华为的成功可能在很大程度上是由于得到了中国政府的支持。

    总而言之,华为承认其客户获得了来自中国国有银行数十亿美元的支持,也承认多年来收到了中国银行的优惠贷款。华为拒绝对有关这些援助是如何被担保的问题提供直接答复,也没有提供内部文件或可审计的财务记录,以用来评估其声称的这些协议的条款符合标准程序和国际贸易协定。委员会也同样关注由公司领导层提供的声明,这些声明也都削弱了委员会对该公司所提供的财务信息的信心。例如,在2007年6月对华为英国员工发表的演讲中,任先生说,他赞赏子公司创建的财务报表,“不管数据是否准确”[105]。根据现有的资料,委员会认为华为从中国政府和中国的国有银行得到了大力支持,这至少在部分程度上帮助华为奠定了其在全球市场中的地位。

    (八) 华为美国分部未能提供足够的关于其在美国的运营、财务及管理方面的细节或支持文档; 这些都破坏了所谓的华为美国是一个完全独立于其在中国深圳母公司的子公司的声称。

    为了理解华为的设备对美国当前脆弱的供应链带来多大的威胁,有必要了解华为的设备在多大程度上已经被放置在美国的基础设施中。因为美国的电信基础设施主要是由私营部门建造和拥有的,美国政府并不完全了解它包含了什么,因此尚未完全知情,并制定相关的政策来保护关键基础设施[106]。

    委员会因此要求华为提供其在美国的产品和服务合同的信息。了解华为的设备在多大程度上已经存在于美国,对于评估目前给国家带来的风险是很必要的,同时也能核实华为提供的关于其在美国的规模和业务范围的声明。遗憾的是,华为未能提供其在美国商务交易的具体信息。华为的确向委员会提供了一份在美国的客户清单,包括: Cricket Communications、Clearwire、Cox TMI Wireless、Hibernia Atlantic、Level 3/BTW Equipment、Suddenlink; Comcast 和Bend Broadband等公司,但华为并未提供其运营规模和范围、向基础设施提供何种元件及在何地运营等信息[107]。

    委员会所要求的关于华为在美国的合同信息对用来评估华为所声称的它们销售的产品和服务的价格遵守了所有法律和贸易义务也是非常有必要的[108]。到目前为止,华为未能提供任何信息,用来证实其宣称的华为产品的价格是根据市场来制定的。华为拒绝提供明确答复或文档支持其声称,迫使委员会认为华为的辩解是不可信的。委员会认为华为可能收到来自中国政府的大力支持,以使华为在美国至少有一些产品以低于成本的价格在市场销售。

    同样,华为在美国的子公司在多大程度上独立于在中国深圳的母公司运营仍不清楚。这样的信息是重要的,因为在中国的母公司与中国政府的任何联系都可能影响美国分公司的运营和行为,委员会因此要求华为提供信息说明华为美国公司的决策在多大程度上受到母公司的控制、影响和审查。

    华为解释说,第一个美国华为子公司成立于2005年,总部设在德克萨斯州普莱诺。华为表示其母公司不需要批准在美国的合同个案[109]。相反,它表示在中国的董事会并未对在美国的运营设置通用条款,并且如果子公司需要,父公司可以帮助它调动资源并制定战略。然后,委员会已从数位前华为美国员工那里得知他们不同意华为对其美国分公司运营模式的解释。来自美国各地的资料也提供了大量具体实例,表明在美国的商业决策需要通过中国母公司的审批。在一个案例中,一位具有第一手资料的知情者解释道, 没有中国的批准,美国的高级主管不能签署关于在美国的网络安全服务的合同。事实上,在一个实例中,先前由美国高级官员签订的合同后来被母公司拒绝[110]。在讨论华为美国来自中国母公司的政策时, 这些华为前员工提供了包括内部备忘录和电子邮件在内的文档证据。这些关于华为美国子公司的描述也与其他华为分公司和中国母公司之间关系的报告相一致[111]。

    为解决这个矛盾,委员会试图从其给华为的书面问题质询中获得更多信息,以便理解华为深圳母公司通过何种精确机制来控制华为在美国市场进入和增长的策略。当华为官员声称,如果需要的话华为美国将从母公司得到一般性的方向指导和相应的“资源”[112 ], 调查委员会对于北京对华为的支持可能影响美国市场的担忧被加重了。然而,在其书面回复中,华为未能回答委员会的细节问题,或提供更多关于华为美国子公司和其母公司之间协调层面的细节信息[113]。

    由掌握一手资料的华为员工提供的信息和材料,再加上华为未能提供详细的内部信息,这些都削弱了华为声明的可信度。基于这些原因,委员会认为华为关于其美国子公司独立于华为深圳总部运营的声称是不可信的。

    (九) 有证据显示,华为对美国公司和实体的知识产权表现出一种漠视。

    华为对知识产权的保护能力,是该公司是否遵守美国的法律能力的重要佐证。因此,委员会试图寻求更多关于华为在知识产权保护方面过去的记录。

    委员会有理由相信,华为并未严格执行知识产权保护相关法律。调查人员从大量渠道得知,当涉及到保护其他实体的知识产权时,华为的态度一直是多变的[114]。特别地,一些前华为员工声称,华为有意使用其他公司拥有专利的材料是众所周知的。前任员工掌握的第一手资料表明,华为并未恰当地购买软件程序以供其员工使用[115]。同样,委员会从业界专家那里得知,华为曾有意使用和销售其他公司的专利产品[116]。 最后,委员会收到了一份华为公司提交给美国国会办公室的幻灯片,该文稿其实就未经允许使用了一家外部咨询公司的相关材料,这本身就违反了知识产权保护原则[117]。

    华为官方一直否认曾侵犯其他公司的知识产权。即使在关于华为与思科的诉讼方面,华为已经同意从市场上撤出某些产品,但华为仍声称,它并未侵犯思科的利益[118]。相反,华为认为,在那次对其设备的专家审查中没有发现任何侵犯思科的专利[119]。

    华为的辩解是不可信的。首先,关于思科的诉讼,华为的声明与华为官员在诉讼期间的声明并不一致,当时华为表示将从市场上撤下侵权设备[120]。其次,当时和思科的庭外和解的协议中包含了要求华为“更新和更改所有被指控侵犯版权或知识产权的产品”[121]。最后,在2012年9月13日的听证会期间,查尔斯•丁拒绝明确回答思科的代码是否曾被用在华为的设备上[122]。丁先生在听证会期间的蓄意阻挠,违背了华为关于自己并未侵犯思科专利的说法。

    委员会发现,华为否认侵犯知识产权的说法是不可信的或者并没有可靠的证据支持相反的观点。由于华为未能出示任何内部文件或证据来支持其辩解的观点,委员会认为华为对其他实体的知识产权至少是表现出一种漠视的态度。

    (十) 华为未能提供关于其在伊朗业务的详细信息,尽管其否认与伊朗政府有商业往来,但未能提供证据证明其遵守所有的国际制裁或美国出口法律。

    华为遵守国际制裁制度和美国出口管控法规的能力,是该公司独立于中国政府的影响或利益去遵守公司行为的国际标准和美国法律的一个重要指标。目前公开的报告质疑了该公司遵守这些法律的能力。

    在对委员会问题的回复中,华为官员只提供了很模糊的陈述来表明他们会遵守所有相关的法律,特别地,华为声称该公司尽力遵守所有的法律法规,并在外部商业顾问的建议下转变其商业模式以便更透明地监管公司行为以确保符合国际制裁制度的要求。为了强调中国政权对华为商业决定没有影响力,华为指出,中国驻伊朗大使馆对华为决定限制公司在伊朗的业务发展感到十分惊讶。华为也声称它禁止其员工参与在伊朗任何地方的网络活动,如人口监测等。

    尽管如此,华为拒绝回答关于其在伊朗或其他受制裁国家的业务的详细问题。在其提交给委员会的书面资料中,华为再次重申它限制了其将来在伊朗的业务,主要是因为国际社会进一步的制裁以及在伊朗回款的困难度增加。不过华为也强调, “华为尊重其与客户签订的合同”,因而不会终止在伊朗现有的合同[123]。华为声称将“遵守联合国、美国、欧盟以及其他国家和地区关于制裁的法律法规[124]。”同时也声称已经建立了一个关于贸易合规的内部流程,从而可用最好的去处理这些事务[125]。但华为拒绝提供任何有关其决定缩减在伊朗的业务,或其他有助于让我们相解华为(美国)在遵守美国法律的内部文件。

    这些资料其实可以帮助华为证实其做出的公司的决策是基于遵循法规的要求,而非基于中国政府压力影响。

    (十一) 华为拒绝提供其研发项目细节和其他文件,这降低了华为所声称的没有为中国军方或情报部门提供研发帮助的可信度。

    为了了解华为在多大程度上为中国军方或情报部门进行研发活动,委员会要求华为提供关于其代表中国政府或军方的相关业务的信息。具体而言,委员会要求华为提供由中国政府支持或资助的任何技术,设备,资金项目的信息。在其提交给委员会的书面材料中,华为未能提供关于政府支持的研发活动的具体细节[126]。相反,华为只是声称它仅仅竞标公开投标项目[127]。

    在与委员会的会谈中,华为同样声称其并未对中国军方或国家安全部门提供特殊服务[128]。

    在回答委员会听证会后的问题时,华为又一次宣称其“从未运营过任何解放军的网络”以及“从未受到中国政府的资助去帮助军方系统进行研发项目”。然而,华为的确承认它为中国军方开发了占华为总销售额千分之一(0.1%)的“传输网络产品、数通产品、视频会议产品、数据中心和VoIP产品[129]”。然而, (矛盾的是), 华为也声称,它“仅仅为民用目的开发,研究和制造通信设备。[130]”

    委员会也从前任华为员工那里收到华为内部的文档,文档显示华为曾为一个被认为是解放军内部的特种网络战部队提供特殊网络服务[131]。这些文档看起来是华为官方可信的文件,该前任员工声称在他还是华为员工时收到的这份材料[132]。这些文件再次表明,当描述该公司代表解放军所进行的研发和其他活动时,华为官员也许不是那么乐于提供信息。

    委员会发现华为关于其对中国军方的销售额的陈述是内在前后矛盾的。委员会也发现华为未能完全回答关于其研发活动的细节问题,再加上它承认为中国军方提供了产品,以及从员工那里收到的文件,都削弱了华为所声称的没有为中国政府或军方进行研发活动的可信度。

    (十二) 前任与现任华为员工提供了关于华为官员潜在非法行为的模式与实际证据

    在调查期间,一些前任和现任华为员工主动提供了关于华为在美国行动的声明和指控。出于所涉及问题的敏感性考虑以及为了保护证人不被报复或解雇,委员会决定对这些人的身份保密。委员会已从这些人那里收到关于华为官员一些潜在违规行为的大量可信的证据。这些指控包括:
    * 违反移民法
    * 贿赂和腐败
    * 歧视行为
    * 侵权问题

    具体 而言,委员会从许多员工那里听说,从中国来短暂旅游签证或持会议签证的华为员工事实上在华为美国全职办公,这违反了美国的移民法。类似的,华为员工提供了可信证据表明,持特殊技术人才签证(如工程师专业)来美国的人在华为美国并未被被雇用。这些与其他违反移民法的指控将被移交国土安全部进行审理及有可能的进一步调查。

    其次,员工实例指控了华为在与美国寻求商业合同时有欺诈和贿赂行为[133]。这些指控将被移交司法部进行审理和可能的进一步调查。

    第三,委员会约谈的华为员工谈到了对华为官员普遍的歧视行为的指控。这些员工声称,对于非中国籍员工而言,在美国的华为机构获得提拔是非常困难甚至不可能的。此外,这些员工声称非中国及员工经常被解雇,工作岗位被 来自中国持短期签证的员工所取代[134]。这些指控将被移交行政机构的相关部门进行审理和研究。

    最后,委员会从前华为员工那里得知,华为在其美国办公部门建立了一种使用盗版软件的方式并行为。如前所述,委员会收到消息称,华为公司的商标标志有意的而且公开的违反了另一家公司受版权保护的材料[135]。委员会因此发现,华为公司非常粗心的不顾其他机构的版权问题。由于这些员工的指控可能是可信和属实的,委员会也会将这些指控移交司法部进行调查。

  • 透明化--走向中高层管理的信任之道

    2008-12-27 09:55:09

    在个人的职业生涯中,不可否认技术能力和管理能力一直为众人所重视,很多人忽略了个人工作的透明化、学习的透明化,甚至个人生活的透明化, 只是获得更高层的信任和了解的唯一途径。 正所谓成也萧何, 败也萧何,只有简单的背景和面向高层透明化的工作才能为现代普遍的中小企业老板和高层认可。

    待续...

    在这个敏感的年代,属于公众主导的社会,信任是非常宝贵的东西,个人若要事业成就,就必须学会做一个公共人物。

    我们可以举很多例子,如你身边的高管,简单的个人背景,透明的行为,他们的行为往往容易被身边的人,大众所有接受。没有任何污点。

    大家一直有一种共识:不开放的东西,完全暗箱的行为,是有风险的。这也是老板用人的原则。

    记得一句名言:污点,只有用血才能洗干净。借鉴之处在于:当我们因为污点辜负了别人的信任,再重建信任,需要付出极大代价。

    你是一个团队的核心吗?你是一个关键的合伙人吗? 你是一名创业者吗?

    你值得以“身家性命”相托吗,你能理解什么“以饭碗相托”吗?

    这就是信任的最核心的价值。

    也许有人会说“获取老板的信任, 是靠拍马屁”,我在这里想说这只是获取信任的一部分,这信任是很浅,不牢固,不能赢得尊重。

    信任是动态的,也是有限的,需要互动,透明化自身的行为,实际是一种自我接受监督的状态。

    如果说记录是信任的历史,那么透明化行为则是信任的现在。

    希望与有志之士分享一些思考。

     

Open Toolbar