測试基础知识笔记.docx

学习资料整理 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了解产品的商业目标 每次接到的新项目，它都是针对一个新的业务领域，我们接触过产品管理，产品代购，物流管理等等软件。每个产品针对的业务领域不同，该产品的商业目标也是不同的。我们作为测试和开发人员首先要抓住该项目的商业目标，这样才能知道产品的重点在哪里，也就知道产品的主要风险在哪里，该如何针对其商业目标开发我们的测试用例。比如我们接触过的Route Version项目，它是关于交通工具管理系统，收集所有交通工具每天的数据，在这个项目中报表是最多的，也是该项目最主要的功能，那我们就需要在项目一开始把报表系统作为一个风险考虑进来，包括其采用的开发技术，以及如何测试还有很多的测试数据，都是需要提前考虑清楚的，而且既然是报表系统，那么它就会和很多其他模块有着许多的联系，这样集成测试就显得特别重要了。我们还开发的另一个项目GTO，它是一个代购网站，将卖家和买家都召集到这个网站上进行交易，其中一个最重要的业务是招标系统，招标系统是个很专业的业务领域，如果提前没有把它的流程搞得很清楚，就会对后面的开发造成不小的影响。 2.1.2.2测试驱动设计 测试人员可以发挥过去在其他项目中积累的对客户需求的理解，以一个代表“用户”的角色与老板，与开发负责人一起商讨产品应该具有哪些功能，如何设计才能满足用户的需求。对于能力很强，经验丰富的测试人员还可以参加产品的架构评审，设计方案质量的把关。确保产品设计满足最初的需求规划，产品的设计缺陷不会留给用户