2020-05-14 09:41发布
编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。每个公司都有适合自己公司用例编写的模板，各有各的特点。测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。
我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。
第一层，表单测试为最底层（最基础的）。
这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试。我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低，时间不充足的情况就不用去执行。
第二层，逻辑判断层。
根据需求的设计，各功能之间的简单逻辑联系。以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。根据这一点，我们就可以从这个要求设计这一层测试用例。例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试用例也必须执行。
第三层，业务流程层。
这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。根据不同的业务需求，就有不同的业务流程。这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成。其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求。
我总结的测试用例的划分有三种： 1）按照功能划分 2）按照路径（业务流程）划分 3）按照功能和路径（业务流程）划分 目前我用的方法是第三种。第一种按照功能划分，优点是最简捷，版但其缺点是：对于复杂操作的程序模块，其各功能的实施是相互影响，紧密相关，环环相扣的。如果没有权严密的逻辑分析，很容易产生遗漏。第二种纯粹按照路径划分也容易造成对功能点的遗漏。所以我基本都是大方向用功能块的划分来走，然后再结合上路径（业务流程）的划分方法。
虽然从事开发行业的女生越来越多，但女生的比例还是远比不上男生。软件测试的男女生比例则基本相当，软件测试要求细心、耐心，大部分女生也是比较适合学的。而且软件测试课程分为手工测试和自动化测试，手工测试分为功能测试、性能测试、接口测试。自动化测试...
需要。很多人当初抱着测试不需要懂代码，才选择了这个行业，这个就要看对自己的职业定位了，是止步于月薪过万就可以了，还是往20k、30k去突破，如果这样的话，是肯定要会接口、会自动化，就必然要涉及到代码。如果真的看不懂代码，实际的测试后期的工作会出现...
在我看来游戏开发挺难的，尤其像手游一类的还有网游，里面有很多的程序代码而且伤神又费力，不过也有女生在这方面做的很好的，如果你感兴趣，非常想学，可以试试
软件测试专业现在很火热，很缺少人才，25岁学软件测试能学会，就业薪资也高，工作也相对轻松
测试类型有：功能测试，性能测试，界面测试。功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用...
这个其实和接口测试的场景密不可分的，比如说：外部接口测试： 必须先接口测试通过了，才能执行功能测试子系统或者各个模块之间的联调测试： 必须各子系统后台代码完成，并提供接口才可以完成测试，一般来说都要求各子系统功能测试通过后再进行...
这个是会因为公司的架构不同而不同的，并不是固定的，但是一般是会有专门的测试部门，或者叫质量保证部，也有可能是叫别的名字。
移动端测试，包括App兼容性测dao试，7*24小时稳定性测试，功耗性能测试，UI测试，交互测试等，课程主要学习的内容有：1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库，学习目标是掌握软件测试核心理论，结合Linux、数据库等可实现移动端、w...
标题 1. 首先要做一个标题党（此标题党非彼标题党）。标题一定要清晰简洁易理解，不应该臃长 2. 尽量前缀要规范，例如模板： [Product][Version]_[Feature]_[Title]，这样描述会很清晰，也方便查找 3. 缺陷的标题一定要描述在什么情况下发生了什么问...
1、 缺陷报告可以记录缺陷2、可以对缺陷进行跟踪管理3、可以对缺陷报告进行分类 总结 统计
1、缺陷编号（Defect ID)，提交BUG的顺序。2、缺陷标题（summary),简明扼要的说明一下这个BUG。3、缺陷的发现者（DetectedBy) ,一般是自己。4、发现缺陷的日期（Detected on date)，一般是当天。5、缺陷所属的模块（subject)， 在测试哪个模块的时候发现的BUG...
缺陷标题好的缺陷标题需要让相关人员一目了然，一般建议的格式是条件+失败。缺陷类型缺陷类型也是根据具体的项目而定的。但一般情况下分为功能、界面、建议。重现步骤重现步骤的编写规则可以参考测试用例中的操作步骤 ，一定要足够详细、说明清楚问题的操作顺...
工具：NoSQLUnitJsTestDriverQTRunnerVenusFluintBuster.JSSQLUnitECUTQTestlibUnitilsgreatestDbUnitAbbotGoogleTest框架：JUnitMoqJSCaptureMockCUnitPyUnitCppUTestCppUnitzCUTcipra
JunitTestNGGoogleTestpytestunittestJmockitJaCoCogcov、lcov、gcovrCoverage.pyEvoSuiteDiffblue Cover
React Hooks测试库( Testing Library)是一个简单而完整的React Hooks测试工具。 React Hooks测试库让用户可以为React钩子创建简单的测试工具，自定义钩子的输入和检索输出，以处理在功能组件体内运行的情况。 使用React Hooks，用户不必为了测试而去担...
1、单元测试注重代码逻辑，接口测试注重业务逻辑；2、单元测试的粒度最小，是测试最小独立的单元模块（不依赖其他模块）；接口测试不是，会覆盖很多；3、单元测试是白盒测试，接口测试是黑盒测试；4、单元测试关注的是代码的实现和逻辑，测试范围较小，保证实...
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','/static/images/logo.png', '推荐 叮叮不叮咚 的问题《怎么设计测试用例？》','http://www.shouhuola.com/q-11695.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。每个公司都有适合自己公司用例编写的模板，各有各的特点。测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。
我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。
第一层，表单测试为最底层（最基础的）。
这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试。我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低，时间不充足的情况就不用去执行。
第二层，逻辑判断层。
根据需求的设计，各功能之间的简单逻辑联系。以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。根据这一点，我们就可以从这个要求设计这一层测试用例。例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试用例也必须执行。
第三层，业务流程层。
这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。根据不同的业务需求，就有不同的业务流程。这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成。其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求。
我总结的测试用例的划分有三种：
1）按照功能划分
2）按照路径（业务流程）划分
3）按照功能和路径（业务流程）划分
目前我用的方法是第三种。第一种按照功能划分，优点是最简捷，版但其缺点是：对于复杂操作的程序模块，其各功能的实施是相互影响，紧密相关，环环相扣的。如果没有权严密的逻辑分析，很容易产生遗漏。第二种纯粹按照路径划分也容易造成对功能点的遗漏。所以我基本都是大方向用功能块的划分来走，然后再结合上路径（业务流程）的划分方法。
相关问题推荐
虽然从事开发行业的女生越来越多，但女生的比例还是远比不上男生。软件测试的男女生比例则基本相当，软件测试要求细心、耐心，大部分女生也是比较适合学的。而且软件测试课程分为手工测试和自动化测试，手工测试分为功能测试、性能测试、接口测试。自动化测试...
需要。很多人当初抱着测试不需要懂代码，才选择了这个行业，这个就要看对自己的职业定位了，是止步于月薪过万就可以了，还是往20k、30k去突破，如果这样的话，是肯定要会接口、会自动化，就必然要涉及到代码。如果真的看不懂代码，实际的测试后期的工作会出现...
在我看来游戏开发挺难的，尤其像手游一类的还有网游，里面有很多的程序代码而且伤神又费力，不过也有女生在这方面做的很好的，如果你感兴趣，非常想学，可以试试
软件测试专业现在很火热，很缺少人才，25岁学软件测试能学会，就业薪资也高，工作也相对轻松
测试类型有：功能测试，性能测试，界面测试。功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用...
这个其实和接口测试的场景密不可分的，比如说：外部接口测试： 必须先接口测试通过了，才能执行功能测试子系统或者各个模块之间的联调测试： 必须各子系统后台代码完成，并提供接口才可以完成测试，一般来说都要求各子系统功能测试通过后再进行...
这个是会因为公司的架构不同而不同的，并不是固定的，但是一般是会有专门的测试部门，或者叫质量保证部，也有可能是叫别的名字。
移动端测试，包括App兼容性测dao试，7*24小时稳定性测试，功耗性能测试，UI测试，交互测试等，课程主要学习的内容有：1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库，学习目标是掌握软件测试核心理论，结合Linux、数据库等可实现移动端、w...
标题 1. 首先要做一个标题党（此标题党非彼标题党）。标题一定要清晰简洁易理解，不应该臃长 2. 尽量前缀要规范，例如模板： [Product][Version]_[Feature]_[Title]，这样描述会很清晰，也方便查找 3. 缺陷的标题一定要描述在什么情况下发生了什么问...
1、 缺陷报告可以记录缺陷2、可以对缺陷进行跟踪管理3、可以对缺陷报告进行分类 总结 统计
1、缺陷编号（Defect ID)，提交BUG的顺序。2、缺陷标题（summary),简明扼要的说明一下这个BUG。3、缺陷的发现者（DetectedBy) ,一般是自己。4、发现缺陷的日期（Detected on date)，一般是当天。5、缺陷所属的模块（subject)， 在测试哪个模块的时候发现的BUG...
缺陷标题好的缺陷标题需要让相关人员一目了然，一般建议的格式是条件+失败。缺陷类型缺陷类型也是根据具体的项目而定的。但一般情况下分为功能、界面、建议。重现步骤重现步骤的编写规则可以参考测试用例中的操作步骤 ，一定要足够详细、说明清楚问题的操作顺...
工具：NoSQLUnitJsTestDriverQTRunnerVenusFluintBuster.JSSQLUnitECUTQTestlibUnitilsgreatestDbUnitAbbotGoogleTest框架：JUnitMoqJSCaptureMockCUnitPyUnitCppUTestCppUnitzCUTcipra
JunitTestNGGoogleTestpytestunittestJmockitJaCoCogcov、lcov、gcovrCoverage.pyEvoSuiteDiffblue Cover
React Hooks测试库( Testing Library)是一个简单而完整的React Hooks测试工具。 React Hooks测试库让用户可以为React钩子创建简单的测试工具，自定义钩子的输入和检索输出，以处理在功能组件体内运行的情况。 使用React Hooks，用户不必为了测试而去担...
1、单元测试注重代码逻辑，接口测试注重业务逻辑；2、单元测试的粒度最小，是测试最小独立的单元模块（不依赖其他模块）；接口测试不是，会覆盖很多；3、单元测试是白盒测试，接口测试是黑盒测试；4、单元测试关注的是代码的实现和逻辑，测试范围较小，保证实...