新加入一个团体，如何尽快的展开测试工作？

发布时间: 2009-1-13 15:35    作者: zhuzx    来源: 51Testing论坛

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖

　　个人认为可以从软件测试的活动中的以下指标综合考评，去评估衡量测试效率，每项指标都高，自然能够说明一些问题：

　　1.发现缺陷的质量：

　　同一个项目组内，我们一般运用测试管理工具TD, 按优先级和严重等级，把每个人的缺陷做成柱状图和饼图，放到一个文档中，邮件发给大家，让组内成员了解自己的工作情况和其他人的工作情况。同时也让开发人员，对每个测试人员的工作，做出评估，供绩效考核时参考。特别是发现非常隐蔽缺陷的测试人员，一定要重赏。

　　2. 测试的有效性：

　　一般来说，递交Bug的有效性，体现了测试员是否能够正确理解系统，并发现问题，是否能够发现有效的问题。很多时候，测试人员没有弄准确需求，或者是没搞清楚设计，一旦出现异常，就提交Bug。不是和前面的缺陷相同，重复递交相同类型的缺陷，就是递交无效的Bug，导致后来很多缺陷，都被项目评审时拒绝，既耽误了时间，效率自然不高。

　　3.测试组员交叉测试，发现漏测问题数量：

　　经常是这样，一个测试人员测试结束，修复了全部的缺陷。这个时候，测试的模块和测试人员交叉一下，再测试，很有可能又发现很多问题。这样我们可以对测试发现问题数量，进行统计。这样做，就迫使测试人员认真执行每一轮测试，每次测试都不敢懈怠。

　　4.遗漏到客户缺陷的比例：

　　一旦版本测试通过，发布给客户以后，客户要对发布的版本进行验收测试。同样会发现一些问题，我们也会对测试过程中发现的Bug分配到每个模块和具体的人。但是，如果缺陷在测试环境中不能重现，只能在实际工作环境中出现，则不属于遗漏给客户的Bug，不计入漏测统计里面。有时候，客户系统在使用中也会发现缺陷，我们同样做好记录。

　　5.递交的缺陷数量：

　　在同一个项目组内，每天递交的Bug数量，每周递交的Bug数量，每个版本测试结束，总共递交的Bug数量。最终测试结束，算出每个人递交有效缺陷的百分比。

　　6.执行用例的数量：

　　同一天，每个测试人员，执行用例的数量。但是一定要去除那些不能够测试的功能模块，或者是被阻塞的模块，这些一定要考虑到。否则大家意见就大了呢！

　　7.编写测试文档的速度和质量：

　　每次编写测试用例时，大家都要编写部分模块的测试用例，我们也可以通过单位时间内编写case的数量、速度和质量，来区分每个人的效率，我觉得也是一种好方法。

　　8.评审发现问题的效率：

　　在组织部门内部的case评审时，同一个测试文档的评审，如果提出的修改建议比较多，并且很有参考价值。这样的测试人员，效率应该比较高，得考虑考虑加薪，呵呵。

　　9.测试工具使用的熟练程度：

　　当然，一个测试人员，对测试工具的熟练程度越高，使用技巧越强，一般来说，测试的效率就越高。按常理来说，每个人不可能了解全部的自动化测试工具，我们只对常用的测试工具进行考核就可以了，还算人性化吧。并且后面懂得较多的同事，给组内成员集体培训，使大家迅速掌握测试工具的基本使用，这才是我们的真正目的。

　　10.测试结果的分析水平：

　　对自动化的测试工具来说，特别是性能测试结束之后，我们要分析部分测试结果，如果你都不熟悉测试工具的分析，何谈效率呢？所以测试结果的分析水平，也可以作为衡量测试效率的一个指标。

　　如何提高测试效率？

　　1.首先要有一个合理的详细的测试计划：

　　没有详细的测试计划，测试部的每个成员都在那儿盲无目的测试，何谈提高测试效率？当然测试计划也不能够太细，太细了，编写测试计划同样浪费时间，做到时可而止。最好是测试任务尽量能细化到测试的功能和测试的case这个级别去监控进度，较为理想。

　　2.测试尽早介入项目详细了解项目的业务需求，做好测试的前期准备：

　　目前来说，可能大家都有类似的感受，接触到的大多数的项目，都是测试周期比较短，开发人员耽误了时间，为了不拖延项目进度，留给测试人员做测试的时间都非常紧张。如果项目测试的前期了解业务需求、了解产品属性和准备测试数据不充分，往往测试效率很低，测试时间变长，测试效率急剧下降。

　　3.对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情：

　　一般来说，如果大家认为测试的项目没什么发展前景，当然测试也不会很卖命，测试效率不用说。如果某个测试人员碰到什么不顺心的事，当天的工作效率肯定比平常低。所以，要保证测试效率，测试负责人要察言观色，及时找不开心的下属谈心，了解并帮忙消除部分员工的不良情绪，让员工有更好的心情投入到测试工作中去。

　　4.提高测试接受的标准，减少测试版本送测次数：

　　大部分公司的开发人员都有一种惰性，一旦公司成了测试部，他们自己测试时，都不会那么认真，以为有了测试人员，就自己就解放了。很多时候都是调试编译通过，实际上开发人员没有做完整的自测，就拿到测试部进行测试。如果测试部门有严格的测试接受标准，一旦发现有重大问题，立即拒绝测试，送回开发人员修改。可以减少很多次反复测试，重复测试，明显提高了测试效率。

　　5.测试负责人认真做好测试文档的评审：

　　测试经理一定要认真做好测试用例的评审，尽量使用较少的测试用例，发现较多的Bug，无疑是最佳提高效率的一种方式。很多时候，经验较少的测试人员在设计测试用例的时候，写了很多的测试用例，测试时几乎没有发现缺陷。还有一种：比如说等价类的测试，只要具备代表性就可以了，如果写了很多测试用例，执行了半天，臃肿的测试用例，未发现任何问题，也很不值。这些主要是靠测试用例评审的时候，测试Leader去把握了。尽量做到在满足需求的情况下，精简测试用例数量，提高测试覆盖率。很多时候，测试人员写好用例就自己测试,根本没人评审,有些地方理解有偏差,测试点没测试到,导致发给客户版本被退回，给公司也会带来巨大经济损失。

　　6.加强项目组成员的相互沟通工作和项目信息收集工作：

　　测试工作是一项沟通要求比较高的工作，一般需要同项目经理、产品经理、开发人员、业务人员、客户沟通。很多时候，由于测试介入较晚，测试时间短，测试初期测试人员了解需求不及开发人员，为了迅速熟悉需求，需要项目组成员之间相互培训和沟通。

　　测试人员为了利于测试工作，平时也需要主动和开发团队沟通项目的进度、项目存在的问题、项目的需求变更等等情况。与团队成员沟通得越充分、对项目的信息收集和把握得越及时、越准确，我们的测试工作才可能做得越顺利，才可能提高测试效率。

　　7.积极配合开发人员工作，努力赢得开发人员的尊重和支持：

　　作为测试人员，我们绝不能消极等待或一味埋怨开发人员的不理解和不重视。我们首先需要正视自己、改进自己，通过自身的不断努力让开发人员，真正体会到测试的价值。同时，也需要理解并配合开发人员的工作。只有这样，才能赢得开发人员的支持。互相配合、互相促进，项目成员之间形成良性循环，彼此感情加深了、配合默契了、工作效率和工作质量也就自然提高了。

　　8.按照项目的大小不同，必要的情况下引入自动化测试工具：

　　是否引入自动化的测试工具，主要取决于测试的时间长短和测试的轮次。一般来说，测试周期较长、版本升级平凡和回归测试次数较多的项目，引用测试工具可以提高测试效率。如果测试周期较短，本来测试周期只有两三个月，开发测试脚步就要花费大量时间，引入自动化测试工具，用的次数较少，结果得不丧失，劳民伤财，呵呵！

　　9.测试部门内部成员的工作业绩数据化：

　　具体的做法如下：每天给每个人分配的任务非常具体，并且随时关注他们的进展情况，完成百分比，不断督促他们。并且，把每个人每天的工作成果（发现缺陷的数量和工作的质量）数据化，通过邮件的形式发给组内的成员，让大家有个比较。大家都有自尊心，看到自己落后，后面就加油赶工，形成一种良好的测试氛围。每周周例会的时候，对表现突出的给予表扬，对每次都比较差的下属，单独谈心，问问具体原因。

　　10.提高测试人员的专业技能和工作能力：

　　由于测试技术的不断成熟和完善，许多的新技术陈出不穷，作为测试人员需要不断提高自己的专业技能和工作技能。不断的给自己充电，补充测试理论知识，让自己工作技能力去弥补专业技能的不足。这样，你的工作同样可以做到最棒，效率自然很高。一段时间过去，回过头来一看，自己确实进步不少，没有虚度光阴呀！

　　只是我个人的想法，希望同行批评指正！！

转载请保留：本文出自51Testing软件测试论坛每周一问活动，感谢会员爱吃鱼的月亮的精彩回答。

　　整个工作内容主要有:

　　1、改善测试流程，形成《测试流程》文档

　　2、规范测试工作，形成《测试规范》文档

　　看上去就只需要上面两个文档就够了，但经详细分析，发现还需要很多相关的需要文档，整理了一下主要有

　　1、《测试申请与反馈表》模板

　　2、《测试计划》模板

　　3、《功能测试测试点》模板

　　这个与测试用例差不多，但不用写得很详细，主要把容易漏掉的测试点写下来

　　4、《BUG严重性等级与优先级定义》文档

　　5、《BUG提交注意事项》文档

　　6、《功能测试报告》模板

　　7、《性能测试计划》模板

　　8、《性能测试指标及相关说明》文档

　　9、《性能测试报告》模板

　　10、《项目测试报告》模板

　　11、《项目资料存档规范》文档

　　二、测试执行计划

　　执行计划是确保正常的实施测试活动

　　包含内容：

　　注意考虑：1.测试执行的轮次安排

　　2.测试执行的时间安排（参考程序发布计划）

　　3.测试执行的人员分配

　　4.测试执行的环境要求和搭建

　　三、测试执行记录

　　● 做测试执行记录原因？

　　1.保证测试工作的可追溯性

　　2.记录测试人员的工作情况

　　3.绩效评估的重要数据

　　● 记录的内容

　　1.什么人－－测试执行人员

　　2.在什么时候－DATE

　　3.做了什么－－Case ID

　　4.结果如何－（Pass/fail ）

　　四、执行测试过程

　　1.设置测试环境，确保所需的全部构件（硬件、软件、工具、数据等）都已实施并处于测试环境中

　　2.将测试环境初始化，以确保所有构件都处于正确的初始状态，可以开始测试

五、测试执行活动结束或终止

　　1.正常终止：所有测试过程（或脚本）按预期方式执行至结束。

　　– 如果测试正常结束，则核实测试结果

　　2.异常或提前结束：测试过程（或脚本）没有按预期方式执行或没有完全执行。当测异常终止时，测试结果可能不可靠。在执行任何其他测试活动前，应确定并解决异常/ 提前终止的原因然后重新执行测试。

　　– 如果测试异常终止，则恢复暂停的测试

　　六、核实测试结果，真正的缺陷：

　　1.通常发生在实际结果与预期结果不匹配时

　　2.意外的GUI窗口（图形界面）

　　3.业务流程错误

　　七、测试执行准备

　　1. 执行前，动员工作：阐述策略，回答问题，定义测试计划、测试范围

　　2. 严格审查测试环境，包括硬件、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本

　　3. 将测试用例分类进行有效整合，构造测试套件（test Suite）

　　4. 所有测试用例、测试套件、测试任务和测试执行结果通过测试管理系统进行管理，使测试执行的操作、过程记录在案，能跟踪、控制和追溯，保证测试进度和质量

　　5. 确保每个测试人员理解测试策略、测试目标，对测试进程进行审查，确保测试策略得到执行，可奖励手段，测试经理、组长要勇于承担风险，使测试人员有发挥、想象的空间，但同时也施加压力，提高工作效率和责任心

　　八、测试执行过程

　　1. 记录测试记录，用例的执行状态使pass/fail

　　2. 记录缺陷报告捕获测试结果，提交给上级审查及实现人员进行修复

　　3. 缺陷跟踪和管理一般由特定工具来执行，对各模块、各测试人员、整体项目等进行事实跟踪。

　　4. 进行常规的缺陷审查，包括BUG的严重性、BUG的描述、BUG修正等

　　5. 对每个阶段测试结果进行分析，保证阶段性的测试任务得到完整的执行并达到预定的目标

　　6. 良好的沟通，测试人员之间，与项目组之间保持有效的沟通，如每周例会，可以及时发现测试中问题。

　　1．基于“测试阶段”的原则：

　　每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100％经过Code Review”、“功能覆盖率达到100％”、“代码行覆盖率不低于80％”、“不存在A、B类缺陷”、“所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。

　　2．基于“测试用例”的原则：

　　测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。

　　3．基于“缺陷收敛趋势”的原则：

　　软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。

　　4．基于“缺陷修复率”的原则：

　　软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。

　　转载请注明出自51Testing软件测试论坛

　　5．基于“验收测试”的原则：

　　很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。

　　6．基于“覆盖率”的原则：

　　对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心，非得要看看测试用例的执行效果，检查是否有用例被漏执行的情况，可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试，每个阶段都不能忽略。

　　7．基于“项目计划”的原则：

　　大多数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成，就可以作为一个结束点。很多不规范的软件公司，都是把项目计划作为一个测试结束点，但是如果把它作为一个结束点，测试风险较大，软件质量很难得到保证。

　　8．基于“缺陷度量”的原则：

　　这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题，我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然，最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说：一万行代码最多允许存在多少个什么严重等级的错误，这样比较好量化，比较好实施，成为测试缺陷度量的主流。

　　9．基于“质量成本”的原则：

　　一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是：人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候，可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”，同时保证公司利益最大化。如果找到bug的成本比，用户发现bug 的成本还高，也可以终止测试。

　　10．基于“测试行业经验”的原则：

　　很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。

转载请保留：本文出自51Testing软件测试论坛每周一问活动，感谢会员爱吃鱼的月亮的精彩回答。

在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与；测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。

　由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些

　识别和注意少数重要的方面，而忽略多数次要的方面，有时候少数的问题足以致命，这些问题将是软件测试结果中重要性最高的错误。

　错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。

　对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。

　有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。

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

测试用例的基本格式

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

用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： 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 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。
　　
测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。
　　
输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。
　　
日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。
　　
根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。
　　
测试结果分析
　　
软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。

      1：易用性：
     按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

     易用性细则：
     1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
     2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
     3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
     4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
     5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
     6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
     7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
     8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
     9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
     10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
     11):复选框和选项框按选择几率的高底而先后排列。
     12):复选框和选项框要有默认选项，并支持Tab选择。
     13):选项数相同时多用选项框而不用下拉列表框。
     14):界面空间较小时使用下拉框而不用选项框。
     15):选项数叫少时使用选项框，相反使用下拉列表框。
     16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
     2： 规范性：
     通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。

     规范性细则：
     1):常用菜单要有命令快捷方式。
     2):完成相同或相近功能的菜单用横线隔开放在同一位置。
     3):菜单前的图标能直观的代表要完成的操作。
     4):菜单深度一般要求最多控制在三层以内。
     5):工具栏要求可以根据用户的要求自己选择定制。
     6):相同或相近功能的工具栏放在一起。
     7):工具栏中的每一个按钮要有及时提示信息。
     8):一条工具栏的长度最长不能超出屏幕宽度。
     9): 工具栏的图标能直观的代表要完成的操作。
     10):系统常用的工具栏设置默认放置位置。
     11):工具栏太多时可以考虑使用工具厢。
     12):工具厢要具有可增减性，由用户自己根据需求定制。
     13):工具厢的默认总宽度不要超过屏幕宽度的1/5。
     14): 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
     15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
     16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
     17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
     18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
     19):右键快捷菜单采用与菜单相同的准则。

     3：帮助设施：
     系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

     帮助设施细则：
     1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
     2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
     3)：操作时要提供及时调用系统帮助的功能。常用F1。
     4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
     5)：最好提供目前流行的联机帮助格式或HTML帮助格式。
     6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
     7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
     8 )：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

     4：合理性：
     屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

     合理性细则：
     1)：父窗体或主窗体的中心位置应该在对角线焦点附近。
     2)：子窗体位置应该在主窗体的左上角或正中。
     3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
     4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
     5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
     6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
     7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
     8)：非法的输入或操作应有足够的提示说明。
     9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
     10):提示、警告、或错误说明应该清楚、明了、恰当。
     5：美观与协调性：
     界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

     美观与协调性细则：
     1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
     2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
     3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
     4): 按钮的大小要与界面的大小和空间要协调。
     5): 避免空旷的界面上放置很大的按钮。
     6)：放置完控件后界面不应有很大的空缺位置。
     7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
     8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
     9): 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
     10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
     11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
     12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
     13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
     14): 通常父窗体支持缩放时，子窗体没有必要缩放。
     15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

     6：菜单位置：
     菜单是界面上最重要的元素，菜单位置按照按功能来组织。

     菜单设测试细则：
     1)：菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
     2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
     3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
     4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
     5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
     6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
     7): 菜单深度一般要求最多控制在三层以内。
     8): 对常用的菜单要有快捷命令方式，组合原则见8。
     9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
     10)：菜单前的图标不宜太大，与字高保持一直最好。
     11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
     12)：主菜单数目不应太多，最好为单排布置。

测试工程师的工作流程，与公司的整体工作流程，项目的测试要求等因素相关。本文主要讨论测试工程师的一般工作流程。

做好测试准备

1) 明确测试任务的范围  

    测试文档通常包括测试目的、测试环境、测试方法、测试用例、测试工具等。测试工程师首先要通读文档，对整个测试要求形成整体认识，明确测试目的，以及测试要求和测试重点，明确软件测试方法和使用的测试工具。  

2) 明确测试时间  

    明确测试周期和测试时间进度。如果是多人合作完成一个软件，则要首先明确属于自己的测试内容、根据测试内容和测试周期，估算自己每日应该完成的工作量。此外由于软件测试是群体协作的测试活动，需要明确哪些测试内容要与其他测试工程师协作才能完成。  

3) 设置测试环境

    根据测试文档要求，设置测试需要的软件和硬件环境，包括操作系统，要测试的软件和其他必要的测试工具软件等。所有这些完成后，分别运行，查看是否能正确运行，保证符合测试文档要求的测试环境。  

4)学习被测试软件

    对于不太熟悉的软件，可以通过阅读软件自身的教程和帮助文件，学习本软件的一般操作方法，也可以参照相关的书籍资料等。另外，向熟悉测试软件的其他同事请教软件使用方法，也是学习软件的一条捷径。对软件使用越熟练，测试过程越顺利，测试效果越理想。  

5) 确认完全理解测试任务

    软件测试最重要的要求就是确实明确了测试任务和要求，这包括正确理解了测试文档，确认可以按照测试进度要求，完成测试。对于测试工具要正确安装，熟练使用。如果有任何不明白之处，向软件测试负责人询问。切忌凭自己的理解和主观推测，自行其事。当然，真正测试中，往往会遇到各种新的小疑难问题，也需要及时向测试负责人请教，以保证测试顺利进行。

执行软件测试任务  

1) 按照测试文档要求，逐项认真测试

    根据测试文档测试要求，按照测试步骤，逐项进行。通过运行软件，观察测试结果，与软件需求说明书的内容进行比较，找出软件错误。对于需要调用测试用例的测试，保证正确地调用了测试用例，注意观察和分析测试结果。某些不容易重复的错误，需要反复测试，总结重复该错误所需要的测试步骤，直到确认可以重复出现为止。  

2) 记录发现的错误，填写软件问题报告  

    为了纠正软件中的错误，测试工程师要正确记录发现的错误，将错误再现的步骤写入测试报告中，测试报告是程序测试的重要组成部分，正确书写测试报告是对测试工程师的基本要求。采用软件缺陷数据库管理测试中发现的软件缺陷，每一条错误作为数据库的一条记录，方便记录、修改、查询。  

3) 填写测试进度表和必要的测试内容记录表

    每天将测试内容写入测试进度表文档，可以使测试负责人了解测试进度，控制测试周期内测试的连续性，增强测试过程控制性，保证测试的正常进行。测试记录要准确完整，实事求是，必要时插入测试注释，解释测试中的特殊问题。测试进度表是评价测试质量和工作内容的重要凭证，对于测试后发现的测试错误和失误，可以通过检查测试记录，寻找产生错误的原因。  

4) 测试中发现疑难及时请教

    测试是一个动态的过程，可能由于自己的错误操作或者测试文档内容的错误，使得测试过程中出现自己不能解释的现象或结果，出现与测试要求不符合的情形，这时可能需要与其他测试者协商或求助，如果问题仍然不能解决，应该及时请教，听取意见和建议，必要时反复讨论直到问题全面解决。

全面检查测试结果

1) 对照测试文档要求，检查测试内容是否完整  

    测试完成后，要对照测试文档检查测试是否全部完成，保证没有丢失测试内容。如果某些内容，由于测试环境的要求不满足，或者由于测试时间短没有进行，则要写入测试进度表文档。  

2) 检验书写的软件问题报告的记录，使之确切、规范

    正确书写测试记录是保证迅速定位软件错误，加快改正错误的必要前提。专业规范的软件记录报告是体现公司测试水平和专业实力的外在体现。认真检查书写的每条记录是否符合规范，格式、步骤、内容一一检查，必要时补充或删减。  

上述三个阶段，相互联系紧密，其中准备是基础，测试是重点，检查是保证，应该根据测试的软件特点合理安排