测试基本知识笔记.docxVIP

学习资料整理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测试驱动设计测试人员可以发挥过去在其他项目中积累的对客户需求的理解，以一个代表“用户”的角色与老板，与开发负责人一起商讨产品应该具有哪些功能，如何设计才能满足用户的需求。对于能力很强，经验丰富的测试人员还可以参加产品的架构评审，设计方案质量的把关。确保产品设计满足最初的需求规划，产品的设计缺陷不会留给用户。我们把这个阶段的测试活动都定义为“测试驱动设计”。在我接触的项目当中，我参与了很多项目的设计阶段，发现很多产品设计不合理的地方，也就是易用性比较差，但平常总结的比较少，在这方面对专业软件关注的比较