菜单

宏观的软件测试

2019年3月1日 - 一点资讯

1 全经过的软件测试图解

价值观的软件测试,开发职员实现职责之后,最终交付给测试职员,那种形式下,测试人士无法尽快发现需求阶段的瑕疵,同时测试工作的展开也落后了,产性能量得不到实惠的长河控制和分析,总体过程只怕会出于返工难点造成推延。

什么是全程软件测试,也能够说到家的软件测试,如下图所示:
一点资讯 1

在全部SDLC中,三条角色主线和四个级次。

三条剧中人物主线:开发、QA、测试,文中重要教授测试。

多个级次:供给、开发、发表、平时运维。

粗略来说能够总结为下图所示:

一点资讯 2

测试职员贯穿那四个级次,开始展览测试活动,试实践活动大致描述如下图所示:

一点资讯 3

每种阶段也有开发人士对应的移动,以及QA职员对应的运动。

对于产品而言,每一遍版本迭代,都会经历:须求、开发、宣布,最后推向平时营业,公布阶段虚线指向的急需阶段和常见运行阶段,并不是二个结束阶段,而是不断迭代的长河。

那测试人士是什么开始展览全程软件测试活动的呢?

2 供给阶段测试

在需要阶段,开发人士、测试人员、QA人士根本做的事情,如下表所示:

阶段

开发人员

测试人员

QA人员

需求阶段

· 用户故事分析

· 用户故事估时

· 参与用户故事分析、挖掘故事含混性

· 参考经验库质疑开发的时间估算

· 保证确认需求活动符合需求管理过程

· 管理用户故事评审

· 管理需求变更

用作测试职员的第贰实施如下:

涉足用户有趣的事分析、挖掘故事含混性

在sprint会议上,对用户故事举办分析,检查效率性必要和非功效性需要是不是描述清晰,个中能够将非功能性要求当作验收要点,例如三个用户旧事:

“客户愿意增加响应时间”

测试人士应当补助开发职员消除遗闻的含混性:升高什么的响应时间和响应时间为多少?可以提议修改为:

“客户新闻平日查询重返结果的响应时间为5s内”

表明在“客户新闻”模块,进行“普通查询”操作,再次回到结果的时间在5s内,那么些陈述句已经白纸黑字表明了,也达到了化解含混性的职能。同样,测试人员能够编写制定进步查询功效的用户传说:

“客户在音信查询模块,举行平时查询,能够在5s内回到结果”

“备注:5s为非功效性供给,也是验收要点”

参考经验库思疑开发的光阴推测

在sprint会议上,开发人员依照经验出牌(团队协调定义的规则,用扑克牌)猜度时间,当给出最后结果的时候,测试职员应当对其开始展览质询。测试人士借鉴历史经验库:开发人士在某地点的技术怎么样、该模块曾经发生过何种程度的毛病、修复缺陷的消耗时间是有点之类,综合考虑,提议疑义,让开发猜度最后的年华,尽或许考虑那些要素。当然,测试人士能够思疑的中间一个前提是:测试人士具备有关支出经历。

总计:在须求阶段,测试人士要发挥成效,收缩含混性必要引入到开发阶段、同时扶助开发做好时间估计。

3 开发阶段测试

在开发阶段,开发人士、测试人士、QA职员重点做的作业,如下表所示:

阶段

开发人员

测试人员

QA人员

需求阶段

· 用户故事分析

· 用户故事估时

· 参与用户故事分析、挖掘故事含混性

· 参考经验库质疑开发的时间估算

· 保证确认需求活动符合需求管理过程

· 管理用户故事评审

· 管理需求变更

用作测试职员的关键实施如下:

功效要点确认

Xmind是一个十分好用的脑图工具,日常在开发人士实行编码前,测试人员会指向需要处理的用户传说,与开发职员进行确认,创新掌握偏差,确认保障必要掌握一致。

一点资讯 4

 

图-5-脑图用例模板

测试用例设计

测试职员首要设计测试典故点,使用DSL(Domain Specific
language),对测试用例进行描述,包含八个基本要素:

Feature、Scenario、Example,补充要素:xmind、Requirement。

Feature:把测试分类到某些模块,并对这一个天性本人的事情目标进展连锁描述,带进业
务指标,传递业务知识。

Scenario:标明那几个Feature的测试场景,能够应用文字描述步骤,恐怕利用xmind脑图

叙述,场景中的数据使用Examples中列出的。

Example:引出具体的数目表格把用到的数目都突显出来,幸免同一步骤因为测试数据
的变通而重新若干遍造成冗余。

Xmind:脑图像和文字件,显示测试传说点

Requirement:关联供给管理种类的急需id。

随着高效越来越广为人知,敏捷测试也更多受到了大家的关爱。在那里,作者想谈一下自身在便捷项目中遭逢的三个自动化测试相关题材以及大家怎么借助DSL领域专用语言来化解它。

对急速软件开发方法有一定掌握的人都知道,敏捷软件开发进程是八个迭代式交付的长河。每个迭代约等于相比小型的提交周期。那么,为了合作往往的软件提交,敏捷测试相对于守旧一测试试必须求做相应的调动。那也促成了急迅项目中的测试面临多少个特有的挑衅:

  1. 再三的回归测试以担保种种迭代的果实都是可交付的
  2. 让总体开发协会参与到测试活动中以收缩质量音信的反馈周期
  3. 让客户参与到测试活动中来提携提升测试的有用

自动化测试在应对反复的回归测试那一个挑衅上起着老大首要的效果。自动化测试做糟糕,团队最终会被每一个迭代都会追加的回归测试工作量压垮。

本人经历过的三个集体,在那个组织中,大家很已经发现到了自动化测试的根本,在自动化测试上的投入不遗余力。大家信任自动化效能测试扩张到丰盛多的时候,它就能指引手动回归测试,保障总体交付进度顺遂举行。

实在,自动化测试刚开端实行的时候,大家低收入颇多。每扩充四个自动化测试,大家就能减小部分手动测试。自动化测试让大家我们有相比充裕的年华来手动测试那3个还没有来得及自动化的、难以被自动化的效能点上,而且还是能有时间和精力做探索性测试。那些结果让集体觉得生存绝对漂亮好,也让大家对自动化测试坚信不疑

而是好景十分长,随着自动化测试的不停加码,大家晤面临那样一些题材:

  1. 自动化测试是围绕着落成细节进行的。随着数据的充实,业务的概略很简单迷失在细节中。
  2. 在功效级别丧失了对测试的寻踪。由于测试人士无法实际领会那么些测试案例被自动化测试覆盖。每趟回归的时候,团队都亟待回归整个测试组。

于是,我们的手动测试越来越难获得自动化测试的扶植。它发轫成了花色的鸡肋。测试代码阅读困难、维护困难以及测试结果的看起来也很困难。这直接导致了我们不仅要投入极度的流年来扩大自动化测试,也要投入不少日子来读书并运用测试结果。

于是大家开首重复审视自动化测试的做法,继续寻找更好的主意。

马上,大家发现“能够跑起来”并不是好的自动化测试仅需的本性。让大家因此一段测试代码来看一下有血有肉怎么回事。

selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))

其一测试中,我们第③打开了七个页面,在页面中追寻3个id为username的输入框,输入“myname”,然后再寻找贰个id为password的输入框,输入“password”,然后点击1个id为btnLogin的按钮,等待30秒今后,断言页面应该出现的文字。

咱俩能够看看,那一个测试的兑现很完整的叙说了测试的操作进度,是二个面向步骤而不是目标的讲述。当然,稍加分析,大家也足以看出来那几个测试的目标是测用户登录成功系统。

只是,想象当大家有很多这么面向步骤来描述的测试时,要从中抽离出被很多零星的操作步骤所淹没的测试意图,并把测试的结果使用起来,其实并从未那么直观。而且,假若在测试中出现了错误,对于难点的具体效果点的一向也不是那么简单。

并且,并不是集体中有着的成员都有能力阅读和编写制定那样的测试。那活脱脱降低了团协会成员对于自动化测试的出席度。对于客户,自动化测试更是一个黑盒子,做了什么样,没做什么,基本上搞不清,更谈不上参加到自动化测试中,扶助提升测试的管事。

种种现象,究其原因正是测试可读性太差,测试意图不够醒目。可运营并且简单读的测试才是好的自动化测试。那样才能够保险别的时候,大家不会丧失对于测试案例的跟踪与管理。测试人员随时都得以通过火速阅读测试,掌握那四个效果已经被自动化测试覆盖,有效统一筹划手工业测试的工作量。

怎么坚实地度量试的可读性呢?

大家的消除办法是DSL领域专用语言。

什么样是小圈子专用语言?在马丁岳丈的博客里有比较详细的叙述。大概来说,领域专用语言正是本着某些世界的一定指标编制程序语言。不像Java、C#等通用语言,可以缓解其余领域的题材。领域专用语言由此祥和特有的语法结构来讲述更近乎于专业领域语言的事情。

让测试的叙说可以接近被测系统的世界语言、使测试意图获取清晰表达就是我们想要获得的效益。DSL正好能够帮大家达成。

让大家再看看在此之前的那段代码:

selenium.open(“/”)
selenium.type(“id=username”, “myname”)
selenium.type(“id=password”, “mypassword”)
selenium.click(“id=btnLogin”)
selenium.waitForPageToLoad(30000)
assertTrue(selenium.isTextPresent(“Welcome to our website!”))

是因为采用的是通用语言,在大家那几个一定的运用意况中突显过于细节化、进程化,无法清晰表明测试意图。

调换DSL,我们的测试就足以向来用验收标准的言语来叙述如下:

Given I am on login page
When I provide username and password
Then I can enter the system

诸如此类测试的始末就直观多了,还富含了某个工作音讯,让我们清楚那几个是在测试二个报到的场合,而不是随机的输入消息,兼顾传递了业务知识的任务。至于那一个DSL背后能够运维的代码,也被埋伏起来。借使是不可见阅读原来那么的测试代码的人(不管是须要分析职员恐怕客户甚至一些对自动化代码关怀相比少的测试职员)想要参加到自动化测试活动中展开汇报,就不会被DSL背后的代码带来的“噪音”所影响。

当然,在我们的有血有肉应用场景中,那些须要没有那么粗略,我们的验收标准还会考虑分歧的数据比如输入差别组合的用户名密码:

Given I am on login page
When I provide ‘david’ and ‘davidpassword’
Then I can enter the system
Given I am on login page
When I provide ‘kate’ and ‘kate_p@ssword’
Then I can enter the system

以及愈多的测试数据。

那么那种气象下,仅仅是比较粗浅的言语还是不够的,究竟测试数量在那摆着。假若测试数量无法减弱,维护起来照旧很劳累。打个要是,假若系统的贯彻成为了历次都要输入用户名、密码和贰个无限制验证码,大家就要求在大家的自动化测试中期维修改多处,相比麻烦。由此,大家须要在可读性相比好的自然语言描述的测试上,把它的抽象层次再增进一点。

有幸的是,大家及时采用的DSL工具是cucumber,它除了提供了多少个测试的描述层次:Feature,Scenario,Steps,还提供了极度好的一种集体章程—数据表。

那样,大家的这么些自动化测试就足以把此前的分外登录的功效依照天性、场景计算和具体的手续分离开来,清晰的支行,同时使用数据表大家的测试精简成一连串被另行多次但输入数据颇具扭转的操作进度,如下:

Feature: authentication
In order to have personalized information
I want to access my account by providing authentication information
So that the system can know who I am
Scenario Outline: login successfully
Given I am on login page
When I provide ‘<username>’ and ‘<password>’
Then I can enter the system
Examples:
|username |password |
|david |davidpass |
|kate |kate_p@ssword|

测试那下看起来就更舒心了。首先,用Feature关键字,大家把测试分类到login那些大特色下的,并对这几个特性本人的事体目的进展有关描述,带进业务目的,传递业务知识;然后用Scenario关键字来拉长挈领的表明大家以此测试场景中做的是测试登录成功的场地,并且把手续都写出来;最终,大家用Examples关键字引出具体的多少表格把用到的多少都来得出来,制止大家的如出一辙步骤因为测试数据的成形而重复若干遍造成冗余。万一碰上了要求的转变,供给同时提供用户名、密码和验证码,那大家的测试也只需求改变较少的地点就丰裕了。

更棒的是,用了那种数据表的不二法门,整个公司的合作效用提升了。对于写代码没有那么百发百中的测试人士来说,扩充自动化测试也正是充实更加多测试数据,填充到数据表里就足以了。

就像此,我们用DSL完毕了可实施的可读性高的文书档案。扶助了回归测试,下跌了文书档案维护难度,也助长团队成员选拔测试来传递知识的积极,让更五个人能够插足到测试中。

用例评定审查

第二是滴水穿石同行业评比审的原则,重要在测试组内实行,负责该职务的开发人士也会参预,简单的话正是对测试用例举行查漏补缺的干活。

测试探索

开始展览了“功用要点确认”和“用例评定审查”后,为了保险测试场景的覆盖率,必要再拓展测试探索。在开发人士完结雏形之后,使用探索式测试的政策,对职能大旨流程展开有目标的神速走查,挖掘效能不显明的地点和互补测试场景,制止不鲜明的成分拖延到开发阶段早先时期,造成返工。

里头:作用测试、Bug
Tracking、回归测试、系统一测试试、验收测试都以惯常测试工作所需环节。

燃尽图公布

其它,测试职员还有一项关键工作,天天揭橥燃尽图,让组织询问当前速度情状,总结难题

中国人民解放军第⑤野战军,寻求耗费时间跨越预期时间义务的消除办法。

一点资讯 5

图-6-燃尽图

图形特点:

1)剩余工时在布署条件上方,代表进程有所推迟,应抓紧进程;

意识此类难题,须求分析总计,原则是保证交到时间,对相应职分进展调整,拥抱变化,发现职分粒度太大,该拆分的接轨拆分;对于重构供给郑重,不要过于深刻重构,给测试带来十分工作量,影响全数进度,对于全体版本而言,只有付出、测试在答应的日子内做到任务,才是真的做到,仅仅开发实现交付算不上成功。

2)剩余工作时间在陈设条件接近,代表开始展览不错,继续有限支撑;

那儿也亟需查阅在那种进程下,优先级高的任务是还是不是得到时间保障,而不是因为拍卖完简短任务才使得燃尽图长的美观。往往有个别开发职员,喜欢挑着职务来做,把大概易做、优先级的任务先达成了,因为那么些总在预料内能够做到,所以最初燃尽图的倾向看起来没有毛病。

缺点经验库

种种组织都存在支付/测试新人和支付/测试老人,当测试职员与付出新人进行必要肯定的时候,还亟需举行缺陷经验教训的提醒,防止多走弯路。

一点资讯 6

升级开发自测品质

测试人士能够提供有关checklist(大家能够根据原我提供的改动为顺应集团的)支持开发职员在编码进程中关切开发自测的要义,从而升级品质。

一点资讯 7

 

图-8-web软件测试checklist

不止集成

选用持续集成(Jenkins)平台,做到飞快的营造开发代码,自动的单元测试化,来增强支付代码的频率和品质。

担负单元测试的开发人士,会收取失败塑造的邮件;

负责集成测试的开发人士,会吸收战败创设的邮件;

担负自动化测试(Selenium)的测试负责职员,会接收失利营造的邮件;

那种格局,确认保证险单元测试、集成测试、自动化测试,有相关职员关爱和爱戴。

一点资讯 8

图-9-持续集成

Sonar反馈

Sonar is an open platform to manage code quality. As such, it covers the
7 axes of code quality。

一点资讯 9

sonar分析结果

测试职员主要反映难题如下:

Code coverage:团队须要代码覆盖率在五分之四上述;

一点资讯,Test success:团队须求测试成功率在百分之百;

Duplications:团队须求代码重复率在1/10之下;

Violations:团队需求Major连串的代码规则缺陷在20以下;

付出组织必须确定保障种种环境的成色指标,才能够保障全体的品质目的。

小结:

测试人士与开发人士永远不是敌对关系,而是协理关系,确切来说是质量天枰的两边,任何单方面的行事尚未办好,都会失去平衡。

4 发表阶段测试

在发布阶段,开发职员、测试人士、QA人士根本做的作业,如下表所示:

阶段

开发人员

测试人员

QA人员

发布阶段

· 上线申请

· 上线部署

· 服务监控

· 测试报告

· 线上功能检查

· 管理评审活动

· 管理文档产物

作为测试人士的基本点实施如下:

测试报告

完结验收测试,提供测试报告,给出测试数据衡量,例如:

缺陷总括分析报告

其它,测试人士还有一项主要工作,对当前版本的后天不足进行总计分析:

按缺陷级别计算:

 

Critical

Major

Medium

Minor

总计

首页

0

0

1

0

1

模块一

0

0

0

2

2

模块二

0

1

2

10

13

模块三

0

0

1

4

5

模块四

0

0

1

2

3

模块五

0

0

3

2

5

模块六

0

1

0

1

2

模块七

0

2

0

6

8

sonar

0

1

2

0

3

总计

0

5

10

27

 

一点资讯 10

图-11-缺陷计算

按缺陷来源总结:

 

开发1

开发2

开发3

开发4

开发5

遗留

Critical

0

0

0

0

0

0

Major

1

2

0

0

0

2

Medium

1

7

0

1

0

1

Minor

1

7

4

6

3

6

总计

3

16

4

7

3

9

按缺陷状态计算:

缺陷总数

已关闭缺陷数

遗留

缺陷修复率

严重缺陷数

严重缺陷率

已关闭严重缺陷数

严重缺陷修复率

42

40

2

95%

5

12%

5

100%

测试进度和题材分析:

1.
从BUG的不得了级别分布来看,Major级别以上的BUG占12%,占的比例不高,表明大多数的主要成效已经落到实处了;

2.
里头在sonar定义级其他症结,主要集中在代码规范和单元测试覆盖率,说南陈码品质有待压实;

3.
本子测试的初期时间较足够,中期随着开发提交成功的功效点增多,BUG数量增多,剩余测试时间变得魂不附体;

4.
在本子测试时期,发现测试环境存在一遍代码被遮盖、一次因开发职员操作失误影响测试执行的意况;

小结:

测试人士应当不断反馈、创新、计算种种版本发生的难点(不管是缺点,还是经过中出现的),并对瑕疵进行辨析,总计出某个原理,协助开发职员建立杰出的习惯,立异代码的身分。

5 日常营业阶段测试

在经常营业阶段,开发人士、测试人士、QA职员重点做的事体,如下表所示:

阶段

开发人员

测试人员

QA人员

日常运营

生产故障登记

· 版本问题反馈和改进提议

· 生产故障分析

管理日常运营活动

万般运转阶段,并不是终止阶段,固然供给、开发、公布等级暂停活动,只要产品提供劳务,常常营业都存在着。

用作测试人士的首要实施如下:

本子难点反馈和革新建议

对常常运维发生的标题,总计汇报,提出革新提议,并且跟踪实施。

生产故障分析

扶持开发排查生产故障,防止测试场景的疏漏。

6 人力财富

软件测试并不是保险产质量量的最后一道防线,测试职员也不是,测试职员的干活全盘可以由尤其资深的开发职员来完结,可是现实总是凶恶的,近年来测试与开发的百分比为:1:3,在成熟的团队是那样子,别的一些还在时时刻刻革新的团伙,由于能源缺乏,大概去到1:7。开发职员在非常的短的一段时间内不容许完全代表测试人士,有个根本因素:思维方法各异,有句古话来形容:江山易改特性难移。当开发人士的沉思方法改变的时候,这就改为测试人士了,倒不如把测试人士独立出来更好,并且培育给开发职员一定的测试素养,这些对有限补助产品质量都是有帮带的。

全程软件测试实践,强调的是贯通每一种阶段的测试活动,不论是开发、依然测试,要掌握两者的移动价值,几时该做什么样工作,什么业务该到位如何水平才算好,保证各种环节的质地,才能够保证产品的全程品质,其它产品质量不是测试出来的,而是构建进度中沉淀下来的,开发人士的武术、测试人士的功力、以及团体对开发测试进程的重视程度,决定了产品质量。产品品质就不啻一块翻糖蛋糕,应当切分为小块,落到实处到各种人手里,让各种人尝到甜头,担当起来。

7 TQM(周详质管) in Software

那是3个延长与关系,进度如下:

一点资讯 11

TQM是以产质量量为宗旨,建立起一套科学严峻高效的品质种类,以提供满足用户供给的成品的整套活动.

在软件业,软件品质得不到抓好重点原因在于品质观念的缺点和失误,而将完美质量管理的合计运用于软件业,是坚实软件产质量量、获取竞争优势的得力手段。CMM不但对于辅导进程立异是一项很好的工具,而且把周详质管概念应用到软件上,完成从必要管理到品种布署、项目控制、软件取得、品质担保、配置管理的软件进度周到质量管理。CMM的考虑是百分百从消费者须要出发,从全公司层面上推行进度质量管理,正顺应了TQM的基本原则。因而,它的意思不仅是对软件开发的进程进度控制,最根本的它依旧一种高效的管制办法,有助于公司最大程度的减退资金,提升质量和用户满意度。

软件质管展现TQM的运行机制
软件质量管理是CMM四级中二个单身的KPA,其指标是使项目标软件质管活动是有安排的、软件出品的品质指标是量化的和遭受管理的。它服从了一揽子质管活动的正确程序—PDCA(Plan、Do、Check、Action),即四个等级:

(1)
布置:即分明品质指标以及贯彻那些指标须求接纳的不二法门。制定品质安顿是整个质管活动的基本功。国标对品质下的概念为:
品质是产品或劳务满意显然或包蕴需求力量的特征和特色的总额。

对于软件以来,软件品质则反映在品质特点上,ISO/IEC9126中规定了5个性能特点,即功效性、可信赖性、易用性、效能、可维护性和可一致性,每种性格包罗若干子天性。设定品质目的正是要找到用户的成色须求与这几个品质特点的相关性,并将其转会为付出进度中可衡量的技术目的或能力指标,作为质控的依照。

上述的六大特色属于软件的表面属性,与用户满意度直接有关,能够遵照公司的靶子和类其他特点建立品质模型,并行使一定的方式,如QFD(Quality
Function Deployment)、GQM(Goal Question
Metrics)等规定量化的身分目的,但那在事实上中国人民解放军海军事工业程学院业作中反复是非常复杂和难以获得的。因而,更常用的做法是以进度能力指标反映产品质量目的,一个第一名的力量目的便是缺点密度(即每单位规人体模特工作产品中留存的瑕疵数)和对应的阶段缺陷排错率,能够依照历史数据测度产品的范畴和目的缺陷密度,从而对每一种阶段发现的弱点数量进行控制。

(2) 实施
:即按约定布置、指标措施及其分工实际执行。为了在进程中央控制制软件的品质,需采纳对应的伎俩在预订的阶段点或里程碑上海展览中心开软件工作产品质量的度量,常用的法门有
同行业评比审、原型评价、测试等。那一个主意主要从两方面对软件的质量开展衡量,一是个中属性,即经过和平运动动笔者能够衡量的属性,例如工作产品的瑕疵密度
;二是外表属性,即与用户环境有关的性质,那么些属性在进度中多次难以衡量,只有通过在项指标后期引入用户测试来予以评价,而让用户参加开发进度,大大有利于产质量量的滋长。

(3) 检查
:即把执行的结果和安排的须求比较,检查安顿的执行景况和执行的功力,是或不是达到预期的对象,并找出原因。在对质量衡量的结果进行剖析时,往往会用到有的总计工具和措施,如检查表、直方图、控制图、Pareto图、散布图、因果图、运维图等。那个工具得以协助显然难题、评估现状、发现原因依然形成下一步措施。

(4) 处理
:即下结论经验教训,将未缓解的题材作为下一阶段制虞升卿插的依据。CMM必要对软件品质度量的结果分析后,应“接纳适度的与软件品质布置相平等的办法,以便使得产品的质量衡量结果与软件质量指标相适合”。


瞩望对你公司IT软件研发与质管有支持。 其余您或许感兴趣的稿子:
迅速软件品质担保的办法与执行
营造快速的研究开发与自动化运营
IT运转监察和控制消除方案介绍
IT持续集成之品管
红颜集团环境与商店文化
店铺绩效管理种类之平衡记分卡
供销社文化、团队文化与学识共享
高功效的团体建设
协会目的与私家目的
膳食连锁店铺IT音讯解决决方案一

如有想询问更加多软件研究开发 , 系统 IT集成 , 集团新闻化,项目管理,企管等情报,请关心本人的微信订阅号:

一点资讯 12

 

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
正文版权归小编和天涯论坛共有,欢迎转发,但未经作者同意必须保留此段评释,且在篇章页面分明地方给出原文连接,否则保留追究法律权利的职责。
该小说也同时发布在自身的独门博客中-Petter Liu
Blog

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图