发表于： 2019-07-27 23:34:25
1 556
一、今天完成的任务
1、了解测测试用例
测试用例编写流程
①需求分析
需求的类别：1.业务需求：
关注系统是否满足业务
分析客户业务流程以及相关需求
ps：同类客户业务需求具有较高的相似性
2.用户需求：
关注系统是否满足用户习惯
分析用户使用时的逻辑舒适度和操作舒适度
ps：要考虑不同用户个体的主观差异性，美观也很重要
3.功能需求：
关注系统是否满足功能需求
分析软件是否最终满足业务流程和最终目的
ps：以结果导向为主
常见问题：如果客户没有需求，或者说需求模糊该怎么办？
解决步骤：
1.以市面上的成熟产品为例，与客户深入沟通
给客户普及基础知识，让他们了解到你的专业性。客户一开始没有提出明确需求，并不是指客户就没有需求，而是客户不清楚自己有什么样的特别需求可所以提，所以要通过给客户普及知识，让他们了解你专业性的同时，认识到你的价值 。
ps：也有可能客户在联系你之前自己也稍作了解了，如果你能讲比他们了解的深入，会给你加分
2.了解客户业务，引导客户提出个性化需求
满足客户的个性化需求才能体现你和其它公司的差异，这些差异性是你产品溢价的基础（这意味着你谈价钱可以找到溢价点，底气更足），也是你增加客户忠诚度的基础（这功能人家没有，我有，并且还是给你量身定制的），更是你作为产品经理的核心价值。
ps：不要引导客户提无理需求或者无法实现的需求，对于客户提出的奇怪需求要学会找合适的方法规避，不要给自己和开发找不必要的麻烦。
②提取测试点
测试点提取我们依据每个测试阶段的测试输入的文档(需求分析)结合前面的需求分析的审查，覆盖测试需求和隐藏的业务需求，我们后期的测试，全是建立在提取的测试点之上进行的，可以说测试点提取是后续工作进展必要必经路径。主要步骤就是，将每个模块可能存在的问题全部罗列出来，并对其最初可以输入或者流程路径的不同，将每个测试点细分，写成文档！
●一份好的测试点提取文档不但能够覆盖所有业务分支和功能点，而且能够将相关隐藏需求体现出来
③测试用例编写
在编写测试用例之前，你得想好有哪些前置条件。这些前置条件满足了才能达到你得预期。比如账号密码登录，前置条件时账号和密码同时正确才能正常登录成功。那么此时你就得编写条件不符的时候，是否也会成功。如果成功了，那就属于BUG，需要技术进行修复。
一般正常情况，请考虑一下几个方面：
- 页面布局是否合理，如导航栏上面应该显示三个按钮，实际上却显示了两行。
- 页面文字描述是否准确，如气泡提示：密码格式错误，请重新输入。实际上却显示：账号密码错误。
- 如果有加载规则，是否符合加载规则。如：进入页面加载20条内容，实际上却加载了10条。
- 如果有排列规则，是否符合排列规则。如应按照时间倒序排列，实际上却是正序排列。
- 操作是否符合要求，如单击某个点，是否准确跳转或显示内容。如本应该进行跳转，实际上却未进行跳转。
- 输入框输入的内容是否有符合格式要求。如：账号不允许”,”,而实际上却允许了。
- 输入的内容是否符合合法性要求。如：账号密码是否一致等问题。
- ……
这些基本考虑内容都需要考虑进来。
大概理清楚需要考虑的内容之后，就可以开始动手写了。
- 序号： 不用说，就是按顺序下去的。
- 模块：该功能点具体属于哪个模块的，填写这个主要是方便查找，如：注册/登录模块
- 编号：对每个用例进行编号，方便后期跟进。毕竟用文字说，容易口误。不过此处建议编号设计的有点规则，方便快速定位查找。如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。
- 功能点：具体指某个功能，如：账号登录、首页、发布等。
- 子功能点：具体指功能点，如：账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
- 用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。
- 前置条件：指要达到预期测试结果，需要满足那些条件才能达到。如：账号密码不一致时，就需要登录失败，那么此时就得保
证账号正确或密码正确以及账号正确时是存在的。 - 操作步骤：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。
- 预期结果：说明按照前面写的应该呈现出怎样的结果。
- 测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，
- 结果描述：如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。
- 测试人员：填写测试人的名字，方便后期跟踪BUG。
- 测试日期：填写测试的时间，方便后期查询。
- BUGID：跟测试编号一样，自己设定ID规则，方便快速查询。
- BUG负责人：此处应该有技术那边填写，具体落实到某个人身上，才能更好的解决到问题。
一个测试用例的简单例子：
④测试用例评审
什么是用例评审？
用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。
用例评审的目的
为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题） 为了避免三方需求理解不一致； 为了每个测试人员的质量标准与项目要求标准达成一致。
测试用例评审加入测试流程规范并试用2个多月了，期间根据各方人员的反馈，及为了提高用例评审的效率，特制定以下用例评审规范：
一、评审前需要做哪些准备工作
1、需求评审结束后，就可以着手把需求拆分为功能点 。
工具：建议用XMind，需包含预期结果和测试结果，Android和iOS测试结果可用标签区分标注。
优点：用画思维导图的方式，逻辑清楚，便于评审人员（产品和开发人员）快速查看，评审效率高。
这里需要说明的是，很多测试者喜欢用Excel设计用例，我也不例外，但是根据一段时间的试验，和开发产品沟通后，大家都觉得用XMind写思维导图的方式更好，看起来更便捷。
所以具体用什么工具方法，大家可依个人爱好而定，不过目标是一样的，让用例评审高效快捷的开展，并产生价值。
2、把功能点再分解为具体的测试用例 。
这里需在思维导图上补全预期结果和实际测试结果，便于测试结果跟进。
3、用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。
4、和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看。
二、用例评审参加人员
主要是产品、开发（客户端和后端）、测试、项目负责人、运营。
注：以上人员为必须参加人员，其他和项目质量、进度有关人员，根据实际情况可邀请参加。
三、用例评审时间
对于敏捷开发项目，建议控制在半小时以内。
如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标，不能流于形式。
四、用例评审的形式
1、对照测试用例，从上而下，从左到右，逐条念。
这是目前很多公司的做法，如果你也这么做过，相信你并不一定喜欢这种方式，因为它费时，不分主次，参会人员的热情与注意力逐渐降低，整个用例评审效率低，作为主持人也讲的口干舌燥，事倍功半。
2、先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。
对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。
这种做法，有很多优点，评审刚开始的一段时间，大家注意力集中，参与激情高，这段时间讨论有难度有疑问的问题，效率高。最重要的事最先做。
另外，整个评审会主次分明，有高潮有缓点，可以更高效的达到我们评审的目的。
五、正式评审
正式评审过程中需要注意几个细节，如果你都做到了，那么可以说整个评审是成功的，有价值的。
1、评审要按用例的优先级，功能的复杂程度进行；
2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；
3、超过5分钟无法确定结果的问题留作会后讨论跟进。
六、评审结束后需要做些什么事？
不是说评审会结束了，就完事了，其实对于整个用例评审，这才做了一半。
评审结束后，第一时间整理测试用例，把修正的内容重新整理补全。
会上未确定的内容，会后继续跟进，直到确定结果。
没有任何有疑问的地方了，再做个简单的用例评审会议总结（如修正了哪些功能点，补全了哪些？哪些模块功能有变动？哪些功能推迟到下一期做？等），
这个总结是给自己整个用例评审工作总结，同时需同步给项目组其他成员，做好信息共享，这点很重要。
好了，整个完整的用例评审及需要注意的地方大概就是这些，希望测试组人员认真去看，并落实到具体的工作中。
个别地方根据项目实际情况可灵活变动。
二、明天的计划
按要求编写完成测试用例，并交给师姐检查
三、完成的任务及思考
1、已经了解了任务一相关的绝大多数概念，尤其是需求和测试用例
2,、问题在于，如何给给测试用例划分结构？
按客户需求来划分，还是按照网页结构来划分？
是按网页一级页面结构划分还是怎么划分？
二级网页又需要重新划分模块吗？
四、收获
已经了解了任务一的要求和测试用例内容的编写方式
就是不知道按什么逻辑来进行划分模块
返回列表
评论