题目： 环境：B/S结构
由安博测试空间技术中心http://www.btestingsky.com/提供
内容：后台，一个文本框，要求输入5-100个长度的任意格式的字符串；要求输入的字符可以在前台正确的显示。请根据需求设计一组测试数据，根据这组测试数据的测试，可以完整把握功能的正常使用。
答案：
长度分别为4，5，6的中文字符串——长度为4不通过，其他通过 长度分别为50的中文字符串——通过
长度分别为99，100，101的中文字符串——长度为101不通过，其他通过
长度分别为4，5，6的英文字符串——长度为4不通过，其他通过 长度分别为50的英文字符串——通过
长度分别为99，100，101的英文字符串——长度为101不通过，其他通过
字符串： ——显示和编辑的时候正常显示
字符串： 99个空格+“中中中中中中”——通过
字符串：“中中中中中中”+ 99个空格——通过
另外，我觉得作为软件测试人员，应该打开思路，逆向思维，这样才可以发现更多缺陷。
作为一位功能测试人员，其主要的职能就是进行测试用例的设计，并根据测试用例执行测试，通过全面的测试来验证产品的质量。因此测试用例也从侧面反映了一个测试人员的测试思路的严密和发散性，要做好功能测试，测试用例的重要性无法忽视。现将本人设计测试用例的流程和思路进行总结，也方便进行交流和探讨：
1） 首先要对测试用例的组织结构进行划分
如果公司的测试流程还算规范完整的话，在进行需求评审的时候，测试人员就应该根据需求对测试用例的结构进行分类，如果是一个比较大型的管理系统，那么测试用例就可以根据功能模块来进行分类，比如：
如果是游戏，就可以根据场景来进行划分，比如：
对测试用例的组织结构进行划分的思路，主要根据需求文档的测试切入点来进行参考。
2） 根据功能点细致地设计测试用例
进行完需求评审后，开发人员会根据需求文档及自己所负责的工作提交自己的设计文档来进行评审，测试人员可以参考设计文档中的内容提取出各个功能模块中的功能点来设计测试用例，如果是管理模块，首先可以将增删查改功能作为第一层功能点，然后再根据必填项非空判断、输入格式验证来作为第二层功能点；如果是报表模块，就可以根据各种查询条件来提取功能点。
划分好功能点后，就可以利用等价类划分、边界值分析等一些测试方法来编写测试用例，并且可以进行标注，这样对于后期的测试用例整理相当有帮助。
3） 执行完一轮测试之后，都要对测试用例进行补充和整理
执行完一轮测试之后，都会对所测试的内容有进一步的了解，并且开发人员在实际开发过程中，会对某些功能的细节部分做出一些修改，测试人员应该根据变更和熟悉程度对之前编写的测试用例进行完善，主要是对测试步骤的修改和异常情况的补充，提高测试用例对需求的覆盖率，以便能发现更多的BUG 。
4） 测试结束之后，根据测试用例整理出测试思路进行总结 测试结束之后，测试人员在提交测试报告之后一般基本就会有一段短暂的休闲期，在此期间，再看看被自己不断完善的测试用例，根据用例中的标注，可以将之前的测试思路很条理地整理出来，反思有哪些地方考虑不足，这就是经验积累。
做好这些工作之后，在面对领导问你功能测试会测试到哪些功能，会测试哪些情况，执行一轮测试所需的大概时间问题时，测试人员就可以根据自己编写的测试用例进行流利回答。套用郭德刚的一句词：做科学的人都是很严谨的。大家作为都是有身份证的测试人员，只有工作做得细致严谨，自身的水平才能得到提高。
列表页面显示：
1. 确认页面的默认排序方式，字段+升降续；
2. 含link 的列，验证其有效性，即，点击后的跳转是否正确；
3. 第一列的选择框，“全选”和“部分 选择”需有效；部分选中时，全选按钮应自动取消。
顶部搜索功能：
4. 逐个测试每个搜索条件的有效性；
5. 做2-3个组合条件的查询，验证结果；合计共有N+3个搜索条件的测试。
6. 有时间区间的，验证列表项的开始到结束时间 和 选择区间有交叉，则为有效，且包含所选日期的记录；
7. 条件中，开始时间不能大于结束时间；
8. 搜索条件，在分页显示时，需始终保持有效；
9. 点击名为“显示全部”的按钮，需清除所有条件，并显示所有记录。
10. 每一次新的搜索执行，都应该去除分页，显示第一页、并回到进入页面时的默认排序方式。
右侧或底部的按钮（按功能分成多个用例）：
11. 单选，多选、全选的情况下，点击按钮执行某个功能，如暂停服务、恢复服务的按钮；
12. 跨页选择，在一些 选择成员的列表中是应有效的，需进行确认。
列表数据的验证：
13. 验证从数据库中得到的列表项中每列数据的正确性，要求覆盖不同情况下的值，比如“开通”、“暂停”的服务状态；已使用空间大小和总空间大小等数字的正确性。可考虑结合其他用例来描述，但必须覆盖到。
列表按标题的排序：
14. 检查每个列标题，要求点击后能按其进行排序：第一次点击为正序，以后每次点击为升、降续的切换。
15. 进入下一页、上一页，以及任意分页显示时，条件需始终保持有效。
分页：
16. 第2页/共8页 每页 10条/共 79条中的 分页数据必须正确；
17. 第一页、 上一页、下一页、最后一页的link 在当前上下文有意义时显示，否则隐藏或显示为文本标签；
18. 填入某个数字，点击“跳转到”按钮，到正确的页数；
另外请考虑每个文本框输入的有效性，比如日期、域名、跳转到某页的文本框的能接受的值，具体可参考需求文档。以上为工作中的手记，供新手参考。
对于测试用例我自己的理解为：测试用例将软件测试的行为活动，做一个科学的组织归纳的过程，简单地说，测试用例就是设计一个情况，软件程序在这种情况之下，必须能正常运行并达到程序所设计的执行结果；测试用例描述了按一定的顺序执行的并与测试目标相关的测试活动，它明确的是“怎样”测试。
编写测试软件用例设计的目的，是为了能将软件测试的行为转换为" 可管理、可维护" 的模式。软件测试行为必须能量化，这样才能进一步让管理层掌握所需要的测试过程，同时软件测试的生命周期伴随着产品生命周期的发展，其中测试行为也需要逐渐推进的过程，所以测试用例就成为测试行为具体量化与改进的有效途径。
有了测试用例，可以进行测试用例评审和测试用例的持续改进，进而达到提高测试用例质量的目的。对于测试用列的日常时间中，个人有以下几点心的体会：
1、明确用例设计的必要性：日程的测试行为中，我们不可能对软件进行穷举测试，为了节省资源与实践、提高测试效率、就必须从数量极大的可用测试数据中科学的挑选即有代表性、特殊性、或典型性(基于业务使用场景) ，的测试数据来进行测试；
2、以日常实践指导用例设计、改进的思想：
2.1、在实施软件测试之初，以测试的角度解读需求，设计完成测试用例，避免盲目测试，提高测试效率
2.2、测试用例的使用，使得测试的实施重点突出、目的明确
2.3、在软件版本更新后只需维护较少数用例便可开展后续测试迭代，降低测试强度，缩短整个项目周期
2.4、测试用例亦能做到通用化与复用化，使得软件测试过程针对性强，互补性强。并且用例的设计水平不断的精化与攀升
3、科学选择设计方法：目前主流用例方法都比较实用，但在测试实践中，具体采用什么方法，还是要正对开发项目的特点对方法加以适当的选择，切勿死板硬套。
题目： 环境：B/S结构
由安博测试空间技术中心http://www.btestingsky.com/提供
内容：后台，一个文本框，要求输入5-100个长度的任意格式的字符串；要求输入的字符可以在前台正确的显示。请根据需求设计一组测试数据，根据这组测试数据的测试，可以完整把握功能的正常使用。
答案：
长度分别为4，5，6的中文字符串——长度为4不通过，其他通过 长度分别为50的中文字符串——通过
长度分别为99，100，101的中文字符串——长度为101不通过，其他通过
长度分别为4，5，6的英文字符串——长度为4不通过，其他通过 长度分别为50的英文字符串——通过
长度分别为99，100，101的英文字符串——长度为101不通过，其他通过
字符串： ——显示和编辑的时候正常显示
字符串： 99个空格+“中中中中中中”——通过
字符串：“中中中中中中”+ 99个空格——通过
另外，我觉得作为软件测试人员，应该打开思路，逆向思维，这样才可以发现更多缺陷。
作为一位功能测试人员，其主要的职能就是进行测试用例的设计，并根据测试用例执行测试，通过全面的测试来验证产品的质量。因此测试用例也从侧面反映了一个测试人员的测试思路的严密和发散性，要做好功能测试，测试用例的重要性无法忽视。现将本人设计测试用例的流程和思路进行总结，也方便进行交流和探讨：
1） 首先要对测试用例的组织结构进行划分
如果公司的测试流程还算规范完整的话，在进行需求评审的时候，测试人员就应该根据需求对测试用例的结构进行分类，如果是一个比较大型的管理系统，那么测试用例就可以根据功能模块来进行分类，比如：
如果是游戏，就可以根据场景来进行划分，比如：
对测试用例的组织结构进行划分的思路，主要根据需求文档的测试切入点来进行参考。
2） 根据功能点细致地设计测试用例
进行完需求评审后，开发人员会根据需求文档及自己所负责的工作提交自己的设计文档来进行评审，测试人员可以参考设计文档中的内容提取出各个功能模块中的功能点来设计测试用例，如果是管理模块，首先可以将增删查改功能作为第一层功能点，然后再根据必填项非空判断、输入格式验证来作为第二层功能点；如果是报表模块，就可以根据各种查询条件来提取功能点。
划分好功能点后，就可以利用等价类划分、边界值分析等一些测试方法来编写测试用例，并且可以进行标注，这样对于后期的测试用例整理相当有帮助。
3） 执行完一轮测试之后，都要对测试用例进行补充和整理
执行完一轮测试之后，都会对所测试的内容有进一步的了解，并且开发人员在实际开发过程中，会对某些功能的细节部分做出一些修改，测试人员应该根据变更和熟悉程度对之前编写的测试用例进行完善，主要是对测试步骤的修改和异常情况的补充，提高测试用例对需求的覆盖率，以便能发现更多的BUG 。
4） 测试结束之后，根据测试用例整理出测试思路进行总结 测试结束之后，测试人员在提交测试报告之后一般基本就会有一段短暂的休闲期，在此期间，再看看被自己不断完善的测试用例，根据用例中的标注，可以将之前的测试思路很条理地整理出来，反思有哪些地方考虑不足，这就是经验积累。
做好这些工作之后，在面对领导问你功能测试会测试到哪些功能，会测试哪些情况，执行一轮测试所需的大概时间问题时，测试人员就可以根据自己编写的测试用例进行流利回答。套用郭德刚的一句词：做科学的人都是很严谨的。大家作为都是有身份证的测试人员，只有工作做得细致严谨，自身的水平才能得到提高。
列表页面显示：
1. 确认页面的默认排序方式，字段+升降续；
2. 含link 的列，验证其有效性，即，点击后的跳转是否正确；
3. 第一列的选择框，“全选”和“部分 选择”需有效；部分选中时，全选按钮应自动取消。
顶部搜索功能：
4. 逐个测试每个搜索条件的有效性；
5. 做2-3个组合条件的查询，验证结果；合计共有N+3个搜索条件的测试。
6. 有时间区间的，验证列表项的开始到结束时间 和 选择区间有交叉，则为有效，且包含所选日期的记录；
7. 条件中，开始时间不能大于结束时间；
8. 搜索条件，在分页显示时，需始终保持有效；
9. 点击名为“显示全部”的按钮，需清除所有条件，并显示所有记录。
10. 每一次新的搜索执行，都应该去除分页，显示第一页、并回到进入页面时的默认排序方式。
右侧或底部的按钮（按功能分成多个用例）：
11. 单选，多选、全选的情况下，点击按钮执行某个功能，如暂停服务、恢复服务的按钮；
12. 跨页选择，在一些 选择成员的列表中是应有效的，需进行确认。
列表数据的验证：
13. 验证从数据库中得到的列表项中每列数据的正确性，要求覆盖不同情况下的值，比如“开通”、“暂停”的服务状态；已使用空间大小和总空间大小等数字的正确性。可考虑结合其他用例来描述，但必须覆盖到。
列表按标题的排序：
14. 检查每个列标题，要求点击后能按其进行排序：第一次点击为正序，以后每次点击为升、降续的切换。
15. 进入下一页、上一页，以及任意分页显示时，条件需始终保持有效。
分页：
16. 第2页/共8页 每页 10条/共 79条中的 分页数据必须正确；
17. 第一页、 上一页、下一页、最后一页的link 在当前上下文有意义时显示，否则隐藏或显示为文本标签；
18. 填入某个数字，点击“跳转到”按钮，到正确的页数；
另外请考虑每个文本框输入的有效性，比如日期、域名、跳转到某页的文本框的能接受的值，具体可参考需求文档。以上为工作中的手记，供新手参考。
对于测试用例我自己的理解为：测试用例将软件测试的行为活动，做一个科学的组织归纳的过程，简单地说，测试用例就是设计一个情况，软件程序在这种情况之下，必须能正常运行并达到程序所设计的执行结果；测试用例描述了按一定的顺序执行的并与测试目标相关的测试活动，它明确的是“怎样”测试。
编写测试软件用例设计的目的，是为了能将软件测试的行为转换为" 可管理、可维护" 的模式。软件测试行为必须能量化，这样才能进一步让管理层掌握所需要的测试过程，同时软件测试的生命周期伴随着产品生命周期的发展，其中测试行为也需要逐渐推进的过程，所以测试用例就成为测试行为具体量化与改进的有效途径。
有了测试用例，可以进行测试用例评审和测试用例的持续改进，进而达到提高测试用例质量的目的。对于测试用列的日常时间中，个人有以下几点心的体会：
1、明确用例设计的必要性：日程的测试行为中，我们不可能对软件进行穷举测试，为了节省资源与实践、提高测试效率、就必须从数量极大的可用测试数据中科学的挑选即有代表性、特殊性、或典型性(基于业务使用场景) ，的测试数据来进行测试；
2、以日常实践指导用例设计、改进的思想：
2.1、在实施软件测试之初，以测试的角度解读需求，设计完成测试用例，避免盲目测试，提高测试效率
2.2、测试用例的使用，使得测试的实施重点突出、目的明确
2.3、在软件版本更新后只需维护较少数用例便可开展后续测试迭代，降低测试强度，缩短整个项目周期
2.4、测试用例亦能做到通用化与复用化，使得软件测试过程针对性强，互补性强。并且用例的设计水平不断的精化与攀升
3、科学选择设计方法：目前主流用例方法都比较实用，但在测试实践中，具体采用什么方法，还是要正对开发项目的特点对方法加以适当的选择，切勿死板硬套。