软件测试用例心得 软件测试
关于测试用例如何编写，测试组做过培训，当然以后也会继续，这几天集中精力在做UEM8.0R6的系统测试用例的走查，发现一些小的问题，总结如下：
1、期望结果中含执行步骤。期望结果即输出。如果把输入放到输出中会让测试执行人员无所适从。
2、两种情形在用例中是相连的两个步骤。界面上经常可以看到两个或以上选择项，确定or取消等。用例编写人员为了方便，经常这样写，前一个步骤，点击“确定”，期望结果A，接着下一个步骤，点击“取消”，期望结果B，可执行中的实际情况是，当我们点击了“确定”后，整个环境已经发生了很大的变化，往往需要重复前面很多步骤才能恢复到上次出现点击确定or取消这种场景，设计测试用例的基本原则是执行人员可以按照测试步骤一一做起，所以当我们遇到这样的情况，最好是写上，重复以上步骤m-n，这样用例才更完整。
3、反面用例。理论上每个需求至少应该有两个用例，正面的和反面的，虽然在实际上尤其是我们这种测试环境下，不是所有的需求都有反面的用例，但至少输入内容的时候应该有这样的情况，比如输入IP地址段，必须要有反面的用例。测试用例设计人员不能总指望执行人员自由发挥，应该尽可能全面的考虑所有可能的输入和输出。当然这方面的工作我们有些不足，下一阶段，计划进行测试用例公有库的补充，比如IP地址输入框应该如何测试等，也希望大家积极的提供素材。
4、多种情况设计多用例。我们经常遇到这样的情况，一个完整的操作流程中，其中几步分别有不同的选择方式，比如软件分发，可信授权。对于这种的流程我建议应该这样编写测试用例，首先是一个三级的用例，基本的授权过程，作为每次测试必须测试的用例，编写一个模板，针对有不同选项的步骤用参数表示，然后每种不同的情况设置一个用例有针对性的单独测试，比如授权时间到期，包括时间未到，时间处于有效期内，时间超过有效期，并且对临界点也有单独的步骤测试，针对时间到期的处理方式，锁定，自毁等又设置单独的用例，在测试每个用例的时候，其他过程均使用默认的情况执行操作，注意用例必须对每个分支都进行覆盖，这一类用例属于2级;最后是混合测试，也就是每个步骤选择不同的情况，猴子测试不同的组合对结果的影响，这算是一级的用例，事先不需要穷举所有可能的组合加入用例库，主要取决于测试执行人员的测试敏感度，但是在发现bug后一定要把用例添加到用例库中，属于一级的用例。
5、对文档中的文字和数字敏感。当文档中出现该字段长度260等数字的时候，千万不能马虎，在用例中一定要对这个数字设计相关的测试过程。同理文档中的描述信息都应该在用例中有所体现。
6、注意文档中注明的相关文档信息。比如UEM8.0R6概要设计中提到数据库表的改动见***文档，但是在用例中我没有看到这些改动信息在用例中的体现，我们不能指望测试执行人员去看每份文档，而且最大的可能是他压根不知道文档的存在，因此我们在用例的备注信息中应该提醒执行人员参考文档的信息，最重要的是这些改动都写到用例中，不要让每个执行人员花太多心思琢磨设计去测试的问题。
测试用例的编写和维护是个相当大的工作，而且测试用例编写的质量直接决定了系统测试的质量，本次测试用例走查的过程中对测试用例的改动很大，原因很多，包括我们以前对这块重视程度不够，包括留给用例设计人员的时间有限等等，但是我觉得这种返工是值得的，如果这样时候不做这样的工作，等用例到开发组走查会浪费大家更多的工时，等系统测试阶段工时又会被无限放大，对以后用例维护也会带来更多的工作量。所以我希望以后测试用例的设计人员一定要多思考，多读几遍相关的设计文档。当然了这些问题实际上也是我们都容易出错的地方，因此写出来大家共勉。
文章来源于领测软件测试网 https://www.ltesting.net/
