请问软件测试的整个流程是啥(从项目需求开始到项目结束的整个流程)?

Posted 2023-05-15

测试经理和PM对TC进行Review：敏捷测试流程总结： 在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。 根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：1. 验证需求和设计 需求和设计具体来说一般包括：(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性. 在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。 产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来2. 测试计划，测试用例2.1 编写计划、测试用例 在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。 好处： 客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。问题： 在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。 分析： 由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。 举个例子： 开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。2.2 测试用例的审核 为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix(Test Case跟踪矩阵)，其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见。 另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。在迭代后期测试要抽时间更新test case。3. 实施运行测试 在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。 由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个发布完成。• 单元测试在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test 做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。• 验证测试 测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。3.1 每日提供bug趋势 为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug， 对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。 测试需要考虑:探索性测试用例的编写3.2 测试用例的维护 在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁)，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。3.3 根据项目不断补充Common Sense 在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。3.4 控制中间版本 为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。3.5 发布版本前编写Release Note 在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善;或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。4. 需求管理 采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。问题： 客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能。后来又由于一些原因，有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明。说白了，是有证据证明我们做了很多的变更。大家可能觉得，怎么会有这个问题。其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p)建议： 目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名5. 项目开发末期开展“bug大扫除” 在项目开发的末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：(1)尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益;(2)要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。(4)可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。 参考技术A 测试经理和PM对TC进行Review：敏捷测试流程总结： 在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。 根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：1. 验证需求和设计 需求和设计具体来说一般包括：(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性. 在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。 产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来2. 测试计划，测试用例2.1 编写计划、测试用例 在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。 好处： 客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。问题： 在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。 分析： 由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。 举个例子： 开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。2.2 测试用例的审核 为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix(Test Case跟踪矩阵)，其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见。 另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。在迭代后期测试要抽时间更新test case。3. 实施运行测试 在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。 由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个发布完成。• 单元测试在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test 做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。• 验证测试 测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。3.1 每日提供bug趋势 为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug， 对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。 测试需要考虑:探索性测试用例的编写3.2 测试用例的维护 在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁)，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。3.3 根据项目不断补充Common Sense 在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。3.4 控制中间版本 为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。3.5 发布版本前编写Release Note 在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善;或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。4. 需求管理 采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。问题： 客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能。后来又由于一些原因，有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明。说白了，是有证据证明我们做了很多的变更。大家可能觉得，怎么会有这个问题。其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p)建议： 目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名5. 项目开发末期开展“bug大扫除” 在项目开发的末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：(1)尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益;(2)要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。(4)可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。 参考技术B 测试经理和PM对TC进行Review：敏捷测试流程总结： 在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。 根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：1. 验证需求和设计 需求和设计具体来说一般包括：(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性. 在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。 产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来2. 测试计划，测试用例2.1 编写计划、测试用例 在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。 好处： 客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。问题： 在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。 分析： 由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。 举个例子： 开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。2.2 测试用例的审核 为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix(Test Case跟踪矩阵)，其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见。 另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。在迭代后期测试要抽时间更新test case。3. 实施运行测试 在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。 由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个发布完成。• 单元测试在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test 做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。• 验证测试 测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。3.1 每日提供bug趋势 为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug， 对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。 测试需要考虑:探索性测试用例的编写3.2 测试用例的维护 在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁)，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。3.3 根据项目不断补充Common Sense 在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。3.4 控制中间版本 为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。3.5 发布版本前编写Release Note 在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善;或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。4. 需求管理 采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。问题： 客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能。后来又由于一些原因，有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明。说白了，是有证据证明我们做了很多的变更。大家可能觉得，怎么会有这个问题。其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p)建议： 目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名5. 项目开发末期开展“bug大扫除” 在项目开发的末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：(1)尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益;(2)要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。(4)可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。 参考技术C 测试经理和PM对TC进行Review：敏捷测试流程总结： 在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。 根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：1. 验证需求和设计 需求和设计具体来说一般包括：(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性. 在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。 产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来2. 测试计划，测试用例2.1 编写计划、测试用例 在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。 好处： 客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。问题： 在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。 分析： 由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。 举个例子： 开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。2.2 测试用例的审核 为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix(Test Case跟踪矩阵)，其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见。 另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。在迭代后期测试要抽时间更新test case。3. 实施运行测试 在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。 由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个发布完成。• 单元测试在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test 做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。• 验证测试 测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。3.1 每日提供bug趋势 为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug， 对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。 测试需要考虑:探索性测试用例的编写3.2 测试用例的维护 在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁)，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。3.3 根据项目不断补充Common Sense 在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。3.4 控制中间版本 为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。3.5 发布版本前编写Release Note 在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善;或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。4. 需求管理 采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。问题： 客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能。后来又由于一些原因，有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明。说白了，是有证据证明我们做了很多的变更。大家可能觉得，怎么会有这个问题。其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p)建议： 目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名5. 项目开发末期开展“bug大扫除” 在项目开发的末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：(1)尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益;(2)要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。(4)可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。 参考技术D 理论上越早参与越好！
当接到一个开发项目是，软件测试就要介入，一般认为从需求分析开始！
你可以看看双V模型，国内游一部分公司采用这种模型进行软件开发、测试流程。
软件测试界有一句名言叫做：尽早了解被测系统！但是真正能做到这一点的又能有几个呢？！

当你从事这个行业的时候，你就会有真实的体验，理论和现实区别……
当然有些大型公司做的还是比较好的！

一个项目的整个测试流程

最近一直在进行接口自动化的测试工作，同时对于一个项目的整个测试流程进行了梳理，希望能对你有用~~~

 

需求分析：

• 整体流程图：

需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind

• 分析流程：

1. 需求提取：

• 分析依据（包括：需求矩阵、产品交互图、需求说明书）
• 获取需求的纬度
• 客户价值
• 可以为客户带来哪些价值？
• 可以解决哪些问题？
• 根据以上问题定位功能是否合理
•  UI功能 - 展示功能
• 模块关联-历史模块
• 新功能模块关联
• 考虑是否关联？耦合部分是否需要支持？
• 客户使用场景-部署方式
• 网络特性
• 客户使用服务器常见外设
• 性能参数-性能要求
• 网卡最低速率
• 硬件支持
• 输出（提取最原始的测试需求）

2. 需求分析：

• 分析依据（五维分析）
• 用户场景

1. 功能是否和场景强关联
2. 网络拓扑能否满足客户需求
3. 和竞争对手比较差异
4. 功能是否能满足客户实际应用场景
5. 是否考虑了用户的实际操作

• 明确性

1. 范围明确性（参数、类型长度范围）
2. 清晰性限制等范畴
3. 无法预知影响的需求提出进行确定，风险

• 二义性

1. 概念模糊【大概念、第三方支持、与上个版本相同】
2. 支持与不支持等范畴
3. 一个需求描述能出现多种理解

• 完整性

1. 需求一致性【用户需求、需求规格、需求矩阵三者是否同意】
2. 需求完整【隐形需求】
3. 关联性【与新老功能、与外置软件设备】

• 可测试性

1. 实现测试需要的工具、方法【调试、接口命令】
2. 定位方式【日志等形式观察】
3. 复杂环境、容量边界、操作时过程不可见

• 输出

1. 测试需求跟踪
2. 缺陷预防bug
3. 工具需求
4. 整理出明确的需求点
5. 测试地图

• 分析思路误区：需求和实现的区别【现有需求才有代码实现，不能把代码实现当作需求】
• 需求分析的意义

1. 明确产品给客户带来的价值
2. 明确产品支持和不支持的功能
3. 明确产品各个功能的约束性
4. 知道开发实现功能
5. 知道测试分析和产出测试点

 

测试设计：

• 测试分析：

1. 我们需要做什么？

1. 把明确的需求点转换成测试项
2. 缺陷预防

2. 怎么做？

1. 整体模块分析
2. 逻辑分析【这一点主要是从产品实现的原理上去分析可能的影响】

• 怎么做？
• 开发的设计文档
• 补充和挖掘测试点

1. 全部服务的异常监控、服务重启
2. 各类存储对空间的占用、占满、是否需要做存储的接口测试
3. 所有类型的管理员、操作权限测试、支持的多少管理员并发操作
4. 对流程图的挖掘 -- 流程图全部流程测试、流程图重要的节点异常测试
5. 对状态的挖掘 -- 所有状态的相互转化需要覆盖全、状态转化是否合理、每一个状态下哪些操作可做哪些不可做，多个状态是否可以共存
6. 对关联项的挖掘 -- 流程进展到哪一步关机重启/服务重启、和备份配置的关联，和操作日志的关联等等
7. 任务的并发操作测试、是否可配置、是否会出现性能不足，是否符合用户场景
8. 异常处理机制测试，异常处理机制是否完善
9. 指标测试，开发的指标设计是否合理

• 修正不合理的需求
• 如何分析
• 逻辑原理：

1. 该模块是否涉及到一些全新的概念(比如我们的 bbc 全量包)，需要明确?
2. 该模块包括哪些服务?
3. 该模块涉及到哪些存储技术(如 mysql、dap、redis)?具体怎么存储的?占用大小如何?
4. 该模块的操作流程有哪些?是否有子流程图?
5. 该模块是否有多个状态的转化?是否有明确的状态转化图?
6. 该模块对多个管理员是否区分，管理员权限如何设计?
7. 该模块是否有一些特殊的操作限制?操作限制是否有明确的表格?
8. 该模块的任务是否有并发需求?并发的设计?
9. 该模块的所有指标如何?
10. 该模块是否有异常处理机制?在设备各种异常时，该模块的设计是否满足能稳健运行?

• 场景分析

1. 从用户的使用习惯和使用方法去分析影响
2. 检查当前案例是否覆盖到用户场景

• 关联测试分析：

1. 考虑你的模块所在整个系统的地位，分析上下游的影响
2. 对老功能的影响

• 经验补充分析

1. 版本分析
2. 模块分析

• 输出

1. 测试项
2. 补充测试地图

 

• 测试设计：

1. 需要做什么？

• 把测试项细化成测试点 
• 缺陷预防 

2. 需要做什么？

• 基本设计方法

1. 等价类划分法【将输入域和输出域划分为不同的等价类，等价类之内的操作结果相同】，使用范围：显示输入框输入
2. 边界值法【需要结合等价类划分法方法，在划分出来的等价类选取有代表性的值】
3. 正反对比【一般会放到同一个用例里覆盖】
4. 字符多样性【考虑不同字符的输入】
5. 测试类型

• 产品专项测试
• 正交组合设计【正交矩阵，覆盖各个参数间的组合情况】
• 业务逻辑设计【根据业务设计测试点】

3. 输出：

• 基本测试点

 

用例设计：

1. 需要做什么？

• 把测试点用文字完整表述出来

2. 怎么做？

 

• 功能用例框架：
• 模块框架模板
• 需求类
• UI测试【如果UI用例可以被功能用例覆盖，这里可以不写】
• 公共测试类：
• 链接

1. 选中会有高亮显示
2. 点击跳转到对应页面
3. 当前页面对应的名称下有区别显示

• 翻页
• 按钮
• 输入框【这个功能用例一般可以覆盖】
• 下拉框
• 排序
• 条目选择【这个很重要，第一次集成测试一定要保证每个选项都是有效的】
• 搜索

1. 所有字符类型验证
2. 为空验证
3. 模糊搜索
4. 精确搜索
5. 搜索不存在的关键词

• 刷新

1. 验证自动刷新
2. 验证手动刷新
3. 验证持续刷新

• 拖动
• 移动

1. 点击下移，往下移动一行
2. 点击上移，往上移动一行
3. 最上面的行，上移不能点击，图标灰色
4. 最下面的行，下移不能点击，图标灰色

• 功能测试
• 测试点：

1. 功能基本流程逻辑覆盖
2. 业务流程多样性覆盖
3. 用户操作习惯的多样性
4. 模块配置的多样性
5. 数据流的多样性覆盖

• 测试目录

1. 平级分类相对独立
2. 上下级分类有关联
3. 下级从上级细化而来

• 关联类：

1. 模块与模块之间的
2. 模块与功能之间
3. 模块与硬件之间

• 场景类
• 建模思路

1. 部署方式【比如用户一般使用2主机还是3主机部署集群】
2. 数据流
3. 业务流【用户是怎么使用申请工单，是怎么样的完整流程】
4. 操作顺序【创建云主机的顺序之类的】
5. 配置方法【用户一般怎么配置使用静态路由】
6. 使用时间【用户会不会连续长时间开启云主机】
7. 用户角色【一般那些角色做什么操作】

• 用户操作的设计方向

1. 最常用的功能
2. 最容易出现网上问题的功能
3. 典型客户使用的功能
4. 版本的性能验证

• 专项类

1. 兼容性
2. 可靠性【测试产品在异常情况下能否正常工作或者是恢复正常工作，可靠性重点测试对模块自身处理的覆盖】. 补充：容错性测试【测试系统在非正常操作、非正常的外部环境下是否能够处理错误和正常运行】

eg：

1. 1. 针对数据库的测试：【磁盘空间不足、数据库文件损坏、无读写数据权限、写数据时断电、写数据时强制关闭mysql、读写速度】
   2. 针对网络设备：【网络中有攻击数据、丢包时延大、IP冲突、网络线路断开、同时掉电】
   3. 针对程序：【 客户端进程被手动停止、设备后台资源cpu、内存占满】

3. 安全性【主要是验证程序有哪些缺陷可能会造成安全方面的问题】

eg：

1. 1. 密码加密方式【什么时候用明文，什么时候用密码显示】 
   2. 隐私数据隐藏【用户的隐私显示】
   3. 设备的完整目录【完整的目录会增加后台被攻击的危险】
   4. 文件上传功能【检查上传的文件类型；限制上传文件的权限】
   5. 防暴力破解【对于连线认证之类的操作要冻结、禁用其连续错误尝试操作】

4. 脚本测试

• 使用注意细节

1. 文件夹以01-xx，02-xx区分开
2. 每个文件夹下不能超过10个用例
3. 每个测试用例一个测试点
4. 在02-功能测试的描述中，备注说明功能测试框架的思路

• 用例整体规范
• 用例标题【好的标题需要准确的表达你的测试目的、要测试的测试点】

eg：

1. 测试。。。
2. 验证。。。
3. 。。。的测试
4. 与。。。的关联测试
5. 。。。的异常测试
6. 。。。的兼容性测试

• 用例属性

1. 测试环境【默认的前置条件可以不用写；写的前置条件要准确，不要写的模糊】
2. 测试方法
3. 优先级

• BVT【最最最基本的功能】-BVT(10%)：模块最基本的功能验证(含常用部署、基本关联)，推荐1级用例的20%左右
• level1【基本操作、基本场景】-Leve1(30%)：基本需求点，基本逻辑，基本可靠性，基本关联，基本用户场景
• level2【比较少见的正常操作】-Leve2(40%)：常见功能/逻辑细化点/专项细化点，常见关联/容错/边界值/用户场景
• level3【异常操作；后续不需要再执行】-Leve3(20%)：错误提示、极少测试的用例、非常见部署方式/用户场景/容错/边界值等
• 用例格式

1. 前置条件
2. 测试步骤【单个用例全部步骤不能超过8步】
3. 后置条件【不是必填的】
4. 预期结果
5. 备注【不是必填的】

• 语言规范

1. 语言简练
2. 不能出现模糊的形容词【比如说大概、可能、很多、差不多】

• 可维护性

1. 灵活运用模块备注

• 设计原则

1. 目的明确【一个用例对应一个测试点；测试步骤和测试目的一致】
2. 用例效率

• 保证设计出来的用例10分钟内可以执行完成；
• 用例需要的环境可以整理出来，然后写到模块备注中，让执行者先准备好环境一次性执行全部用例；
• 执行的时候按照测试集方式来执行；
• 有工具可以实现的用例不要采用脚本方式实现

3. 测试步骤：

• 用户角度

1. 1. 设计的用例要符合用户的操作顺序和操作习惯
   2. 符合用户的使用环境
   3. 符合用户的配置

• 可执行

1. 不要出现那种用例设计没有错，但是执行起来很复杂或者是依赖环境很夸张的用例

• 正反对比

1. 这一点很重要，很多时候我们会把有正反操作的用例分开写，其实是可以合在一个用例里面写

• 强弱关联

1. 对于强关联的步骤一定要写清楚
2. 对于弱关联的可以备注或者是不写

• 测试用例不能出现操作步骤

1. 直接写需要做的操作就可以了

4. 预期结果

• 用户角度：

1. 反思用户期望操作完会有什么结果
2. 反思客户最关注的测试点

• 可检查

1. 预期结果要可以观察到，不要写的很模糊
2. 把重点检查的检查点覆盖到

• 用例编写口诀

1. 强弱正反之业务
2. 重点突出之效率
3. 目的明确之语言
4. 框架覆盖之检查
5. 逻辑场景之经验

 

用例执行和回归

• 用例执行标准

1. 执行优先级

1. 建议用例级别执行顺序【bvt、leve1、leve2、leve3】
2. 建议用例区域执行顺序【基本功能、高风险区域、复杂逻辑优先测试】

2. 用例执行状态

1. Not Complete：用例无效、用例错误、无测试环境等过程状态
2. Passed：执行通过
3. No Run：默认状态，未执行
4. N/A：无须执行，需填写备注，需处理；
5. Failed：执行失败，需填写BUGID
6. Blocked：被其他问题阻塞
7. Not Modify：由Failed状态而来，用例发现的bug不修改，bug为halt、Won‘t Fix

3. 自动化用例

1. 覆盖全部bvt用例
2. 大部分level1（基本的功能一定要覆盖）

4. 执行技巧总结

• 执行前：

1. 1. 首先要看执行备注（模块备注、文件夹备注、用例备注），了解这个模块是做什么的，需要注意哪些点和执行的辅助命令和工具
   2. 然后把一个模块下的所有用例大概过下，能一起执行的可以一起执行

• 执行时：

1. 增改查删顺序执行用例
2. 一类的用例一并执行，比如说测试多种不同的nfv设备的授权之类操作，虽然每个nfv设备都是一个用例，但是都可以一起操作
3. 执行UI限制的用例，可以把限制条件整理出来，做成模版，直接套用
4. 执行的时候关注的测试点，遇到测试点很简单但是测试步骤很复杂的，可以异测试点测试为主，和用例编写的人协商优化一些执行步骤，或者是先自己优化再备注，后面统一和用例执行人讨论可不可以这样优化
5. 不理解的用例可以问执行过的人或者是写用例的人
6. 耗时或者是异常的用例【可以在别人休息吃饭的空闲时间去执行，不要影响公共测试环境】

• 执行后

 

• bug回归标准

1. bug分类：

• low【UI问题、体验问题】
• medium【基本功能问题】
• high【性能问题】
• urge【宕机、无法使用、数据丢失、业务无法使用】

• 补充用例

1. 在执行用例或者是回归bug的时候遇到level1级别的用例没有覆盖的一定要补充用例覆盖
2. 用例覆盖点过多，把几个级别的用例覆盖了，需要拆分用例

• 质量分析

1. Bug的类型主要是哪几类？

包括：功能问题,性能问题,稳定性,可靠性,关联,兼容性,需求方案等改进,易用体验性,异常容错；分析出主要类别后，在进一步分析各个类别产生的根本原因，比如用例编写问题（测试步骤达不到测试目的，用例有歧义等）；改动引发（是需求、方案变动带来的还是纯粹的改一个bug引发另一个？）

2. 模块质量分析

1. 缺陷分析
2. 用例质量分析
3. 测试漏侧分析
4. 需求变更分析
5. 模块改动分析
6. 发散测试分析
7. 重点难点分析
8. 开发人员评价
9. 回归测试分析

bug定位

• 前端定位：

1. 工具

• 谷歌浏览器
• network
• 检查参数【是否准确、是否有缺少】
• 检查响应时间【查看加载时间】
• 检查响应内容【查看响应内容是否有缺少{缺少的话是后端返回的问题；如果没有缺少的话有可能是前端处理的问题}】
• source【在测试用例的时候可以打开source调试，有一些页面的错误可以被俘获到】
• postman【模拟请求发送是否正常】

• 后端定位：

1. 后台报错日志

• 方法一：

1. cd日志文件所在的目录 | grep -rn "关键词"
2. 根据行号查看异常日志内容 ：tail -n +203915 文件名 | head -n 200行 （显示文件中第203915行之后的200行）

• 方法二：

1. less 具体的目录文件 #进入指定的目录文件
2. 然后 /关键词

2. 数据库【mysql】

 

• 非技术方法

• 对比法【比如说acmp上私有云的功能都是沿用acloud的功能，想判断acmp上的问题可以对比查看acloud上是不是有也有这个问题，如果有很可能是acloud引入的问题】
• 客户导向法【对于一些新功能，我们可以根据用户场景去判断这个功能实现是属于正常的操作还是不合理的设计】
• 逻辑分析【有时候开发自己设计的产品实现原理不一定是合理的，可以分析下实现步骤，看看是不是有问题】

• 总结下排除思路

• 判断是否是必现问题【先查看是否是必现的【到别的环境去试下问题是否能必现】；非必现的问题【排查网络问题；资源不足的问题】】
• 判断是我们平台本身的问题
• 判断是前端的问题还是后端的问题【抓包查看请求，请求中的返回数据是否显示完整。显示完整，那么一般就是前端没有处理好数据显示，找前端看看；如果返回数据有空缺或者是不完整，那就找后端看看】