手机设计公司是根据不同的手机研发平台来设计不同性能的产品！
手机研发的基本流程是：
用一个较简单的阐释，一般的手机研发公司是需要最基本有六个部门：ID、MD、HW、SW、PM、Sourcing、QA。
1、ID(Industry Design)工业设计
包括手机的外观、材质、手感、颜色配搭，主要界面的实现与及色彩等方面的设计。

例如摩托罗拉“明”翻盖的半透明，诺基亚7610的圆弧形外观，索爱W550的阳光橙等。这些给用户的特别感受和体验都是属于手机工业设计的范畴，一部手机是否能成为畅销的产品，手机的工业设计显得特别重要！

2、MD(Mechanical Design)结构设计
手机的前壳、后壳、手机的摄像镜头位置的选择，固定的方式，电池如何连接，手机的厚薄程度。如果是滑盖手机，如何让手机滑上去，怎样实现自动往上弹，SIM卡怎样插和拔的安排，这些都是手机结构设计的范畴。繁琐的部件需要MD的工作人员对材质以及工艺都非常熟识。

摩托罗拉V3以 13.9mm的厚度掀起了手机市场的热潮，V3手机以超薄为卖点，因为它的手机外壳材质选择十分关键，所以V3的外壳是由技术超前的航空级铝合金材质打造而成。可以这样说，特殊外壳材质的选择成就了V3的成功。
另外有个别用户反应在使用某些超薄滑盖手机的时候，在接听电话时总能感觉到手机前壳的左右摇动，这就是手机结构设计出了问题，由于手机的壳体太薄，通话时的扬声器振动很容易让手机的机身产生了共振。
3、HW(Hardware) 硬件设计
硬件主要设计电路以及天线，而HW是要和MD保持经常性的沟通。
比 如MD要求做薄，于是电路也要薄才行得通。同时HW也会要求MD放置天线的区域比较大，和电池的距离也要足够远，HW还会要求ID在天线附近不要放置有金 属配件等等。可想而知一部内置天线的设计手机，其制造成本是会较一部外置天线设计的手机贵上20-25%，其主要因素就是天线的设计，物料的要求与及电路 的设计和制造成本平均都是要求较高一些。

通常结构设计师(MD)与工业设计师(ID)都会有争论，MD说ID都是画家，画一些大家做不出 来的东西，而ID会说MD笨，不按他们的设计做，所以手机卖得不好。所以，一款新的手机在动手设计前，各个部门都会对ID部门的设计创意进行评审，一个好 的ID一定要是一个可以实现的创意，并且客户的体验感觉要很好才行。当年摩托罗拉V70的ID就是一个很好的实现创意例子，后期市场的反应也不错，而西门 子的Xelibri的创意虽然也很好，也可实现，但可惜的是最终客户的使用感觉并不好，所以一个真正好的创意，不但要好看，可实现，而且还要好用。

另外HW也会与ID吵架，ID喜欢用金属装饰，但是金属会影响了天线的设计以及容易产生静电的问题，因此HW会很恼火，ID/MD会开发新材料，才能应付ID的要求。诺基亚8800就是一个好例子，既有金属感，又不影响天线的接收能力。
?
4、SW(Software)软件设计
相对来说，SW是更容易为大家所理解，由于计算机的普及，让我们最大程度地接触了各种各样的软件，手机操作界面的模式，大家经常看到的手机九官格操作菜单的实现，这都是SW设计的范畴。

SW 要充分考虑到界面的可操作性，是否人性化，是否美观的因素。SW的测试非常复杂，名目繁多，SW的测试不仅只是在寻找Bug，一致性的测试、兼容性的测试 等都是非常重要的项目，在目前“内容为主”的信息时代，软件才是手机的最终幕后支柱，硬件的驱动是软件来实现，软件和硬件的工程师之间的冲突相信是不会比 其它部门少，这种关系的绕来绕去，所以便需要有PM(Project Management)项目管理来协调了。
5、PM(Project Management)项目管理
大 规模公司的PM都分得非常细致，比如TPM (Technologly Of Project Management)，即专门管技术的PM，而普通的PM，只管理项目的进度各协调工作，PM这个部门通常存在于那些自己设计，自己生产，自己销售手机 的公司，AM（Account Manager）的职位恐怕大家都不陌生，作为客户经理，对公司内部是代表客户提出要求，对外则代表公司的整体形象，在两者之间起着不可或缺的桥梁作用。

6、Sourcing资源开发部
资源开发部的员工要不停地去挖掘新的资源，如新材质、新的手机组件、测试器材等，当手机开始试产时，他们要保证生产线上所需要的所有生产物料齐备。

手机进行小批量试生产，考察的不仅是软/硬件的成熟度，还包括考察生产工艺和生产的测试技术，有些手机在进行到这个阶段时，却通过不了这一关的话，最后是以失败告终。于是这款新设计的手机便不会出现在市场上了，而投入的开发资金和人力却付之流水，是一个极大的损失。

7、QA(Quality Assurance)质量监督
QA部门负担起整个流程质量保证的工作，督促开发过程是否符合预定的流程，保证项目的可生产性，有很多新设计的手机，就因为碰上了不可生产的某种因素而放弃了。

生产一部手机不是在实验室内做实验那么简单，一旦生产就是成千上万部，要保证每一部产品的优质绝非一件简单容易的事。生产一部手机的样品和生产10万部手机完全是两码子事。
举例：中国的菜馆出的都是样品，麦当劳做的是产品，所以麦当劳可以做得很大，而且到目前为止，中国的菜馆暂时还没有做到像麦当劳的规模是事实，所以手机设计公司才会建立起很多流程来防止出现设计研制出来的手机却不能投入生产的情况。
不仅如此，一款手机的成功上市，能够卖个满堂红，仍然是需要与大众手机用户有亲密的接触，并且经过用户的反馈以及快速的改善才能成功。
二、鲜为人知的手机测试项目
1、压力测试
用自动测试软件连续对手机拨打1000个电话，检查手机是否会发生故障。倘若出了问题，有关的软件就需要重新编写了。所以有时候手机上会出现不同的软件版本存在的情况，其实告诉大家一个秘密，手机的版本越多，这可以证明该手机在推出发售前，未经过充分的测试工作便发售了。

2、抗摔性测试
抗摔性测试是由专门的Pprt可靠性实验室来进行，0.5m的微跌落测试要做300次/面(手机有六个面)。而2m的跌落测试每个面需各做一次，还仿真人把手机抛到桌面，而手机所用的电池，也要经过最少4m的高度，单独的向着地面撞击跌落100次而不能有破裂的情况出现。

3、高/低温测试
让手机处于不同温度环境下测试手机的适应性，低温一般在零下20摄氏度，高温则在80摄氏度左右。

4、高湿度测试
用一个专门的柜子来作滴水测试，仿真人出汗的情况(水内渗入一定比例的盐分)，约需进行30个小时。

5、百格测试(又称界豆腐测试)
用H4硬度的铅笔在手机外壳上画100格子，看看手机的外壳是否会掉下油漆，有些要求更严格的手机，会在手机的外壳上再涂抹上一些“名牌”的化妆品，看看是否因有不同的化学成分而将手机的油漆产生异味或者掉漆的可能。


6、翻盖可靠性测试
对翻盖手机进行翻盖10万次，检查手机壳体的损耗情况，是用一部翻盖的仿真机来进行，它可以设置翻盖的力度、角度等。
7、扭矩测试
直机用夹具夹住两头，一个往左拧，一个往右拧。扭矩测试主要是考验手机壳体和手机内面大型器件的强度。

8、静电测试
在 北方地区，天气较为干燥，手摸金属的东西容易产生静电，会引致击穿手机的电路，有些设计不好的手机就是这么样突然损坏了。进行这种测试的工具，是一个被称 为“静电枪”的铜板，静电枪会调较到10-15KV的高压低电流的状况，对手机的所有金属接触点进行放电的击试，时间约为300ms-2s左右，并在一间 有湿度控制的房间内进行，而有关的充电器(火牛)也会有同样的测试，合格才能出厂发售。


9、按键寿命测试
借助机器以给设定的力量对键盘击打10万次，假使用户每按键100次，就是1000天，相当于用户使用手机三年左右的时间。

10、沙尘测试
将手机放入特定的箱子内，细小的沙子被吹风机鼓吹起来，经过约三小时后，打开手机并察看手机内部是否有沙子进入。如果有，那么手机的密闭性设计不够好，其结构设计有待重新调整。
此外，手机的测试还包含了更多更离奇的测项目，比如把手机放在铁板上打电话加以测试，由于此时磁场发生了变化，什么情况都会发生，例如寻找不到SIM卡等。

用铁丝在手机底部连接器内拨来拨去，主要是要考虑到手袋内有锁匙的情况下，是否会令手机出现短路的问题。
还有故意把充电器/电池反接测试，看看手机的保护电路设计是否能正常运作，靠近日光灯打电话的测试，人体吸收电磁波比例的测试，以及靠近心脏起博器打电话的测试等等，上述所提及的各种测试都是不可少的。

1, 黑盒测试:也称功能测试或数据驱动测试。它在已知产品应具有的功能的条件下，通过测试来检测每个功能是否都能正常使用

黑盒测试-主要试图发现几类错误：功能不对或遗漏、界面错误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误。

黑盒测试有两种基本方法，即通过测试和失败测试

具体的黑盒测试方法包括等价类划分、因果图、正交实验设计法、边值分析、判定表驱动法、功能测试等。

功能测试:检查软件的功能是否符合规格说明

基本方法: 测试基本的方法是构造一些合理输入（在定义域内），检查是否得到期望的输出。

(在定义域内使用等价类划分比较有效)

等价类划分;是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

容错性测试:检查软件在异常条件下的行为（输入不同的数据类型或者定义域之外的值进行测试）。

边界值分析（Boundary Value Analysis，BVA）:是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，在设计测试用例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常可以取得良好的测试效果。BVA不仅重视输人条件边界，而且也从输出域导出测试用例。

边界值设计测试遵循的五条原则：
1、如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围边界外的值作为测试用例。如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值；
2、若规定了值的个数，分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例；
3、针对每个输出条件使用上述1、2条原则；
4、如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例；
5、分析规格说明，找出其他的可能边界条件。

错误推测设计方法:就是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

因果图方法:是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。

正交试验设计法，\:就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

2, 白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作

　　一个故事 :

　　我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。

　　以前，我们有一个软件项目，开发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具，最后选择了一种，并且购买了几份拷贝。她委派一位员工 ——Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作，还有其他的很多任务。他尝试使用刚刚购买的自动化测试工具。当把测试工具应用到软件产品测试中的时候，遇到了问题。这个测试工具太复杂，难于配置。他不得不给测试工具的客户支持热线打了几个电话。最后， Jerry 认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。在打过几个电话后，测试工具厂商派过来一位技术专家。技术专家到达后，找出问题所在，测试工具可以正常工作了。这还算是顺利了。但是，几个月后，他们还是没有真正实现测试自动化， Jerry 拒绝继续从事这个项目的工作，他害怕自动化测试会一事无成，只是浪费时间而已。

　　项目经理 Anita 把项目重新指派给 Kevin Shorttimer ，一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚获得计算机科学的学位，希望通过这份工作迈向更有挑战性的、值得去做的工作。 Anita 送 Kevin 参加工具培训，避免 Kevin 步 Jerry 的后尘 —— 由于使用测试工具遇到困难而变得沮丧，导致放弃负责的项目。 Kevin 非常兴奋。这个项目的测试需要重复测试，有点令人讨厌，因此，他非常愿意采用自动化测试。一个主要的版本发布后， Kevin 准备开始全天的自动化测试，他非常渴望得到一个机会证明自己可以写非常复杂的，有难度的代码。他建立了一个测试库，使用了一些技巧的方法，可以支持大部分的测试，这比原计划多花费了很多时间，不过， Kevin 使整个测试工作开展的很顺利。他用已有的测试套测试新的产品版本，并且确实发现了 bug 。接下来， Kevin 得到一个从事软件开发职位的机会，离开了自动化的岗位。

　　Ahmed Hardluck 接手 Kevin 的工作，从事自动化测试执行工作。他发现 Kevin 留下的文档不仅少，并且没有太多的价值。 Ahmed 花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。这个过程中， Ahmed 经历了很多失败，并且不能确信测试执行的方法是否正确。测试执行中，执行失败后的错误的提示信息也没有太多的参考价值，他不得不更深的钻研。一些测试执行看起来仿佛永远没有结束。另外一些测试执行需要一些特定的测试环境搭建要求，他更新测试环境搭建文档，坚持不懈地工作。后来，在自动化测试执行中，它发现几个执行失败的结果，经过分析，是回归测试的软件版本中有 BUG ，导致测试执行失败，发现产品的 BUG 后，每个人都很高兴。接下来，他仔细分析测试套中的内容，希望通过优化测试套使测试变得更可靠，但是，这个工作一直没有完成，预期的优化结果也没有达到。按照计划，产品的下一个发布版本有几个主要的改动， Ahmed 立刻意识到产品的改动会破坏已有的自动化测试设计。接下来，在测试产品的新版本中，绝大多数测试用例执行失败了， Ahmed 对执行失败的测试研究了很长时间，然后，从其他人那里寻求帮助。经过商讨，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。最后，大家根据新接口修改自动化测试，测试都通过了。产品发布到了市场上。接下来，用户立刻打来投诉电话，投诉软件无法工作。大家才发现自己改写了一些自动化测试脚本，导致一些错误提示信息被忽略了。虽然，实际上测试执行是失败的，但是，由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。这个产品终于失败了。

　　这是我的故事。或许您曾经亲身经历了故事当中某些情节。不过，我希望你没有这样的相似结局。本文将给出一些建议，避免出现这样的结局。

　　问题

　　这个故事阐明了几个使自动化测试项目陷入困境的原因：

　　自动化测试时间不充足：根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间，无法得到真正的关注。

　　缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。但是，自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。

　　缺乏经验：尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。

　　更新换代频繁（ High turnover ）：测试自动化往往需要花费很多时间学习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。

　　对于绝望的反应：在测试还远没有开始的时候，问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言，测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。

　　不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。

　　关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。

　　遵守软件开发的规则

　　你可能了解 SEI （软件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分为 5 个界别，该模型用来对软件开发组织划分等级。 Jerry Weinberg （美国著名软件工程专家）也创建了自己的一套软件组织模型，在他的组织模型中增加了一个额外的级别，他称之为零级别。很显然，一个零模式的组织实际上也是开发软件；零模式组织中，在开发人员和用户之间没有差别 [Weinberg 1992] 。恰恰在这类组织环境中，经常采用自动化测试方法。因此，把资源用于自动化测试，并且把自动化测试当作一个软件开发活动对待，把软件测试自动化提升到一级。这是解决测试自动化的核心的方案。我们应该像运作其他的开发项目一样来运作软件自动化测试项目。

　　像其他软件开发项目一样，我们需要软件开发人员专注于测试自动化的开发任务；像其他软件开发项目一样，自动化测试可以自动完成具体的测试任务，对于具体的测试任务来说，自动化开发人员可能不是这方面的专家，因此，软件测试专家应该提供具体测试任务相关的咨询，并且提供测试自动化的需求；像其他软件开发项目一样，如果在开发编码之前，对测试自动化作了整体设计有助于测试自动化开发的顺利开展。像其他软件开发项目一样，自动化测试代码需要跟踪和维护，因此，需要采用源代码管理。像其他软件开发项目一样，测试自动化也会出现 BUG ，因此，需要有计划的跟踪 BUG ，并且对修改后的 BUG 进行测试。像其他软件开发项目一样，用户需要知道如何使用软件，因此，需要提供用户使用手册。

　　本文中不对软件开发做过多讲述。我假定您属于某个软件组织，该组织已经知道采用何种合理的、有效的方法开发软件。我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。本文按照在软件开发项目中采用的标准步骤组织的，重点关注测试自动化相关的事宜和挑战。

　　? 改进软件测试过程

　　? 定义需求

　　? 验证概念

　　? 支持产品的可测试性

　　? 可延续性的设计（ design for sustainability ）

　　? 有计划的部署

　　? 面对成功的挑战

　　步骤一：改进软件测试过程

　　如果你负责提高一个商业交易操作的效率，首先，你应该确认已经很好的定义了这个操作的具体过程。然后，在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前，你想知道是否可以采用更简单、成本更低的的方法。同样的，上述过程也是用于自动化测试。我更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。

　　例如，很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行，再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行，并且单调乏味。怎样才能做好回归测试文档化的工作呢？通常的做法是采用列有产品特性的列表，然后对照列表检查。这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。

　　在你开始测试自动化之前，你需要完善上面提到的回归测试检查表，并且，确保你已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。如果测试掌握了基本的产品知识，这会更好。确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果，这些通常被忽略，建议测试人员知道。太多的测试人员没有意识到他们缺少什么，并且由于害怕尴尬而不敢去求助。这样一份详细的文档给测试小组带来立竿见影的效果，因为，现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。不过，这时候千万不要走极端去过分细致地说明测试执行的每一个步骤，只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。但是，不要假定他们理解那些存留在你头脑中的软件测试执行的想法，把这些测试设计的思路描述清楚就可以了。

　　我以前负责过一个软件模块的自动化测试工作。这个模块的一些特性导致实现自动化非常困难。当我了解到这项工作无需在很短的时间内完成后，决定制定一个详细回归测试设计方案。我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷，针对每个缺陷，我写了一个能够发现该问题的测试执行操作。我计划采用这种方法提供一个详细的自动化需求列表，这可以告诉我模块的那一部分最适合自动化测试。在完成上述工作后，我没有机会完成测试自动化的实现工作。不过，当我们需要对这个模块做完整回归测试的时候，我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。依照文档的指导，几乎不需要任何指导的情况下，各自完成了回归测试，并且发现了 BUG 。从某种角度看，这实际上是一次很成功的自动化测试。在这个项目中，我们与其开发自动化测试脚本，还不如把测试执行步骤文档化。后来，在其它项目中，我们开发了自动化测试脚本，发现相关人员只有接受相关培训才能理解并执行自动化测试脚本，如果测试自动化设计的很好，可能会好一些。不过，经过实践我们总结出完成一份设计的比较好的测试文档，比完成一份设计良好的测试脚本简单的多。

　　另外一个提高测试效率的简单方法是采用更多的计算机。很多测试人员动辄动用几台计算机，这一点显而易见。我之所以强调采用更多的计算机是因为，我曾经看到一些测试人员被误导在单机上努力的完成某些大容量的自动化测试执行工作，这种情况下由于错误的使用了测试设备、测试环境，导致测试没有效果。因此，自动化测试需要集中考虑所需要的支撑设备。

　　针对改进软件测试过程，我的最后一个建议是改进被测试的产品，使它更容易被测试，有很多改进措施既可以帮助用户更好的使用产品，也可以帮助测试人员更好的测试产品。稍后，我将讨论自动化测试的可测试需求。这里，我只是建议给出产品的改进点，这样对手工测试大有帮助。

　　一些产品非常难安装，测试人员在安装和卸载软件上花费大量的时间。这种情况下，与其实现产品安装的自动化测试，还不如改进产品的安装功能。采用这种解决办法，最终的用户会受益的。另外的一个处理方法是考虑开发一套自动安装程序，该程序可以和产品一同发布。事实上，现在有很多专门制作安装程序的商用工具。

　　另一些产品改进需要利用工具在测试执行的日志中查找错误。采用人工方法，在日志中一页一页的查询报错信息很容易会让人感到乏味。那么，赶快采用自动化方法吧。如果你了解日志中记录的错误信息格式，写出一个错误扫描程序是很容易的事情。如果，你不能确定日志中的错误信息格式，就开始动手写错误扫描程序，很可能面临的是一场灾难。不要忘记本文开篇讲的那个故事中提到的测试套无法判断测试用例是否执行失败的例子。最终用户也不愿意采用通过搜索日志的方法查找错误信息。修改错误信息的格式，使其适合日志扫描程序，便于扫描工具能够准确的扫描到所有的错误信息。这样，在测试中就可以使用扫描工具了。

　　通过改进产品的性能对测试也是大有帮助的。很显然的，如果产品的性能影响了测试速度，鉴别出性能比较差的产品功能，并度量该产品功能的性能，把它作为影响测试进度的缺陷，提交缺陷报告。

　　上面所述的几个方面可以在无需构建自动化测试系统的情况下，大幅度的提高测试效率。改进软件测试过程会花费你构建自动化测试系统的时间，不过改进测试过程无疑可以使你的自动化测试项目更为顺利开展起来。

　　步骤二：定义需求

　　在前面的故事中，自动化工程师和自动化测试的发起者的目标存在偏差。为了避免这种情况，需要在自动化测试需求上保持一致。应该有一份自动化测试需求，用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。很多人认为自动化测试显然是一件好事情，但是，他们不愿意对自动化测试的目标给出清晰的描述。下面是人们选用自动化测试的几个原因：

　　? 加快测试进度从而加快产品发布进度

　　? 更多的测试

　　? 通过减少手工测试降低测试成本

　　? 提高测试覆盖率

　　? 保证一致性

　　? 提高测试的可靠性

　　? 测试工作可以由技术能力不强测试人员完成

　　? 定义测试过程，避免过分依赖个人

　　? 测试变得更加有趣

　　? 提高了编程技能

　　开发管理、测试管理和测试人员实现自动化测试的目标常常是有差别的。除非三者之间达成一致，否则很难定义什么是成功的自动化测试。

　　当然，不同的情况下，有的自动化测试目标比较容易达到，有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高，测试人员必须能理解充分的理解自动化测试，从而通过自动化测试不断发现软件的缺陷。不过，自动化测试不利于测试人员不断的积累测试经验。不管怎么样，在开始自动化测试之前应该确定自动化测试成功的标准。

　　手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源，建立测试环境，执行测试用例。测试过程中，如果有什么异常的情况发生，手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果，记录测试结果，复位被测试的软件系统，准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况，研究测试过程可疑的现象，寻找测试用例执行失败的过程，设计并执行其他的测试用例帮助定位软件缺陷。接下来，他们写作缺陷报告单，保证缺陷被修改，并且总结所有的缺陷报告单，以便其他人能够了解测试的执行情况。

　　千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分，部分的采用自动化测试是最好的方法。或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择，或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。我听到有人讲，除非测试的各个环节都采用自动化方式，否则不是真正意义上的自动化测试，这真是胡言乱语。如果仅仅是为了寻找挑战，可以尝试在测试的每个环节都采用自动化方法。但是，如果寻找成功测试的方法，请关注那些可以快速建立的，可以反复利用的自动化测试。

　　定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。通过定义自动化测试需求，距离成功的自动化测试近了一步。

　　步骤三：验证概念

　　在前面的故事当中，那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。不过，在项目的进行中，他得到了来自各个方面的支持。

　　你可能还没有认识到这一点，不过，你必须验证自动化测试项目的可行性。验证过程花费的时间往往比人们预期的要长，并且需要来自你身边的各种人的帮助。

　　很多年前，我从事一个测试自动化项目的工作，参加项目的人员有各种各样的好点子。我们设计了一个复杂的自动化测试系统，并且非常努力工作去实现系统的每个模块。我们定期的介绍测试自动化的设计思路和工作进度，甚至演示已经完成的部分功能。但是，我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。最后，整个项目被取消了，此后，我再也没有犯这个错误。

　　你需要尽可能快地验证你采用的测试工具和测试方法的可行性，站在产品的角度验证你所测试的产品采用自动化测试的可行性。这通常是很困难的，需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。你需要做是验证概念 —— 一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性，从而验证了你的测试概念。你选择的用来验证概念的测试套是评估测试工具的最好的方式。

　　对于很多人来说，自动化测试意味着 GUI 自动化测试，我不同意这种观点。我曾经做过 GUI 和非 GUI 自动化测试，并惊奇的发现这两类测试的测试计划有很大的互补性。不过， GUI 测试工具很昂贵、并且过分讲究。选择合适的 GUI 测试工具是很重要的，因为，如果没有选择合适的测试工具，你会遇到很多不可预测的困难。 Elisabeth Hendrickson 曾经写过一篇关于选择测试的工具的指导性文章 [Hendrickson 1999] 。我建议在评估测试工具中，找出能够验证你的想法的证据是很重要的环节。这需要测试工具至少有一个月试用期，你可能打算现在购买一份测试工具，然后直到评估完成后再购买更多份。你需要在付出大笔金钱购买测试工具的之前，找出工具存在的问题。这样，你可以从测试工具供应商得到更好的帮助，当你打算更换工具的时候，你不会感觉很为难。

　　下面是一些候选的验证概念的试验：

　　回归测试：你准备在每个版本运行同样的测试用例吗？回归测试是最宜采用自动化测试的环节。

　　配置测试：你的软件支持多少种不同的平台？你打算在所有支持的平台上测试执行所有的测试用例吗？如果是的，那么采用自动化测试是有帮助的。

　　测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。

　　非 GUI 测试：实现命令行和 API 的测试自动化比 GUI 自动化测试容易的多。

　　无论采用什么测试方法，定义一个看得见的目标，然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。

　　步骤四：支持产品的可测试性

　　软件产品一般会用到下面三种不同类别的接口：命令行接口（ command line interfaces ，缩写 CLIs) 、应用程序接口（ API ）、图形用户接口（ GUI ）。有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。从本质上看， API 接口和命令行接口比 GUI 接口容易实现自动化，去找一找你的被测产品是否包括 API 接口或者命令行接口。有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者 API 接口，从而支持产品的可测试性。

　　下面，更多多的讲解 GUI 自动化测试相关内容。这里有几个原因导致 GUI 自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有 “ 录制回放 ” 或者 “ 捕捉回放 ” 功能，这确实是个很好的方法。可以手工执行测试用例，测试工具在后台记住你的所有操作，然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法，但是很多时候却不能奏效。很多软件测试文章的作者得出结论 “ 录制回放 ” 虽然可以生成部分测试脚本，但是有很多问题导致 “ 录制回放 ” 不能应用到整个测试执行过程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 结果， GUI 测试还是主要由手工完成。

　　第二个原因，把 GUI 自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的 GUI 接口技术才能使 GUI 测试工具正常工作。这个主要的困难也是 GUI 自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。另外，还需要分析测试工具中的 BUG ，并且给工具打补丁。也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。 GUI 测试中，困难总是意外出现，让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。

　　第三个原因， GUI 设计方案的变动会直接带来 GUI 自动化测试复杂度的提高。在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。一般来讲，第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候，就开展 GUI 自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。不管怎样，即便界面的修改会导致测试修改脚本，你也不应该反对开发人员改进图形界面。一旦原始的设计完成后，图形界面接口下面的编程接口就固定下来了。

　　上面提到的这些原因都是基于采用 GUI 自动化测试的方法完成产品的功能测试。图形界面接口当然需要测试，可以考虑实现 GUI 测试自动化。不过，你也应该考虑采用其他方法测试产品的核心功能，并且这些测试不会因为图形界面发生变化而被中断，这类测试应该采用命令行接口或者 API 接口。我曾经看到有人选择 GUI 自动化测试，因为，他们不打算修改被测试产品，但是，最终他们认识到必须对产品做修改，以保证 GUI 测试自动化可以正常工作。无论你选择哪种方法，自动化都需要对被测试的产品做修改。因此，采用可编程的接口是最可靠的。

　　为了让 API 接口测试更为容易，应该把接口与某种解释程序，例如 Tcl 、 Perl 或者 Python 绑定在一起。这使交互式测试成为可能，并且可以缩短自动化测试的开发周期。采用 API 接口的方式，还可以实现独立的产品模块的单元测试自动化。

　　一个关于隐藏可编程接口的例子是关于 InstallShield—— 非常流行的制作安装盘的工具。 InstallShield 有命令行选项，采用这种选项可以实现非 GUI 方式的安装盘，采用这种方式，从提前创建好的文件中读取安装选项。这种方式可能比采用 GUI 的安装方式更简单更可靠。

　　另一个例子是关于如何避免基于 WEB 软件的 GUI 自动化测试。采用 GUI 测试工具可以通过浏览器操作 WEB 界面。 WEB 浏览器是通过 HTTP 协议与 WEB 服务器交互的，所以直接测试 HTTP 协议更为简单。 Perl 可以直接连接 TCP/IP 端口，完成这类的自动化测试。采用高级接口技术，譬如客户端 JAVA 或者 ActiveX 不可能利用这种方法。但是，如果在合适的环境中采用这种方式，你将发现这种方式的自动化测试比 GUI 自动化测试更加便宜更加简单。

　　我曾经受雇在一家公司负责某个产品 GUI 相关的自动化测试，该产品也提供命令行接口，不过，他们已经实现了 GUI 的自动化测试。经过一段时间的研究，我发现找到图形界面中的 BUG 并不困难，不过，用户并不关注图形界面，他们更喜欢使用命令行。我还发现我们还没有针对最新的产品功能（这些功能即可通过 GUI 的方式，也可以通过命令行的方式使用）实现自动化测试。我决定推迟 GUI 自动化测试，扩展命令行测试套，测试新增的产品功能。现在回过头看这个决定，我没有选择 GUI 自动化测试是最大的成功之处，如果采用了 GUI 自动化测试所有的时间和努力都会浪费在其中。他们已经准备好做 GUI 自动化测试了，并且已经购买了一套测试工具和其他需要的东西，但我知道在开展具体的 GUI 自动化测试活动中，会遇到各种各样的困难和障碍。

　　无论你需要支持图形界面接口、命令行接口还是 API 接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，未来的测试工作中，你很可能成功。尽可能早的启动自动化测试项目，提出可测试性需求，会使您走向自动化测试成功之路。

　　步骤五：具有可延续性的设计

　　在开篇的故事中，我们看到由于自动化工程师把注意力仅仅集中在如何使自动化运转起来，导致测试自动化达不到预期的效果。自动化测试是一个长期的过程，为了与产品新版本的功能和其他相关修改保持一致，自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过，测试人员应该相信得到的结果，测试执行的实际结果也应该是通过了。其实，有很多存在问题的测试用例表面上执行通过了，实际上却执行失败了，并且没有记录任何错误日志，这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果，而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误，都会导致这种失败的测试自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。

　　性能： 提高代码的性能往往增加了代码的复杂性，因此，会威胁到代码的可靠性。很少有人关心如何对自动化本身加以测试。通过我对测试套性能的分析，很多测试套都是花费大量的时间等候产品的运行。因此，在不提高产品运行性能的前提下，无法更有效的提高自动化测试执行效率。我怀疑测试自动化工程师只是从计算机课程了解到应该关注软件的性能，而并没有实际的操作经验。如果测试套的性能问题无法改变，那么应该考虑提高硬件的性能；测试套中经常会出现冗余，也可以考虑取出测试套中的冗余或者减少一个测试套中完成的测试任务，都是很好的办法。

　　便于分析： 测试自动化执行失败后应该分析失败的结果，这是一个棘手的问题。分析执行失败的自动化测试结果是件困难的事情，需要从多方面着手，测试上报的告警信息是真的还是假的？是不是因为测试套中存在缺陷导致测试执行失败？是不是在搭建测试环境中出现了错误导致测试执行失败？是不是产品中确实存在缺陷导致测试执行失败？有几个方法可以帮助测试执行失败的结果分析，某些方法可以找到问题所在。通过在测试执行之前检查常见的测试环境搭建问题，从而提高测试套的可靠性；通过改进错误输出报告，从而提高测试自动化的错误输出的可分析性；此外，还可以改进自动化测试框架中存在的问题。训练测试人员如何分析测试执行失败结果。甚至可以找到那些不可靠的、冗余的或者功能比较独立的测试，然后安全地将之删除。上面这些都是减少自动化测试误报告警、提高测试可分析性的积极有效的方法。另外，有一种错误的测试结果分析方法，那就是采用测试结果后处理程序对测试结果自动分析和过滤，尽管也可以采用这种测试结果分析方法，不过这种方法会使自动化测试系统复杂化，更重要的是，后处理程序中的 BUG 会严重损害自动化测试的完整性。如果由于自动化测试本身存在的缺陷误把产品中的正常功能视为异常，那该怎么办？我曾经看到测试小组花费开发测试自动化两倍的时间来修改测试脚本，并且不愿意开展培训过程。那些仅仅关注很浅层次测试技术的测试管理者对这种方法很感兴趣，他们排斥采用隐藏测试复杂度的方法。

　　综上所述，应该集中精力关注可以延续使用的测试套，从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

　　可读性： 很多情况下，在测试人员开始测试项目之前，公司已经有了一套测试脚本，并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它，但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性，在具体应用中，那些脚本常常没有多大的实用价值，越来越让人迷惑。因此，测试人员很难确定他们实际在测试什么，反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本，并且理解测试脚本究竟测试了什么，这是很关键的。好的文档是解决问题的手段之一，对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法，我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩，把所有执行的产品相关的命令记录到日志里。这样，当分析日志确定执行了哪些产品命令，命令采用了何种参数配置时，可以提供一个非常好的测试记录，里面记录了自动化测试执行了什么，没有执行什么。如果测试脚本可读性不好，很容易变得过分依赖并没有完全理解的测试脚本，很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后，可以更容易的开展同行评审活动。

　　可维护性： 在工作中，我曾经使用过一个测试套，它把所有的程序输出保存到文件中。然后，通过对比输出文件内容和一个已有的输出文件内容的差别，可以称已有的输出文件为 “ 标准文件 ” （ “gold file” ）。在回归测试中，用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了，它会产生很多错误的警告。随着时间的推移，软件开发人员会根据需要修改产品的很多输出信息，这会导致很多自动化测试失败。很明显，为了保证自动化测试的顺利进行，应该在对 “ 标准文件 ” 仔细分析的基础上，根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是，每次只检查选定的产品的某些特定输出，而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试，这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改，并研究使测试修改量最小的方法，测试中采用库是解决问题的方法。当产品发生变化的时候，只需要修改相关的库，保证测试与产品的变动同步修改即可。

　　完整性： 当自动化测试执行后，报告测试执行通过，可以断定这是真的吗？这就是我称之为测试套的完整性。在前面的故事中，当没有对自动化测试完整性给予应有的关注的时候，发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果？自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败，但是，对于自动化测试误报告警的情况，大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效，当测试发现异常的时候，能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法，分类包括 PASS ， FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果，它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分，另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ，这个 BUG 引起测试队列中部分测试用例被跳过，没有执行。当测试队列运行完毕后，没有上报任何错误，我不得不通过走读代码的方式发现了这个 BUG 。如果，我没有关注到这个 BUG ，那么可能在认识到自动化测试已经出现问题之前，还在长时间运行部分测试用例。

　　独立性： 采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候，通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化，测试执行是由一台不会说话的计算机完成的，你必须告诉计算机什么样的情况下测试执行是失败的，并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境，因此，保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档，以便一个接着一个有序地完成测试执行，每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误，这个错误源于 “ 多米诺骨牌 ” 测试套，当一个测试执行失败，会导致后续一系列测试失败。更糟糕的是，所有的测试关联紧密，无法独立的运行。并且，这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后，人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式，不过，重要的是在不牺牲测试的可靠性的前提下保证测试的独立性，如果测试可以在无需人看守情况下运行，那么测试的执行效率就不是大问题了。

　　可重复性： 自动化测试有时能够发现问题，有时候又无法发现问题，对这种情况实在没有什么好的的处理办法。因此，需要保证每次测试执行的时候，测试是以同样的方式工作。这意味着不要采用随机数据，在通用语言库中构造的随机数据经常隐藏初始化过程，使用这些数据会导致测试每次都以不同的方式执行，这样，对测试执行的失败结果分析是很让人沮丧的。这里有两个使用随机数据发生器的的方法可以避免上述情况。一种方法是使用常量初始化随机数据发生器。如果你打算生成不同种类的测试，需要在可预测，并且可控制的情况下建立不同类型的随机数据发生器。另外一个办法是提前在文件中或数据库中建立生成随机测试数据，然后在测试过程中使用这些数据。这样做看起来似乎很好，但是我却曾经看到过太多违反规则的做法。下面我来解释到底看到了什么。当手动执行测试的时候，往往匆匆忙忙整理文件名和测试数据记录。当对这些测试采用自动化测试方法，该做哪些工作呢？办法之一是，可以为测试中使用的数据记录给固定的命名。如果这些数据记录在测试完成后还要继续使用，那么就需要制定命名规则，避免在不同的测试中命名冲突，采用命名规则是一种很好的方法。然而，我曾经看到有些测试只是随机的命名数据记录，很不幸，事实证明采用这种随机命名的方式不可避免的导致命名冲突，并且影响测试的可重复性。很显然，自动化工程师低估了命名冲突的可能性。下面的情况我遇到过两次，测试数据记录的名字中包含四个随机产生的数字，经过简单的推算如果我们采用这种命名方式的时候，如果测试使用了 46 条记录，会存在 10% 冲突的可能性，如果使用 118 条记录，冲突的几率会达到 50% 。我认为测试当中使用这种随机命名是出于偷懒的想法 —— 避免再次测试之前写代码清除老的数据记录，这样引入了问题，损害了测试的可靠性和测试的完整性。

　　测试库： 自动化测试的一个通用策略是开发可以在不同测试中应用的测试函数库。我曾经看到过很多测试函数库，自己也写了一些。当要求测试不受被测试产品接口变动影响的时候，采用测试库方法是非常有效的。不过，根据我的观察测试库已经使用的太多了，已经被滥用了，并且测试库往往设计的不好，没有相关的文档支撑，因此，使用测试库的测试往往很难开展。当发现问题的时候，往往不知道是测试库自身的问题，还是测试库的使用问题。由于测试库往往很复杂，即便在发现测试库存在问题，相关的维护人员也很不愿意去修改问题。通过前文中的论述，可以得出结论，在一开始就应该保证测试库设计良好。但是，实际情况是测试自动化往往没有花费更多的精力去保证一个优良设计的测试库。我曾经看到有些测试库中的功能根本不再使用了或仅仅使用一次。这与极限编程原则保持一致，即 " 你将不需要它 " 。这会导致在测试用例之间的代码出现一些重复，我发现微小的变化可能仍然存在，很难与测试库功能协调。你可能打算对测试用例作修改，采用源代码的方式比采用库的方式更容易修改。如果有几个测试，他们有某些共同的操作，我使用剪切和粘贴的方式去复制代码，有的人认为我采用的方法不可理喻。这允许我根据需要修改通用代码，我不必一开始尝试和猜测如何重用代码。我认为我的测试是很容易读懂的，因为阅读者不必关心任何测试库的语法。这种办法的优势是很容易理解测试，并且很方便扩展测试套。在开发软件测试项目的时候，大多数程序员找到与他们打算实现功能类似的源代码，并对源代码做修改，而不是从头开始写代码。同样，在写测试套的过程中可以采用上述方法，这也是代码开发方式所鼓励的方法。我比较喜欢写一些规模比较小的测试库，这些库可以被反复的使用。测试库的开发需要在概念阶段充分定义，并且文档化，从始至终都应该保持。我会对测试库作充分的测试后，才在测试中使用这些测试库。采用测试库是对所有面临的情况作权衡的。千万不要打算写一个大而全的测试库，不要希望有朝一日测试人员会利用你的测试库完成大量的测试，这一天恐怕永远不会到来。

　　数据驱动测试： 把测试数据写入到简单表格中，这种测试技术得到了越来越广泛的应用，这种方法被称为表驱动（ table-driven ），数据驱动 (data-driven) 或者 “ 第三代 ” 自动化测试（ "third generation" automation ）。这需要写一个解析器，用来解释表格中的数据，并执行测试。该测试架构的最主要的好处是，它允许把测试内容写在具有一定格式的表格中，这样方便数据设计和数据的检视。如果测试组中有缺少编程经验的业务专家参与测试，采用数据驱动测试方法是很合适的。数据驱动测试的解析器主要是由测试库和上层的少量开发语言写成的代码组成的，所以，上面关于测试库的说明放在这里是同样合适的。在针对上面提到的少量代码的设计、开发、测试的工作，还存在各种困难。代码所采用的编程语言是不断发展的。也许，测试人员认为他们需要把第一部分测试的输出作为第二部分测试的输入，这样，加入了新的变量。接下来，也许有人需要让测试中的某个环节运行一百次，这样加入一个循环。你可以采用其他语言，不过，如果你预料到会面临上述情况的时候，那么做好采用一些能够通过公开的渠道获取的编程语言，比如 Perl,Python 或者 TCL ，这样比设计你自己的语言要快的多。

　　启发式确认： 我曾经看到很多测试自动化没有真正意义上的结果校验，其原因有两个，一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的，另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过，采用手工校验测试结果的方法是真正意义上的测试校验。标准文件（ Gold file ）是另外一中校验测试结果的方法。首先，捕获被测试程序的输出，并检视程序的输出，然后，把输出信息文档化，并归档，作为标准文件。以后，自动化测试结果与标准文件作比较，从而达到结果校验的目的。采用标准文件的方法，也有弊端。当产品发生变化，自动化测试的环境配置发生变化，产品的输出发生变化的时候，采用标准文方法，会上报大量的误报告警。做好的测试结果校验方法是，对输出结果的特定内容作分析，并作合理的比较。有时候，很难知道正确的输出结果是什么样的，但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法，是因为担心如果结果校验漏掉了任何信息，可能导致自动化测试自身出现错误。不过，我们在测试过程中往往采用折衷的做法，没有采用大而全的测试结果校验方法，这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法，那么他必须找相关人员咨询，寻找一种合适的测试结果校验策略，这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下，找到被测试产品的缺陷。

　　把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，你将进一步迈向成功的自动化测试。

　　步骤六：有计划的部署

　　在前面的故事中，当自动化工程师没有提供打包后的自动化测试程序给测试执行人员，会影响到测试执行，测试执行人员不得不反过来求助自动化工程师指出如何使用自动化测试程序。

　　作为自动化工程师，你知道如何利用自动化方法执行测试和分析执行失败的结果。不过，测试执行人员却未必知道如何使用自动化测试。因此，需要提供自动化测试程序的安装文档和使用文档，保证自动化测试程序容易安装和配置。当安装的环境与安装的要求不匹配，出现安装错误的时候，能够给出有价值的提示信息，便于定位安装问题。

　　能够把自动化测试程序和测试套作为产品对待，那真是太好了。你应该对自动化测试程序和测试套开展测试，保证它们不依赖于任何专用的库或者是设备上的任何其他程序。

　　保证其他测试人员能够随时利用已经提供的自动化测试程序和测试套开展测试工作；保证自动化测试是符合一般测试执行人员的思维习惯的；保证测试执行人员能够理解测试结果，并能够正确分析失败的测试执行结果；这需要自动化工程师提供自动动化测试相关的指导性文档和培训。

　　作为测试管理者，你希望在自动化工程师离开前，能够识别并修改测试套中的所有问题。自动化工程师迟早会离开的，如果你没有及时的把测试套中的问题提出来，就会面临废弃已有的测试套的决定。

　　良好的测试套有多方面的用处。良好的测试套支持对产品新版本的测试；良好的测试套在新的软件平台上可以很方便的验证产品的功能；良好的测试套支持每天晚上开始的软件每日构造过程；甚至开发人员在代码 check in 之前，用良好的测试套验证代码的正确性。

　　测试套的共享也很重要。很难预见以后什么人会继续使用你开发的测试套。因此，尽量让产品开发测试团队中的成员都很容易获得你的测试套。可以把测试套放在公司的内部网络上，这是个很好的办法。这样，大家就不必为了获取一份需要的测试套而四处打听。有些人总是感觉自己的测试套还没有最终完工或者不够完美，而没有拿出来与人分享，这种做法一定要改变，共享出来的测试套不一定非常完美，共享才是关键。

　　有计划的自动化测试部署，保证你的测试套能够被产品相关人员获取到，你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。

　　步骤七：面对成功的挑战

　　当你完成了所有的事情，测试套已经文档化了，并且文档已经交付了。测试执行人员能够理解要开展的测试，并知道如何完成测试执行。随着你所负责产品的进一步开发和维护，测试被反复重用。虽然，在自动化使测试变简单的同时，也总是使测试过程复杂化。测试人员需要学习如何诊断自动化测试执行失败的情况，如果不这样做，测试执行人员会认为执行失败的情况是由自动化引起，然后，自动化工程师被叫过来帮助诊断每一个执行失败的情况，开发人员往往也会认为执行失败是由于自动化测试自身引起的问题，这样，测试执行人员就不得不学习通过手工的方式，或者通过采用少量脚本的方式重现自动化测试发现的问题，以证明他们确实发现了产品当中的 BUG 。

　　测试套的相关工作还没有结束，为了提高测试覆盖率或者测试新的产品特性，需要增加更多的测试。如果已有的测试不能正常工作，那么需要对之修改；如果已有的测试是冗余的，那么需要删除这部分测试。

　　随着时间的推移，开发人员也会研究你设计的测试，改进产品的设计并且通过模拟你的测试过程对产品做初步测试，研究如何使产品在第一次测试就通过，这样，你设计的测试很可能无法继续发现新的问题，这种现象被称为一种杀虫剂悖论。这时候，会有人对你的测试有效性提出质疑，那么，你必须考虑是否应该挖掘更严格的测试，以便能够发现开发人员优化之后的产品中的缺陷。

　　以前，我提到过一个基本上无法实现的设想，设想通过按下一个按钮就完成了所有的测试工作。自动化测试是不是全能的，手工测试是永远无法完全替代的。

　　有些测试受测试环境的影响很大，往往需要采用人工方法获取测试结果，分析测试结果。因此，很难在预先知道设计的测试用例有多大的重用性。自动化测试还需要考虑成本问题，因此，千万不要陷入到一切测试都采用自动化方法的错误观念中。

　　我曾经主张保证给与测试自动化持续不断的投入。但是，在开展自动化测试的时候，一个问题摆在面前，测试自动化应该及时的提供给测试执行人员，这个不成问题，但是如何保证需求变更后，能够及时提供更新后的自动化测试就是个大问题了。如果自动化测试与需求变更无法同步，那么自动化测试的效果就无法保证了，测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。识别项目计划中的软件发布日期，然后把这个日期作为里程碑，并计划达到这个里程碑。当达到这个里程碑后，自动化工程师应该做什么呢？如果自动化工程师关注当前产品版本的发布，他需要为测试执行人员提供帮助和咨询，但是，一旦测试执行人员知道如何使用自动化测试，自动化测试工程师可以考虑下一个版本的测试自动化工作，包括改进测试工具和相关的库。当开发人员开始设计产品下一个版本中的新特性的时候，如果考虑了自动化测试需求，那么自动化测试师的设计工作就很好开展了，采用这种方法，自动化测试工程师可以保持与开发周期同步，而不是与测试周期同步。如果不采用这种方式，在产品版本升级的过程中，自动化测试无法得到进一步的改进。

　　持续在在自动化投入，你会面临成功的挑战，当自动化测试成为测试过程可靠的基础后，自动化测试的道路将会越来越平坦。

　　参考文献：

　　Bach, James. 1996. “Test Automation Snake Oil.” Windows Technical Journal , (October): 40-44. http://www.satisfice.com/articles/test_automation_snake_oil.pdf

　　Dustin, Elfriede. 1999. “Lessons in Test Automation.” Software Testing and Quality Engineering (September): 16-22.
http://www.stickyminds.com/sitewide.asp?ObjectId=1802&ObjectType=ART&Function=edetail

　　Fewster, Mark and Dorothy Graham. 1999. Software Test Automation , Addison-Wesley.

　　Groder, Chip. “Building Maintainable GUI Tests” in [Fewster 1999].

　　Kit, Edward. 1999. “Integrated, Effective Test Design and Automation.” Software Development (February). http://www.sdmagazine.com/articles/1999/9902/9902b/9902b.htm

　　Hancock, Jim. 1997 “When to Automate Testing.” Testers Network (June).
http://www.data-dimensions.com/Testers'Network/jimauto1.htm

　　Hendrickson, Elisabeth. 1999. “Making the Right Choice: The Features you Need in a GUI Test Automation Tool.” Software Testing and Quality Engineering Magazine (May): 21-25. http://www.qualitytree.com/feature/mtrc.pdf

　　Hoffman, Douglas. 1999. “Heuristic Test Oracles: The Balance Between Exhaustive Comparison and No Comparison at All.” Software Testing and Quality Engineering Magazine (March): 29-32.

　　Kaner, Cem. 1997. “Improving the Maintainability of Automated Test Suites.” Presented at Quality Week. http://www.kaner.com/lawst1.htm

　　Linz , Tilo and Matthias Daigl. 1998. “How to Automate Testing of Graphical User Interfaces.” European Systems and Software Initiative Project No. 24306 (June). http://www.imbus.de/html/GUI/AQUIS-full_paper-1.3.html

　　Jeffries, Ronald E., 1997, “XPractices,”
http://www.XProgramming.com/Practices/xpractices.htm

　　Marick, Brian. 1998. “When Should a Test Be Automated?” Presented at Quality Week. http://www.testing.com/writings/automate.pdf

　　Marick, Brian. 1997. “Classic Testing Mistakes.” Presented at STAR. http://www.testing.com/writings/classic/mistakes.html

　　Pettichord, Bret. 1996. “Success with Test Automation.” Presented at Quality Week (May). http://www.io.com/~wazmo/succpap.htm

　　Thomson, Jim. “A Test Automation Journey” in [Fewster 1999]

　　Weinberg, Gerald M. 1992. Quality Software Management: Systems Thinking . Vol 1. Dorset House.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=651566

   在验证之余，我认真研究了他们出的故障单，做了一些总结。

   1、手机软件系统测试的角度分为：功能模块测试，交叉事件测试，压力测试，容量性能测试，性能测试和用户手册测试等。

   2、功能模块测试：首先应分析功能模块的功能项，测试每个功能项是否能够实现对应的功能。一般根据测试案例（Test Case）或软件本身的流程就可以完成基本功能测试。（相对简单，故障也较容易解决）

   3、交叉事件测试：又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或来响闹。应该以执行干扰的冲突事件不会导致手机死机或花屏等严重的问题。
   交叉事件测试非常重要，能发现很多应用中潜在的性能问题。另外有中英文模式的切换的手机要注意中英文模式切换后的功能实现存在的问题，通常会被测试人没忽略。

   4、压力测试：又叫边界值容错测试或极限负载测试，即测试过程中，已经达到某一软件功能的最大容量，边界值或最大的承载极限，仍然对其进行相关操作。例如连续进行短信的接收和发送，超过收件箱和PIM卡所能存储的最大的条数，仍然进行短消息的接收或发送，以检测软件在超常态条件下的表现，来评估用户能否接受。
   压力测试用手工测试非常繁锁，可以考虑自动化测试，目前没有比较大量使用的工具，一般都是由开发人员配合开发出的工具，或者高级的测试人员编写出的脚本。

   5、容量测试：又叫满记忆体测试，包括手机的用户可用内存和SIM/PIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试，如果软件的极限容量状态下处理不好，有可能导致死机或严重的花屏等问题的出现。
   与压力测试有些类似，也可考虑自动化测试。

   6、兼容性测试：也就是不同品牌手机，不同网络，不同品牌和不同容量大小的SIM/PIM卡之间的互相兼容的测试，以短消息为例：中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息，接收，显示和回复功能是否正常等

   另外从我测试的这几个小模块中，按与时间相关和文字两方面容易出现故障的地方总结如下：

   1、与时间相关：首先是时间的输入域，是否有输入限制，如：文字、标点符号、小时大于24或12、分钟大于60、秒大于60、月大于12、日大于31（按月情况而定）等
   特别注意日期变更分界点如23：59或12：59的变化。以及12/24小时切换模式的测试。

   2、文字输入相关：当界面过多时，注意功能按钮的点击事件能否正常完成相应功能的实现。超过文字字数限制时的系统提示等。

软件测试步骤

2007-08-08 15:06:49 / 个人分类：软件测试技术

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展：从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门；测试工作也从简单测试演变为包括编制测试计划、编写测试用例、准备测试数据、开发测试脚本、实施测试、测试评估等多项内容的正规测试；测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

一、测试用例是软件测试的核心

       软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

       影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

       因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。

二、什么叫测试用例

       测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

       不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

三、编写测试用例

       着重介绍一些编写测试用例的具体做法。

1、测试用例文档

       编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

       软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

       测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

2、测试用例的设置

      我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

      按功能测试是最简捷的，按用例规约遍历测试每一功能。

      对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

      但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

3、设计测试用例

      测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

      设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

      可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

四、测试用例在软件测试中的作用

1、指导测试的实施

       测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

       根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

2、规划测试数据的准备

       在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

      除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3、编写测试脚本的"设计规格说明书"

      为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4、评估测试结果的度量基准

      完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5、分析缺陷的标准

      通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

五、相关问题

1、测试用例的评审

      测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

2、测试用例的修改更新

      测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

      一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

3、测试用例的管理软件

      运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

      有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

测试方法概述

1.         功能测试

1.1.        手工测试与自动化工具测试划分

分析软件系统的各个模块，

将需要大量重复操作测试的功能做自动化测试

将自动化测试实现较难的功能做手工测试

1.2.        手工测试

a           分析系统需求说明书和规格说明书，

b           编写测试需求，

c           根据测试需求书写测试用例

d           按照测试用例，手动运行软件

e           发现bug，

f            将bug填写在vsts软件中

g           通知开发人员修改程序

h           进行回归测试

1.3.        自动化测试

a           分析系统需求说明书和规格说明书，

b           编写测试需求，

c           根据测试需求书写测试用例

d           根据测试用例编写\录制测试脚本

e           调试和整理测试脚本，

f            运行测试脚本，进行测试。

g           分析运行结果，发现bug

h           将bug填写在vsts软件中，

i             通知开发人员修改程序

j             进行回归测试

1.4.        测试通过标准

如果测试结果与预期结果一致测试通过，否则不通过。

1.5.        测试结果审批过程

测试工作执行完毕，写测试总结报告，召开测试总结会议，讨论产品是否可以发布（评审标准：测试案例是否完全，测试程序是否正确，测试结果是否令人满意，…）。

1.6.        测试挂起和恢复条件

l         测试挂起条件：

由于程序中存在重大问题或者问题过多，测试无法正常进行，测试人员申请测试挂起，经领导审批通过；

由于存在其他优先级更高的任务，通过批准，测试挂起。

l         测试恢复条件：

重大问题被解决或者程序通过重新修正；

优先级更高的任务被完成。

2.         性能测试

2.1.        测试的要点

速度 系统反应速度是否可以符合要求

负载 测试系统是否可以在正常的负载范围内正常运行

压力 测试系统的限制和故障恢复能力，是否会崩溃

2.2.        具体实施方法

预期指标的性能测试----测试系统要求的基本性能是否可以满足

模拟多用户同一时间数据的上传和下发

模拟多用户同一时间使用系统的相同功能

模拟多用户同一时间使用系统的不同功能

模拟多用户长时间适用系统，系统长时间运行（3至4天），测试系统的稳定性

大量数据同时上传或下发，数据的传输是否有误

网络性能测试测试，测试系统在网络延迟，网络断开，网络不稳定的状况下系统的运行情况以及是否可以有相应的措施

3.         图形测试

Ø         要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

Ø         验证所有页面字体的风格是否一致。

Ø          背景颜色应该与字体颜色和前景颜色相搭配。

Ø          图片的大小和质量也是一个很重要的因素，一般采用JPG 或GIF 压缩。

4.         内容测试

内容测试用来检验应用系统提供信息的正确性、准确性和相关性

5.         界面测试

整体界面是指整个Web 应用系统的页面结构设计，是给用户的一个整体感。

6.         操作系统版本测试

检验在不同的操作系统版本下，系统的运行

7.         安装与卸载测试

1. 软件测试在公司的组织保障是基础
1.1 研发部组织结构介绍
以华友公司研发部的组织结构为例，测试部门属于研发部副总裁直接管理，见如下结构图
公司研发部的组织结构图

对于从事软件研发的组织来说，工作类型至少包括项目管理、产品设计、编码、测试、质量保证和软件配置管理，以及其它人员，如文档编制人员和美工人员/系统硬件管理人员等。根据职能需要，可以以半独立方式进行部门和项目的矩阵管理，即职员要对项目经理/组长负责，也要对部门经理/总监负责，工作考核由双方共同完成，标准的组织应包括技术开发部/组（主要是编码和设计人员），产品开发部/组（产品需求和项目管理），测试部/组，配置管理部/组（因为配置管理人员基本上是按20个技术人员配一个配置管理人员，所以一般部门规模较小，或者只是配置管理组），软件质量保障部/组，其它部/组（如系统/文档/美工等）。华友公司组织结构中，研发部是公司软件研发的核心部门
产品研发Ⅰ部、Ⅱ部、和应用研发部主要负责：
与软件产品部或内容产品部配合，协助完成内容产品的可行性、合理性分析；
平台、网关、应用产品的研发项目的立项和方案评审；
研发项目的概要设计、详细设计工作；
研发项目的编码、单元测试工作；
组织公司相关部门进行研发产品的培训；
协助相关部门做好产品的售前技术支持工作；
协助相关部门进行软件的安装与调试；
根据相关部门的要求做好产品的售后服务工作，保障软件的运行正常。
测试部隶属研发部，主要职责如下：
与内容产品部和软件产品部配合完成软件需求分析讨论，并根据需求说明书制订《项目测试方案》，编写《测试用例》，建立测试环境；
负责完成研发部各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改升级软件的模块测试和系统测试；
建立、推广并维护实施软件版本管理系统CVS和VSS；
使用并维护软件缺陷管理系统Bugzilla，负责软件问题解决过程跟踪记录；
负责推广实施软件开发文档规范化工作，管理研发产品相关文档；
负责配合软件运维部门等对于新业务软件或修改升级业务软件的上线测试工作，并提供上线测试报告；
负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。
1.2 软件产品研发各部门的组织结构分解
1)华友公司从2003年10月开始，对项目组制订明确指标的独立考核，各开发部门是技术总监带队，再细分各项目经理具体负责项目计划和执行，对项目具体开发成员进行分工。对于测试部门制订年度测试部门任务计划/考核表，如SMS业务销售额指标完成：目标1：9900万（奖金提取比例为0.01％）；目标2：16800万（奖金提取比例为0.02％）；目标3：23200万（奖金提取比例为0.03％）
详细给出财务目标和业务运营目标。
在每周的开发经理工作会议上交流报告任务进展情况，并提出最近测试需求，测试部门经理负责制订测试计划、测试用例和测试实施方案，安排测试工程师与对应的开发人员交流完成测试执行工作。测试部经理负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之外的部门定期交流掌握下周或近期可能测试任务，所有其他外部接口都由测试部经理负责完成，与其他项目组和产品部门协调项目进度。
2) 工作汇报关系为:
开发部门：Team Member->Team Leader->研发总监->研发部副总裁->总裁。
测试部门：测试工程师->测试小组经理->测试部经理/总监->研发部副总裁->总裁。
3）项目成员结构：
公司通常的开发项目组为6到8个开发人员，最多不超过10人。
华友公司的经过三次改造后的组织结构和项目组结构，各个业务部门分类非常细，任务明确，软件开发的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总监和副总裁，层层管理，沟通渠道畅通。而在软件测试上，由于有限的测试资源，首先体现在公司的组织结构上，集中表现为测试部门不得不面对公司级管理部门的缺失和管理的交叉上，没有质量管理部门，部门质量管理工作测试部门兼做。公司从成本角度考虑，测试部门规模较小，测试人员总数不超过10人，几乎每个测试人员接收处理10个开发人员的测试任务需求。从实际情况出发，首先明确测试部门和软件开发部门相对独立的组织关系，保证测试人员的工作不受开发小组的控制，实现测试客观、公证。华友公司要想有效地保障产品质量，首先就要在构架合理的组织结构和测试流程上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构和流程不合理，其他方面再下功夫也是徒劳。
从实践经验看，一年前首先成立测试部，把属于开发部门的测试工程师归口到独立的测试部门管理，其次建立规范的测试流程，与开发部门交流，要求每周提出测试需求，再根据现有的资源制订每周测试计划，同时向人力资源部门提出招聘计划，随着测试工作的成绩不断被开发部门和上级领导认可，再推广实施软件开发过程规范化的管理，通过测试实践的优良成绩来确立测试部门在公司的地位和作用，经过一年的奋斗测试部门从无到有，从最初两人到现在十人，软件配置管理和缺陷跟踪系统已经被60%的开发人员自愿使用和接收。 总结本人在华友一年多测试工作经验，深深体会到在国内从事软件项目开发难、从事软件测试和质量保证工作更难，需要具备扎实的技术功底同时，不断提高测试项目管理能力，寻找工作的突破口。世上无难事，只怕有心人，但是只要你努力献身于软件测试工作，打出一片天地是有可能的。(
2．配置管理系统是项目经理的"眼睛"，是软件测试有效实施的前提
在软件质量体系的诸多支持活动中,配置管理系统处在支持活动的中心位置,它有机地把其它支持活动结合起来,形成一个整体,相互促 进,相互影响,有力地保证了质量体系的实施。建立公司配置管理系统很容易得到公司领导层的支持，几乎没人反对。更重要的是建立配置管理系统后测试人员的工作有了系统保证，测试工作的"矿藏资源"有了明确的位置，可以主动积极开展测试工作。
2.1 项目管理存在的主要问题
华友公司测试部门去年刚成立时，以建立、规范和推广使用配置管理系统CVS为突破口，同时建立缺陷跟踪系统Bugzilla提高测试流程的管理水平。我做为测试负责人首先分析华友公司几个软件项目在开发管理上的现状,。
存在问题一、公司几个核心项目仍然过分分依赖少数个人的作用,没有建立起协同作战的氛围,没有科学的软件配置管理流程; 技术上只重视系统和数据库、开发工具的选择,而忽视配置管理工具的选择,导致即使有些项目有配置管理的规程,也由于可操作性差而搁浅。以上种种原因导致开发过程中普遍存在如下一些问题: 调查说明华友研发成员的变动的比率达到30%，几乎每周都有新加入的员工或者辞职人员， 一个新成员熟悉项目的最佳途径就是通过配置管理系统阅读项目文档，甚至阅读同行代码，达到快速学习、共同提高的目的。一个辞职人员可以利用配置管理系统保留部分一段时间工作，最大程度减少对项目开发造成的损失。
存在问题二、开发管理松散。领导了解工作完成情况重视口头交流，忽视书面文档。有些部门主管无法确切得知项目的进展情况,项目经理也不知道各开发人员的具体工作,项目进展随意性很大,可"左"可"右"。"左"时按领导下达的"期限"进行,到期时,似乎一切已顺利完成,大家一阵胡弄,交差完成,反正领导看的是界面,至于里面是什么,留到施工时再说。施工时的工作因此变成了无法汇报、无法理清的无休止的维护。"右"时则项目工期无休止地延期。对我们软件工程来说,总的特点是先"左"后"右"。在领导面前表现"左",在用户面前表现"右"。有个测试人员经常利用上班时间学习英语，过了一个多月，看她依然如此，我做为项目领导进行批评教育，这名员工并不认为自己错了，她争辩，公司采取弹性工作时间，考核员工是分配的任务是否完成等理由。同时、我对她批评结果遭到她的恶意报复，她给有关领导报告新来的经理如何不懂公司业务，采取不适合公司的管理方式等，由于领导无法了解真相，使得我的工作在一段时间开展很困难，直到过去半年，这名员工辞职出国学习领导才明白发生了什么。
存在问题三、项目之间沟通不够。各个开发人员各自为政,每个项目经理都像个"地主"，编写的代码不仅风格各异,而且编码和设计脱节。每个项目组的人力资源和硬件资源成了"私有财产"，自己人员即使暂时空闲，让他从事所谓的新技术研究，也不考虑友邻项目需要他们帮助的现状。本来开发中错误在所难免, 进展早一点的项目组或者人力资源强的项目组已经积累类似问题的解决经验，也不愿意分享给其它项目组。 开发大量重复, 留下大量难维护的代码。典型案例是有个短信项目D两年来在这个开发人员Y 的研发支持下运转效益很好，但是三个月之前，开发人员 Y因为待遇问题和公司领导谈判失败，提出辞职。项目D仍然在运行，但是最近移动公司规范修改、系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。公司领导出面请开发人员Y来协助，因为没有文档记录，Y忙于新公司的工作也不能解决修改。
存在问题四、文档与程序严重脱节。软件产品是公司的宝贵财富,代码的重用率是相当高的,如何建好知识库,用好知识库对公司优质高效开发产品,具有重大的影响。但开发人员的一句名口号是:"叫我干什么都可以,但别叫我看别人的程序"。当然,开发人员的工作态度要转变,但客观上有一个很重要的原因是:前人留下的程序既无像样的文档(即使留下了文档 ,其与源程序也严重脱节),开发风格又不统一,就像一堆垃圾,要开发人员到垃圾中去捡破烂,从这个角度上看,开发人员的要求是合理的。
存在问题五、测试工作不规范。仍然停留在"小姑娘做测试"的底水平上，传统的开发方式中,测试工作只是人们的一种主观愿望,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是走一走过场,测试结果既无法考核又无法量化,当然就无法对以后的开发工作起指导作用。
存在问题六、虽然项目施工时间不长，但软件版本更新周期过短,几乎每天都修改在线运行系统，且开发人员必须亲自现场或远程登陆操作，全国十几个地点软件内容多少都有点差别，这些差别都记录在几个骨干人物的脑袋里。 由于应用软件的特点,各个不同的施工点有不同的要求,开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同地方提出,由不同人解决,其做法也不同,程序的可维护性越来越差。久而久之,最后连自已都分不清楚了,代码的相互覆盖现象时有发生,且这苦水还无法倾诉,因为怕别人笑话,甚至别人问起,还得想法搪塞,可谓费尽苦心。
2.2 建立配置管理系统,规范项目管理流程，建立知识库的同时节约项目费用
针对以上问题, 利用自己在Beijing Precom Inc, 普天润汇等公司积累的经验，建立配置管理系统CVS, CVS 的全称是Current Version Control. CVS是一种GNU 软件包.由Intersolv公司开发，它明确的将源文件的存储和用户的工作空间独立开来, 并使其有利与并行开发.这个工具属于Open Source， ,CVS可以在intenet 上很方便的得到. 它的源码在ftp://202.113.29.4/pub1/unix/cvs 它的说明文档在ftp://202.113.29.4/doc/cvs.任何人可以很方便的下载.目前他的最新版本是2..10.8。 不需要花钱，很快建立，重点在于使用和推广。配合项目经理共同制定相应的配置管理策略,取得了很好的成效。
2.2.1. 节约费用
(1) 缩短开发周期
利用CVS对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version 系统查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从版本控制系统上得到不同的运行版本,并且可以安装在Web Server或在Unix操作系统上命令行方式存取供外地施工人员存取最新版本,无需开发人员亲临现场。
利用CVS系统,可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。
(2) 减少施工费用
利用CVS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,工程人员可以通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。
2.2.2. 有利于知识库的建立
(1) 代码对象库
软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。CVS系统为开发管理提供了一个平台和仓库,有利于建立公司级的代码对象库。
(2) 业务及经验库
通过CVS的注释,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。
2.2.3. 规范管理
(1) 量化工作量考核
传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自已把握,随意性相当大;靠管理人员把握,主观性又太强。采用CVS管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。
(2) 规范测试
采用CVS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。
(3) 加强协调与沟通
采用CVS后,通过VSS文档共享系统和 Bugzilla缺陷跟踪系统,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。
3．性能测试是软件测试专业化的核心所在
从华友实践看，软件测试对于产品经理、开发经理和市场经理都有所认识，他们大部分人会认为功能测试工作他们能够很好的完成，产品经理是公司对于业务最熟悉的 一批人，他们对于测试工程师最急切的需求是你帮我实施产品的性能测试工作，他们听说过性能测试，我们的产品投入在线运行后碰到的最大故障是大用户量访问业务是机器凼机，或停止正常的服务，每次故障，几乎给公司的收入都造成很大损失。如果测试部门能有一套有效的性能测试手段，就确立了测试部门在项目开发过程中关键地位。
性能测试在华友软件的质量保证中起着非常重要的作用，将性能测试概括为四个方面：Wap无线应用服务在手机用户端性能测试、 Web/Wap应用服务在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下， 四方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
3.1 Wap无线应用服务在手机用户端性能测试
如今人人用手机都追求时尚，时尚体现在款式, 品牌和功能。手机产品功能的日新月异，移动增值业务功能层出不穷，从最初的短信、彩信、铃声到GPRS,CDMA,K-Java, Brew手机,功能的多样性带来手机用户端软件系统测试的复杂性。众所周知, Java手机吸引人之处是能提供智能的, 个人化的互动服务, 例如: 动态产生个人化的股市服务, 显示图形, 动画, 实时路况, 气象报告, 数字照像, 玩游戏等, 部分服务能直接于用户端执行。
为了提供如此生动的服务, 移动通信系统要能给终端用户在无线装置上提供接入互联网的功能, 要能储存、提取、管理、计算、结帐、下载软件服务, 并使内容提供商能提供丰富的声像多媒体内容, 形成广大的个人化交互式服务环境。 而作为移动用户, 可将手机视作虚拟机, 能随时、随地在适当的装置上存取应用, 享受服务。 这确是一种时尚。
当前, 对于不同品牌的手机, 它们所用的平台(指CPU和操作系统)各不相同, 由于采用不同的设计方案, 各设计之间缺乏兼容性, 操作系统和二进制代码都不兼容。 当手机运行需要大量内存时, 特别是随着接入互联网, 手机用户要求能使用个性化的 交互式应用软件, 应用程序运行在虚拟运行环境下时, 问题显得尤为突出。 所以, 有必要建立一种标准的通用运行平台, 达到在合适的成本下提供统一的交互式应用软件运行环境。 但是, 除非该平台是基于完全标准的器件, 否则是难以达到要求的。
标准的通用的运行平台是满足运营商, 软件开发商, 和终端用户三者综合要求的解决办法。 理想的环境必须具备以下性质:
(1)、平台应提供二进制兼容性。 可执行软件是二进制目标码, 需要在处理器和应用软件目标码之间建立沟通;
(2)、平台必须包括微处理器,或一个与微处理器机器代码相离的通用机器码仿真器;
(3)、平台应包括带有应用程序接口API及支持一致性图形用户界面GUI相应功能的操作系统。 API 是执行典型操作功能的软件功能库, 例如打开文件, 读写数据, 配置和管理内存, 处理事件, 显示文档和图形等。 为使应用软件真正做到可移植, 装置上必须有公共功能集, 并让软件开发者能通过一致性API 扩展功能;
(4)、平台不应要求过多的系统资源, 可移植性设备不应使成本上升太多;
(5)、平台应对功率有高效率, 尤其考虑用电池供电的设备;
(6)、由于要在互联网上应用, 安全性也是重要因素。
以Java手机软件测试为例潜在的测试问题和解决办法
Java有移植性好和其它很多优势, 但用在手机上, 速率和功耗仍是个瓶颈。 Java带来的新问题是执行速度慢, 消耗功率大。 与PC不同的是, 手机资源有限, 一般流行的手机中CPU的速率为26MHz, 或52MHz,带128M闪存, 8Mb, 16M 或64Mb内存, 没有硬盘, 由电池供电, 体积小, 空间窄。 系统慢的原因是:
(1) 系统必须同时运行两套软件: Java应用和虚拟机JVM;
(2) Java软件需要被翻译成自然CPU指令;
(3) Java平台是基于栈(相对于寄存器)结构的, 导致更多的内存存取。
因而, 如何对执行 Java加速成为关键。 加速处理数据和图形, 这对手机上互联网和多媒体的应用具有重要意义。 要克服这些问题, 提高Java软件性能, 可能的方法有四种:
(1) 提高微处理器速率。 然而Java软件性能与时钟频率并不成线性关系, 微处理器运行一般比内存存取时间高2-10倍, 增加时钟频率只会增加等待周期。
(2) 对JVM软件进行优化。 这可能涉及到要用汇编语言对字节码翻译环路进行编程, 而这会导致JRE变得与微处理器类别有关。 而与可移植相抵触;
(3) 编译。 将软件直接编译到微处理器的自然机器语言。 但是这会增加内存的开销, 也不节省能量的消耗。
(4) 采用基于硬件的加速器。 这可以做到提高性能, 保障能量和成本的有效性。 被手机设计厂商认为是较理想的措施。 通用型Java加速芯片于今年年初问世。
3.2 分析Web/Wap应用服务在客户端性能的测试
Web/Wap应用服务在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、大数据量测试和速度测试等，其中并发性能测试是重点。
并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。
我们公司自己组织力量同时委托第三方软件HG公司开发Hawa网站的一套应用Avatar形象系统的时候, Avatar形象在网站业务中占有着重要的位置，网站上的很多业务都是围绕Avatar开展。 这套系统能不能承受大量的并发用户同时访问? 成为这个网站能否成功的关键，也是这次两个公司合做开发能否顺利完成的关键。这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。
Web软件测试实例说明：哈哇网站Avatar形象系统软件。Avatar形象系统在上线试运行三个月后，所有的功能测试顺利完成，软件功能缺陷也修改完毕。但是，性能问题越来越成为项目经理关心的焦点，我们测试部门借助比较熟悉的压力测试工具Web Stress 实施客户端性能测试进行100，500，1000等并发用户访问。每次测试主要在基于URL：http://avatar.hawa.cn/index.jsp的基础上，与HG公司实时交互地进行多种情况下的测试。按照HG公司要求主要针对并发数为1000和500的情况下，尽量准确的对Avatar系统的性能压力进行模拟测试；并排除所有不是从web服务器（即avatar.hawa.cn）上得到的URL，即只对/index.jsp等页面进行测试。三次结果后，尽管程序优化、运行服务器配置多次修改，仍然存在用户量并发数达到1000，服务质量下降，页面方面时间超过正常显示时间。这里有最后一次测试结果与前几次大致相同。但是本次测试，是用多客户端测试，按原理是应该比以前的单机测试准确度要高，但其结果是比用单机测试的时间还要长，当并发数达到1000时，其页面的最长响应时间在80多秒（而单机测试时时59秒多）！第三次又发现ISP网络100MB带宽实际上不到20MB，也是影响用户服务的关键因素之一。
这个性能问题经过HG公司开发人员近三个月改进，/index.jsp页面的1000个用户并发响应时间10秒左右。对于我方采用的Web Stress性能测试工具HG公司也认同其测试结果的客观性，公司因为该软件性能问题推迟支付对方经费200万圆三个月，更重要的是软件的性能问题得到很好解决，并与HG公司的关系很好保持。另外一个更大的收获是测试部门在Web 产品部门有个很好的形象，他们每次新软件产品需求提出、产品上线都主动要求测试部门参与并实施严格测试。
如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间？ 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。
测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。
并发性能测试前的准备工作
　　
测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。
　　
一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。
　　
测试工具：成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory、 Webstress和AB-Apache等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。
　　
测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。
　　
在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。
模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。
　　
并发性能测试的关键的是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择Java scrīpt监控对象，手工编写脚本，可以达到测试目的。
　　
采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。
　　
3.3 应用在网络上性能的测试
应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。
　　
网络应用性能分析
　　
网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。
　　
网络应用性能监控
　　
在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。
　　
网络预测
　　
考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。
　　
从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。 PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。
3.4 应用在服务器上性能的测试
　　
首先分析服务器的类型，服务器的划分起码可以依据四大部分进行。一是根据整个架构，可分为IA服务器和RISC服务器；二是按照硬件配置的差别可分为工作组级、部门级、企业级；三是按照具体安装的应用软件可分为Web服务器、文件服务器、FTP服务器、E-mail服务器、数据库服务器等等；四是根据操作系统分为WINDOWS阵营、UNIX阵营。这四大分类有所关联，但其中按应用分类是最能给用户清晰概念的。因为用户在采购选型时，总是先想好了拿它做什么用的。Intel最近所提出的前端（用于接入等）、中端（用于各种应用和中间件）和后端（用于数据库、在线分析等）的分类办法，这也是从应用角度考虑的。
分析服务器性能指标莫不聚焦于三大指标：CPU、I/O及Web。如果大家还记得图灵机的话，应该对计算单元和输入输出的重要不会抱什么怀疑的态度。至于选择Web作为衡量服务器性能的要点，只能说是网络的力量。Internet的大行其道让我们很难想象有服务器孤岛出现。工程师往往通过给与被测服务器不断增加的并发式文件读写、数据库操作以及HTTP访问来取得其最大的潜值。
以Web测试为例，衡量Web性能一般有下列几个重要指标：HTTP 每秒交易数（Transaction Per Second）；每秒会话数（Sessions Per Second）；当前用户数（Concurrent users）；吞吐量（Throughput）。HTTP TPS通常也叫做每秒的点击数；每秒会话数是每秒到达Web服务器的用户数；当前用户数是特定时间在Web 站点上的用户数；吞吐量是在特定时间由Web站点发出的数据流量带宽，它与服务器提供服务的内容和交易数相关。以上将是我们对测试结果进行评述与点评的重要技术基础。
4.项目管理开发环节的测试任务
当公司构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。 下面以已经实施完成的CYB项目一期为例，分析华友公司在项目管理上的正在推广的具体 项目管理细节的优缺点和测试工作改进探讨：
CYB项目一期需求：由于华友各类业务（SMS和WAP等）在不同运营商（中国联通、中国移动、中国电信等）的不同平台和在网站www.hawa.cn 的WEB门户中向用户提供服务，各类业务的相互独立，为了统一管理用户信息、业务和计费等信息，并汇总进行统计分析处理，同时也为了整合各类业务系统的资源，建立公司的业务运营支撑系统。
4.1 开发阶段和项目周期
开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。明确项目经理为D，项目组开发程序员六人，项目第一阶段周期3个月，项目需要完成的功能：
1)实现用户信息的统一管理，包括：用户基本信息，用户使用业务的积分，用户的定制/退定信息的管理
2)实现各类业务信息的集中管理，包括：短信业务、WAP1.2、WAP2.0、JAVA、彩铃等各种业务
3)实现计费信息的统一管理
4)提供客服功能
5)提供统计分析功能
6)提供统一的标准接口，分别与各业务子系统及运营商的系统相连接
7)提供网络管理、监控等功能
在这个阶段，测试经理需要负责详细了解项目开发需要的需求、设计文档等，制订初步的测试方案，根据测试任务的特点决定测试开发任务。实际结果表明开发阶段的最大两个问题：重视设计、不重视测试和软件质量，设计会议开了至少五次，参加会议有公司很有经验的设计人员，测试有关人员没有被邀请参加，忽视产品的性能需求，更多的关注基本功能实现；忽视需求是客服和运维人员，自以为很理解市场部提出的需求，忽视程序开发人员实现的难度和开发人员之间理解需求的差别，项目组成员之间重视口头交流，忽视文档价值。
问题解决方法：开始阶段请测试和质量保证工程师参加讨论，就会提出软件实现的性能需求；重视文档交流的价值，建立软件文档模版和版本控制机制，每次交流落实在成员理解和书面文档。
4.2 软件开发流程
华友公司原来是重视项目管理，忽视流程，一味夸大个别人努力在项目成功中的作用。经过一年痛苦的实践，开始探讨流程管理，已经启动公司的SW-CMM质量体系认证工作，希望建立非常规范化和系统化的软件开发流程，其流程的有很高的可执行性，并且能在实践过程中不断改进。华友公司的流程管理改进从一个项目研发的所有方面开始摸索，包括从最开始的意向、市场策划到最后软件的版本发布(release)上线投入商业运营，都设计有相应的流程规定，基本上已由测试部门负责推广一种能够达到规范、高效的软件开发流程。
CYB项目经理D重视口头交流沟通，忽视文档交流，同时缺少与项目组成员知识共享意识；经理D重视与领导的交流，忽视与开发人员交流，项目实施中开发人员碰到具体问题没人协助解决，开发效率降低。虽然流程没错，但是流程涉及到开发人员出现问题也是需要重视的。流程管理的关键，以"人"为本。
目前的组织框架下，经过一年多的工作实践，深深体会到人和流程是保证项目成功的两个最关键因素。由具备项目实施基本素质的人按规范的合理化流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差一点的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。通过流程我们部门间的配合才节省宝贵时间，为项目早期完成，赢得市场主动权。
4.3 项目计划的阶段性
1) 努力做到项目计划详细、周到。CYB项目计划从开始有三个月计划，到修改三次以上，计划完成时间从三个月、延长到六个月、直到现在的八个月。计划已经形同虚设。实践证明不合理的计划不如没有计划，不合理的计划给领导造成错误的认识。合理的计划应该是先明确本周工作计划，对于难以预测的任务或者困难给出一个近期工作的方向，然后根据实际进展情况进行细化调整。
2) 流程中明确定义开发阶段、测试阶段。开发阶段任务没有完成，占用测试阶段计划时间，测试工作效率降低。正确的处理方式建议不要减少测试工作时间，项目开发完成时间根据实际需要顺延。
3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性:
进入条件，输入;
验证方法;
结束条件，输出。
4) 每个阶段结束都要召开阶段结束会议。前一个阶段结束（以本阶段开发任务测试完成为标志）才能进入下一阶段。项目经理需要在每个阶段测试任务完成情况进行分析，存在的问题要充分暴露出来，以便于早点解决。 CYB项目经理D采取报喜不报优的做法，在会议上常得到领导的表扬，其他项目经理常愁眉苦脸摆出人员问题、可能的技术问题、测试人员和时间问题等。实际结果最后笑的项目经理也是项目完成比较顺利。
5) 理想计划中每个活动都比较具体，每个活动的时间以天为单位。计划包括了开展质量控制活动的时间，推广说明版本控制系统和缺陷跟踪系统的使用的时间。
典型案例是公司研发用于用户信息管理的代号CYB项目，CYB项目开始时副总裁牵头，由于测试人员少没有参与，开发经理们讨论设计实施方案后几乎大家一片赞美。随后项目经理D负责开发，他认为时间紧，省去了许多必须的文档工作。经理D采取报喜不报优的做法，项目文档差，过分强调计划，而忽视计划任务达到的质量，大部分项目测试没有完成就宣布开发完成，结果前三个月每次经理会上总裁都会表扬他们取得的阶段成果，我做为测试经理没有说话的机会，有一次刚讲几句，总裁马上提醒希望大家克服困难，每个组的任务都可能需要加班等。结果原计划三个月完成项目，已经过了半年发现要实现商用还需要做很多工作，具体完成时间也不确定， 可是现在每天总是强调专人测试，问文档没有，只能通过问了一次又一次的沟通方式实施测试工作， 有个不错的测试人员实在无法忍耐，辞职了，我只好安排新的测试人员应对完成任务。这个CYB项目遭到了整个公司的一片嘘声，虽然没有放弃，但没有商业价值了。快9个月的研发成本老本最清楚去那儿了。
总结教训，项目经理对计划和测试工作的高度重视、周密制定、严格执行是能够实现项目有效商业价值的基本保障。
4.4 重视Review的作用
按软件工程规范化流程，一般把Review和测试作为保证软件质量两个主要手段。测试的重要性已经成为各项目经理认识，并贯穿于开发的全过程，形成了项目组成员人人重视测试工作的氛围。Review则是一个非常简单有效并能尽早发现软件中错误的有效方法，项目经理在每周必须根据进展情况制订Review计划，可以说，任何交付物都要经技术总监参加的Review后才能进行基线化。目前华友公司正在建立比较详细全面、可执行性高的由Review流程和各种交付物的Review Checklist。
我们正在弥补这方面的工作流程缺陷，提出：凡事有计划，凡事必review。首先在开发组内部推广代码规范化工作，定期进行员工Code Review的工作， Code Review 是工作的重要环节。
4.5 质量管理和测试（QA）
公司目前没有独立的质量管理部门，暂时由测试部门测试经理作为质量保证部门的代表，监督和保证项目的进展的各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。由于公司对测试人才有着迫切的需要，因此，只好自己组建培养测试人才队伍。从现实出发，我们不可能想IBM和微软等大公司有雄厚的才力支持质量保障和测试工作开展，我们的工作重点放在软件测试方面。从起步三人开始的实施测试工作，首先测试工程师的工作让项目经理和上级领导发现并肯定他们的工作成果。通过对比测试人员实施测试后的模块和未实施测试的模块投入商业运营带来的很大差异，看到软件修补的高昂费用，提高了领导和项目经理对测试部门的重视程度。逐步扩大测试人员数量，增加测试队伍的规模，提高测试人员的的福利待遇成为可能。
招聘测试人员时，要把好质量关，国内联想、华为等公司一般对于测试人员待遇底，重视不够，我们需要测试认为改变这种错误认识，让优秀的人加入测试队伍。目前测试部门工程师10个人中有2个留学回国计算机方面硕士，其余几人都是计算机或相关学科本科生。尽管经验方面不够，但测试人员的素质和专业技能是国内一流的，一段时间测试团队的努力，这个部门已经成为公司业务开发的至关重要的部门。要不断提高软件测试的自动化程度，测试工作不能仅靠手工劳动来完成，更多的情况是要使用工具软件和编写测试程序来完成，培养全面的测试专业人才是项任重道远的工作。
4.6 度量数据
公司最近开始CMM的质量管理体系工作，CMM中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。但是公司的项目管理定量化工作实施有一定难度，配合华友公司的绩效考核，测试部门要求项目经理重视项目中的数据收集，主要包括各种Review数据、测试数据以及项目组员每天的活动数据等。要求项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。测试部门提供能够进行团队项目开发的CVS或VSS等团队开发系统，可以这么说，有了这个项目团队开发系统，测试经理和项目经理就可以方便了解这个项目的开发过程。
4.7 团队精神
团队精神就好比人身体的每个部位，一起合作去完成一个动作。对公司来讲，团队精神就是每个人各就各位，通力合作。我们公司的每一个奖励活动或者我们的业绩评估，都是把个人能力和团队精神作为两个最主要的评估标准。如果一个人的能力非常好，而他却不具备团队精神，那么我们宁可选择后者。公司强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。公司不定期的对经理级别人员进行团队管理培训，在对员工不断进行相关培训，使员工的合作精神和协调精神都比刚进入公司时有较大提高。
4.8 培训
公司有专门的培训人员和培训费用计划，每半年会征集员工培训需求和建议，然后安排有关主题的培训活动。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。
4.9 配置管理
在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。
4.10 记录
记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
1)提倡与客户和其他项目组的所有往来必须邮件记录。
2)对所有的活动都有一个跟踪落实的过程，比如对所有的Review记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。
3)对所有的活动，包括对文档和代码的更改都会有一个历史记录。
4)记录比较准确、比较客观。
以上是华友公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。

谈项目管理和软件测试过程（二）  
    
   2004-11-19 11:48:13 
  
 
 
  雷红旗  
  2．配置管理系统是项目经理的"眼睛"，是软件测试有效实施的前提

在软件质量体系的诸多支持活动中,配置管理系统处在支持活动的中心位置,它有机地把其它支持活动结合起来,形成一个整体,相互促 
进,相互影响,有力地保证了质量体系的实施。建立公司配置管理系统很容易得到公司领导层的支持，几乎没人反对。更重要的是建立配置管理系统后测试人员的工作有了系统保证，测试工作的"矿藏资源"有了明确的位置，可以主动积极开展测试工作。

2.1 项目管理存在的主要问题
华友公司测试部门去年刚成立时，以建立、规范和推广使用配置管理系统CVS为突破口，同时建立缺陷跟踪系统Bugzilla提高测试流程的管理水平。我做为测试负责人首先分析华友公司几个软件项目在开发管理上的现状,。

存在问题一、公司几个核心项目仍然过分分依赖少数个人的作用,没有建立起协同作战的氛围,没有科学的软件配置管理流程; 技术上只重视系统和数据库、开发工具的选择,而忽视配置管理工具的选择,导致即使有些项目有配置管理的规程,也由于可操作性差而搁浅。以上种种原因导致开发过程中普遍存在如下一些问题: 调查说明华友研发成员的变动的比率达到30%，几乎每周都有新加入的员工或者辞职人员， 一个新成员熟悉项目的最佳途径就是通过配置管理系统阅读项目文档，甚至阅读同行代码，达到快速学习、共同提高的目的。一个辞职人员可以利用配置管理系统保留部分一段时间工作，最大程度减少对项目开发造成的损失。

存在问题二、开发管理松散。领导了解工作完成情况重视口头交流，忽视书面文档。有些部门主管无法确切得知项目的进展情况,项目经理也不知道各开发人员的具体工作,项目进展随意性很大,可"左"可"右"。"左"时按领导下达的"期限"进行,到期时,似乎一切已顺利完成,大家一阵胡弄,交差完成,反正领导看的是界面,至于里面是什么,留到施工时再说。施工时的工作因此变成了无法汇报、无法理清的无休止的维护。"右"时则项目工期无休止地延期。对我们软件工程来说,总的特点是先"左"后"右"。在领导面前表现"左",在用户面前表现"右"。有个测试人员经常利用上班时间学习英语，过了一个多月，看她依然如此，我做为项目领导进行批评教育，这名员工并不认为自己错了，她争辩，公司采取弹性工作时间，考核员工是分配的任务是否完成等理由。同时、我对她批评结果遭到她的恶意报复，她给有关领导报告新来的经理如何不懂公司业务，采取不适合公司的管理方式等，由于领导无法了解真相，使得我的工作在一段时间开展很困难，直到过去半年，这名员工辞职出国学习领导才明白发生了什么。 

存在问题三、项目之间沟通不够。各个开发人员各自为政,每个项目经理都像个"地主"，编写的代码不仅风格各异,而且编码和设计脱节。每个项目组的人力资源和硬件资源成了"私有财产"，自己人员即使暂时空闲，让他从事所谓的新技术研究，也不考虑友邻项目需要他们帮助的现状。本来开发中错误在所难免, 进展早一点的项目组或者人力资源强的项目组已经积累类似问题的解决经验，也不愿意分享给其它项目组。 开发大量重复, 留下大量难维护的代码。典型案例是有个短信项目D两年来在这个开发人员Y 的研发支持下运转效益很好，但是三个月之前，开发人员 Y因为待遇问题和公司领导谈判失败，提出辞职。项目D仍然在运行，但是最近移动公司规范修改、系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。公司领导出面请开发人员Y来协助，因为没有文档记录，Y忙于新公司的工作也不能解决修改。

存在问题四、文档与程序严重脱节。软件产品是公司的宝贵财富,代码的重用率是相当高的,如何建好知识库,用好知识库对公司优质高效开发产品,具有重大的影响。但开发人员的一句名口号是:"叫我干什么都可以,但别叫我看别人的程序"。当然,开发人员的工作态度要转变,但客观上有一个很重要的原因是:前人留下的程序既无像样的文档(即使留下了文档 ,其与源程序也严重脱节),开发风格又不统一,就像一堆垃圾,要开发人员到垃圾中去捡破烂,从这个角度上看,开发人员的要求是合理的。 

存在问题五、测试工作不规范。仍然停留在"小姑娘做测试"的底水平上，传统的开发方式中,测试工作只是人们的一种主观愿望,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是走一走过场,测试结果既无法考核又无法量化,当然就无法对以后的开发工作起指导作用。 

存在问题六、虽然项目施工时间不长，但软件版本更新周期过短,几乎每天都修改在线运行系统，且开发人员必须亲自现场或远程登陆操作，全国十几个地点软件内容多少都有点差别，这些差别都记录在几个骨干人物的脑袋里。 由于应用软件的特点,各个不同的施工点有不同的要求,开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同地方提出,由不同人解决,其做法也不同,程序的可维护性越来越差。久而久之,最后连自已都分不清楚了,代码的相互覆盖现象时有发生,且这苦水还无法倾诉,因为怕别人笑话,甚至别人问起,还得想法搪塞,可谓费尽苦心。 

2.2 建立配置管理系统,规范项目管理流程，建立知识库的同时节约项目费用

针对以上问题, 利用自己在Beijing Precom Inc, 普天润汇等公司积累的经验，建立配置管理系统CVS, CVS 的全称是Current Version Control. CVS是一种GNU 软件包.由Intersolv公司开发，它明确的将源文件的存储和用户的工作空间独立开来, 并使其有利与并行开发.这个工具属于Open Source， ,CVS可以在intenet 上很方便的得到. 它的源码在ftp://202.113.29.4/pub1/unix/cvs 它的说明文档在ftp://202.113.29.4/doc/cvs.任何人可以很方便的下载.目前他的最新版本是2..10.8。 不需要花钱，很快建立，重点在于使用和推广。配合项目经理共同制定相应的配置管理策略,取得了很好的成效。 

2.2.1. 节约费用 

(1) 缩短开发周期 

利用CVS对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version 系统查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从版本控制系统上得到不同的运行版本,并且可以安装在Web Server或在Unix操作系统上命令行方式存取供外地施工人员存取最新版本,无需开发人员亲临现场。 
   
利用CVS系统,可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。 

(2) 减少施工费用 
   
利用CVS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,工程人员可以通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。
 
2.2.2. 有利于知识库的建立 

(1) 代码对象库 
   
软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。CVS系统为开发管理提供了一个平台和仓库,有利于建立公司级的代码对象库。 

(2) 业务及经验库 

通过CVS的注释,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。 

2.2.3. 规范管理 

(1) 量化工作量考核 

传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自已把握,随意性相当大;靠管理人员把握,主观性又太强。采用CVS管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。 

(2) 规范测试 

采用CVS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。 

(3) 加强协调与沟通 

采用CVS后,通过VSS文档共享系统和 Bugzilla缺陷跟踪系统,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。

测试用例设计

　　测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：

　　测试用例的基本格式

　　软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

　　用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

　　测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

　　重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，

　　测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

　　操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

　　预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

　　软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。

　　重用同类型项目的测试用例

　　如果我看得远，那是因为我站在巨人的肩上 －－牛顿。

　　一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

　　利用已有的软件 Checklist

　　在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

　　加强测试用例的评审

　　测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。 如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

　　定义测试用例的执行顺序

　　　

　　　　在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

　　测试用例执行

　　测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：

　　搭建软件测试环境，执行测试用例

　　测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。

　　如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

　　测试执行过程应注意的问题

　　测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：

　　全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。

　　加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

　　及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

　　与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

　　及时更新测试用例

　　测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。

　　总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

　　提交一份优秀的问题报告单

　　软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

　　软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。

　　硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。

　　测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。

　　输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。

　　日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。

　　根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。

　　测试结果分析

　　软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

　　总结：

　　限于文章的篇幅，本文不可能给出一个类似于 checklist 的指导性的软件测试新手入门。无论从事软件测试还是从事其它的工作，技术上的和技巧上的问题都可以通过查询相关的软件测试技术书籍获取，掌握一套基本的方法论是最重要的。以上文字，都是作者从事软件测试工作积累的经验之谈，如发现谬误之处请不吝指出。

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。

就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。

　　冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。

　　简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费。

一、软件测试员自身素质培养

    （1） 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。

    （2） 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。

    （3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。

    （4） 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。

    （5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。

    （6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。

    （7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。

    （8） 设身处地为客户着想，从他们的角度去测试系统。

    （9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。

    （10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。

    （11） 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。

    （12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。

    （13） 幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。

    （14） 到此是不是对测试很有兴趣呢？不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？

    二、浅谈软件测试之技巧

    软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。

    （1） 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。

    （2） 非法测试，例如在输入数字的地方输入字母。

    （3） 跟踪测试，跟踪一条数据的流程,保证数据的正确性。

    （4） 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。

    （5） 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。

    （6） 代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。

    （7） 突发事件测试，服务器上可能发生意外情况的测试。

    （8） 外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。

    （9） 在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。

    （10） 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。

    （11） 文字测试，如果在系统中有用词不当的地方，我想这是不应该的。

    （12） 系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。

    （13） 用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。

    软件测试是软件开发中的重中之重，没有一点可以马虎的，在项目管理过程，强调的是每个过程的每一个环节都要进行测试，保证系统在每个阶段可以控制。因为软件测试中考虑的问题基本上是项目管理中考虑的问题。 工作中真的需要多总结，多剖析，对于毛病：“有则改之、无则加冕”。

    软件开发是一件很辛苦的事，只有在工作中多总结，才能找到符合自己的方式方法，才能在工作中事半功倍。