去年六月份毕业入坑，一直叨叨念念将工作的内容总结起来，给以后的自己温故知新。还好自己算是一个比较喜欢做笔记的人，工作簿上的每一个日期都记录自己在这条道路上的所看所得，庆幸，一路走来，有那么多并肩前进的人~以下用一个项目的进行流程为线索，记录每个阶段的包含的内容及关注点。
项目的测试流程大只包含的几个阶段：立项、需求评审、用例评审、测试执行、测试报告文档
立项后测试需要拿到的文档
1、需求说明书
2、原型图（及UI图）
3、接口文档
4、数据库字典（表的数量、缓存机制）
需求评审
参加人员：开发、测试及需求人员，由需求人员主持讲解。
为了会议的有效举行，测试及开发人员需要在会议开始之前熟悉需求文档及原型，将有疑问 的点标注出来在会议中一一确认，对不明确的点要督促开发及需求一并关注，对不能立马得到肯定回复的点记录在一起，会议结束后，邮件整理好发出给各位参与的人员。
在项目可控的进度中，需求评审时必要的环节。当然，有些比较小的项目会忽略此阶段，个人认为这是非常有必要的环节，这不但减少了后期开发、测试、需求人员的意见分歧，保证项目的进度的必要手段。
用例编写（同时根据开发计划编写测试计划）
用例功能类型
所在就职部门将用例分成7类：
1、主流程：该模块实现的主要功能流程。
2、备选流：不一定完成执行一个功能，而是终止了流程。
3、异常流：由于某些异常原因，使流程的功能无法实现。
4、业务规则：必填项，强制的要求。
5、正常类：返回功能、必填项输入范围、页面按钮的切换等。
6、异常类：网络异常、返回异常等。
7、界面检查：针对每个页面的样式及内容检查。
注：几个大类中主流程、正常类、异常类、和界面检查四个大类使用的比较多，一个项目不需要涵盖所有的用例类别，只需要根据所在项目的实际情况来进行测试用例的分类即可。
编写用例可在TestLink及excel上进行，一般会在TestLink上进行，小项目会比较习惯用excel进行，excel记录测试用例的字段有：
用例编号、功能模块、功能类型、用例等级、用例描述、前置条件、数据、测试步骤、预期结果、客户端、执行结果、备注、设计人、执行人等
用例编写注意点：
1、尽可能结合用例设计方法设计测试用例
2、不要只根据需求文档明确标出的需求编写用例，还需要多考虑一些衍生的场景；
3、用例编写前，先画出整个功能的煎药流程图；
4、用例描述简洁且带有结果，不要重复赘述；
5、用例步骤和预期结果要一致，且一个步骤对应一个预期结果。
测试用例的编写方法
1、等价类划分
2、边界值分析法
3、错误推断法
4、因果分析法
5、场景法
用例评审
参与人员：开发、测试、需求人员、项目经理，由测试人员主导。
此环节在开发完成功能之前进行，根据评审时提的点进行用例完善，完善后邮件发给参与人员。
在项目组中，更多情况下测试比开发会更了解需求，专业决定我们对需求的理解是肯定更接近客户的，我们的对需求理解后的输出产物是测试用例，某种意义上讲用例是对需求细化的一种。 而开发对需求理解会更偏向于功能实现，产物就是程序。所以开发、测试经常会存在需求理解不一致的情况，开发也不会那么细致的去理解需求，这点相信所有的项目经理和需求分析都是有共鸣的：
我们做测试用例评审的作用有但不局限于以下3点：
1、统一开发、测试、需求三方对需求的理解
2、帮组开发更细致的去理解需求、同时养成看需求的习惯
3、需求分析人员在一定程度上对需求的理解也是有盲点的，通过评审可以挖出这些盲点（需求评审的作用也是一样）
4、测试人员的能力和经验不一样，所有用例也会有差异性，通过评审可以指出我们遗漏的场景，从而能更好的保障咱们的项目质量
5、在用例评审时，很多交互设计上的问题，前后台交互的问题等都会暴露
6、如果测试用例在开发完成前进行评审，很多时候开发人员即使不去看需求说明书，只要他认真的参加了用例评审会，基本上也不会出现遗漏需求，需求实现偏差太大的情况了.因为你要去每个开发人员那么仔细的去看需求，短时间内是不太可能的。用例评审是这个过渡期的桥梁。
一般可根据计划时间完成用例编写，中间会预留1天给他们看需求。在评审每一个模块的用例之前，会明确点名这几个人要注意，在评审的过程中，问开发一些问题,不是只单纯的讲用例,他们可以不看需求，但是我会提问一下,们要同时提升开发人员的参与感。
测试执行
showcase测试：
测试到开发的电脑上进行，主要执行一下关键测试用例、流程用例，由开发操作，测试人员一起查看。showcase不通过，则打回，邮件发出。
冒烟测试：
showcase测试通过后，提交到测试，由测试人员开始大量跑关键测试用例。若针对某个模块跑用例时，出现较多问题，则也可重新打回给开发。
未完待续……
来源：51Testing软件测试网
更多精彩内容请关注微信公众号“Testin”
网友评论