7.容量测试
在开票机中，进行大数据量开票（容量开票），针对不同类型开票机，观察点不同：
集中申报方式：所谓集中申报，即每月月初，由纳税户单位带着类似UKey的东西到相关单位报税，只有此时，纳税户上一月所有开票数据才会写入税务系统，而此时涉及到纳税户的抄报与注销抄报两种操作，容量开票后，要保证税务系统中所读取的数据正常（包括各类0抄报，数据抄报，大数据量抄报，重复抄报等），并且可以通过查询，查询到所有开票数据，如正票、正废票，负票、负废票，特殊负票，空白废票，缴销及退回号段等等。另外涉及到的是数据滚动，如开具6000张票，滚动3500张，每次滚动从最先开具发票数据进行擦除，第3500份发票所在当天数据同样被全部擦除掉，此时要注意存根查询中是否可以正常查询到应有，或查询不到应无的发票，另外在擦除时，注意未抄报数据是不允许被擦除的，在集中申报方式中，存在一种现象，如当剩下5份发票即满6000份时，连续作废大于5份发票也可正常完成，正常情况应当作废5份时，即开始整理数据，整理过后方可继续开票，存在未抄报数据无法进行整理的，不允许开具任何票，偶数次滚动时也会出问题。
在开票机中，进行大数据量开票（容量开票），针对不同类型开票机，观察点不同：
集中申报方式：所谓集中申报，即每月月初，由纳税户单位带着类似UKey的东西到相关单位报税，只有此时，纳税户上一月所有开票数据才会写入税务系统，而此时涉及到纳税户的抄报与注销抄报两种操作，容量开票后，要保证税务系统中所读取的数据正常（包括各类0抄报，数据抄报，大数据量抄报，重复抄报等），并且可以通过查询，查询到所有开票数据，如正票、正废票，负票、负废票，特殊负票，空白废票，缴销及退回号段等等。另外涉及到的是数据滚动，如开具6000张票，滚动3500张，每次滚动从最先开具发票数据进行擦除，第3500份发票所在当天数据同样被全部擦除掉，此时要注意存根查询中是否可以正常查询到应有，或查询不到应无的发票，另外在擦除时，注意未抄报数据是不允许被擦除的，在集中申报方式中，存在一种现象，如当剩下5份发票即满6000份时，连续作废大于5份发票也可正常完成，正常情况应当作废5份时，即开始整理数据，整理过后方可继续开票，存在未抄报数据无法进行整理的，不允许开具任何票，偶数次滚动时也会出问题。
实时申报方式：实时申报即通过网络，开具一张票，即上传至后台，此种情况下，对于数据滚动，此种情况下就简单一些，当达到最大份数时，提示数据整理，整理后即可继续发票，此时只需要注意开具发票的存根情况即可。
8.外设
当开票机业务功能等不再存有问题时，可在发布前对所涉及的外设进行测试，所涉及外设有
1）扫描枪 使用扫描枪销售商品，前提必须是该商品扫描码所对应的商品信息已添加。
2）钱箱 发票开具、负票开具界面，及钱箱自检时响应开钱箱
3）手写板 包括带屏与不带屏两种手写板，测试时所有可修改输入法至手写的地方均需要进行验证（切记）
9.用例编写注意
1）注意用例的先后执行顺序
编写用例时，一行一用例，用例与用例之差要注意先后顺序，尽量做到前面的用例是后面用例的前置条件，不要前面的用例执行完后，操作后台用例时，还要将环境重置到最起初状态，给用例的执行带来不便，且不易维护，凌乱。
2）给出DATA正确，符合逻辑
在书写用例时，不要使用描述模糊的数据，如操作步骤中“输入正确的数据”或“输入一个字符”之类的描述，尽量要给出具体且符合用例要求的数据，只有这样，在出现问题时，才容易定位问题，比如只输入小写字母才会有问题的bug，描述为输入一个字符，就太不明确了。另外，注意数据的逻辑性，比如同一个发票号1，在书写用例时，总不能开具的两张正票都是1，这样子也就太不符合逻辑情况了。
3）用例细化问题
在一个用例步骤的描述过程中，尽量不要一个用例融合多种情况，做到一个用例一个步骤（具体要求视公司要求而定），也只有这样，在执行用例的过程中，才不会因为用例的复杂而乱了思绪。
4）预期结果描述
对于预期结果的描述，在编写用例的时候，我个人经常犯的一个错误就是预期结果不明确，总是用“票面数据正确无误”之类的语句而过，并非写出具体的应该是什么样的数据，其实这是一种很不好的现象，写用例也不应该写到这种模糊程度，应该写出具体的结果，在执行的时候，才方便执行人员判断结果是否真的是正确无误。
5）用例角度方面
在写用例的时候，根据不同情况，对于用例异常与正常两种情况思考的前后顺序不同，只要符合整体逻辑，不会造成过多的重复操作就可以。作为测试人员，在对系统进行测试的时候，正常与异常两种情况是都需要进行考虑的，而且还要尽量想的全面一些，尤其是不要落下相关联的一些情况。
10.缺陷报告注意
1）缺陷报告的描述方面不用多说，要做到让其它人看懂，看明白，简洁等等。
2）当遇到一些比较严重的问题时，最好当时就把调试信息保存下来，以防因其是无法重现缺陷而无法提供调试信息，使得研发人员无法定位问题，这一点起初的时候我做的不太好，最终导致有两个缺陷因为没有调试信息而无法定位问题，延后修改
3）在与研发进行沟通时，发现的一些问题倘若研发口述说不用修改，也要提交缺陷，让其致为不修改的状态，作为备案用，以防以后因为此问题而出现状况时，导致互相推卸责任的情况出现。
4）同一类型的问题总结后提交一个bug，比如易用方面光标定位问题，方便研发一次性修改，缺陷管理中也容易管理。
5）提交缺陷报告时，切忌不可急躁，而导致前置条件或是详细步骤缺少必要条件或是步骤的情况出现，另外在缺陷报告书写完毕后，要检查一下有无错字，语句不通情况出现。
暂至此。。。。
