| 编辑推荐: |
本章主要介绍了如何做好测试需求分析、如何做好测试用例设计、bug管理流程及业务测试方法，希望对你有帮助。
本文来自于csdn，由火龙果软件Linda编辑、推荐。 |
|
一、如何做好需求分析
1.测试需求分析的过程
根据需求规格提取独立的功能点，确定测试范围；
对独立功能进行分析，确定各独立功能的测试点；
对业务场景即功能组合进行分析，提供业务场景的测试点；
对非功能特性进行分析，了解需要测试的非功能特性；
针对系统级接口进行分析，了解被测试对象、测试规格。分析可测性，确定测试方法、工具。
具体见需求分析过程图（如下：）
2. 测试需求分析需要考虑的一些问题和细节
问题：
已文档化的需求是否被正确实现；
是否存在遗漏需求；
是否存在画蛇添足的问题(实现了不存在于需求规格的需求)。
功能设计是否完整。避免出现流程不通的功能。
细节：
需求项与测试项关联、与测试用例关联（避免遗漏）；
区分出测试项的优先级（80/20法则）；
（可以使用两次80/20法则，将优先级快速分为三个层次：5%、15%、80%） 针对可能存在的需求遗漏和疑似额外的实现，主动联系需求提出方，进行沟通并确认；
若需求项（测试项）可测试性差，及时反馈（涉及接口的，需要看到API，或接口文档）。
3.额外的个人经验：
在需求分析阶段 熟悉需求
原型图、需求说明书一起阅读。在此，我们熟悉时要对比原型图中的一些元素和UI图中的元素，应是完全一致的。另在看需求说明书的过程中列出一个功能清单，包含功能模块、子模块、功能点、测试点。
总结需求
即总结需求中的功能及测试点，我们要熟悉到看UI图上的某一功能，就知道该功能实现规则及测试点。 总结功能设计是否完成。
二、如何做好测试用例设计
1.测试用例描述
是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
2.编写测试用例的好处
进一步理解、细化需求； 理清测试点及测试思路，避免遗漏；
3. 用例包含的属性
ID、所属系统、功能模块、重要性、用例标题、前置条件、步骤、测试数据、预期结果、测试记录（通过、不通过、阻塞、无效）。
4.用例设计注意事项
用例标题需简洁、明了、清晰的概括一个测试点。（用例标题要包含详细的一个功能点。一条好的用例标题，只需看标题就知道怎么去执行。）
用例标题关键字:
页面检查的用例标题关键字：查看、检查；例：检查某某页面包含如下元素：（列出具体元素）；
功能实现类用例标题关键字：验证……
文本框用例：验证输入框不能为空；验证输入框最大可输入N个字符；验证某某输入框支持汉字、英文、数字等输入。
功能性用例：验证商品下架后，不会在用户端显示；验证购买某一商品（数量为N ）后，库存也要-N。
5.用例设计及评审注意事项
编写用例时要覆盖到所有功能，用例要描述清楚；
复用性、变更性强。
功能细节描述不清晰点需要记录，向产品确认；
有不合理的功能需要记录、确认；
评审时要提出自己觉得需求中设计不完善和不清楚的功能。
三、bug管理流程
1.Bug提交注意事项
（ps:写bug注意事项 是因为在项目经理向我们吐槽 说开发人员说某一些人bug描述看不懂简直看不懂。而且描述各种口水话，让我们在组内做个这方便的培训。。好尴尬的。所以各位要注意了）
Bug标题描述需要 精简、准确，删除冗杂/无用描述，使用中性化语言（无任何偏激/幽默等修饰）。尽可能描述如何触发的
bug，如何重现 bug，bug 的影响。有附件、日志，尽可能贴上 截图/关键日志 进一步说明问题.
bug标题描述我们最好按照以下格式： 【某某功能模块】某某子功能/页面：某个功能显示错误，显示……。应显示……
例：功能/UI缺失的bug，直接写成：【某某功能】某某页面:‘某某功能’未实现/未生效；页面缺少什么。需求UI图上有显示。附上UI图。像接口
一些特别复杂不好描述的，尽量把图贴上 。 可以截图的都把图片贴上。另有多张图片时，把所有图片合在一张里面再上传。
2.Bug提交验证流程
提交----各种bug（代码错误、需求设计、建议、用户体验类的 等等）都要提交到公司的bug管理工具上，(备案备案)。
指派---直接指给对应的开发人员
验证、关闭--开发人员解决后，进件验证，验证完成关闭（关闭时记录备注 注明在哪个环境，哪个版本/包上回归的，并写明回归结果）。
不修复的bug处理:确认好不修复的原因(代码错误、需求遗漏、设计实现困难、改动影响其他功能)-向产品、TL各个领导报备确认，指出影响范围(这个时候多半遵循他们的意见)
四、业务测试方法
1. 业务测试的方法和实践
a．站在用户的角度
优秀的需求应该是站在用户的角度来思考问题，是用户能够利用系统完成什么，而不是系统自己完成。因此在需求理解时要多和软件的最终用户进行交流，了解他们的诉求，以便有针对性的进行测试。
b．重视全局，而非细节
工作重点应该是放在尽可能全面的收集需求要点、了解整体的业务流程、分析主体业务流程和重点业务流程等工作上。在获得了系统的全貌之后，我们会发现原先在编写功能测试用例对系统的认识是不充分的，这时要编写的流程测试用例需要根据新的思路进行重新排列。
c．现场客户
现场客户随时提供对需求细节的指导。如果没有条件，可以定期的邀请用户参加项目例会或安排和用户交流等。另外在需求理解评审和测试设计评审会尽量邀请用户参与。
2、业务测试学精必备的两种能力
为产品质量负责的能力。
为产品体验负责的能力。
五 总结
正常迭代需求、紧急需求的测试任务，我们都要有目的性的测试，不能盲目测试。测试时要思考从哪里入手测试，一步一步的测完整。不能东测一下，西弄一下。测试时若是思路不是很清楚，先写一个测试思维导图，测一个点或是场景就记一个场景。觉得所有功能都全部测完的，再想一下拓展性、或是异常的场景进行测试。
|
