测试方案与测试用例.docVIP

测试方案与测试用例学习笔记 杨富焜 测试方案： 有些地方叫做测试计划，如果要计划和方案的话，测试计划测试方案。分开两份编写时，测试计划主要用于指出测试的风险、测试重点、以及时间进度等内容，让项目经理及时安排项目人员的分配。测试方案则包含： 编写目的 作为后续的测试工作的指导，是后期编写测试用例的依据。 测试目标 列出本次测试工作的测试目标。 测试范围 描述软件各功能的需求、以及针对这些功能的测试模块。 测试内容 测试大纲，描述出测试重点、测试观察点等，用于指导测试用例的描写。 测试方法 包括黑盒、白盒、边界值、等价划分等。 个人总结： 在学校的学习中、以往公司实习中，并没有把计划和方案分开，而是整合在一起。这样子文档的重点就落在计划上面，所以常见的文档提纲有： 测试目标 测试范围 测试种类 数据和数据库完整性测试接口测试集成测试功能测试用户界面测试性能评测负载测试安全性测试  测试用例： 测试用例时整个测试过程的枢纽。它根据需求、方案一级级生成，是测试执行的直接依据。如果编写不全面，则结果就是导致产品质量出现问题，甚至在一两个错误出现后导致死机、无法重用等。但是测试用例不可能100%覆盖软件，所以相同模块的测试用例至少需要两个人编写或移交另一人进行审核。 根据测试方法，测试用例的编写主要是利用的等价划分法和边界值法。利用等价划分法编写测试用例的优点是可以减少测试用例的数目，并且可以最大限度地覆盖软件缺陷；利用边界值法，是因为在开发过程中，程序员可能会在开闭区间上出现失误，可能会在索引上出现失误（计算机的索引是从0开始的，出来的数值往往会比需求数值少了或多了一位），所以最多的错误时在边界值上产生的。 测试用例的字段应该包括：测试编号、测试模块名称、用例名称、前置条件、具体步骤、预期结果、制定人、评审人。有一些公司还会加上实际结果、通过条件等。 繁多的测试用例时最令人头痛的。为什么需要这么多呢？这里要解释一下程序是如何开发的： 当程序员接收到要求，开发一段代码，他的思路基本是一路往下走，即从功能出发，从输入到输出一句一句编写，中间不会发生偏离。所以这里可能发生，或者可以说会必定发生非预期错误。比如数字框输入字符时会产生异常。 有些多重条件的操作，可能程序员能写出非常优秀的代码，简单几句就可以覆盖90%的条件判断。但是作为测试人员，跑黑盒时是不应该知道代码的，否则容易出现主观的错误。但是作为测试人员又不知道程序员不能覆盖的位置在哪里，所以就需要将那些多重条件逐一测试，这样子才能准确找出错误。 说到这里引用一个例子：某种疾病的患病率是10%，现在需要对一个城市的100万人做检查，那么是否要查100万次样本呢？有种快捷的方法，把两个人的血混起来，那么只需要测试50万次就可以知道哪些样本出现问题，按照概率来说有问题的样本只是5万份，那么把这5万份分开测试，总60万次就可以知道那些人染病，节省成本之余还节省时间，要知道时间对病人来说很重要的。 这种情况是否适用于软件测试？我觉得要看情况。疾病在一种正常血液混带病血液时能检验出来，但是软件测试就不一样。有可能软件在编写时出错，只要判断某条件正确了，就不理会其他条件。结果就是对错得对，漏掉一个缺陷。但是有些情况下，是可以两个用例一起测试的。比如删除一条信息、出现删除提示、提示可以取消、确定、对应消息统计数减1，这是一段连续性有顺序的测试，但在用例上来说却分成5条。由此看出合理编排用例还能减少测试的时间。