|
本文属于转载文章，仅供参考，原文链接：https://www.cnblogs.com/tynam/p/9078274.html
一、测试的流程
测试贯彻在产品生命周期中的每一个环节，从需求提出开始到测试计划、测试设计以及测试用例设计与评审及执行，最后进行回归测试。产品发布上线后跟踪用户使用的反馈，周而循环直到产品不在维护。
1、参与需求的评审
评审内容主要分为功能性、准确性、完整性、可测性、优先级和约束性。当然还有其他的性能要求、安全、可补充性、易用性等
功能性指描述功能的规格说明、状态变化、界面格式的定义等表述合理；准确性指需求清晰完整，无歧义；完整性指需求可以满足用户的使用；可测性指需求是否可以被测试用例覆盖到；优先级指优先完成那部分；约束性指某些事件是否需要一定的前提条件。
2、测试计划
测试计划应该以文档的形式输出，主要包含的几个点为测试对象（根据需求分析测试对象的应测特性和不测特性，不测说明原因）、测试通过或失败的标准（主要为测试用例的覆盖率和问题的修复率）、测试任务安排（谁负责什么模块）以及工作量的估算。还有其他的一些资源统计、项目简介等。
3、测试设计
测试设计是对测试计划的细化。也是以文档的形式输出。主要内容有测试环境的描述、用例执行的顺序（一般都是功能性用例到易用性、兼容性再到安全性、异常行为等）、用例的设计规定（用例编号的定义、冒烟测试的计划等）以及问题单相关的（缺陷管理工具、缺陷严重级别定义、以及缺陷的分析等）。
4、测试用例
测试用例的设计主要运用等价类、边界值、输入域、因果图、错误猜测、异常分析等方法进行设计。覆盖的点越全越好。必要的时候可以上网搜素下类似的产品用例是怎么设计的，可以作为参考。
测试执行根据测试用例执行，正常每天执行的用例为20-30条。每执行一条用例要执行其相关的，可能用例没覆盖到的功能，出现问题不管什么是什么问题（包含自己误操作）都要重复操作并且找到问题所在。然后提交问题单。
5、回归测试
回归测试一般分为两种，全部回归和部分回归。全部回归为测试用例重新执行一遍，；部分回归为测试问题单用例及问题单相关的部分。
6、跟踪用户反馈
收集用户使用过程中反馈的问题，整理问题，设计需求的与产品经理讨论解决。产品现有问题整理后提交问题单，下一次迭代的时候进行测试。
二、不同团队对问题单的管理
谈问题单的管理首先要弄清楚对问题单管理的目的是什么？大概有以下几点：
1、确保发现的每个问题都能有效解决，并且不会出现重复的问题。
2、将问题补充到测试用例中确保以后迭代都不会出现相同的问题。
3、根据问题趋势曲线判断测试过程的阶段。
4、对问题进行数据统计分析，判断软件的质量。
基于以上目的使用合适的方式进行问题单管理。通常有三种形式。
1、小团队一切都还不是很完善，人员少甚至没有测试人员。遇到问题直接找开发沟通、确认。开发人员自己记录问题，划分问题严重级别然后作出处理。通常是由于处于起步阶段，资源不足、中坚力量不足，问题容易遗漏从而导致产出不可保证。
2、中型团队基本有初级的流程制度，有比较简单的问题处理流程。通常只对软件的功能、界面、交互等测试，实现软件的基本功能。遇到问题会做简单的分类，集中提交开发修改。可以根据团队的习性确定用什么记录问题，走什么流程。灵活性特别大。对于迭代频繁、事件紧迫的项目来说是不错的选择。
3、大型团队。人员多，分工明确。有完整的流程。对问题单的确认、提交、分配、修改、验证、关闭、统计有一定的规则。每天执行多个用例，每1000行代码中发现的问题数都有规定。每个问题桩体的改变都有邮件通知，这种方式可以确保软件质量。但是问题流程繁杂，要一步一步都走清楚。成本大。
三、xxx小团队测试该如何进行
1、测试流程的建立
目前的流程为：
1) 参与需求讨论；
2) 有一个简单的时间计划；
3) 测试用例无只会列出简单的测试点保证需求的每一个点都测到，业务流程可以正常进行；
4) 执行测试的时候先测测试点，然后测需求延伸的内容；
5) 遇到问题，分析后整理写在石墨文档中，并且与相关开发一个问题一个问题分析一遍，保证问题的清晰；基本在1个工作日问题就可以修改并且回归测试；
6) 对于问题没有做统计分析。
短期计划：
增加一个测试人员，分工测试。对于大需求合作完成，对于小需求单独一个人完成。其他如下几点：
1) 测试计划更为详细，不只是简单的x日-y日测试什么内容，而是测试点的提取、测试执行、问题单解决及回归时间有明确的估算。
2) 测试用例的编辑、管理有个初步的形状。即测试用例有个初步的模板，不仅测试人员能看懂，非研发人员都能看懂。主要为概述、优先级、步骤（每一步尽量以傻瓜式的方式写，一个用例不超过7步）。保存在石墨或其他文档上，保证共享文件每个人看到的都是一致的。
3) 问题单规则化，有个基本模板使用，每个问题该怎么提，内容有什么都有个雏形，并在jira上管理。
4) 有个简单的测试报告输出。简单的统计，主要有测试范围和内容，软件质量的评估，用例覆盖的需求百分比，通过用例发现的问题占总问题的百分比，非用例发现问题的百分比，非用例非测试人员发现的问题占比。什么模块发现严重问题多少个、一般问题多少个，根据这次测试下次注意的事项等。
长期计划：将流程合理化，简洁化。
1) 参与需求谈论，对需求有合理的分析；
2) 计划更周全详细，考虑到测试中异常情况（比如开发交付测试延期等情况）；
3) 对测试用例进行优化，提升测试用例质量。文章末尾附上测试用例模板。
4) 在测试执行前有严格的测试用例依据，执行前对每天的工作量有估算根据（实际情况而定），对与发现的问题单有要求（非用例发现的问题要占总问题的百分比，或每20条用例中要发现一个非用例问题）；
5) 问题单的管理和提交更为详细，规范；
6) 回归测试做到问题单全覆盖以及问题延伸部分的覆盖；
7) 对问题单有更详细的统计，并输出测试报告（该报告更偏重软件质量的说明）。并以邮件的形式通知相关人员。另附测试报告文档（参照笔者的另一个笔记）。
2、问题的管理
目前状况：操作中发现问题，记录问题，分析问题。不清楚的问题找产品再次了解。管理是在石墨文档中，问题按操作步骤编辑，然后找相关开发分析问题，最后回归问题及问题相关内容。
计划：对于开发、设计等一些列活动工程中出现的问题进行记录、分析、跟踪、提交、验证最后整理分析。给出问题单统计报告并以邮件的形式发送给相关人员。文末附问题单模板。
3、构建接口测试、自动化测试、性能测试、安全测试
长期计划：鉴于公司的快速成才，纯手工测试可能满足不了日后的测试工作，则需构建接口测试、自动化测试、性能测试、安全测试等
构建接口测试的必要性：可以检测外部系统与系统、系统内部模块与模块之间的交互，检查数据的传递、和控制，知道业务逻辑是否满足需求，返回字段是否达到预期。
构建自动化测试的必要性：目前项目比较多，迭代也比较频繁。时间紧。每次迭代测试只对每次迭代的需求进行测试，对整个软件没有进行测试，人工测试费时费力。进行自动化测试可以对整个系统的业务在很短的时间内进行一遍测试。保证软件质量。
构建性能、安全测试：从长远的角度考虑需要，软件使用的用户量越来越大，对于服务器的性能指标、安全指数也会有进一步的要求。所以性能、安全测试是非常必要的。
4、测试用例的完善
目前：没有测试用例。之前写过美店管理后台、美店H5、美店app的测试用例，在jira上
计划：完善现有产品的测试用例，对没有测试用例的进行增加，有已有测试用例的进行增删改查。
在以后的项目中，测试执行前编辑好测试用例，并且交给产品、开发审核，发现没有写到的或者标记容易漏测的用例。执行测试的时候按照测试用例执行，并且发散测试。迭代结束后对测试用例进行管理，增加问题单用例，并做好备注（此用例由问题单增加）提醒下次迭代中着重关注。
5、人员构成
目前需要一个功能测试（招聘ing）
长期计划：根据业务需求招功能测试。可适当的增加一个安全测试、一个性能测试
测试用例模板：
1.标题：
就是对测试用例的描述，标题应该清楚的表达测试用例的用途。
2.步骤：
提供测试执行的过程步骤。对于复杂的测试用例，应该分为多个步骤完成。
最好不好超过七步。
3.预期结果：
提供测试执行的预期结果。预期结果应该根据需求规格说明书得到。
如果实际结果和预期结果一致，则测试通过。
如果实际结果和预期结果不一致，则测试不通过。
4.实际结果
5.用例编号
产品编号-ST-系统测试项-系统测试子项-xxx
6.预置条件
执行当前测试用例所需要的前提条件。
如果这些条件不满足则后续的测试无法执行或者无法得到想要的结果。
7.重要级别
高：保证系统基本功能、核心业务，重要特性或者实际使用频率高。
中：介于高和低之间
低：非系统基本功能、非核心业务，实际使用频率低。
8.其他的要素，所属项目、用例创建时间、作者等
问题单模板：
1.标题:在xx地方做xx操作发现xx问题
2.步骤
3.期望结果
4.实际结果
5.项目
在jira上一个项目一个文档，一个项目按照迭代分类
6.编号
系统自动生成
7.测试环境
a、使用的环境操作系统、浏览器等
b、测试的软件或系统环境，版本等
8.严重级别
a、致命问题。软件根本无法使用或导致系统问题。
b、严重问题。严重影响用户使用。
c、一般问题。影响用户使用。
d、提示性问题。非界面的字符串错误。
9.出现频率
a、必现：
b、偶发：
按照固定频率出现
不按照固定频率出现
只出现一次
10.初步定位
11.发现人
12.其他，比如问题定位分析等
|
