严格捕获单元测试的测试用例

假设我们有一个用伪语言定义的简单函数.

List SortNumbers(List unsorted, bool ascending);

我们传入一个未排序的数字列表和一个指定升序或降序排序顺序的布尔值.作为回报,我们得到一个排序的数字列表.

根据我的经验,有些人比其他人更擅长捕捉边界条件.问题是,"你怎么知道你什么时候'完成'捕获测试用例"？

我们现在可以开始列出案例了,一些聪明的人无疑会想到以前任何一个都没有涵盖的"再一个"案例.

不要浪费太多时间去思考每一个边界条件.您的测试将无法第一时间捕获每个错误.这个想法是有一个是测试还不错,然后每一个错误的时间做表面,特别是写一个新的测试为bug,因此你永远不会从中再听到.

关于代码覆盖工具我想做的另一个注意事项.在像C#或Java这样的语言中你有很多get/set和类似的方法,你不应该以100%的覆盖率进行拍摄.这意味着你在为简单的代码编写测试时浪费了太多时间.您只希望100%覆盖复杂的业务逻辑.如果您的完整代码库接近70-80%的覆盖率,那么您的工作做得很好.如果您的代码覆盖率工具允许多个覆盖率指标,那么最好的是"块覆盖率"来衡量"基本块"的覆盖范围.其他类型是类和方法覆盖(不提供太多信息)和线覆盖(太细粒度).

你怎么知道你什么时候"完成"捕获测试用例？

你没有.除了最琐碎的案例外,你不能达到100%.100%覆盖率(线条,路径,条件......)并不能告诉您已达到所有边界条件.

最重要的是,测试用例不是一劳永逸的.每次发现错误时,请编写一个额外的测试.使用原始程序检查它是否失败,检查它是否已通过更正的程序并将其添加到您的测试集.

摘自Glenford J. Myers的The Art of Software Testing:

如果输入条件指定值的范围,则为范围的末尾写入测试用例,对于超出结束的情况写入无效输入的测试用例.

如果输入条件指定了多个值,请为最小值和最大值编写测试用例,并在这些值之下写下一个值.

每个输出条件使用准则1.

每个输出条件使用准则2.

如果程序的输入或输出是有序集,请关注集合的第一个和最后一个元素.

此外,使用您的聪明才智来搜索其他边界条件

(出于版权原因,我只粘贴了最低限度.)

第3点和第4点非常重要.人们倾向于忘记产出的边界条件.好的.6.真的没有帮助:-)

短期考试

这比它看起来更难.迈尔斯提供此测试:

程序从输入对话框中读取三个整数值.这三个值表示三角形边的长度.程序显示一条消息,指出三角形是斜角,等腰还是等边.

请记住,斜角三角形是没有两边相等的三角形,而等腰三角形有两个相等的边,等边三角形有三条长度相等的边.此外,等腰三角形中与等边相对的角度也相等(也可以是三角形中相等角度的边相等),并且等边三角形中的所有角度相等.

写下你的测试用例.你有多少？迈尔斯询问了14个关于你的测试集的问题,并报告说,高质量的专业课程在可能的14分中平均为7.8分.