转自：http://blog.sina.com.cn/s/blog_48f5a98701000ajc.html
以下是我对测试工作的认识，并做了些阐述：
一、前提条件
1.培养个人素质：
A对工作一丝不苟的谨慎态度和一如既往的高昂热情。
B探索精神，打破沙锅问到底。
C追求完美，创造性思维，想出富有创意甚至超常的手段来寻找缺陷。
D善于表达观点，并组织好语言，描述操作过程应做到通俗易懂。
2.认识职责所在：
A测试用例、测试计划的编写，测试资源、测试质量的协调保证。
B测试执行，部分自动化测试、性能测试。
C国外、国内，外场测试的支持。
二、测试目的
测试的目的是为了发现尽可能多的缺陷，这个观念很容易让人接受，但是却很难落实到实际工作中，因为测试的目的常常被定位为“证明软件没有问题”。软件质量是否优良在投产后才能有所体现。
正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地设计很多不易暴露错误的测试示例，这些测试用例恰恰证明软件实现了预期功能，这样的测试是不真实的。成功的测试在于发现了迄今尚未发现的缺陷。
三、测试流程
1.项目需求评审：
B评审要点：是否描述可输入/输出值的属性，如边界值，度量单位，时序要求等。是否描述清楚软件模块与模块间衔接处的处理情况及返回值。专用名词是否一致性等等。
2.制定测试计划
3.设计测试用例：
A基本要素：测试目的、前提条件、输入数据或操作过程、期望的响应。
B不同的测试例其用途应当不同，不要冗余。
C设计测试用例在除了常用数据外，还需要考虑极限值、边界值、重复值、0值及负值，即不同的测试用例需要不同类型的数据值来进行测试。
D设计测试用例时需要注意的是，除了对整体流程及功能注意外，还要注意强度测试、性能测试、压力测试、边界值测试、稳定性测试、安全性测试等多方面。
4.测试过程
CTA预测：主要是测手机的射频特性，也叫RF指标。通俗的讲，CTA就是通信设备的入网认证。
FTA预测：全面型号认证（FULL TYPE APPROVAL）。GSM认证预测试。
GCF预测：GSM和WCDMA认证预测试。
（测试重点：针对本项目的重点，如是音乐手机、电影手机、拍照手机、智能手机、游戏手机等。从用户的使用点来测试。根据用户购买想法来进行重点模块的测试。在测试过程中，也要进行负载测试，压力测试，易用性测试，安装与升级卸载测试，安全性测试等等。）
5.缺陷描述
6.测试报告及评估
7.沟通
8.小结
总之在这测试过程中，应尽可能做到“80-20”原则，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会暴露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。还有就是一般情况下80％的缺陷聚集在20％的关键核心业务模块中。
四、测试遗漏的后果
如果软件缺陷被遗落并流落到客户那里，结果就是代价高昂的电话或者现场支持费用，还可能需要修复、重新测试和发布新的产品，更糟糕的情况是产品要被召回甚至被客户起诉。这种成本付出非常高，几乎是在内部修改缺陷的几何级数倍。
质量之父PhilipCrosby把质量的费用分为整合费用和非整合费用两类，整合费用是指与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式进行。如果发现缺陷，经过一系列的缺陷处理流程而解决缺陷，这种费用就是非整合费用。PhilipCrosby在自己的作品中详细论述了内部的整合费用和内部的非整合费用之和远远小于外部也就是客户引起的非整合费用。
总之，软件缺陷一定要尽可能的在内部解决，这对节约成本、提高产品知名度都大有裨益。
以下是本人对现今测试存在的问题及部门管理上的一些看法：
1没按照测试例进行测试，因为测试例条目实在太多，况且测试时间短，人力资源少，所以只是对基本测试例过一遍而已。这样对于撰写测试例来说纯属浪费，这点我觉得既然实行了走测试例就要严格执行，统一管理，执行结果应总结，并进行对该次测试给个评分。每个测试阶段应有一定的改善。
2测试例应有两种版本，一种是给程序员执行的，（一般在20条测试例之内，并且是基本的，不会耗很多时间。保证版本的有效率，降低出版本次数。）在每次编译程序之前，程序员都应先自己执行一遍。另一种是给测试员执行的，测试例要详细，平常要及时更新，一人分两个模块，测试一周左右，对测试例进行交叉测试。并在一定时间内测试任务也要替换，避免反复测试的烦恼。有任务则有效的制约了空闲的测试人员，增强时间性及工作氛围。在最后一次回归测试应对测试例全部过一遍，这将是必要的。
3建议增加测试人员，一个成功的项目，它的开发人员与测试人员比例应为1：2。在当前我们比例都少于1：1/2，这样对于一个项目的开发进程及质量是起抑制作用的。
4开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一平台，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。
5在系统测试阶段，有时会碰到很多低级缺陷，说明测试对象是不合格的，没有达到测试标准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多，最好停止测试，转由开发人员进行测试，发现问题立刻修改，因为这种由测试人员进行的成本较高，反复交互还会耽误进度。建议建立预测试制度：系统测试前对核心模块进行抽查测试，如果问题较多（例如平均每个核心模块发现10个以上缺陷），就可以停止本次测试，直到抽测后发现问题较少才可以启动系统测试。
6对测试人员的培训少，建议设立一个日常培训机构，并分别由各组来组织，时间为每天下班前半个小时（这段时间总是没心情测试的），利用这时，来对各组进行总结每天的测试成果，并开展组与组的座谈交流，有利于提高测试技能。
7避免特有技能在单人手中掌握，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。
自己的缺点：