标签：分析 操作 常用 上线 格式 基本功 bug 要求 过程
软件在开发完成后，测试作为一个保证软件质量的关键步骤。可是在一些小公司，开发人员也就一两个，就像我一样，除了在开发过程中会测试之外，也就在项目完成时对基本功能测试一下。全部的过程都是有开发人员完成的，测试的时候也没有测试文档，可能就是想到哪测到哪，这样当然不能保证软件的质量，上线之后可能就会出现各种各样的问题。那么如何在软件发布前进一步保证软件的质量呢？常用的方法就是编写测试用例，在发布之前按照测试用例进行测试。那么什么是测试用例？应该如何编写测试用例？
1. 什么是测试用例
什么是测试用例，说白了，也就是测试软件参考的文档，测试人员能够按照这个文档对软件进行测试。这个文档应该能够覆盖软件的所有功能测试，这份测试文档才有意义。
2. 如何编写测试用例
如果项目有详细的需求分析文档，编写测试用例应该严格按照需求分析文档；如果App功能很简单，没有详细的需求文档，则可以按照功能划分成多个模块，然后按照各个模块编写即可。
编写人员需要对所测试的产品功能非常熟悉，测试用例需要最大的覆盖产品的所有功能点。测试用例除了要覆盖产品基本功能外，还要考虑到异常情况、边界值、性能等。
测试用例包含的内容其实没有固定的格式，只要内容清晰的表达出要测试的内容，使测试人员能够操作，能够达到保证质量，发现Bug的目的。
设计一个测试用例文档，至少需要包含以下几个要素：
1）测试平台
需要指定要求的平台以及系统版本，比如iOS系统要求9.0及以上版本
2）测试项目
也就是需要测试人员测试的项目，需要描述清楚要测试什么，比如App有多语言支持，就可以描述为设置App语言
3）测试项目编号
用来唯一标识测试项目，用来跟踪测试项目。其实项目不是很复杂，测试项目不是很多，直接使用从1开始的编号即可；如果测试项目较多，编号时最好有一定规则，方便确定问题
4）操作步骤
操作步骤需要详细描述测试项目的操作步骤，必须要详细明白，使测试人员看明白，能操作
5）期望结果
也就是测试项目的正确结果，不能够有歧义，模糊不清
6）实际测试结果
实际测试得到的结果，如果符合期望结果，则可以直接填写通过；如果不符合期望结果，则说明该测试项目不通过，需要描述清楚结果，以便开发人员验证修复
4. 完善测试用例
测试用例需要不断完善，随着产品的不断完善升级，新功能的增加，测试用例也需要不断完善以覆盖新增加的功能
5. 回归测试
在测试之后，开发人员修复测试中出现的问题，需要进行回归测试，对上次测试中出现的问题重点进行测试，确保测试中发现的问题已经修复
标签：分析 操作 常用 上线 格式 基本功 bug 要求 过程
原文地址：https://www.cnblogs.com/huangzhengguo/p/10511594.html
