测试基础知识笔记

学习资料整理1.1测试风险表1.1.1风险描述：开发交付版本延期风险（例如不满足入口准则）风险发生可能性：高风险的影响程度：高规避方法：调整各个阶段投入人员的比例，但是会造成我方人员工作上安排的不便；考虑如何解决不满足测试入口准则的情况。1.1.2风险描述：项目延期风险风险发生可能性：高风险的影响程度：高规避方法：尽量控制前面投入的人员及工作量；要求增加因外包项目延期导致产生的附加工作量。1.1.3风险描述：项目提交测试较晚，测试周期短风险发生可能性：高风险的影响程度：高规避方法：提高开发进度的要求；保证必要的测试周期；通过适当的加班、增加测试时间来解决；采用研发交付系统+测试周期的形式（T+D）1.1.4风险描述：如果在测试过程中发现较多缺陷，开发人员需要完成新功能，同时要修复的缺陷可能来不及修复完，导致项目延期。且部分缺陷要流转给客户风险发生可能性：高风险的影响程度：中规避方法：约为致命缺陷修复的周期为两个工作日，而其他类型缺陷修复的最长时间为3个工作日；开发方应严格按照代码规范编写代码，做好代码评审和单元测试，测试应尽早发现业务逻辑方面的bug。1.1.5风险描述：由于是第三方进行代码研发，系统在交付日期到达时可能存在未全部交付测试的情况，而是部分交付风险发生可能性：高风险的影响程度：中规避方法：测试人员安排进行调整；测试计划进行调整；各测试阶段和用例设计方案进行调整，很可能造成测试延期；采用一次性集成方式进入集成测试。1.1.6风险描述：版本控制风险风险发生可能性：高风险的影响程度：中规避方法：按照方案中的计划，事先约定好测试的版本交付日期和测试轮次；建议质量控制部门控制版本发布，采用版本控制从研发到质量部门再到测试团队，测试团队测试后版本回到质量部门，质量部门再交付运行中心的方式。1.1.7风险描述：需求变更过多，未能及时提交信息到全部相关人员风险发生可能性：中风险的影响程度：中规避方法：需求尽早充分明确，文档描述准确，避免歧义；变更要及时通过禅道记录并通知。1.1.8风险描述：测试团队人员的变动、生病、事假等风险发生可能性：中风险的影响程度：中规避方法：加强团队管理，确保项目核心人员稳定，最好建立备份机制。2.1测试发散2.1.1测试中经常存在的问题目前，测试会碰到如下现象：2.1.1.1测试人员没有办法了解所测系统的用户需求具体表现：没有用户需求文档；测试人员不需要了解也没有权力知道用户需求。2.1.1.2测试人员在项目组中工作职责和内容不明确具体表现：测试人员要记录整理需求变更，进行新需求确认，培训用户，系统维护支持，培训文档、维护手册的编写，测试的执行以及问题的跟踪，测试文档的编写。2.1.1.3测试人员要在短时间内测试改动很大的软件，同时软件更新很频繁具体表现：版本更新频繁，需求变更管理不友好。程序发生了变化，测试人员是看到所测试的软件才知道发生了什么变化。由于时间短，人力资源短，测试很难做到更深一层和更完善。2.1.1.4测试人员和开发人员的沟通有效问题2.1.2软件测试随想2.1.2.1了解产品的商业目标每次接到的新项目，它都是针对一个新的业务领域，我们接触过产品管理，产品代购，物流管理等等软件。每个产品针对的业务领域不同，该产品的商业目标也是不同的。我们作为测试和开发人员首先要抓住该项目的商业目标，这样才能知道产品的重点在哪里，也就知道产品的主要风险在哪里，该如何针对其商业目标开发我们的测试用例。比如我们接触过的RouteVersion项目，它是关于交通工具管理系统，收集所有交通工具每天的数据，在这个项目中报表是最多的，也是该项目最主要的功能，那我们就需要在项目一开始把报表系统作为一个风险考虑进来，包括其采用的开发技术，以及如何测试还有很多的测试数据，都是需要提前考虑清楚的，而且既然是报表系统，那么它就会和很多其他模块有着许多的联系，这样集成测试就显得特别重要了。我们还开发的另一个项目GTO，它是一个代购网站，将卖家和买家都召集到这个网站上进行交易，其中一个最重要的业务是招标系统，招标系统是个很专业的业务领域，如果提前没有把它的流程搞得很清楚，就会对后面的开发造成不小的影响。2.1.2.2测试驱动设计测试人员可以发挥过去在其他项目中积累的对客户需求的理解，以一个代表“用户”的角色与老板，与开发负责人一起商讨产品应该具有哪些功能，如何设计才能满足用户的需求。对于能力很强，经验丰富的测试人员还可以参加产品的架构评审，设计方案质量的把关。确保产品设计满足最初的需求规划，产品的设计缺陷不会留给用户。我们把这个阶段的测试活动都定义为“测试驱动设计”。在我接触的项目当中，我参与了很多项目的设计阶段，发现很多产品设计不合理的地方，也就是易用性比较差，但平常总结的比较少，在这方面对专业软件关注的比较少，所以自己也不能提出更多由建设性的意见，希望以后我能将所有工作中碰到的这些问题总结出来，不断提升自己在产品设计阶段的能力。2.1.2.3测试覆盖率问题有效的测试覆盖率是最重要的测试工作目标，需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试可以达到代码覆盖率100%，但是单元测试只能保障消除产品编码的问题，针对产品设计的问题则很难发现。发现产品设计问题的最主要方法还是需要基于黑盒的测试分析和设计。如何做好测试分析和测试设计，需要从以下几个方面来大致达到一个比较高的有效测试覆盖率：1、将软件所有的功能按照用户实际场景划分，开发测试用例；优点：可以覆盖到主要的基本场景；缺点：从事场景分析的人无法做到了解客户所有的场景，这样就会有场景遗漏；2、通过软件内部实现流程的路径及依赖关系分析入手，开发测试用例；优点：可填补前面没有覆盖到的一些场景，特别是异常处理和分支交互处理的场景；缺点：仍然会遗漏真实环境中的一些偶然小概率事件；3、依赖基于经验的测试分析和设计，例如：错误猜测法和探索性测试法；优点：对测试设计再次作出补充；缺点：测试用例的完整度取决于组织内部经验的积累量及测试人员思维的发散能力和创造性；因此：测试的核心技术是测试分析和测试设计的能，它决定了后续所有测试活动的质量及效果，同时，要做好一个测试任务，掌握广泛的测试类型也是必要的核心技术。4、测试结束时间：验证系统已100%满足项目需求规格，就可以作为测试结束的标准；在满足的基础上如果还有时间和资源，就可以开展探索性测试，继续以挖掘bug为动机进行测试，探索性测试覆盖的内容可以是测试用例之外的场景，考虑一下还有哪些场景没有测试到。在测试计划时间结束前，都可以一直把探索性测试做下去，以发行bug为准，结束标准只有一个：测试时间结束了。2.1.3手机测试测试伴随着整个手机软件开发的各个阶段中。测试的成功与否，测试的覆盖好坏与测试质量的高低直接关系到手机软件的可用性，友好性，可靠性。直接影响到产品能否如期上市，关系到手机厂商的切身利益与长期的市场竞争力。可以说，测试环节事后及软件开发的重要环节，整个开发过程中的“中枢神经”。同时，测试用例的设计在测试过程中是一个非常重要的一个环节，是重中之重。2.1.3.1测试用例的常见分类2.1.3.1.1基本功能测试基本功能是指手机软件向手机用户提供的最小的、可以进行的所有简单操作的集合。对基本功能的测试是指测试工程师在被测试手机上进行实际操作，来验证操作是否可行，操作结果是否满足设计的要求，如果不满足，就要报告错误，由开发者来改正错误。具体操作例如：接听一个电话，拨打一个电话，发送一条普通短信，接收一条普通短信，发送一条彩信，接收一条彩信，播放一首静态音乐文件（MP3），播放一段视频，照一张相片，录制一段录像，接收电子邮件，用浏览器浏览网页，设置一个闹钟，使用计算器，通过蓝牙发送数据，通过蓝牙接收数据等等。2.1.3.1.2交互测试所谓交互测试就是指当手机不同的两个或者多个功能之间有交互的时候，对手机所对应的状态或者行为进行测试，被测手机的状态或者行为应该与需求设计中的要求一致。如果有错误，同样应该由开发人员来进行改正。具体操作例如：打电话时接收短信，看短信内容时进来一个电话，听音乐时浏览新短信，听音乐时进来一个电话，上网浏览时进来一个电话，接电话时闹钟报警，等等。2.1.3.1.3临界测试所谓的临界测试是指当手机的某些可用资源达到或者超过理论允许的极大值时，在手机上继续进行某种操作时候的测试。此时手机的行为应该是友好的，可被使用者接收的，应该与需求分析的要求相符合。具体操作例如：内存满时拨打电话，内存满时启动浏览器，内存满时启动音乐播放器，内存满时启动Email，内存满时启动闹钟，内存满时启动视频播放器，数据库满时拨打电话，数据库满时启动浏览器，数据库满时启动音乐播放器，地址本满时继续添加记录，短信收信箱满时继续接收新短信，等等。2.1.3.1.4压力测试压力测试一般是指在比较短的一段时间内，被测手机执行比较多的任务或者操作，来检测被测手机承受压力的能力。具体操作例如：短时间内发送大量的短信，同时并接收大量的短信，发送和接收的数量都在50条以上。短信的群发（包括超长短信），查看接收和返送的成功率，接通一个电话并且保持很长一段时间（大于10个小时），等等。2.1.3.2测试用例设计主要注意事项对于测试用例的设计来说，操作步骤的描述总体上要求尽量笼统化。为了表述一个概念或者操作，不必具体说清楚怎么样具体的完成这个操作，只需一带而过地说要进行什么操作即可，比如说，只需要说明“启动计算机应用”，而不必说先到主菜单，再到某某选项下面找到“计算机”之类的话，再比如说，只需要说“接通一个电话，然后接收一条短信”，而不必说如何接通几通电话，如何从别的手机或者软件发送一条短信。同时为了防止测试工程师在执行测试用例的时候不清楚某些操作的具有操作方法，还需要在相应测试用例的联机帮助文档中对可能引起混淆的操作或者比较笼统的描述作出进一步的详细说明。这样的好处是测试用例没有同时分具体的某一款产品绑定的太紧密。在实际的商业模式中，经常同一个手机平台会衍生出一系列的不同产品。，这些产品的功能基本相同，只是具体的操作界面有所不同。新开发的测试用例应该是面向整个平台，而不是针对具体的某一款产品的。否则无形中会大大增加额外的劳动力。所以无论从商业成本的考虑还是从开发周期成本角度来说，开发针对平台的测试用例无疑是最正确的选择。其实，为了能够是开发出的测试用例能够快速的被新来的测试工程师所理解和掌握，为了能使这些测试用例有更多的可使用者，也应该尽可能地把对操作步骤的详细描述详细化和具体化，因为只有这样，才能使测试用例更加通俗易懂，节省更多的新手的熟悉和适应的周期。所以，这就需要找到一个“笼统”与“详细”之间的平衡点，只用适当地掌握了详细的分寸与火候，才能使测试用例具有更高的认可度和质量。2.1.4软件测试软件测试包含对软件评审和测试执行两个过程，对应静态和动态两种测试方法。2.1.4.1测试阶段软件测试可以分为几个阶段2.1.4.1.1测试计划阶段理解测试需求，编写测试计划，并根据需求规格说明书，完成系统的需求分解；2.1.4.1.2测试设计阶段为第一步中分解得出的具体的测试需求，设计相应的测试用例；2.1.4.1.3测试执行阶段按照自己设计的测试用例，执行测试，并记录用例执行结果，提交测试过程中发现的缺陷；2.1.4.1.5测试总结阶段对测试过程中发现的缺陷进行整理分析，完成测试报告。2.1.4.2测试用例基本准则1、测试用例应具有代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的输入数据、操作、环境设置等；2、测试结果应具有可判定性：即测试执行结果的正确性是可以判定的，每一个测试用例都应有相应的期望结果；3、测试结果应是可再现的：即对同样的测试结果，系统的执行结果应当是相同的。2.1.4.3用例设计着眼点1、测试的依据是需求规格说明书，首先应根据需求规格说明书对软件进行需求分析，然后针对每个测试需求去编写相应的测试用例；2、测试用例的编写时，应按照需求规格说明书的内容，设计合理的测试用例，同时更重要的是考虑不合理的输入情况；3、除