QTP 技术集锦&描述性编程

摘要：本文针对需求不明确的情况下如何做测试，列举了3个步骤。这些步骤，都是实际经验的总结。利用这些步骤，可以在需求不明确，或是没有需求的情况下，进行必要的测试工作。但是，这些都是不规范的方法。需求不明确，或是根本没有需求，这本身就是一件不规范的事情，无论是开发人员，还是测试人员都无法在不规范的环境中，做规范的事情。但是工作要继续，不能因为某些障碍而停止。这时，请参考每一个步骤，尽可能地完成测试工作。关键字：需求；需求规格；测试需求；文档；猜测；沟通软件生命周期中，需求是整个.

虽然我已经可以使用很多种编程语言进行工作，但我的工作常常会要求我快速掌握一门新的语言。我没有选择去阅读几百页的程序手册，而是快速浏览10到15页的教程（可以在Google中搜索），并把程序语言的语法参考说明印在小卡片上（在google里搜索language to learn+reference card就能找到）。　　首先，我会熟悉这种程序语言的编译器、编译选项、编辑器或集成开发环境的的快捷键和小技巧，写一个简单的“你好世界”程序，编译并运行它，再用调试器进行简单的调试，如设置断电、查看变量值、跳转到某一位置等。　　为了能够快速地掌握.

请见附件

实际工作当中，我对测试需求的提取和测试需求变更操作的过程：测试需求的提取一．熟读《用户操作手册》，熟悉用户对系统的操作流程；二．依据《用户操作手册》的指导，站在用户的角度，能够熟练地操作系统；三．依据《用户操作手册》的指导，使用Rational Rose工具，建立业务流程图（使用者角色、活动（输入和输出）、外界系统的交互等）；四．仔细阅读SRS（系统需求规格说明书），了解用户需求，提取测试需求点（页面检查、功能项、业务流程、状态转换、）。将测试需求点在rose工具中做相应.

测试执行的用例选择原则——抢钱原则（作者: gracehjd）　　“抢钱原则”——你面对飘洒满地的纸币，有100元，50元，10元，5元，2元，1元，5毛，2毛，1毛。 各种面值。大家抢钱的时候，都是先挑选100元的抢走，然后找50元的，选择的顺序很清晰，都是从面值大到面值小。这就是“抢钱”原则。　　测试执行的时候，大家面对是一堆用例，这些用例起到的作用也是不同的，那么如何保证我们在有限的时间执行的用例是最有效的，最有价值的。　　尤其是无法全部执行用例的时候，势必有裁剪的时候，我们需要有很好的用例执行的优选原则。.

测试用例设计方法---场景VS功能1 目的站在用户的角度，以用户的使用逻辑及操作习惯为出发点，结合功能用例的设计方法，使用例设计更符合用户使用逻辑更具有可执行性，从而最大程度上覆盖用户需求。2 使用者用例设计、执行及热爱测试的人员3 测试用例设计方法按照不同的规则可以将测试用例分为四个部分：场景用例（用户场景）、系统用例（用户场景的细化）、功能用例（基于业务规则、界面）、设计指标（基于环境、性能、安全等）。用户场景用例：按照用户的实际操作与业务逻辑设计用例，不必.

下面是转载的一片关于bug严重级别和优先级的文章。工作中对bug严重级别和优先级的关系一直很迷惑，感觉应该是事先规定好的。看了项目的软件测试管理流程才知道优先级是由tester主观定义的。看来是不科学！流程管理方面有问题。今天看到论坛里一个学员在问“到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？”，还有学员对优先级这个字段理解的不够透彻，原话是“优先级的填写要看情况的。因为有时Tester 开的bug 很多，而PM又有好多TESTER，那PM就来不及去一一看那些BUG了，这时Priority就得由.

〈〈〈〈〈〈转载学习〉〉〉〉〉〉本人在HSBC做core banking 的黑盒测试有2年了， share一点点经验吧，1. 黑盒测试一般有SIT(System integration testing), SAT(System acceptance testing), UAT(User acceptance testing), BAT(Business acceptance testing), OAT(Operation acceptance testing).前面3种会比较常见，后面两种要看user的意见了。2. 对于我们银行系统的黑盒测试来说， 业务知识是非常重要的，特别是UAT,BAT的时候，我们所写的test cases也必须能让user看懂，因为这时我们已经在模仿一个USER的日常工作。 .

　在论坛里读了前辈的一篇《如何有效提交问题报告》文章，感受颇深！抱着学习的态度，我将前辈的工作经验进行了总结，并制作了操作流程图。希望对个人和他人的工作能有所帮助。当然，初涉测试行业，能力浅薄，不足和错误的地方，大家不吝赐教！！！　　（一）ｂｕｇ报告的目标：　　　　　　　　　　　１。让开发人员看到报告就能确定ｂｕｇ　　　　　　　　　　　２。开发人员根据报告很快的重现ｂｕｇ　　　　　　　　　　　３。能给开发人员修改ｂｕｇ提供帮助　（二）ｂｕｇ报告的要求：　　　　　　　　　　　非常清.

如何才能提交好的测试bug在有些组织里，程序员几乎会把一半的测试bug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决：因为编写这些报告浪费了时间；会影响程序员和测试人员之间的团队凝聚力；最糟糕的是失去改进产品质量的机会。有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不.

bug描述的标准有：　　1、基本标准：需要让开发人员能根据描述理解这个bug。　　2、最好能让开发人员能明确这个bug在哪可以找到（定位）、需要怎样修复。　因此我对bug描述的建议就是：　　1. 有条理的把每个小问题列出来，分123，不要怕条目多。　　2. 描述问题时一定要把背景交代清楚，即在哪些操作后或者什么环境中会出现，不要忽视那些你看来可能不会引起问题的操作，越细致越好。　　3. 善于使用截图和视频录制，这些可以更直观的说明bug的产生过程和结果。4.再现：尽量三次再现故障。如果问.

工作当中，如何在有限的时间内有效的设计测试用例