（4） 结论： 有0出0 全1才1 （5）表达式：Y=A*B=AB
（6）多位二进制数，按位与运算
右侧对齐，位数少的前面补0，上下对应的位分别进行与运算即可 2、逻辑或
（1）定义：只要有一个条件成立，这件事情就成立 （2）两个条件真值表 输入条件 A 0 0 1 1 （3）三个条件 输入条件 A 0 0 0 0 1 1 1 1 B 0 0 1 1 0 0 1 1 C 0 1 0 1 0 1 0 1 输出结果 Y 0 1 1 1 1 1 1 1 B 0 1 0 1 输出结果 Y 0 1 1 1
（4）结论：有1出1，全0才0——输入只要有1（成立），输出必为1（成立）；只有输入全部为0（不成立），输出才为0
6
（5）四个条件 输入条件 A B 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 C 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 D 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 输出结果 X= ABCD 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 Y= A+B+C+D 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
（6）表达式：Y=A+B
（7）多位二进制数，按位或运算
右侧对齐，位数少的前面补0，上下对应的位分别进行逻辑或运算
3、逻辑非（反）
（1）定义：一件事情的成立要求其条件要不成立 （2）真值表
逻辑非只能有一个条件 输入条件 A 0 1 输出结果 Y 1 0
（3）表达式：Y=A （4）多位二进制数，按位取反把每一位数分别取反即可
7
第三讲 测试报告
一、 测试人员的职责
1、阅读或编写测试计划（3篇） 2、编写测试用例（1000条） 3、执行测试（包括返测），发现bug，提交缺陷报告（50份） 4、编写测试总结报告（3篇）
5、使用测试管理工具跟踪测试管理bug
二、缺陷报告的组成 1、缺陷编号（Defect ID）
提交bug的顺序
如果使用缺陷管理工具会自动编号 在一个项目组是中会统一编号 2、缺陷标题（summary） 简明扼要的描述一下该bug 3、缺陷的发现者（Detected By）
一般就是自己
4、发现缺陷的日期（Detected On Date）
一般就是当天
5、缺陷所属的模块（Subject） 在测试程序的哪个功能模块时发现的bug，开发经理据此分配由谁解决bug 6、发现缺陷的版本（Detected in release） 在测试程序的哪个版本时发现的bug 7、指派给谁处理（Assigned to） 测试人员指派给开发经理，开发经理会根据bug所在的模块，再次指派给该模块的开发人员对bug修复
8、缺陷的状态（status） 描述bug此时所处的状态或处理情况 （1）测试人员发现bug，提交缺陷报告给开发经理，把缺陷的状态写成new（新提交） （2）开发经理验证该bug，如果是bug，开发经理把缺陷的状态改为open（打开的bug，开发组承认的bug），然后把该bug指派给该模块的开发人员修复；如果不是bug，把缺陷的状态改为rejected（拒绝的bug，开发组不承认的） 。 （3）开发人员看到指派给自己的bug，对bug进行修改，修改完后把缺陷状态改成fixed（已修复的bug，待返测的bug） （4）测试人员对修改的bug进行返测，如果返测通过，把缺陷的状态改为closed（关闭的bug，返测成功的bug，归档的bug）；如果返测失败，把缺陷的状态改为reopen（重新打开的bug，返测失败的bug）
此过程称为“缺陷（报告）的处理流程”，或者称“缺陷的生命周期” New->Ope n->Fixed->Closed 9、缺陷的严重程度（severity） 表明该缺陷有多糟糕:
Urgent：致命的bug，造成死机、重启、崩溃等 Veryhigh：非常严重的缺陷 High：严重的缺陷
8
Medium：中等程度的bug Low：小的bug 说明：每个词代表的含义在不同公司可能会有所不同，一般需要在专门的文档中定义好具体细节。
案例：Bug level definition.xls 性能：performance 功能：function
10、缺陷的优先级（priority） 希望开发组什么时间内或程序的哪个版本中解决该bug Urgent：立即解决，否则会影响开发/测试进度 Veryhigh：本版本解决
High：下版本解决
Medium：发布之前解决 Low：允许发布中存在 优先级参考的因素：
（1） 严重程度：一般情况下，越严重，优先级越高 （2） 缺陷影响的范围：一般影响范围越广，优先级越高 （3） 考虑开发组当前的任务压力：压力越小，优先级越高 （4） 解决bug的成本问题（时间）：成本越低，优先级越高
11、缺陷描述（Description） 把发现bug的步骤、过程、数据等记录下来，使程序员通过描述可以看到该bug
说明：
（1） 优先级和严重程度是不是严格正比关系？
不是，严重程度只是优先级其中一个参考。 成本 时间 （2）严重程度和优先级确定好后，是否还会修改？ 严重程度一般不做修改； 优先级根据实际情况，经常会调整（一般会推延）
（3）是不是所有已经发现的bug在发布之前都会被修复？ 不是。 对于不解决的bug，一定要经过项目组的讨论，明确解决bug的成本（时间），分析缺陷存在的风险，尽量避免法律纠纷，经济赔偿，另外存在bug的模块最好为用户使用频率较低的功能
三、缺陷报告的用途
1、记录bug
2、对bug进行分类（发现者、模块、日期、版本、严重程度、状态…） 3、对bug进行跟踪管理（new->closed） 4、对bug进行分析、统计、总结
9
四、如何识别bug
1、通过测试用例的预期结果识别，实际结果与预期结果不一致就是bug 2、参考需求文档，与需求不一致，就是bug 3、通过与相关人员讨论 4、参考缺陷的5点定义
五、提交bug时注意的问题（了解）
六、缺陷报告处理流程***
参考缺陷状态status部分
缺陷的处理流程也就是缺陷的跟踪管理过程
10