1、一 测试部分软件：程序和文档的集合。程序是实现某些功能指令的集合；文档是各个阶段产生的各类文档和图片的综合。软件缺陷：计算机硬件、软件系统或应用软件中存在问题而无法正常工作。软件生命周期：从软件需求的定义、产生直到被废弃的整个生命周期。软件测试：运行系统或程序，检查是否符合用户的需求及预期结果与实际结果之间的差别。软件测试用例：针对需求规格说明书中相关功能描述和系统实现而设计的一组测试输入、执行条件和预期结果的组合。软件测试环境： 硬件环境（PC、电脑、服务器、小型机、大型机等） 软件环境（操作系统、数据库、办公和杀毒软件等） 网络环境（局域网、广域网和因特网）搭建环境注意几点： 尽量模拟用户
2、的真实场景 干净的环境 没有病毒的影响 独立测试环境软件测试的分类：1. 阶段划分：单元测试、集成测试、系统测试、验收测试2. 是否运行程序：动态测试和静态测试3. 是否查看源代码：白盒测试、黑盒测试和灰盒测试4. 其他方式：回归测试、冒烟测试和随机测试5. 功能测试：界面测试、业务功能逻辑测试、兼容性测试、易用性测试、安全性测试和安装测试6. 性能测试：负载测试、压力测试、容量测试、并发测试、配置测试、可靠 性测试和失败测试桩模块：调用被测模块的模块叫桩模块；驱动模块：被测模块调用的模块叫驱动模块； 测试：开发公司组织内部人员模拟各类用户行为对即将上市软件产品进行测试，试图发现错误并修正。
3、测试：开发公司组织各方面典型的用户（如放到互联网上供用户免费下载或以光盘形式发放给用户并试用一段时间）要求用户报告异常情况，提出改进意见。对软件进行更正完善。回归测试：在新版本测试时根据上仪版本的用例进行回归或根据上一版本中存在的 BUG 进行回归测试瀑布模型：计划需求分析设计编码测试运行维护螺旋模型：1. 规划：确定软件目标，选定实施方案，弄清项目开发的限制条件2. 风险分析：分析评估方案如恶化考虑识别和消除风险3. 原型开发：实施软件开发和验证4. 用户评审：评审开发工作，提出修正意见，制定下一步计划V 模型：可行性分析 验收测试 需求分析 系统测试 概要设计 集成测试 详细设计 单元测试
4、 编码软件测试的流程：制定测试计划测试设计和开发实施测试测试总结评审测试计划：描述所有要完成的测试工作，包括测试项目背景、目标、范围、方式、资源、进度安排、测试通过标准、测试组织及测试风险等方面测试总结：系统的概述、编写目的、参考资料、测试环境、残留缺陷、缺陷统计、缺陷分析、测试活动总结、测试结论等二、数据库部分1.Insertinto 表名（字段名 1，字段名 2，）Values（值 1，值2）用字符串转换日期 To_Date(2010-07-05,YYYY-MM-DD)年-月-日 小时:分:秒对应的格式 YYYY-MM-DD HH24:MI:SS2.Delete from 表名 where
5、 条件注意：如果要删除表里全部记录可以用 TRUNCATE 命令即：TRUNCATE TABLE 表名,3.Update 表名 Set 字段名 1=值 1，字段名 2=值 2 Where 条件4、Select 字段名 1，字段名 2 from 表名 where 条件5.Create Table 表6.Alter Table 表名 1 To 表名 2（改表名）Alter Table 表名 Add 字段名（加字段）Alter Table 表名 Modify 字段名（修改字段）7.Drop Table 表名 CASCADE CONSTRAINTS(删除表和所有约束条件)8.Truncate 表名（清
6、空表记录保留表结构）三、业务部分增值税：增 值 税 是 以 商 品 （ 含 应 税 劳 务 ） 在 流 转 过 程 中 产 生 的 增 值 额 作 为计 税 依 据 而 征 收 的 一 种 流 转 税 。车 购 税 ：常常会遇到时间紧张，任务重的项目，在这种情况下，如何保证测试质量，我这里抛砖引玉，希望大家来提出自己的高见：1. 项目成员明确需求，需求按优先级排序，评审之后少做变更需求是源头，PD，开发，测试前期评审把好关，越早发现问题，越容易解决，花费的代价越小。要做到需求按优先级排序，把需求分解成具体的最小级别的功能点，先实现高优先级的需求。三方评审通过后，项目中冻结需求，尽量少做变更。2
7、. 制定合理的测试计划，明确里程牌时间和负责人测试计划是指导测试行动的总纲领，规划好测试设计，用例编写，测试执行的时间，测试负责人每天关注进展，及时调配资源，将问题解决在萌芽状态。3. 保证测试设计和用例的质量资深的测试工程师负责测试设计；按测试组成员能力水平分配任务，完成用例设计。完成之后，进行测试组和项目组的评审，查漏补缺。4. 提高测试介入的标准时间紧张，需要开发保证代码质量，测试介入的标准肯定是必须通过冒烟测试。冒烟用例评审时一定找开发确认，开发自己先执行成功冒烟用例，保证测试介入后能顺利走下面的流程。5. 迭代测试开发迭代提交模块，测试针对性进行测试。迭代测试增加了测试时间但是并没有
8、延误整个的时间进度，因为在每一个迭代过程中测试过程都是提前开始的。6. 每天召开晨会，沟通项目进度，解决问题介入测试时，开发，测试，PM 等团队成员每天花半小时召开晨会，沟通各自的进展，列出项目中的问题，确认解决人和解决时间。问题及时解决，会加深团队伙伴的信任，激发工作热情。当然，测试工作最终还是基于代码质量的，当我们发现低估了项目复杂度的时候，增加测试时间才是明确的选择。欲速则不达，着急冒进，项目的质量很难得到保障，压缩的时间迟早会补偿回去。首先，这个问题是一个非常具有现实意义的问题，特别是国内企业，这类问题很严重，相对国外企业项目也会遇到这类问题，但是相对而言更容易解决。基本上在任何一个项
9、目都没有说是人员充足，时间充足的，这个永远都是多多益善。主要谈一下我自己的经验和看法：在进度较紧、资源也不是十分充足的情况下，如何开展测试工作？1、对外部，对客户，如果这个项目是在某个时期才发现时间紧迫，或者出现什么问题才导致这个时间相当紧迫的，那首先第一点，我们要让客户经理，拖住客户，向客户那边找各种理由多要时间，当然，不一定要告诉客户我们真正的困难，因为也许你说出来，客户更要着急。即使不能拖时间，也要最起码不让客户再压缩时间。如果是非常正规的客户，你们也是非常正规的大公司，在和另外一个公司合作，真的有问题，而且很难隐藏的住，那就跟客户明说，并且寻求客户的帮助，很多国外大公司还是相当开明的，
10、并且喜欢坦诚的这种合作，喜欢共同克服问题，这样效益也是最高的。当然这个看具体情况。这个做目的是稳住客户。2、对内，分 3 部分看：1）向领导说明情况（后面会提到不少问题需要老板知道，并且决定，需要首先跟你的老板说明情况） 。然后在继续要人手，当然，你要确保人手进来要能提高进度，而不是延慢进度，带来更多问题，最好心有某些人选，无论给不给，先要再说。2）对开发团队，要求开发协助，开发人员其实很清楚自己的程序那个地方可能有问题，让他们自己说出来，省的你去找了。然后同时需要问开发很多具体的问题，这个我们下面谈测试团队内部问题是会涉及到和开发的合作。这里目的先跟开发打好招呼，需要分一定时间你们合作，到时
11、候不能让他们赖掉。同时跟 QA 团队也打好招呼，先预告有问题了，在下面具体的论述中我说明谈啥内容。3）对测试团队内部的处理，这个是重点：a）首先我们需要搞清楚，我们处理这类问题的原理，我们的目标是我们要在这，比如剩下的 1 各月时间内，产生最大的效益。同样的一个月，也许我们以前能发现 60%的缺陷，假设其中缺陷严重从最严重到最不严重的程度比例是（1：3：6） ，那现在我们的目标是，能够发现 70%的缺陷，缺陷的比例是 （1。5：4 ：4。5） ，就是说达到投入产出比例最高，尽量把所有最严重的问题都能找出来，这个是我们的目的。然后剩下 30%的缺陷没有发现怎么办？没关系，首先他不够严重，我们遗留
12、下来的缺陷，是那些客户绝对不会在刚上线使用的前，比如 1 个月之内会发现的缺陷，我们可以利用上线之后 1 个月的时间，继续测试这个项目，找出剩下的 20%，然后打补丁过去，在客户还没有完全发现这些缺陷之前，我们这个补丁包过去就全部搞定了。当然这个过程需要老板审批，老板决定后面上线后能继续留出多少时间来给这个系统测试，这个也需要先跟老板打好招呼。然后如何做到，下面说具体的方法：b）根据 80-20 原理，80%的重要缺陷是发现在 20%的代码中的，实际中可能不是完全一致。但是这对我们打到最高的效益有相当的指导意义。c）分析历史数据，或者从 QA 那里得到相关的数据，查看同类型的产品，或者本产品的
13、以前版本，发现的各种类型的缺陷的分布，然后和我们当前的测试数据比较，看看我们的具体的未发现的问题主要可能在什么地方，然后重点测试。这里其实能分析出来的问题非常多，具体内容可以单独另辟文章讨论d）和系统分析员、开发负责人一起分析，各个模块的重要性，哪些地方关联度最高，缺陷影响最大，这些地方一定要测试。就是把模块按照重要程度排序，然后测试顺序按照这个顺序测试，这可以保证测试完最重要的模块，和主流程。和需求人员、维护人员沟通，找出以前的上线版本经常出现的问题，现在尽早关注搞定。e）测试过程，指导测试人员，对于某些非主流程模块，小缺陷不需要写入缺陷库，找出来记住就好了，不影响功能的话，不写，直接写影响
14、功能的缺陷，因为写缺陷还是消耗不少时间的，还有有些缺陷是否可以直接跟开发讲，自己同时记下来，但是不写到缺陷库，我这里是说可以考虑这么做，但是这样的话对后期的缺陷分析有一点问题，后期也可以补充，这些方法可以考虑，自己权衡f）跟项目总负责人，QA 打好招呼，裁剪流程，某些不必要的文档工作，先等等再说，文档的中间过程可以尽量省略，但是最后的重要讨论结果最好记录g）项目进行过程中，注重沟通而不是文档，加强口头沟通，并加强沟通效率，面对面的沟通能减少很多非必要的时间消耗，并且问题说明的更加清楚。这个刚开始要和开发负责人打好招呼，否则这么多沟通，人家不一定愿意，可能他会认为这样浪费了他们时间，这个一定要达
15、成共识，当然，你确实要保证沟通高效h）优化项目内部测试人员安排，一般情况下，我们都是经验丰富的人，能力强的人做比较复杂的模块，能力一般的人，做简单的模块，这时候，我们可以考虑时间效益，是否需要让一个能力强的对业务熟悉去做相对简单的模块，这样可能只需要 50%的时间，让那个能力一般的做难的部分，可能只多用 30%的时间，这样你还多赚了 20%的时间。尽管有一定风险，但是你可以考虑，这里我只是说考虑这些因素，考虑优化人员的安排。i）以前可能测试人员对业务的了解都需要看需求文档等等，但是，在目前时间紧迫的情况下，可以考虑直接让需求人员来讲解，然后测试理解，再复述给需求人员听，然后需求人员再问他们问题，通过这种方式来确保对业务的理解，同样对开发也是尽量多口头沟通，少书面沟通。3、以上步骤，同步进行，自己作为项目测试负责人，一定要心里有谱，同时尽量放权，让每个人责任清晰明确，意识到当前的形势，尽早反馈他们发现的问题，提出各类风险。自己做主要掌控全局的人，同时抽查各个地方的质量。总体就这么多吧，实际操作完全看个人能力和以前对队伍的培养了。因为平时是流程起作用，但是流程的弹性不够，关键时刻一定是人的因素更重要。
