刚入职如何快速熟悉需求并输出测试用例？
Posted 爱吃 香菜
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了刚入职如何快速熟悉需求并输出测试用例？相关的知识，希望对你有一定的参考价值。
软件需求是软件项目开发的依据，代表着用户的需求，是软件设计及软件测试工作的入口，在整个软件项目开发过程中起着举足轻重的作用。对需求的理解是否到位，在很大程度上也影响着测试工作过程的效率。
有部分刚入职的新人，觉得刚刚上岗应该就是熟悉熟悉需求，了解一下环境之类的，没想到直接派任务。实际工作中，入职当天就可能会接到工作任务。
多看
多了解公司业务相关的需求文档。公司系统、公司业务背景、公司框架说明、原型图、一些书写用例的规范、测试报告等等。
重点：信息搜集、信息吸收
多问
多向同事提问，善用工具查询（书、网络等等一切能帮助找到问题答案的途径，都可考虑）；非紧急问题，可以集中保存，适时批次处理。
重点：搜索、归类处理
多做
碰到能够实际操作的地方就主动动手实践，比如画画流程图，架构图等。保持记录（储存、备份、过后回顾）重要（或潜在有用）信息的习惯，分门别类管理文件的习惯。多跑跑业务流程，学着分析动作产生的原因。
重点：实践、习惯、根源
看懂业务之后，我们需要看透业务，通过解剖系统来加深对系统的理解。
在这个过程中， 我们需要了解到：
所负责业务的系统交互
系统内部各个模块的划分，哪些是公共模块，哪些是业务实现层？
数据流向怎么走？数据如何变更？
如果你一进来，跟进的就是一个纯新的系统，从需求到方案设计到系统上线的话，你也要学会打怪升级。
学习跟打怪升级似有异曲同工之处。
不停重复打怪的过程，就是积累经验的过程。业务中的新怪层出不穷，都带有新的技能，那么，要想打败它，就得提升自己的技能。
作为一个「新业务」，应该思考得更多一些：
你是谁？
新业务是什么？在公司那么多产品里面处于一个什么样的位置？前台？中台？后台？
它依赖谁？谁依赖它？它面向的用户是 B 端？C 端？还是 G 端？
它的产品形态是 APP？小程序？网站？H5？PC客户端？还是接口？
从哪儿来？
为什么会有这项新业务？它的定位是什么？
价值是什么？衍变路径是什么？
到哪里去？
新业务的目标是什么？
发展路径是什么？
阶段性目标是什么？
资源分享
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】
成为测试开发工程师后，我如何看待并编写测试用例
记录当时入职CDG的感想
我主要负责内部运营平台的系统测试工作，刚入职，老大先给了我一个运营中心项目迭代流程文档，让我熟悉熟悉内部运营平台。我一看，啊哈，作为软件工程的学生，敏捷开发、双周迭代还是有那么一些了解的（虽然没有实际使用过），然后又发给我了TRPD链接，里面是所有的需求，我一看，晕，本身运营平台就有很多模块，大佬们写需求写的又特别简练（能得到的信息特别少），让我给某个模块写个测试用例，我：？？？在哪写？？在哪测？？测试链接呢？？？
好在我脸皮厚，虽然老大看起来很忙，我还是有问题就问，自己也慢慢熟悉并入手了，虽然一开始写的像小学生写作文一样，但还是经过老大的教诲和自己的聪明才智逐渐能入眼了。
工作了一段时间后，我一句代码也没接触过，但对测试有了更多的了解，比如看问题真的要全面，要仔细去思考可能发生的任何一种情况，这种能力也并不是所有人都具备的，瞬间感觉测试工程师的地位又又又上升了。
1、啥是测试用例？
测试用例就是由前提条件、输入、执行条件、预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档。（简单来说就是给定条件、执行流程、预期结果的一个文档，供后续测试人员进行测试。）测试用例的设计需要尽可能覆盖软件的所有状态，尽量考虑周期。
2、设计用例是否有必要？
如果不记下来，很可能到执行的时候测试点就遗漏了，另外也不便于用例评审，用例总结，对后期测试工作没大的改进作用。所以测试用例一定要写，颗粒度视情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。
3、设计用例的益处？
设计用例的过程可以更深刻的理解需求，熟悉各功能点，保证尽可能全的覆盖到各测试点。也便于用例评审。
4、一定要写测试用例吗？
对于大中型任务，还是要写详细的测试用例；对于紧急小型任务，可以写测试点；对于新人负责的模块，一定要写测试用例。
5、测试用例怎么写？
（1）根据需求文档，拆分测试点；
（2）根据测试用例设计方法 + 经验 + 拆分后的测试点 + 通用用例约束。来设计最终的详细测试用例；
（3）写用例的思路：产品需求-测试需求-测试点-测试用例；
（4）还要考虑兼容性问题、浏览器兼容、操作系统兼容性，如果是app测试还要考虑中断测试、弱网测试等；设计用例时也要注意涉及到的数据库中的字段值是否正确；需要注意关联模块的用例设计；注意新增接口、新增字段的用例的设计；
（5）除了用xmind整理测试点，也可以这样：根据需求文档找到角色和功能模块的匹配关系，输出usecase图—输出流程图—依据业务规则、usecase、流程图输出测试用例。
6、用例必备4个方面？
预置条件、执行步骤、预期结果、测试结果；用例要点：需包括与其他模块耦合关系、用例的级别（level0、level1），考虑哪些需求必须完成，哪些需求可以后续完成。
7、用例设计理念？
首先要保证产品的质量，测试用例的数量并不能决定质量的好坏，要做到覆盖全面，提倡高质量的自动化测试。
8、没有需求文档，如何测试，如何设计测试用例？
A.查找其他相关文档，来帮助理解所要测试的产品需要完成的目标；
B.尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解；
C.咨询相关人员-项目负责人、市场人员；
D.召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了；
E.如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理；
F.也可以去看历史bug，可以了解到一些需要关注的东西。
9、测试用例有哪些设计方法？
等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。10.写用例，用什么形式写，什么工具写?答：excel、word，也可以是工具，如testlink、zentao、xmind。我平时是用xmind去设计测试用例。
最后： 可以关注公众号：伤心的辣条 ！ 进去有许多资料共享！资料都是面试时面试官必问的知识点，也包括了很多测试行业常见知识，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！
好文推荐
转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！
以上是关于刚入职如何快速熟悉需求并输出测试用例？的主要内容，如果未能解决你的问题，请参考以下文章